On Mon, 05.01.15 15:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 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. A long-standing item on the TODO list is adding a concept for pushing fds from services into PID 1, which are then passed back into the service on the next start. That way journald could push each new stream fd into systemd, and would get the fds passed back via the usual socket activation logic. With that in place journald could be stopped/restarted any time without any special tool, and even reconnect to service stdout/stderr on abnormal termination too a certain degree. machined and logind already implement a reexec scheme similar to this, by simply maintaining their state in /run. Of course, things are much simpler for them, since they don't have to serialize any fds, but extending systemd's service management to have a generic fd store would allows us to reuse the same restart concept for journald that we already have for logind and machined. Maybe I should just sit down and implement this... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
