4 ms·

Does that actually require journald to be running though. Following that code through to the actual check gets to the comment: > The journal is fully and entir

Does that actually require journald to be running though. Following that code through to the actual check gets to the comment: > The journal is fully and entirely up? If so, let's permit logging to it, if that's configured. If the journal is down, don't ever log to it, otherwise we might end up deadlocking ourselves as we might trigger an activation ourselves we can't fulfill. I have never run in such a configuration, but based on this code, it sounds like there is explicit support for running without journald.

pengaru 3y ago
The code just has to tolerate a period where journald's starting but not yet available, since it's PID1 which starts journald, to avoid deadlock. Chicken-egg problem. There's assumptions throughout PID1 that journald is the logger, units which log get journald deps added: https://github.com/systemd/systemd/blob/v254/src/core/unit.c#L1357 https://github.com/systemd/systemd/blob/v254/src/core/unit.c... Salient point being, this is all journald-coupled, not some abstracted logging concept you can substitute with any other thing. The problem with supporting a journald-less mode as some first class thing is it's basically a degraded functional state. Edit: Here, I dug up the documentation speaking to this when journald was being developed: > I am using systemd on an embedded system and am not interested in > persistent logging, can I opt out of the journal? > > No you can't really. However, what you can do is tell systemd that > you don't want persistent logging, by removing (or not creating in > the first place) the /var/log/journal directory, in which case > journald will log only to /run/log/journal (which it does in any > case during early boot). /run is volatile and lost on reboots, in > contrast to /var. On top of that you can configure the maximum disk > space the journal may consume to a low value. From the google doc linked @ https://0pointer.de/blog/projects/the-journal.html https://0pointer.de/blog/projects/the-journal.html in the FAQ section.

pengaru 3y ago

The code just has to tolerate a period where journald's starting but not yet available, since it's PID1 which starts journald, to avoid deadlock. Chicken-egg problem. There's assumptions throughout PID1 that journald is the logger, units which log get journald deps added: https://github.com/systemd/systemd/blob/v254/src/core/unit.c#L1357 https://github.com/systemd/systemd/blob/v254/src/core/unit.c... Salient point being, this is all journald-coupled, not some abstracted logging concept you can substitute with any other thing. The problem with supporting a journald-less mode as some first class thing is it's basically a degraded functional state. Edit: Here, I dug up the documentation speaking to this when journald was being developed: > I am using systemd on an embedded system and am not interested in > persistent logging, can I opt out of the journal? > > No you can't really. However, what you can do is tell systemd that > you don't want persistent logging, by removing (or not creating in > the first place) the /var/log/journal directory, in which case > journald will log only to /run/log/journal (which it does in any > case during early boot). /run is volatile and lost on reboots, in > contrast to /var. On top of that you can configure the maximum disk > space the journal may consume to a low value. From the google doc linked @ https://0pointer.de/blog/projects/the-journal.html https://0pointer.de/blog/projects/the-journal.html in the FAQ section.