On Fri, 14.02.14 02:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > So, what I am afraid of here is that some process has some unpriviliged > > children (CGI scripts or so), and for some reason they stay around after > > the daemon itself is already terminated, and then can confuse > > things... I mean, let's say somebody sets KillMode=none, and thus > > processes can survive all the way into the next process start, and can > > then quickly confuse systemd that they are the real main pid or so (for > > example, by sending MAINPID= or so...). Or even if we consider the > > KillMode=none thing irrelevant, then there might still be a small window > > where the main pid is already dead and we kill the other processes and > > wait for them and they then send us invalid data? > > In the bug report it seems that this happens during startup... > Other cases where I saw this were also during startup, and KillMode > was default, as far as I remember. Even if $MAINPID has died, we should > be able to distinguish this from the case where it hasn't been set yet. I am tempted to say that people either should use NotifyAccess=all in this case, and thus clarify that they have no unprivileged rogue processes around. Or, if that's not possible they have to use Type=simple, where the problem would go away. Or if that's not possible, then deal with dropped messages. I mean, this feels a bit like trying to use the new apis but also the old forking mess, at the same time. A bit like eating a cake, and having it too. Or am I missing something? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
