[systemd-devel] [RFC PATCH] journal: pass uid.gid in the stream header

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Mon Jan 5 18:32:28 PST 2015

On Tue, Jan 06, 2015 at 03:28:09AM +0100, Lennart Poettering wrote:
> On Mon, 05.01.15 16:03, Lennart Poettering (lennart at poettering.net) wrote:
> > On Mon, 05.01.15 15:02, Zbigniew Jędrzejewski-Szmek (zbyszek at 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...
> I have implemented this now. "systemctl restart systemd-journald" should now
> no longer lose the stdout/stderr connections. In fact, even if
> journald dies abnormally it should not lose anything now. 

Cool! Great to see this fixed.

> The API I added to PID 1 for this is pretty simple: via the
> sd_notify() stuff send a message with "FDSTORE=1" accompanied by the
> fds to store and systemd will do so (subject to FileDescriptorStore=
> in the service file, which defaults to 0, i.e. this is actually turned
> off by default). The file descriptors are than passed on the next
> restart of the service using the usual fd passing. The fds are kept
> around by systemd until EPOLLHUP or EPOLLERR is seen on them, or the
> service is fully stopped and no jobs queued for it anymore.


More information about the systemd-devel mailing list