Dear Maintainer, I installed tinyproxy on an up-to-date Debian 11.1 (bullseye) installation. I'm seeing the issue that was reported in bug #968322 and later claimed to be fixed in version 1.10.0-5 (which I run) both with the default configuration and my custom configuration (see below) on two different machines. There seems to be some race condition or other magical circumstances involved, though, because after trying to reproduce this issue in a virtual machine, I could only trigger it with the default configuration after installing the package but not anymore with my custom configuration. But on my actual "production" system (a PC Engines APU2 box with some slower/dated AMD CPU) where tinyproxy was initially installed, I see the issue with both configurations. Nevertheless, I tried a couple of changes to the systemd unit file and nothing solved the issue except the directive SuccessExitStatus=2. I still found out one thing of note, though. I tried specifying an ExecStop command like so: ExecStop=/usr/bin/kill -TERM $MAINPID With this, after stopping the service, `systemctl status tinyproxy' showed that the kill command returned 0, but the main process returned 2. It seems to me that this contradicts the following statement in the original bug report which was: I don't know whether that is helpful in terms of solving the cause for the issue. But I thought, I'd at least mention it. As for the issue itself, unfortunately, the changes included in package version 1.10.0-5 don't solve the issue entirely (at least not for me). Thanks and regards, Timo
P.S. Somehow the bug tracker was lost in conversation, so adding it back. Hi, thanks for taking the time to reply on this old issue. Let me respond to a couple of your remarks and statements: RDS schrieb am 18.10.2021 18:03 (GMT +02:00): First off, it's not a big deal for me. I only marked this issue with the severity important because that was the severity of the original issue. But since there seems to be no real fallout from this issue, I'm absolutely fine to edit the systemd unit locally adding the SuccessExitStatus=2 directive. I see. Maybe I should have read the original report more thoroughly, as I assumed the fix is supposed to fix the issue under all circumstances. It reports the unit as failed. So, systemctl reports the state (or exit code) of the main process, not the kill command or SIGTERM call. Regards, Timo
Hi again, RDS schrieb am 18.10.2021 18:42 (GMT +02:00): It sounds like a reasonable option to me. I'm still wondering, however, how other daemons that spawn multiple forks do this. At least I've never encountered an application with such a behavior under systemd. But then again, I'm not really a developer and much more of a user. Regards, Timo
Apologies, didn't notice this was a new bug. Sending only to it now. There's at least a handful of reasons why you've not see this failure when stopping other systemd-managed applications. None of which, IMO, necessarily point to or imply any weakness or shortcoming in tinyproxy's children stop approach. With the caveat that I've not examined systemd/systemctl's stop code, my opinion now and when first digging into this bug is the same: The likely better solution is small additions or backwards-compatible changes to systemd/systemctl, for technical and social reasons. But I could be wrong. The seeming stop-state status contradiction you found is not a true paradox, and would likely be resolved relatively soon into looking at systemctl's stop code. It's also likely not an indication that my proof of root casuse code may not be demonstrating what it claims. While this is possible, it's unlikely. The root cause of the issue is almost for sure that systemctl and tinyproxy are "racing" to send kill signals to tinyproxy's child processes, and in cases where systemctl looses the race*, it responds in an undesirable way (in the context of tinyproxy management). *Pretty sure I'm remembering correctly that it's when systemctl looses the race that the false negative stop-states occur, but it might be the opposite.