6 ms·

I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people lik

I would say it really depends on the context! Some reasons systemd is bad: - Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux). - It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script. - the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments. - (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example. Some arguments for systemd: - systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent) - systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective. - systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop) - systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system ========== In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.

yjftsjthsd-h 4y ago
> Its a "big" for small docker containers Aside size, last I looked it required a lot of hoop-jumping to get systemd to run inside docker at all.
- klodolph 4y ago
  I think the idea of running systemd inside docker (or vice versa) is a little redundant to begin with—systemd and docker share a number of features.
  - yjftsjthsd-h 4y ago
    It's unusual, but there are occasionally times when it's nice to run multiple processes in one container, and a proper service manager would be useful. Usually I see supervisord used for that kind of thing in practice.
- RealStickman_ 4y ago
  Iirc using systemd in Podman is much easier.
panick21_ 4y ago
You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.
- plaguepilled 4y ago
  I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
  - gupnop 4y ago
    There are solid technical reasons for systemd's binary logging. The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones. Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can help guard against log tampering.
    - awruko 4y ago
      > indexed for quicker searching and filtering I think I am not the only one who is missing negative filters - check the log excluding audit messages.
    - UI_at_80x24 4y ago
      Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.
      - fsh 4y ago
        If your live USB image is from this decade, it will almost certainly come with journald for reading the logs. If it doesn't, why choose such a bad live USB image?
gizzlon 4y ago
- It's also "big" in the sense that it's all-encompassing and hard to replace - It makes alternating between systems harder because so much is Linux + Systemd specific.
erik_seaberg 4y ago
nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.
- plaguepilled 4y ago
  Not sure I fully understand this argument. Can you expand? I'm not familiar with nohup and its role.
  - erik_seaberg 4y ago
    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/nohup.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end users shouldn’t need to talk to init.
    - teddyh 4y ago
      Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.
      - erik_seaberg 4y ago
        I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?
kaba0 4y ago
> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the provided “decrypt” tool and then further use the usual unix tools if you wish. But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before.
- ayushnix 4y ago
  > But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before. From what I've seen using Alpine Linux for a few weeks on my Raspberry Pi, logs are written to /var/log/messages after the init process starts and launches the logging service. All logs before the init starts can be retrieved using dmesg? I'm not sure about this though, let me know if I'm wrong. One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).
  - UI_at_80x24 4y ago
    >One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since). I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
    - ayushnix 4y ago
      > I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics. I can grep my way through text logs as well but being able to get logs for different purposes using --flags is better user experience. I can always resort to to using grep, sed, and awk if I want to when using journald but the loss of these quality of life features make it hard for me to consider using a distro that does not have systemd.

yjftsjthsd-h 4y ago

> Its a "big" for small docker containers Aside size, last I looked it required a lot of hoop-jumping to get systemd to run inside docker at all.

klodolph 4y ago
I think the idea of running systemd inside docker (or vice versa) is a little redundant to begin with—systemd and docker share a number of features.
- yjftsjthsd-h 4y ago
  It's unusual, but there are occasionally times when it's nice to run multiple processes in one container, and a proper service manager would be useful. Usually I see supervisord used for that kind of thing in practice.
RealStickman_ 4y ago
Iirc using systemd in Podman is much easier.

panick21_ 4y ago

You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.

plaguepilled 4y ago
I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
- gupnop 4y ago
  There are solid technical reasons for systemd's binary logging. The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones. Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can help guard against log tampering.
  - awruko 4y ago
    > indexed for quicker searching and filtering I think I am not the only one who is missing negative filters - check the log excluding audit messages.
  - UI_at_80x24 4y ago
    Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.
    - fsh 4y ago
      If your live USB image is from this decade, it will almost certainly come with journald for reading the logs. If it doesn't, why choose such a bad live USB image?

gizzlon 4y ago

- It's also "big" in the sense that it's all-encompassing and hard to replace - It makes alternating between systems harder because so much is Linux + Systemd specific.

erik_seaberg 4y ago

nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.

plaguepilled 4y ago
Not sure I fully understand this argument. Can you expand? I'm not familiar with nohup and its role.
- erik_seaberg 4y ago
  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/nohup.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end users shouldn’t need to talk to init.
  - teddyh 4y ago
    Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.
    - erik_seaberg 4y ago
      I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?

kaba0 4y ago

> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the provided “decrypt” tool and then further use the usual unix tools if you wish. But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before.

ayushnix 4y ago
> But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before. From what I've seen using Alpine Linux for a few weeks on my Raspberry Pi, logs are written to /var/log/messages after the init process starts and launches the logging service. All logs before the init starts can be retrieved using dmesg? I'm not sure about this though, let me know if I'm wrong. One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).
- UI_at_80x24 4y ago
  >One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since). I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
  - ayushnix 4y ago
    > I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics. I can grep my way through text logs as well but being able to get logs for different purposes using --flags is better user experience. I can always resort to to using grep, sed, and awk if I want to when using journald but the loss of these quality of life features make it hard for me to consider using a distro that does not have systemd.