Hi again, RDS schrieb am 18.10.2021 18:42 (GMT +02:00):
> Doing the dishes just now, I thought of a possible relatively simple and > "reasonable" tinyproxy-only deterministic solution: > > Add a Boolean key-pair to tinyproxy's config, call it something like > 'letHostManageStops', setting it to 'false' by default, so that the new > default > behavior is tinyproxy's current behavoir. > > If set to 'true', then tinyrpoxy's parent process does something like this > when > it gets external kill sigs from the host: It does NOT send kill sigs to its > childern. Instead, for some fixed period of time, it continusously loops over > it's childern process IDs, each time checking if it's dead yet. I.E. Has the > "host" (aka, in our case, systemd) killed it yet? If all its childern are dead > before the fixed time elapses, it kills itself and exits 0. If one or more > childern are still alive after the kill-time, it kills them itself, then > kill's > itself. What exit status it reports in this case would need to be determined. 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