ctrl-c no longer works since 0.14.44

I keep syncthing running/open in a tmux window to see the console messages. This worked fine until 0.14.43, pressing ctrl-c immediately stops it with a “^C[XXXXX] 17:48:45 INFO: Exiting” message. Since build v0.14.44-rc.1 (including up to 0.14.45-rc.3) this no longer works, ctrl-c is simply ignored. Something changed :frowning:

Is this already a known issue, I couldn’t find anything in the bugtracker, but maybe I just don’t know the proper search words…

Thanks for help :slight_smile:


It still works for me.

Hmm… ok, but I tried now the mentioned official syncthing builds on amd64 and arm and have the problem. Just depack, set a symlink to the new syncthing binary, call with identical start script of config/dir again. Maybe I can’t change versions with same config like I do?

Strange :-/ Maybe someone has an idea/observation, otherwise I have to bisect between 0.14.43 and v0.14.44-rc.1 and see to what commit it leads to…

So .43 still works if you download it and run it in the same environment?


v0.14.43 teamcity@build.syncthing.net 2017-12-29 21:23:06 UTC is fine,

v0.14.44-rc.1 teamcity@build.syncthing.net 2018-01-15 17:11:14 UTC is broken

what changed between them?

Nothing related.

So I tried different CPU architectures, standalone or in a Docker container, different Linux flavours… and attached you see syncthing running in Termux on a Tablet(!). The behaviour is always the same, ctrl-c on 0.14.43 works immediately, on 0.14.44 I can press ctrl-c as I want … see screenshots.

Yeah, odd. I don’t have arm64, but the same build on linux-amd64 doesn’t have any issues like this that I can tell. I suspect something odd in your environment, though I can’t off hand imagine what it would be.

See what happens if you send it a signal using kill and the PID, from another terminal.

also tried on amd64, also tried on arm 32-bit.

Tell me I’m crazy…

ps aux |grep syncthing

kill $PID

The “INFO: Exiting” message appears immediately and syncthing terminates, console text output after the ^C^C^C^C^C.

So it reacts correctly to signals, it just doesn’t receive one. I think the culprit is the change that lowers the niceness level, which for Linux thread reasons plays around with process groups and apparently affects signals from the shell. My bash must be doing something different than your shell.

There’s an advanced config in the options section called something like “don’t lower prio” - set that and see what happens.

We have a winner!

When I disable “Set Low Priority” in Options it works again, tested on arm64 and amd64.

My wild guess would be that I have some other config option that triggers this problem for me on all platforms and runtime combinations, for example I have auto-update disabled everywhere, or something like that.

Thanks for the help! I gotta go to bed now it’s already midnight…

Workaround wise, either keep that option unset, or don’t use -no-restart.

I don’t auto-update because unpredictable version (and feature!) changes on all systems is a bad idea - this issue being an example where an update would have broken on all systems.

I don’t auto-restart because if it was deliberately triggerd by update or config change it is ok and no problem to start it manually, any other way it is noteworthy and should be investigated why it happened before starting again.

So as workaround I now disable the low priority on all systems - are there any significant downsides to this except burning more CPU and not-so niceness?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.