7 ms·

As someone who has been using Linux full time on servers/desktops/laptops/embedded devices and any other computing device I've had since 1998: Systemd is such

As someone who has been using Linux full time on servers/desktops/laptops/embedded devices and any other computing device I've had since 1998: Systemd is such an awesome improvement over everything that came before it. It benefits me on a daily basis. The power and ease of configuring services is so far beyond sysinit (and let's be honest, most of us weren't able to write our own init scripts back then and were resorting to stuff like rc.local or inittab anyway which were inadequate solutions). Timers are generally better than cron. I love that systemd does all the stuff I used to have to do on my own like balancing when jobs run and preventing DST issues. I like journalctl. I know it bothers some people that the logs are stored in some kind of binary format but the practical difference of journalctl is that logs are easier to filter in a variety of ways. Anyway, I think making a init system would be a fun hobby too, but the world is a better place because of systemd and I am sick of the belly-aching about it.

enriquto 7y ago
> Systemd is such an awesome improvement over everything that came before it. It benefits me on a daily basis. Curiously, I have the exact opposite experience. I never cared about init systems and I do not care now. But before systemd I could mostly ignore the existence of the init system (besides editing an occasional script). With systemd, on the contrary, my daily life is made miserable in many different ways due to systemd randombly breaking stuff, and having a state scattered through a myriad of different "configuration" files. When I manage to fold it to my liking, the next version always happens to break my hard-obtained configuration. It feels like it is not my computer anymore and I cannot wait enough to get rid of it. Besides, the people who had the idea to store the logs in binary format should be shot. In front of their families.
- rbjorklin 7y ago
  What do you do with your systems? I adopted it fairly early and it’s been such an improvement for me over System V. Never had an issue really. What’s wrong with storing the logs in binary form when it’s super easy to filter and then pipe to whatever command you want?
- Mashimo 7y ago
  This is not a nice thing to say :(
- PlutoIsAPlanet 7y ago
  "Besides, the people who had the idea to store the logs in binary format should be shot. In front of their families. " Technically text logs are being stored in binary too.
pdkl95 7y ago
> Timers are generally better than cron. (which cron? Many cron daemons are available. While the traditional Vixie cron was popular with distros for historical reasons, it wasn't difficult to switch to another cron variant or any other job scheduler) If that feature or other components like journald were designed as an independent package instead of being unnecessarily coupled into systemd, we could all simply choose which tools we want to use.
- n0rbwah 7y ago
  That's really a bad example. Timers are just standard units that are executed at regular intervals instead of at startup/when a specific file is requested/when another service is started/etc. It makes perfect sense for this particular feature to be part of the core capabilities of systemd units. Journald would be a better example but FYI most systemd components are optional and only a few of them are required. Whether it makes sense for those components to be required is up for debate and there are good arguments on both sides. The systemd team decided it made sense to have a hard dependency on those components. You can disagree with them but the only alternatives you have is to either fork, come up with your own init system or join the core systemd team and try to make them change their mind from within (and probably put up the hard work needed to remove the hard dependency on those components). People seem very passionate about init systems since systemd was introduced but few seem passionate enough to do the hard work needed to implement the changes they would like to see.
  - JdeBP 7y ago
    > The systemd team decided No they did not. Nominally, at least. The systemd people have always maintained that this stuff is up to the people who package systemd for individual operating systems. It is those latter who decided that (a) there would be one big systemd package and (b) other packages would have dependences from it. They could have decided to package systemd up as multiple packages, instead. In fact, a lot of the Debian Hoo-Hah was over the packaging. * http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html This is slightly undermined by the fact that a few of the prominent systemd people are (or have been) the systemd package maintainers for various operating systems, so this is in fact in some cases the same people simply with different hats on their heads.
correct_horse 7y ago
I agree that systemd gets way more hate than it deserves, but it has continual problems on Arch Linux. Wherever you try to shutdown without logging out first, systemd says ”a stop job is running for user manager...", then waits 90 seconds. The issue keeps getting fixed, then resurfacing. People with this same problem are all over the internet.
- zaarn 7y ago
  In my experience, that happens when a user process is ignoring the SIGTERM signal (ie, a word process or browser wanting user confirmation before shutting down). Generally, I personally don't mind it and I set the timeout to 30 seconds, which helps. There is probably no good solution unless systemd starts to send SIGKILL instead of SIGTERM to kill without questioning why, but that would break everything else.
  - mongol 7y ago
    Maybe there should be hard and soft shutdowns? Or maybe there already is?
    - zaarn 7y ago
      SysRq-b is a hard shutdown. "Soft" vs "Hard" isn't a realistic distinction, systemd already does a "hard" shutdown if the timeout is exceeded. There is no reason to do a hard one in any system, a soft shutdown is always preferable as things like database engines might need a moment to save their data. If you send them a SIGKILL then your database engine will loose data.
  - stuaxo 7y ago
    I get this every time I shut down. The GUI has shutdown a while before, but I have to hold the power button down every time I shut down my laptop. TBH it's not as bad, as suspend being broken because it's a ryzen based laptop. (Half the time it comes back with a black screen and I have to hard reboot).
    - 7y ago
m0xte 7y ago
It is functionally better but far more brittle, over complicated, heavily coupled, stateful and poorly managed. The net gain is close to zero. Somewhere between sysv and systemd was the sweet spot. Edit: I know my point is unpopular, perhaps mostly with RH staff browsing HN late at night, but this is experience from running systemd in production over 4 years on CentOS 7. What was not a concern before is now a concern and is actually costing me time, money and friction regularly. Add the Linux boot process, all the FreeDesktop crud to this and it's a nightmare of a system to look after. Windows/FreeBSD/OpenBSD are far far far easier to manage from this perspective.
- ClumsyPilot 7y ago
  > brittle and poorly managed Could you expand on that?
  - m0xte 7y ago
    Brittle - try dealing with a hosed boot or DBus failure. I've dealt with numerous on CentOS 7 and at this point it's easier just to blow the whole node away and start again. Also I've had a couple of segfaults on journalctl recently when I actually need it so i have to then go digging through the GUID encrusted hell it leaves on disk. Poorly managed - Pwnie award, "it's not a bug" from Poettering etc etc.
stuaxo 7y ago
It's a great improvement. As someone that has gone through Redhat, SuSE, Debian and Ubuntu over the years having something that works (efficiently) on all these platforms is great. Trying to work out the init scripts in some distro when you are used to another is a fun way to spend an evening, I don't have the free time for that any more.
deleted 7y ago
[deleted]
JdeBP 7y ago
> everything that came before it ... sysinit Your commentary is undermined by the fact that you do not have the experience with the things that did come before it to know that you are talking about the wrong thing. So you cannot be expressing a fully informed opinion. The assumption that only systemd and van Smoorenburg init exist is a fallacy that was called out by the "Uselessd Guy" several years ago. * https://web.archive.org/web/20190306213420/http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ https://web.archive.org/web/20190306213420/http://uselessd.d... The thing that came immediately before systemd, on operating systems like Ubuntu and Fedora, was upstart. It was not van Smoorenburg init. And that was not systemd's only antecedent. On real Unices there were the Service Access Facility on AT&T System 5 Unix (replacing the running of services through inittab years before Linux even existed), Solaris' SMF, and the AIX SRC. On Linux operating systems there were all of the tools in the daemontools family except for the nosh toolset (which post-dates systemd), InitNG, OpenRC, and a whole bunch of others. * http://jdebp.uk./FGA/unix-service-access-facility.html http://jdebp.uk./FGA/unix-service-access-facility.html * http://jdebp.uk./FGA/inittab-getty-is-history.html http://jdebp.uk./FGA/inittab-getty-is-history.html * https://blog.darknedgy.net/technology/2015/09/05/0/ https://blog.darknedgy.net/technology/2015/09/05/0/
_emacsomancer_ 7y ago
I have a number of systems running with systemd and a number running with other inits (runit or shepherd). I continue to have more problems with the former than the latter two.

enriquto 7y ago

> Systemd is such an awesome improvement over everything that came before it. It benefits me on a daily basis. Curiously, I have the exact opposite experience. I never cared about init systems and I do not care now. But before systemd I could mostly ignore the existence of the init system (besides editing an occasional script). With systemd, on the contrary, my daily life is made miserable in many different ways due to systemd randombly breaking stuff, and having a state scattered through a myriad of different "configuration" files. When I manage to fold it to my liking, the next version always happens to break my hard-obtained configuration. It feels like it is not my computer anymore and I cannot wait enough to get rid of it. Besides, the people who had the idea to store the logs in binary format should be shot. In front of their families.

rbjorklin 7y ago
What do you do with your systems? I adopted it fairly early and it’s been such an improvement for me over System V. Never had an issue really. What’s wrong with storing the logs in binary form when it’s super easy to filter and then pipe to whatever command you want?
Mashimo 7y ago
This is not a nice thing to say :(
PlutoIsAPlanet 7y ago
"Besides, the people who had the idea to store the logs in binary format should be shot. In front of their families. " Technically text logs are being stored in binary too.

pdkl95 7y ago

> Timers are generally better than cron. (which cron? Many cron daemons are available. While the traditional Vixie cron was popular with distros for historical reasons, it wasn't difficult to switch to another cron variant or any other job scheduler) If that feature or other components like journald were designed as an independent package instead of being unnecessarily coupled into systemd, we could all simply choose which tools we want to use.

n0rbwah 7y ago
That's really a bad example. Timers are just standard units that are executed at regular intervals instead of at startup/when a specific file is requested/when another service is started/etc. It makes perfect sense for this particular feature to be part of the core capabilities of systemd units. Journald would be a better example but FYI most systemd components are optional and only a few of them are required. Whether it makes sense for those components to be required is up for debate and there are good arguments on both sides. The systemd team decided it made sense to have a hard dependency on those components. You can disagree with them but the only alternatives you have is to either fork, come up with your own init system or join the core systemd team and try to make them change their mind from within (and probably put up the hard work needed to remove the hard dependency on those components). People seem very passionate about init systems since systemd was introduced but few seem passionate enough to do the hard work needed to implement the changes they would like to see.
- JdeBP 7y ago
  > The systemd team decided No they did not. Nominally, at least. The systemd people have always maintained that this stuff is up to the people who package systemd for individual operating systems. It is those latter who decided that (a) there would be one big systemd package and (b) other packages would have dependences from it. They could have decided to package systemd up as multiple packages, instead. In fact, a lot of the Debian Hoo-Hah was over the packaging. * http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html This is slightly undermined by the fact that a few of the prominent systemd people are (or have been) the systemd package maintainers for various operating systems, so this is in fact in some cases the same people simply with different hats on their heads.

correct_horse 7y ago

I agree that systemd gets way more hate than it deserves, but it has continual problems on Arch Linux. Wherever you try to shutdown without logging out first, systemd says ”a stop job is running for user manager...", then waits 90 seconds. The issue keeps getting fixed, then resurfacing. People with this same problem are all over the internet.

zaarn 7y ago
In my experience, that happens when a user process is ignoring the SIGTERM signal (ie, a word process or browser wanting user confirmation before shutting down). Generally, I personally don't mind it and I set the timeout to 30 seconds, which helps. There is probably no good solution unless systemd starts to send SIGKILL instead of SIGTERM to kill without questioning why, but that would break everything else.
- mongol 7y ago
  Maybe there should be hard and soft shutdowns? Or maybe there already is?
  - zaarn 7y ago
    SysRq-b is a hard shutdown. "Soft" vs "Hard" isn't a realistic distinction, systemd already does a "hard" shutdown if the timeout is exceeded. There is no reason to do a hard one in any system, a soft shutdown is always preferable as things like database engines might need a moment to save their data. If you send them a SIGKILL then your database engine will loose data.
- stuaxo 7y ago
  I get this every time I shut down. The GUI has shutdown a while before, but I have to hold the power button down every time I shut down my laptop. TBH it's not as bad, as suspend being broken because it's a ryzen based laptop. (Half the time it comes back with a black screen and I have to hard reboot).
  - 7y ago

m0xte 7y ago

It is functionally better but far more brittle, over complicated, heavily coupled, stateful and poorly managed. The net gain is close to zero. Somewhere between sysv and systemd was the sweet spot. Edit: I know my point is unpopular, perhaps mostly with RH staff browsing HN late at night, but this is experience from running systemd in production over 4 years on CentOS 7. What was not a concern before is now a concern and is actually costing me time, money and friction regularly. Add the Linux boot process, all the FreeDesktop crud to this and it's a nightmare of a system to look after. Windows/FreeBSD/OpenBSD are far far far easier to manage from this perspective.

ClumsyPilot 7y ago
> brittle and poorly managed Could you expand on that?
- m0xte 7y ago
  Brittle - try dealing with a hosed boot or DBus failure. I've dealt with numerous on CentOS 7 and at this point it's easier just to blow the whole node away and start again. Also I've had a couple of segfaults on journalctl recently when I actually need it so i have to then go digging through the GUID encrusted hell it leaves on disk. Poorly managed - Pwnie award, "it's not a bug" from Poettering etc etc.

stuaxo 7y ago

It's a great improvement. As someone that has gone through Redhat, SuSE, Debian and Ubuntu over the years having something that works (efficiently) on all these platforms is great. Trying to work out the init scripts in some distro when you are used to another is a fun way to spend an evening, I don't have the free time for that any more.

deleted 7y ago

[deleted]

JdeBP 7y ago

> everything that came before it ... sysinit Your commentary is undermined by the fact that you do not have the experience with the things that did come before it to know that you are talking about the wrong thing. So you cannot be expressing a fully informed opinion. The assumption that only systemd and van Smoorenburg init exist is a fallacy that was called out by the "Uselessd Guy" several years ago. * https://web.archive.org/web/20190306213420/http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ https://web.archive.org/web/20190306213420/http://uselessd.d... The thing that came immediately before systemd, on operating systems like Ubuntu and Fedora, was upstart. It was not van Smoorenburg init. And that was not systemd's only antecedent. On real Unices there were the Service Access Facility on AT&T System 5 Unix (replacing the running of services through inittab years before Linux even existed), Solaris' SMF, and the AIX SRC. On Linux operating systems there were all of the tools in the daemontools family except for the nosh toolset (which post-dates systemd), InitNG, OpenRC, and a whole bunch of others. * http://jdebp.uk./FGA/unix-service-access-facility.html http://jdebp.uk./FGA/unix-service-access-facility.html * http://jdebp.uk./FGA/inittab-getty-is-history.html http://jdebp.uk./FGA/inittab-getty-is-history.html * https://blog.darknedgy.net/technology/2015/09/05/0/ https://blog.darknedgy.net/technology/2015/09/05/0/

_emacsomancer_ 7y ago

I have a number of systems running with systemd and a number running with other inits (runit or shepherd). I continue to have more problems with the former than the latter two.