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 p

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.