5 ms·

Starting this off with a disclaimer that these are things I've heard or read, and aren't necessarily a statement of my views. The controversy mainly surrounds

Starting this off with a disclaimer that these are things I've heard or read, and aren't necessarily a statement of my views. The controversy mainly surrounds the claim that it is a single package that tries to do way too much by itself. Calling systemd an init system isn't correct. systemd contains many things, one of which is an init system. The other claim is that the systemd developers aren't open to much outside opinion, but have power over the community because important parts of basically all desktop Linux systems are now part of systemd and have strong dependencies on it (such as udev).

shrimp_emoji 6y ago
For example, systemd timers (timed systemctl services) are like cron if cron was slightly more complicated and had very good logging. :3
- yarrel 6y ago
  journalctl is a text adventure fever dream. Do systemd timers use a different logging system?
  - simcop2387 6y ago
    Nope, they go straight to journald.
  - deadbunny 6y ago
    You can output journald to syslog with one config option[1]. 1. https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html https://www.freedesktop.org/software/systemd/man/systemd-jou...
    - isbjorn16 6y ago
      Then it should be on by default. Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I otherwise don't care about systemd, except for the more-than-one locations I might find an init script hiding on my system. It's fine. But don't make me use journalctl just to tail a god damned file like a normal person. Edit: I may have reached that point on friday night where the bottle of port and my grey beard have finally reached "old man yells at cloud" stage. My apologies.
      - majewsky 6y ago
        > Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I absolutely love the idea of journalctl (without commenting on the execution). As an admin, there was always the chance that $DAEMON_OF_THE_DAY put their logfile in a particularly creative place, thus sending me on some wild goose hunt. Now it's just `journalctl -u $DAEMON` and that works immediately, every single time. Also, as a user running journald on a notebook, I love that it's just one config switch to send all the logs from all the services to /run instead of /var, to reduce the write load on the SSD. Sure you could fiddle with a bind-mount but that would have to happen very early in the boot process so I don't think it would be as reliable. As a daemon writer, it's one less option for me to care about. Especially when my daemon is just some bash script, logging to stdout is the easiest way. And logging to stdout also meshes well with running the same daemon/script in container environments like Docker or Kubernetes where containers usually don't even have syslogd. (In fact, I have containerized a service that requires syslogd and that was kind of a pain. I ended up using a mini-syslogd implementation that just dumps all logs on stdout so Docker can pick it up.)
        viluon 6y ago
        It also allows you to read the logs in JSON, which is fantastic for automation. Parsing the syslog as a text file means a single newline in a syslog message screws your effort up. With journalctl, you can sift through error messages from specific services, confident that the results you are getting are exactly what the logs contain. Unless, of course, some of the binaries are corrupt.
      - shawnz 6y ago
        What is the advantage to having to write all the log messages twice instead of once? What is the disadvantage in having to type "journalctl -f" instead of "tail -f"?
        isbjorn16 6y ago
        My usual "tail" is not tail -f, but tail -n 100. In fact, I jump around a ton doing tails and heads with varying linecounts, and if it gets unweildy even after all of that, that's when I pipe to less and look at it. My major justification is I use tail and head constantly, every single day, and it's rarely on system logging. It's java logs, it's python logs, it's rust logs. I'm not going to be giving up tail or head any time soon. Now I have to type "journalctl --help" every single time I want to look at a system or daemon log, which isn't super common, and when I do need to I'm already frustrated something isn't working. Put another way, this is the exact WORST time to throw up more roadblocks over something. That's why I assert it should be logged twice, and for those who don't want it to be chewing up diskspace or want to relocate it, well, that's where you can configure it. I just want my old log files back in their old locations without forcing me to sift through man pages when all I really want to do is figure out why the fucking bluetooth keeps dropping connection. I understand why others see this as a great step forward but it sounds more like the windows registry and event viewer to me than it does the configuration file and log file approach I adore from my unix systems. I'm sure the registry and event viewer has a lot of devoted fans as well; the difference is it's been there for most of my life (or at least, the parts where I was doing more than playing X-Wing vs Tie Fighter), which is why I mostly just wandered away. I'm not a sysadmin, I don't try to be and I don't want to be, and it seems like systemd is hellbent on forcing me to be one whether I want to be or not and I am so not here for it.
yarrel 6y ago
It tries to do too much, badly, and with an air of entitlement around intentionally breaking things. Change is good, so let's change away from systemd.
- thawaway1837 6y ago
  If someone is able to create something that is half as good as systemd then distros will switch time it. The thing is that systemd solves a lot of problems for distros in a good enough way (frankly, currently in a way that is better than any existing alternative) that they are happy to have systemd deal with those issues while they focus on the stuff the distro makers are interested in.
  - yjftsjthsd-h 6y ago
    > If someone is able to create something that is half as good as systemd then distros will switch time it. Not a given, since one of the issues with systemd is its integrations. Replacing init now requires you to replace your system logging and session manager, at a minimum, as well as replace all your service files.
    - the_why_of_y 6y ago
      systemd-logind is optional and you would be able to use ConsoleKit instead if anybody had maintained it in the last 5 years. Unlike e.g. upstart in its native mode, systemd can run SysV init scripts. https://unix.stackexchange.com/questions/233468/how-does-systemd-use-etc-init-d-scripts https://unix.stackexchange.com/questions/233468/how-does-sys...
      - JdeBP 6y ago
        By "system logging" yjftsjthsd-h was referring to systemd-journald, not systemd-logind.
        the_why_of_y 6y ago

shrimp_emoji 6y ago

For example, systemd timers (timed systemctl services) are like cron if cron was slightly more complicated and had very good logging. :3

yarrel 6y ago
journalctl is a text adventure fever dream. Do systemd timers use a different logging system?
- simcop2387 6y ago
  Nope, they go straight to journald.
- deadbunny 6y ago
  You can output journald to syslog with one config option[1]. 1. https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html https://www.freedesktop.org/software/systemd/man/systemd-jou...
  - isbjorn16 6y ago
    Then it should be on by default. Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I otherwise don't care about systemd, except for the more-than-one locations I might find an init script hiding on my system. It's fine. But don't make me use journalctl just to tail a god damned file like a normal person. Edit: I may have reached that point on friday night where the bottle of port and my grey beard have finally reached "old man yells at cloud" stage. My apologies.
    - majewsky 6y ago
      > Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I absolutely love the idea of journalctl (without commenting on the execution). As an admin, there was always the chance that $DAEMON_OF_THE_DAY put their logfile in a particularly creative place, thus sending me on some wild goose hunt. Now it's just `journalctl -u $DAEMON` and that works immediately, every single time. Also, as a user running journald on a notebook, I love that it's just one config switch to send all the logs from all the services to /run instead of /var, to reduce the write load on the SSD. Sure you could fiddle with a bind-mount but that would have to happen very early in the boot process so I don't think it would be as reliable. As a daemon writer, it's one less option for me to care about. Especially when my daemon is just some bash script, logging to stdout is the easiest way. And logging to stdout also meshes well with running the same daemon/script in container environments like Docker or Kubernetes where containers usually don't even have syslogd. (In fact, I have containerized a service that requires syslogd and that was kind of a pain. I ended up using a mini-syslogd implementation that just dumps all logs on stdout so Docker can pick it up.)
      - viluon 6y ago
        It also allows you to read the logs in JSON, which is fantastic for automation. Parsing the syslog as a text file means a single newline in a syslog message screws your effort up. With journalctl, you can sift through error messages from specific services, confident that the results you are getting are exactly what the logs contain. Unless, of course, some of the binaries are corrupt.
    - shawnz 6y ago
      What is the advantage to having to write all the log messages twice instead of once? What is the disadvantage in having to type "journalctl -f" instead of "tail -f"?
      - isbjorn16 6y ago
        My usual "tail" is not tail -f, but tail -n 100. In fact, I jump around a ton doing tails and heads with varying linecounts, and if it gets unweildy even after all of that, that's when I pipe to less and look at it. My major justification is I use tail and head constantly, every single day, and it's rarely on system logging. It's java logs, it's python logs, it's rust logs. I'm not going to be giving up tail or head any time soon. Now I have to type "journalctl --help" every single time I want to look at a system or daemon log, which isn't super common, and when I do need to I'm already frustrated something isn't working. Put another way, this is the exact WORST time to throw up more roadblocks over something. That's why I assert it should be logged twice, and for those who don't want it to be chewing up diskspace or want to relocate it, well, that's where you can configure it. I just want my old log files back in their old locations without forcing me to sift through man pages when all I really want to do is figure out why the fucking bluetooth keeps dropping connection. I understand why others see this as a great step forward but it sounds more like the windows registry and event viewer to me than it does the configuration file and log file approach I adore from my unix systems. I'm sure the registry and event viewer has a lot of devoted fans as well; the difference is it's been there for most of my life (or at least, the parts where I was doing more than playing X-Wing vs Tie Fighter), which is why I mostly just wandered away. I'm not a sysadmin, I don't try to be and I don't want to be, and it seems like systemd is hellbent on forcing me to be one whether I want to be or not and I am so not here for it.

yarrel 6y ago

It tries to do too much, badly, and with an air of entitlement around intentionally breaking things. Change is good, so let's change away from systemd.

thawaway1837 6y ago
If someone is able to create something that is half as good as systemd then distros will switch time it. The thing is that systemd solves a lot of problems for distros in a good enough way (frankly, currently in a way that is better than any existing alternative) that they are happy to have systemd deal with those issues while they focus on the stuff the distro makers are interested in.
- yjftsjthsd-h 6y ago
  > If someone is able to create something that is half as good as systemd then distros will switch time it. Not a given, since one of the issues with systemd is its integrations. Replacing init now requires you to replace your system logging and session manager, at a minimum, as well as replace all your service files.
  - the_why_of_y 6y ago
    systemd-logind is optional and you would be able to use ConsoleKit instead if anybody had maintained it in the last 5 years. Unlike e.g. upstart in its native mode, systemd can run SysV init scripts. https://unix.stackexchange.com/questions/233468/how-does-systemd-use-etc-init-d-scripts https://unix.stackexchange.com/questions/233468/how-does-sys...
    - JdeBP 6y ago
      By "system logging" yjftsjthsd-h was referring to systemd-journald, not systemd-logind.
      - the_why_of_y 6y ago