BSD support #18

ncw · 2017-10-09T11:07:28Z

An rclone user requested that rclone mount support openbsd.

OpenBSD apparently supports fuse and libfuse now so maybe cgofuse could too?

billziss-gh · 2017-10-09T18:49:43Z

OpenBSD apparently supports fuse and libfuse now so maybe cgofuse could too?

Likely, but it would mean setting up and testing against a system that I have never used.

Does rclone currently support OpenBSD (outside the mount command)?

ncw · 2017-10-10T09:09:05Z

Does rclone currently supports OpenBSD (outside the mount command)?

It does yes. However I don't test against OpenBSD, and I think building a native binary will be difficult.

Unfortunately it seems like xgo doesn't support OpenBSD though which would make creating automated builds very difficult.

billziss-gh · 2017-10-10T21:38:03Z

It might be nice to build BSD support, but I agree that without xgo builds would be difficult. We would probably have to also update xgo to support BSD.

I might look into all this in the future, especially if you get more than one person asking for it. I am rather short on time right now though.

krytarowski · 2017-10-13T13:21:12Z

I'm interested in NetBSD port.

billziss-gh · 2017-10-13T16:29:23Z

@krytarowski does NetBSD support FUSE? Can you point me to good documentation?

Would you have the time to contribute any changes?

A search finds this: https://www.netbsd.org/docs/puffs/

krytarowski · 2017-10-13T17:01:11Z

NetBSD supports 3 implementations for fuse: fuse, perfuse, refuse.

They vary in the scope of implementation. I recall that one of them is using just high-level interfaces, the other one attempted to support both, and the third one aimed to reuse upstream libfuse library with local patches.

krytarowski · 2017-10-13T17:02:58Z

I would get one that is completed, fully-featured and fully-compatible with the world. I hope that one of them can work with cgofuse.

billziss-gh · 2017-10-13T17:14:17Z

Reading a bit through the NetBSD docs it seems that librefuse is the way to go. One problem is that it only support the FUSE high-level API and I did have ideas of one day adding FUSE low-level support to cgofuse (once I get it in WinFsp that is).

So we have so far:

NetBSD: librefuse
OpenBSD: libfuse
FreeBSD: ???

Also very importantly we would have to get xgo support for these platforms in order to easily cross-compile and that is a major undertaking. I will shoot a message to the xgo project and see what they are thinking.

krytarowski · 2017-10-13T17:25:56Z

https://wiki.freebsd.org/WhatsNew/FreeBSD10 notes libfuse work.. but there is an option for wait for requests.

billziss-gh · 2017-10-13T18:00:19Z

FreeBSD information is somewhat contradicting. It does appear that there is good FUSE support in FreeBSD 10 and 11, but good documentation on how to load and use it is lacking. See, for example:

https://forums.freebsd.org/threads/54672/

krytarowski · 2017-10-13T21:38:04Z

I've never installed FreeBSD, no insight from me.

billziss-gh · 2018-05-20T00:38:16Z

My first attempt at porting cgofuse to FreeBSD is in commit 0acc17d (currently in the freebsd branch).

Most things seem to work:

General file system use, although no rigorous testing has been done.
Cleanly unmounting the file system.

A notable exception is that signal handling seems to not be working properly. It is unclear currently why this is the case.

billziss-gh · 2018-05-20T17:23:07Z

Attempting to troubleshoot the signal handling problem in FreeBSD, I am finding that the go runtime does not appear to set signal handlers for SIGINT, SIGTERM, etc. under FreeBSD (it does under Darwin).

I added the following code in hostMount immediately before calling fuse_main_real:

    struct sigaction sa;
    memset(&sa, 0, sizeof sa);
    sigaction(SIGTERM, 0, &sa);
    fprintf(stderr, "sa.handler=%p\n", sa.sa_handler);

This prints on Darwin:

sa.handler=0x403c840

And on FreeBSD we get 0.

sa.handler=0x0

I believe the FreeBSD response to be incorrect. Shouldn't the Go runtime set its own signal handlers, especially when using os/signal?

billziss-gh · 2018-05-20T17:50:30Z

Additional information: I traced the system calls during memfs startup using truss and only kept traces related to sigaction and SIGTERM:

sigaction(SIGTERM,0x0,{ SIG_DFL 0x0 ss_t })      = 0 (0x0)                             <1>
sigaction(SIGTERM,{ 0x4556c0 SA_ONSTACK|SA_RESTART|SA_SIGINFO ss_t },0x0) = 0 (0x0)    <1>
sigaction(SIGTERM,0x0,{ 0x4556c0 SA_ONSTACK|SA_RESTART|SA_SIGINFO ss_t }) = 0 (0x0)    <2>
sa.handler=0x0                                                                         <2>
sigaction(SIGTERM,0x0,{ 0x4556c0 SA_ONSTACK|SA_RESTART|SA_SIGINFO ss_t }) = 0 (0x0)    <3>
sigaction(SIGTERM,{ 0x800bc0d90 SA_SIGINFO ss_t },{ 0x4556c0 SA_ONSTACK|SA_RESTART|SA_SIGINFO ss_t }) = 0 (0x0)    <3>

My analysis:

<1>: the Go runtime tests and sets a SIGTERM handler. It uses the SA_ONSTACK|SA_RESTART flags.

<2>: The modified hostMount executes sigaction and fprintf(stderr). It finds no SIGTERM handler.

<3>: Libfuse executes fuse_set_signal_handlers. It also finds no SIGTERM handler and for this reason it sets its own.

I cannot explain why after SIGTERM is set by the Go runtime, FreeBSD then reports that it is not set.

EDIT: for completeness I checked both sa_handler and sa_sigaction, although my understanding is that they overlap on FreeBSD. Both fields were 0:

sa.sa_handler=0x0, sa.sa_sigaction=0x0

billziss-gh · 2018-05-20T19:03:46Z

I have merged into master, although I cannot cut a release as signal handling remains broken in FreeBSD.

krytarowski · 2018-05-21T02:19:10Z

Good progress.. it's worth to discuss it with upstream go developers.

billziss-gh · 2018-06-06T00:31:44Z

I believe I have found the reason for the "mysterious" sigaction behavior. I also believe that it is a Golang problem and I will report it as such.

The following simple cgo program:

package main

/*
#include <stdio.h>
#include <signal.h>

static void sigprint(int sig) {
	struct sigaction sa;
	int ret = sigaction(sig, 0, &sa);
	fprintf(stderr, "ret=%d handler=%p\n", ret, sa.sa_handler);
}
*/
import "C"
import "syscall"

func main() {
	C.sigprint(C.int(syscall.SIGTERM))
}

Succeeds (prints non-0) on Darwin and Linux:

$ go run sigbug.go
ret=0 handler=0x4034150

But fails (prints 0) on FreeBSD:

$ go run sigbug.go
ret=0 handler=0x0

The reason that this happens is that the Go runtime invokes sigaction using SYSCALL. However FreeBSD expects that C (and cgo) programs should use the libc sigaction, which is "interposed" by libthr to __thr_sigaction. Libthr maintains its own copy of sigaction's and overrides what the kernel returns.

A likely fix for this is to do what Linux does for sigaction. Invoke it using SYSCALL if "!cgo" or use the C library sigaction if "cgo". See rt_sigaction.

billziss-gh · 2018-06-06T03:31:11Z

Turns out this is fixed on the current go repo tip. So the FreeBSD port should work without problems once Go 1.11 is out.

krytarowski · 2018-06-06T06:47:52Z

NetBSD wants to obsolete syscall(2) as this isn't that much portable across CPUs. Ideally we would call C symbols in C.

billziss-gh · 2018-06-10T06:38:47Z

I ended up adding support for OpenBSD in commit c3f5fa1. NetBSD support will have to wait for the next rainy Saturday :)

This support is experimental. It has known issues that stem from the differences in the OpenBSD libfuse implementation from the reference libfuse implementation.
- Signal handling is broken due to a bug in the OpenBSD implementation of fuse_set_signal_handlers.
- Option parsing may fail because the fuse_opt_parse function is not fully compatible with the one in libfuse.

An additional caveat is that in OpenBSD only root can mount and unmount FUSE file systems. There used to be a kern.usermount option, which allowed non-root users to mount file systems, but it was removed in OpenBSD 6 [link].

Finally note that because of the lack of a CI solution for BSD, it will be hard for me to maintain all these ports. I expect that bitrot will eventually set in for the BSD ports.

billziss-gh · 2018-06-26T21:53:12Z

I am on vacation and slightly jetlagged so I am working on NetBSD support. Will see where I get :)

In other news I have created Poor Man's CI for testing the BSD ports. It runs on the Google Cloud and currently supports FreeBSD. Will try to add NetBSD and OpenBSD support for it.

krytarowski · 2018-06-26T21:55:17Z

good progress!

billziss-gh · 2018-06-26T21:59:26Z

@krytarowski good to hear from you.

BTW, how do I get Go 1.10 for NetBSD? Do I have to build it myself? (Even if that is the case I still need a bootstrap Go for NetBSD from somewhere.)

krytarowski · 2018-06-26T22:03:19Z

The typical way is to get pkgsrc. lang/go is 1.10.3 http://pkgsrc.se/lang/go

pkgsrc.org has some instructions.

Please note that there might be need to install mozilla-rootcerts for https.

billziss-gh · 2018-06-26T22:14:48Z

Hmmm... I was misled by the list linked below, which does not appear to list a Go(?):

http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/README.html

I just tried the following and it worked.

export PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/x86_64/7.1.2/All"
pkg_add -v go

billziss-gh · 2018-06-26T22:21:30Z

I indeed needed mozilla-rootcerts to be able to git clone. Thanks for the pointer.

krytarowski · 2018-06-26T22:46:22Z

go is in lang, not devel.

billziss-gh · 2018-06-26T23:32:19Z

Makes sense. Just learning my way around NetBSD, hence the n00b mistake.

BTW, I got this to the point of passing most basic smoke tests, but have to troubleshoot a SIGSEGV, while calling fuse_opt_free_args. Getting very late now and the jetlag "boost" is gone, I will continue tomorrow.

billziss-gh · 2018-06-27T18:49:41Z

NetBSD support was added in commit 3bc5ead.

krytarowski · 2018-06-27T20:16:17Z

This looks great! Thank you.

billziss-gh · 2018-06-28T12:56:00Z

@krytarowski I am attempting to add NetBSD support to Poor Man's CI so that I can regularly test the NetBSD port using the Google Compute Engine.

I am currently using NetBSD 8.0_RC2, but I am not clear on how I should setup my PKG_PATH. I currently have it set as ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/8.0_current/All, but I get warnings such as:

pkg_add: Warning: package `curl-7.55.1nb1' was built for a platform:
pkg_add: NetBSD/x86_64 8.99.1 (pkg) vs. NetBSD/x86_64 8.0_RC2 (this host)

Any pointers on what PKG_PATH I should use for 8.0_RC2? I did try replacing 8.0_current with 8.0_RC2, but that did not work.

krytarowski · 2018-06-28T13:19:29Z

Please try: http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/8.0_2018Q1/All/

8.99.1 is NetBSD-current and 8.0 was branched a year ago.

billziss-gh · 2018-06-28T13:24:27Z

Thank you. This works without warnings.

krytarowski · 2018-06-28T16:54:35Z

Thank you for the port! I wonder whether perfuse would work better in NetBSD... we tend to have too many features for the same thing. 3 fuse implementations.

billziss-gh · 2018-06-28T19:00:56Z

There are indeed 3 choices in NetBSD.

The canonical one is libpuffs, which best represents the kernel capabilities. However it does not have a FUSE compatible interface and therefore can not easily be used by cgofuse.
The librefuse implementation is a FUSE compatibility layer on top of PUFFS. It appears to be the natural choice for cgofuse.
The perfuse implementation is an emulation of the /dev/fuse linux kernel interface using an external daemon perfused. This is useful to FUSE "low-level" file systems, but introduces an unnecessary extra layer for cgofuse thus adding complexity and inefficiency.

I think that despite some incompatibilities librefuse is the right choice.

krytarowski · 2018-06-28T19:22:00Z

I see. Thank you for making it clear.

From a NetBSD developer point of view perhaps it looks like it would be the best to sync the kernel capabilities with Linux and get feature parity in libpuffs.. and keep an option for RUMP/PUFFS users with librefuse and export there low-level parts.

The libperfuse option can be kept around as an intermediate form to get the job done on NetBSD.

Your work is highly appreciated and thank you for the NetBSD port!

billziss-gh · 2018-06-28T19:24:19Z

@krytarowski you are welcome :)

billziss-gh · 2018-06-29T23:21:45Z

@krytarowski sorry to bother you again. I am facing a NetBSD failure while doing Continuous Integration using Poor Man's CI.

I note that cgofuse compiles and runs fine under NetBSD 7.1.2 (on my local VM) but fails when run under NetBSD 8.0_RC2 in the Google Cloud.

Here is the build log:

+ export GOPATH=/tmp/go
+ mkdir -p /tmp/go/src/github.com/billziss-gh
+ cp -R /tmp/repo/cgofuse /tmp/go/src/github.com/billziss-gh
+ cd /tmp/go/src/github.com/billziss-gh/cgofuse
+ go build -v ./...
github.com/billziss-gh/cgofuse/fuse
# github.com/billziss-gh/cgofuse/fuse
In file included from /usr/include/puffs.h:44:0,
                 from /usr/include/fuse.h:41,
                 from fuse/host_cgo.go:51:
/usr/include/fs/puffs/puffs_msgif.h:595:2: error: unknown type name 'register_t'
  register_t  pvnr_retval;  /* IN */
  ^
In file included from /usr/include/fuse.h:41:0,
                 from fuse/host_cgo.go:51:
/usr/include/puffs.h:225:27: error: unknown type name 'register_t'
      puffs_cookie_t, int, register_t *);
                           ^
/usr/include/puffs.h:436:1: error: unknown type name 'register_t'
 PUFFSOP_PROTOS(puffs_null) /* XXX */
 ^
/usr/include/puffs.h:505:20: error: unknown type name 'vsize_t'
        enum vtype, vsize_t, dev_t); 
                    ^
github.com/billziss-gh/cgofuse/examples/shared

BUILD FAILURE

Do you have any idea what the missing register_t and vsize_t C symbols are and why this problem happens on 8.0_RC2 but not 7.1.2?

billziss-gh · 2018-06-29T23:35:38Z

BTW, the PMCI integration is currently in the netbsd branch.

krytarowski · 2018-06-30T01:49:28Z

If this is a C code, please check -D_KERNTYPES or some equivalent like #define _KERNTYPES before including headers.

billziss-gh · 2018-06-30T12:18:31Z

Thanks for the hint. Adding -D _KERNTYPES does indeed allow cgofuse to be built on NetBSD 8.0_RC2.

(As a user of NetBSD I would argue that this should be considered a problem. The need for _KERNTYPES is not documented in the refuse(3) man page. Furthermore users of FUSE on other systems would likely not know about _KERNTYPES.)

In any case I hit an even more serious problem when trying to run some of the cgofuse smoke tests. It does not look that Go 1.10 is ready for use on NetBSD 8.0_RC2 yet :(

It looks like I will have to shelve doing CI for NetBSD, until 8.0 and its associated tooling has matured a bit more. @krytarowski thank you for your help on this.

+ export GOPATH=/tmp/go
+ mkdir -p /tmp/go/src/github.com/billziss-gh
+ cp -R /tmp/repo/cgofuse /tmp/go/src/github.com/billziss-gh
+ cd /tmp/go/src/github.com/billziss-gh/cgofuse
+ go build -v ./...
github.com/billziss-gh/cgofuse/fuse
github.com/billziss-gh/cgofuse/examples/hellofs
github.com/billziss-gh/cgofuse/examples/shared
github.com/billziss-gh/cgofuse/examples/memfs
github.com/billziss-gh/cgofuse/examples/passthrough
+ go test -v ./fuse -run 'TestUnmount|TestSignal'
=== RUN   TestUnmount
reqid: 0, opclass 1, optype: PUFFS_VFS_UNMOUNT, cookie: 0x0,
    aux: 0x702e1132c038, auxlen: 64, pid: 730, lwpid: 6
    since previous call: 1530360048.176428
fatal: morestack on g0
SIGTRAP: trace trap
PC=0x456282 m=0 sigcode=1
signal arrived during cgo execution

goroutine 8 [running, locked to thread]:
runtime.morestack()
	/usr/pkg/go/src/runtime/asm_amd64.s:451 +0x22 fp=0x702e1173fd00 sp=0x702e1173fcf8 pc=0x456282
created by github.com/billziss-gh/cgofuse/fuse.testHost
	/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:76 +0x278

goroutine 1 [chan receive]:
testing.(*T).Run(0xc4200a40f0, 0x54d4d0, 0xb, 0x555148, 0x46b1b6)
	/usr/pkg/go/src/testing/testing.go:825 +0x301
testing.runTests.func1(0xc4200a4000)
	/usr/pkg/go/src/testing/testing.go:1063 +0x64
testing.tRunner(0xc4200a4000, 0xc420051df8)
	/usr/pkg/go/src/testing/testing.go:777 +0xd0
testing.runTests(0xc42000c060, 0x7fad20, 0x3, 0x3, 0x411779)
	/usr/pkg/go/src/testing/testing.go:1061 +0x2c4
testing.(*M).Run(0xc42008e000, 0x0)
	/usr/pkg/go/src/testing/testing.go:978 +0x171
main.main()
	_testmain.go:46 +0x151

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
	/usr/pkg/go/src/runtime/sigqueue.go:139 +0xa6
os/signal.loop()
	/usr/pkg/go/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.0
	/usr/pkg/go/src/os/signal/signal_unix.go:28 +0x41

goroutine 6 [syscall]:
github.com/billziss-gh/cgofuse/fuse._Cfunc_hostUnmount(0x702e11310200, 0x702e1130b080, 0x0)
	_cgo_gotypes.go:554 +0x4d
github.com/billziss-gh/cgofuse/fuse.c_hostUnmount.func1(0x702e11310200, 0x702e1130b080, 0x702e1130b080)
	/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_cgo.go:704 +0x60
github.com/billziss-gh/cgofuse/fuse.c_hostUnmount(0x702e11310200, 0x702e1130b080, 0x702e1130b080)
	/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_cgo.go:704 +0x35
github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Unmount(0xc420010840, 0x0)
	/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:686 +0x4c
github.com/billziss-gh/cgofuse/fuse.testHost(0xc4200a40f0, 0x457c01)
	/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:82 +0x2ad
github.com/billziss-gh/cgofuse/fuse.TestUnmount(0xc4200a40f0)
	/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:102 +0x30
testing.tRunner(0xc4200a40f0, 0x555148)
	/usr/pkg/go/src/testing/testing.go:777 +0xd0
created by testing.(*T).Run
	/usr/pkg/go/src/testing/testing.go:824 +0x2e0

goroutine 9 [chan receive]:
github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Mount.func3(0xc420010840, 0xc420060300)
	/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:659 +0x41
created by github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Mount
	/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:658 +0x3eb

goroutine 10 [select, locked to thread]:
runtime.gopark(0x555690, 0x0, 0x54c6f3, 0x6, 0x18, 0x1)
	/usr/pkg/go/src/runtime/proc.go:291 +0x11a
runtime.selectgo(0xc42002ef50, 0xc4200603c0)
	/usr/pkg/go/src/runtime/select.go:392 +0xe50
runtime.ensureSigM.func1()
	/usr/pkg/go/src/runtime/signal_unix.go:549 +0x200
runtime.goexit()
	/usr/pkg/go/src/runtime/asm_amd64.s:2361 +0x1

rax    0x17
rbx    0x80ea40
rcx    0x459d95
rdx    0x0
rdi    0x2
rsi    0x54fce6
rbp    0xc420040a28
rsp    0x702e1173fcf8
r8     0xc420001980
r9     0xc420001980
r10    0xc42001a070
r11    0x212
r12    0x0
r13    0x10000000
r14    0x0
r15    0x702e1132c000
rip    0x456282
rflags 0x216
cs     0x47
fs     0x0
gs     0x0
FAIL	github.com/billziss-gh/cgofuse/fuse	3.419s

BUILD FAILURE

krytarowski · 2018-06-30T12:52:37Z

We were fixing Go in their HEAD branch.. is it possible to check Go from the HEAD?

krytarowski · 2018-06-30T13:06:24Z

I propose to file the _KERNTYPES issue to gnats. netbsd.org -> support -> report a bug

If Go is still broken in their HEAD or 1.11, please file a bug for it too.

billziss-gh · 2018-06-30T13:09:54Z

We were fixing Go in their HEAD branch.. is it possible to check Go from the HEAD?

Yes. I will look into it.

billziss-gh · 2018-06-30T13:40:56Z

Ok. I compiled my own Go from golang/go tip. Unfortunately not all tests passed, but I will try to use it for building cgofuse on NetBSD 8.0_RC2 nevertheless.

billziss-gh · 2018-06-30T14:52:23Z

@krytarowski unfortunately the problem persists with latest go :(

builder0# uname -a
NetBSD builder0.c.poor-mans-ci.internal 8.0_RC2 NetBSD 8.0_RC2 (GENERIC) #0: Mon Jun 25 13:01:26 UTC 2018  mkrepro@mkrepro.NetBSD.org:/
usr/src/sys/arch/amd64/compile/GENERIC amd64
builder0# go version
go version devel +0dc814cd7f Sat Jun 30 01:04:30 2018 +0000 netbsd/amd64
builder0# git checkout netbsd
Branch 'netbsd' set up to track remote branch 'netbsd' from 'origin'.
Switched to a new branch 'netbsd'
builder0# go build ./...
builder0# go test -v ./fuse
=== RUN   TestUnmount
reqid: 0, opclass 1, optype: PUFFS_VFS_UNMOUNT, cookie: 0x0,
    aux: 0x700f8132c038, auxlen: 64, pid: 1311, lwpid: 6
    since previous call: 1530370183.602584
fatal: morestack on g0
SIGTRAP: trace trap
PC=0x45a182 m=0 sigcode=1
signal arrived during cgo execution

goroutine 8 [running, locked to thread]:
runtime.abort()
        /usr/pkg/go-custom/src/runtime/asm_amd64.s:840 +0x2 fp=0x700f812ffcf8 sp=0x700f812ffcf0 pc=0x45a182
runtime.morestack()
        /usr/pkg/go-custom/src/runtime/asm_amd64.s:397 +0x25 fp=0x700f812ffd00 sp=0x700f812ffcf8 pc=0x458835
created by github.com/billziss-gh/cgofuse/fuse.testHost
        /root/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:76 +0x26f

goroutine 1 [chan receive]:
testing.(*T).Run(0xc000092100, 0x5530aa, 0xb, 0x55af40, 0x46d486)
        /usr/pkg/go-custom/src/testing/testing.go:879 +0x37a
testing.runTests.func1(0xc000092000)
        /usr/pkg/go-custom/src/testing/testing.go:1119 +0x78
testing.tRunner(0xc000092000, 0xc000083e08)
        /usr/pkg/go-custom/src/testing/testing.go:827 +0xbf
testing.runTests(0xc00000c060, 0x842b00, 0x3, 0x3, 0x40dc8f)
        /usr/pkg/go-custom/src/testing/testing.go:1117 +0x2a2
testing.(*M).Run(0xc00008e000, 0x0)
        /usr/pkg/go-custom/src/testing/testing.go:1034 +0x165
main.main()
        _testmain.go:46 +0x13d

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
        /usr/pkg/go-custom/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
        /usr/pkg/go-custom/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
        /usr/pkg/go-custom/src/os/signal/signal_unix.go:29 +0x41
goroutine 6 [syscall]:
github.com/billziss-gh/cgofuse/fuse._Cfunc_hostUnmount(0x700f81310200, 0x700f8130b080, 0x0)
        _cgo_gotypes.go:554 +0x4d
github.com/billziss-gh/cgofuse/fuse.c_hostUnmount.func1(0x700f81310200, 0x700f8130b080, 0x700f8130b080)
        /root/go/src/github.com/billziss-gh/cgofuse/fuse/host_cgo.go:704 +0x60
github.com/billziss-gh/cgofuse/fuse.c_hostUnmount(0x700f81310200, 0x700f8130b080, 0x700f8130b080)
        /root/go/src/github.com/billziss-gh/cgofuse/fuse/host_cgo.go:704 +0x35
github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Unmount(0xc0000507c0, 0x0)
        /root/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:686 +0x4a
github.com/billziss-gh/cgofuse/fuse.testHost(0xc000092100, 0x344801)
        /root/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:82 +0x2a4
github.com/billziss-gh/cgofuse/fuse.TestUnmount(0xc000092100)
        /root/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:102 +0x30
testing.tRunner(0xc000092100, 0x55af40)
        /usr/pkg/go-custom/src/testing/testing.go:827 +0xbf
created by testing.(*T).Run
        /usr/pkg/go-custom/src/testing/testing.go:878 +0x353
goroutine 9 [chan receive]:
github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Mount.func3(0xc0000507c0, 0xc00005e300)
        /root/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:659 +0x41
created by github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Mount
        /root/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:658 +0x3d2
rax    0x17
rbx    0x856a00
rcx    0x45c145
rdx    0x0
rdi    0x2
rsi    0x5558f4
rbp    0xc000044a50
rsp    0x700f812ffcf0
r8     0x32
r9     0x32
r10    0x2
r11    0x212
r12    0x0
r13    0x10000000
r14    0x0
r15    0x700f8132c000
rip    0x45a182
rflags 0x216
cs     0x47
fs     0x0
gs     0x0
FAIL    github.com/billziss-gh/cgofuse/fuse     3.389s

krytarowski · 2018-06-30T14:56:36Z

I see, thank you for the test. Please report it on gnats!

mount is not supported by rclone for openBSD, see: winfsp/cgofuse#18

mount is not supported by rclone for NetBSD, see: winfsp/cgofuse#18

ncw mentioned this issue Oct 9, 2017

Feature request: mount command for OpenBSD rclone/rclone#1727

Open

billziss-gh added the enhancement label Oct 10, 2017

billziss-gh changed the title ~~OpenBSD support?~~ BSD support? Oct 13, 2017

billziss-gh changed the title ~~BSD support?~~ BSD support Oct 13, 2017

billziss-gh mentioned this issue Oct 13, 2017

BSD Support karalabe/xgo#91

Open

billziss-gh mentioned this issue Jun 6, 2018

runtime: sigaction problem when using cgo on FreeBSD golang/go#25745

Closed

billziss-gh closed this as completed Sep 10, 2019

kapitainsky added a commit to kapitainsky/RcloneBrowser that referenced this issue Nov 23, 2019

disable mount for openBSD

c89fb2d

mount is not supported by rclone for openBSD, see: winfsp/cgofuse#18

kapitainsky added a commit to kapitainsky/RcloneBrowser that referenced this issue Nov 23, 2019

disable mount for openBSD

816bcdf

mount is not supported by rclone for openBSD, see: winfsp/cgofuse#18

kapitainsky added a commit to kapitainsky/RcloneBrowser that referenced this issue Nov 23, 2019

disable mount for openBSD

eeebfd1

mount is not supported by rclone for openBSD, see: winfsp/cgofuse#18

kapitainsky added a commit to kapitainsky/RcloneBrowser that referenced this issue Nov 23, 2019

disable mount on openBSD

ff8e3a5

mount is not supported by rclone for openBSD, see: winfsp/cgofuse#18

kapitainsky added a commit to kapitainsky/RcloneBrowser that referenced this issue Nov 23, 2019

disable mount on NetBSD

1ab37fe

mount is not supported by rclone for NetBSD, see: winfsp/cgofuse#18

BSD support #18

BSD support #18

Comments

ncw commented Oct 9, 2017

billziss-gh commented Oct 9, 2017 • edited Loading

ncw commented Oct 10, 2017

billziss-gh commented Oct 10, 2017

krytarowski commented Oct 13, 2017

billziss-gh commented Oct 13, 2017 • edited Loading

krytarowski commented Oct 13, 2017

krytarowski commented Oct 13, 2017 • edited Loading

billziss-gh commented Oct 13, 2017 • edited Loading

krytarowski commented Oct 13, 2017

billziss-gh commented Oct 13, 2017

krytarowski commented Oct 13, 2017

billziss-gh commented May 20, 2018

billziss-gh commented May 20, 2018

billziss-gh commented May 20, 2018 • edited Loading

billziss-gh commented May 20, 2018

krytarowski commented May 21, 2018

billziss-gh commented Jun 6, 2018

billziss-gh commented Jun 6, 2018

krytarowski commented Jun 6, 2018

billziss-gh commented Jun 10, 2018 • edited Loading

billziss-gh commented Jun 26, 2018

krytarowski commented Jun 26, 2018

billziss-gh commented Jun 26, 2018

krytarowski commented Jun 26, 2018

billziss-gh commented Jun 26, 2018

billziss-gh commented Jun 26, 2018

krytarowski commented Jun 26, 2018

billziss-gh commented Jun 26, 2018

billziss-gh commented Jun 27, 2018

krytarowski commented Jun 27, 2018

billziss-gh commented Jun 28, 2018 • edited Loading

krytarowski commented Jun 28, 2018

billziss-gh commented Jun 28, 2018

krytarowski commented Jun 28, 2018

billziss-gh commented Jun 28, 2018

krytarowski commented Jun 28, 2018

billziss-gh commented Jun 28, 2018

billziss-gh commented Jun 29, 2018

billziss-gh commented Jun 29, 2018 • edited Loading

krytarowski commented Jun 30, 2018

billziss-gh commented Jun 30, 2018

krytarowski commented Jun 30, 2018

krytarowski commented Jun 30, 2018 • edited Loading

billziss-gh commented Jun 30, 2018

billziss-gh commented Jun 30, 2018

billziss-gh commented Jun 30, 2018

krytarowski commented Jun 30, 2018

billziss-gh commented Oct 9, 2017 •

edited

Loading

billziss-gh commented Oct 13, 2017 •

edited

Loading

krytarowski commented Oct 13, 2017 •

edited

Loading

billziss-gh commented Oct 13, 2017 •

edited

Loading

billziss-gh commented May 20, 2018 •

edited

Loading

billziss-gh commented Jun 10, 2018 •

edited

Loading

billziss-gh commented Jun 28, 2018 •

edited

Loading

billziss-gh commented Jun 29, 2018 •

edited

Loading

krytarowski commented Jun 30, 2018 •

edited

Loading