3 ms·

As someone who basically started getting into Linux with Systemd (I had dabbled before, but not in-depth) I love it. Mind expanding on what you don't like about

As someone who basically started getting into Linux with Systemd (I had dabbled before, but not in-depth) I love it. Mind expanding on what you don't like about it? One thing I do remember before Systemd though was the fact that every service was essentially a glorified bash script, and I hated that. With Systemd, there seems to generally be a much more clear-cut definition of how things operate, without all the cruft.

saghm 10y ago
One of the big issues a lot of people have (or at least had, back when it was first becoming a thing) was that systemd uses binary log files rather than traditional text ones, which makes them harder to deal with (e.g. you can't `tail` or `grep` them, at least not directly). Another common gripe is that while it started out as an init system, a rather large portion of userland on a typical system depends on one or more systemd components directly or indirectly, making it somewhat difficult to avoid it if you'd prefer not to use it. My biggest issue with systemd is that when something goes wrong, it's pretty impossible to tell why. As an example, virtually every system I've used with systemd after a few months starts to have different services fail to stop on shutdown, causing a timeout of (by default) one-and-a-half minutes. From searches that I've done online, I don't seem to be the only person who runs into this, but I haven't found any good solution, leaving me with the options to reduce the timeout to something more manageable, force shutdown my laptop literally every time I'm done using it, or sit through 90 seconds of systemd trying and failing to stop whichever service is failing that time. Maybe I'm just lucky, but it's fairly rare that any of my non-systemd systems is unable to shut down properly once, let alone every single time consistently.
- BuuQu9hu 10y ago
  tail: journalctl -f Personally, I found journalctl much better than text based logs. For the timeouts, I think try the systemd-bootchart thing.
- totony 10y ago
  Apparently you can use "strings /run/journal/..." But journald lacks way more than simple text files. I tried to "mute" a process and redirect output to a file, because it was counting in the maximum journal size, and found it to be impossible "by design". Had to use an actually good log daemon, but it seems quite hard to just disable journald and not lose any log.

saghm 10y ago

One of the big issues a lot of people have (or at least had, back when it was first becoming a thing) was that systemd uses binary log files rather than traditional text ones, which makes them harder to deal with (e.g. you can't `tail` or `grep` them, at least not directly). Another common gripe is that while it started out as an init system, a rather large portion of userland on a typical system depends on one or more systemd components directly or indirectly, making it somewhat difficult to avoid it if you'd prefer not to use it. My biggest issue with systemd is that when something goes wrong, it's pretty impossible to tell why. As an example, virtually every system I've used with systemd after a few months starts to have different services fail to stop on shutdown, causing a timeout of (by default) one-and-a-half minutes. From searches that I've done online, I don't seem to be the only person who runs into this, but I haven't found any good solution, leaving me with the options to reduce the timeout to something more manageable, force shutdown my laptop literally every time I'm done using it, or sit through 90 seconds of systemd trying and failing to stop whichever service is failing that time. Maybe I'm just lucky, but it's fairly rare that any of my non-systemd systems is unable to shut down properly once, let alone every single time consistently.

BuuQu9hu 10y ago
tail: journalctl -f Personally, I found journalctl much better than text based logs. For the timeouts, I think try the systemd-bootchart thing.
totony 10y ago
Apparently you can use "strings /run/journal/..." But journald lacks way more than simple text files. I tried to "mute" a process and redirect output to a file, because it was counting in the maximum journal size, and found it to be impossible "by design". Had to use an actually good log daemon, but it seems quite hard to just disable journald and not lose any log.