Sending SIGHUP kills rclone serve webdav. I also tested with mount and that does work as expected
What is your rclone version (output from rclone version)
rclone v1.53.4
- os/arch: darwin/amd64
- go version: go1.15.6
Which OS you are using and how many bits (eg Windows 7, 64 bit)
macOS 10.15.7
Which cloud storage system are you using? (eg Google Drive)
Local and crypt(local). Right now just testing.
The command you were trying to run (eg rclone copy /tmp remote:tmp)
rclone -vv serve --cache-dir cache/ --vfs-cache-mode full webdav testdir
The rclone config contents with secrets removed.
N/A. Just using command line since it's local and I am in testing mode.
A log from the command with the -vv flag
I don't think it is relevant for this based on what I am seeing but just in case...
$ rclone -vv serve --cache-dir cache/ --vfs-cache-mode full webdav testdir
2021/01/31 09:28:48 DEBUG : rclone: Version "v1.53.4" starting with parameters ["rclone" "-vv" "serve" "--cache-dir" "cache/" "--vfs-cache-mode" "full" "webdav" "testdir"]
2021/01/31 09:28:48 DEBUG : Creating backend with remote "testdir"
2021/01/31 09:28:48 DEBUG : Using config file from "/Users/<USER>/.config/rclone/rclone.conf"
2021/01/31 09:28:48 DEBUG : fs cache: renaming cache item "testdir" to be canonical "/Users/<USER>/WIP/testdir"
2021/01/31 09:28:48 INFO : Local file system at /Users/<USER>/WIP/testdir: poll-interval is not supported by this remote
2021/01/31 09:28:48 DEBUG : vfs cache: root is "/Users/<USER>/WIP/cache/vfs/local/Users/<USER>/WIP/testdir"
2021/01/31 09:28:48 DEBUG : vfs cache: metadata root is "/Users/<USER>/WIP/cache/vfs/local/Users/<USER>/WIP/testdir"
2021/01/31 09:28:48 DEBUG : Creating backend with remote "/Users/<USER>/WIP/cache/vfs/local/Users/<USER>/WIP/testdir"
2021/01/31 09:28:48 INFO : vfs cache: cleaned: objects 0 (was 0) in use 0, to upload 0, uploading 0, total size 0 (was 0)
2021/01/31 09:28:48 NOTICE: Local file system at /Users/<USER>/WIP/testdir: WebDav Server started on http://127.0.0.1:8080/
Then (macOS doesn't seem to have pidof)
$ ps aux |grep rclone # get the PID
$ kill -SIGHUP <PID>
Log:
Hangup: 1
Any thoughts? Like I said, this does work as expected when mounted.
My answer kind of depends on how hard it is and whether it is worth the effort. Personally, using a SIGHUP to do anything but (nicely) kill the process has always felt a bit wrong and like a hack for communicating. Using rc feels like the "right" way to do it.
With that said, I've never using the rc commands. I suspect it is pretty easy but the documentation always feels daunting and I haven't needed it...yet. So the SIGHUP is nice and easy.
Do you have a feel for how often this is used in mount? Do you agree with my assessment of it being a bit of an abuse of an "interput" signal to not interup? Would you even consider deprecating it? You never know what workflows will break
Until then, I will likely spend some time learning the rc interface when I have time. I spent the weekend learning about Unix Domain Sockets for my rclone credential holder so understanding the rc interface feels like a good next-step (BTW, you provided a very helpful answer when I asked about a credentials store but I wanted the excuse to learn something new so I did it my own way).
The SIGHUP was invented before the rc interface so seemed like a good idea at the time.
There are only 32 or 64 unix signals and in practice there are only a handful that you could re-purpose for your own use. You can't provide an argument with a signal either, so they are quite crude. They don't work on Windows either.
So in an alternate reality where the rc had been invented first, I don't think I would have ever made SIGHUP support.
Maybe there should be specific documentation about this in the vfs help? So how to do the equivalent of SIGHUP? That would make things easier I think.
I think most users use the rc now because you have finer control and it works on Windows.
Yes!
Ha! I can deprecate it, but if I removed it someones workflow would break, that is for sure!
Deprecating it is probably a good idea I think.
Nice!
When you've figured them out you can add support to them for the rc interface - that is something I would like!
Do you think you could please make a new issue on github about this so I don't forget about it?
