On Mon, Jan 05, 2015 at 02:24:35PM +0100, Tomasz Torcz wrote: > On Mon, Jan 05, 2015 at 02:12:45PM +0100, Lennart Poettering wrote: > > On Thu, 01.01.15 04:40, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > Sounds generally OK. > > > > > A disadvantage of the solution implemented here, otoh, is that both > > > systemd and journald must be restarted for it to take effect. > > > > This is something I am concerned about. This will break updates, as > > restarting journald is something we cannot really do without losing > > stdout/stderr of most running services. This means restarting journald > > doesn't really work, but then we couldn't reexec PID1 either on > > updates... Grrr... > Maybe journald needs some serialization around restarts? Remember > all the fds, re-exec new journald, sd_notify() new MAINPID to PID1, > restore fds? But I'm not sure if it's doable in Linux (but CRIU > allegely restores fds). CRIU would not work here, because it requires both sides of the pipe to be serialized/de-serialized together. Our problem is not on the journald side, but on side of the clients, which cannot write to their end of the pipe.
What we can do instead is to implement daemon-reexec equivalent for journald. It would simply reexec itself to a new binary and pass all the fds. Some serialization/de-serialization protocol would be necessary to pass information about those stdout connections (whatever is given in the header currently), but this shouldn't be too hard. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
