V1.56.0: HTTP Serve exits directly after starting

What is the problem you are having with rclone?

When I started to validate rclone 1.56.0 for RCX, the serve http command does not seem to work. Reproducing it on desktop shows that rclone is started and then exits without error (exit code 0).

Has there been some command change or is this bug?

What is your rclone version (output from rclone version)

rclone v1.56.0
- os/version: Microsoft Windows 10 Education 2009 (64 bit)
- os/kernel: 10.0.19043.1110 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.16.5
- go/linking: dynamic
- go/tags: cmount

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Win 10 x64

Which cloud storage system are you using? (eg Google Drive)

Tested with local, probably any.

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone.exe -vvv serve http --addr 127.0.0.1:8080 .

Edit: I initially wrote webdav - but that runs fine.

The rclone config contents with secrets removed.

(none)

A log from the command with the -vv flag

2021/07/20 22:21:40 DEBUG : rclone: Version "v1.56.0" starting with parameters ["C:\\Users\\x0b\\apps\\rclone\\rclone.exe" "-vvv" "serve" "http" "--addr" "127.0.0.1:8080" "."]
2021/07/20 22:21:40 DEBUG : Creating backend with remote "."
2021/07/20 22:21:40 DEBUG : Using config file from "C:\\Users\\x0b\\.config\\rclone\\rclone.conf"
2021/07/20 22:21:40 DEBUG : fs cache: renaming cache item "." to be canonical "//?/C:/Users/x0b"
2021/07/20 22:21:40 INFO  : Local file system at //?/C:/Users/x0b: poll-interval is not supported by this remote
2021/07/20 22:21:40 INFO  :
Transferred:              0 / 0 Byte, -, 0 Byte/s, ETA -
Elapsed time:         0.2s

2021/07/20 22:21:40 DEBUG : 3 go routines active

Is that the full log?

Testing I get:

rclone -vvv serve webdav --addr 127.0.0.1:8585 .
2021/07/20 16:36:29 DEBUG : Setting --config "/opt/rclone/rclone.conf" from environment variable RCLONE_CONFIG="/opt/rclone/rclone.conf"
2021/07/20 16:36:29 DEBUG : Setting --user-agent "animosityapp" from environment variable RCLONE_USER_AGENT="animosityapp"
2021/07/20 16:36:29 DEBUG : Setting --rc-user "felix" from environment variable RCLONE_RC_USER="felix"
2021/07/20 16:36:29 DEBUG : Setting --rc-pass "felix" from environment variable RCLONE_RC_PASS="felix"
2021/07/20 16:36:29 DEBUG : Setting default for drive-pacer-min-sleep="10ms" from environment variable RCLONE_DRIVE_PACER_MIN_SLEEP
2021/07/20 16:36:29 DEBUG : Setting default for drive-pacer-burst="1000" from environment variable RCLONE_DRIVE_PACER_BURST
2021/07/20 16:36:29 DEBUG : rclone: Version "v1.56.0" starting with parameters ["rclone" "-vvv" "serve" "webdav" "--addr" "127.0.0.1:8585" "."]
2021/07/20 16:36:29 DEBUG : Creating backend with remote "."
2021/07/20 16:36:29 DEBUG : Using config file from "/opt/rclone/rclone.conf"
2021/07/20 16:36:29 DEBUG : fs cache: renaming cache item "." to be canonical "/home/felix"
2021/07/20 16:36:29 INFO  : Local file system at /home/felix: poll-interval is not supported by this remote
2021/07/20 16:36:29 NOTICE: Local file system at /home/felix: WebDav Server started on http://127.0.0.1:8585/

http, not webdav :slight_smile:

I only saw it with http.

Sorry to all, I posted the wrong command

Do you have the command you are running and a debug log? I copied your command above.

The debug log is correct, I just accidentally copied my attempt to reproduce this with webdav :see_no_evil:

So the actual command is in the first post? I'm confused. Did you change something?

Sorry again for the confusion - I initially messed up copying the command and instead copied my own attempt of with webdav :roll_eyes:. The log was the correct one.

I've since fixed the command, but here it is again to avoid any further confusion:

rclone.exe -vvv serve http --addr 127.0.0.1:8080 .

When you edit something, no one knows what was changed so it's impossible to tell. It's best to just follow up with a change as everyone can see it.

I got the same thing you get so I'd imagine it's a bug as it works fine for me as well on the previous version.

Log a bug on github for it.

Thanks for verifying this, I wasn't sure since I imagined this would be caught by tests. I'll create a GitHub issue.

Yep as it does seem like a strange one!