3 ms·

I wish we could have a systemd that JUST does the job of init, and leaves the system logging, DNS resolving, etc. to the prexisting software that does a better

I wish we could have a systemd that JUST does the job of init, and leaves the system logging, DNS resolving, etc. to the prexisting software that does a better job of it.

eklitzke 3y ago
You literally don't need to use those features to use systemd. There's no requirement on journald or systemd-resolved if you just want to use systemd as an init. Distros are typically configured to use these features because they bring a bunch of benefits and are simpler to configure, but they're completely optional. At my job we manage an embedded Linux distro (using Yocto) and while we've been using systemd as init for a while, we only enabled journald relatively recently, and don't use the other stuff.
- rnhmjoj 3y ago
  > There's no requirement on journald Are you sure? I don't think it's possible to disable the journal for the whole system.
- pengaru 3y ago
  > You literally don't need to use those features to use systemd. There's no requirement on journald or systemd-resolved if you just want to use systemd as an init. Unit/Service file syntax controls per-service logging, PID1 is rather tightly coupled to journald in implementing those features. Hence the service manager explicitly checks that journald is running at startup: https://github.com/systemd/systemd/blob/v254/src/core/manager.c#L1884 https://github.com/systemd/systemd/blob/v254/src/core/manage... Other components like resolved and networkd are optional however.
  - gizmo686 3y ago
    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.

I wish we could have a systemd that JUST does the job of init, and leaves the system logging, DNS resolving, etc. to the prexisting software that does a better job of it.

eklitzke 3y ago

You literally don't need to use those features to use systemd. There's no requirement on journald or systemd-resolved if you just want to use systemd as an init. Distros are typically configured to use these features because they bring a bunch of benefits and are simpler to configure, but they're completely optional. At my job we manage an embedded Linux distro (using Yocto) and while we've been using systemd as init for a while, we only enabled journald relatively recently, and don't use the other stuff.

rnhmjoj 3y ago
> There's no requirement on journald Are you sure? I don't think it's possible to disable the journal for the whole system.
pengaru 3y ago
> You literally don't need to use those features to use systemd. There's no requirement on journald or systemd-resolved if you just want to use systemd as an init. Unit/Service file syntax controls per-service logging, PID1 is rather tightly coupled to journald in implementing those features. Hence the service manager explicitly checks that journald is running at startup: https://github.com/systemd/systemd/blob/v254/src/core/manager.c#L1884 https://github.com/systemd/systemd/blob/v254/src/core/manage... Other components like resolved and networkd are optional however.
- gizmo686 3y ago
  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.