Escape from System D, episode VI: freedom in sight
davmac.wordpress.com
davmac.wordpress.com
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.
(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.
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.
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
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.
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.
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).
$ systemd-inhibit --list
Cue "applications-shouldn't-depend-on-systemd-we-need-350-competing-init-systems" folk.
I actually enjoy the extra flexibility that I get out of being able to tell systemd how to terminate processes. On the systems I'm building. But it's something that could certainly be improved. It works right for my use case (embedded systems) but I hate it when it does it on my laptop or my home machine.
The whole interface around it is silly. It tells you that a job is running, but it doesn't tell you what that job is, what that process is, and unless you enable the debug shell, there's no way to check it or kill that process either. All you get to is stare at the thing counting down from 90, and in some cases when it reaches 0, it starts counting down again instead of rebooting.
Atleast in my experience, systemd certainly tells you what is hanging. The issue with "timer reset" is that some service that is hanging is also blocking some other service from shutting down (either because the hanging service depends on it or the blocked service needs to be shut down after the hanging service). Old Init systems didn't care either, if the system was to shut down, it just killed in order of runlevel so stuff like "The database was corrupted because init forcibly killed the NFS mount too early" was certainly possible.
i doubt anyone would complain about systemd with such a message. its just beyond annoying not being able to see which application is causing the issue nor having any options beyond waiting or removing the power entirely
That message, and this approach, is 100% inconsequential, and it doesn't make anything safer. IIRC, last time I checked, virtually none of the distributions enable the systemd debug shell. If you see that message, you can't stop the application manually. Ctrl-Alt-Del doesn't work, either, and if systemd can't recover from that state -- which, depending on what's actually happening and on the configuration, it sometimes can't -- all you get to do is press the reset button anyway.
If an application is hung for a legitimate reason, like, there's unsaved work, you can't go back and save it anyway. All you can do is wait for 30 seconds for the system to reboot and lose the data anyway (just 30 seconds later).
That aside, I've debugged my fair share of corruption, back when journaling filesystems were new and NFS was way worse than it is today. I don't want to go back to those days, either, and I'm glad to have a safety switch for sensitive setups, or for misbehaving/legacy applications.
But no one has a problem with that. People have a problem when they don't have anything mounted over NFS (that, by the way, is also something that occasionally caused systemd to hang at one point) and still can't reboot their machine.
It's not like we had to wait until 2010 to figure out that init systems need to handle these things carefully. Nobody compares this behaviour with the golden age of Ultrix and says oh, right, thank God for this, it's a minor inconvenience but at least my files are safe. Everybody compares this with what's available on every other platform that's popular today, not in 1996 -- namely a "Force reboot" button that reboots your machine and virtually never results in data loss.
Why does a program given SIGTERM not quit? Is it because 1) it's still busy desperately trying to save something large and unusual or over a network, 2) it's antisocial and ignores SIGTERM, or 3) it's hung for some permanent reason?
It's hard to tell from the outside.
Most of the time it's the second or third, but the behavior occasionally saves data in the first case.
(Edit: Firstest of all, actually, more often than not it's actually 4) the program is waiting for a user's confirmation, or requires some user action to exit, but if you see that message, you can't do it anymore.)
First of all, not being able to distinguish between these three cases is precisely what makes virtually everyone who's seen this a couple of time hit the reset button as soon as they see it. That doesn't save any data.
Second, if a program is really busy desperately trying to save something large and unusual over a network and you see that message, there's a good chance it won't be able to save anything anyway. The network is usually down by that time, for example.
There's also no way for a program to signal that it's done. If, indeed, a program needed one more second to write everything, it's cool, but you still get to wait 29 more seconds.
And finally, processes ignoring SIGTERM is really just one of the reasons why this happens.
I think all of us in the FOSS community should be more charitable when discussing these things. systemd is a big step ahead but it's not like we had to wait until 2010 to figure out that init systems have to tread carefully during shutdown to avoid data corruption.
Also, people who read HN usually understand that killing processes can cause data corruption under some circumstances. Just sayin'.
It saves data if you don't mash the reset button at first sight
>Second, if a program is really busy desperately trying to save something large and unusual over a network and you see that message, there's a good chance it won't be able to save anything anyway. The network is usually down by that time, for example.
Systemd won't bring down the network until all services that depends on the network have been stopped. The desktop environment doesn't unless the home directory is a NFS mount.
>There's also no way for a program to signal that it's done. If, indeed, a program needed one more second to write everything, it's cool, but you still get to wait 29 more seconds.
A program running as a service can override the timeout in it's unit file.
>And finally, processes ignoring SIGTERM is really just one of the reasons why this happens.
Correct, processes who ignore SIGTERM are the real problem, processes that take a long time are a secondary culprit. But systemd can't do much if the devs of software refuse to read documentation on signals when writing handlers for them.
* https://news.ycombinator.com/item?id=15896376
Machine shutdown is one of the parts of service management that often does not get enough attention.
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.
Could you expand on that?
Poorly managed - Pwnie award, "it's not a bug" from Poettering etc etc.
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.
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.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
Systemd might have its flaws but I'm so grateful that a service/unit file will work on pretty much any distro and that my knowledge of it will serve me on pretty much any modern Linux system, as opposed to years ago where every distro had their own unique way of managing services.
HOWEVER - the Linux world has lived with these problems for ages and I deem it also a strength. You can switch around components, mix and match and it will mostly work. You can run KDE apps on GNOME no problemo. I think this is something we should consider a positive. If we can unify around a common service file language, we can swap out service managers easy.
well you can also run KDE apps on windows and macOS so it would be quite the shit show if they did not run on GNOME :-)...
A system need to be designed first, proved correct first.
This doesn’t have to be the case; there can be multiple implementations of one standard (like we have it the web).
True about the knowledge part, but that often leads to the adoption of suboptimal solutions. I know that the quest for absolute purity is also a problem for a lot of devs but many newer "consolidated" operating systems, especially in the mobile segment, should serve as ample warnings. Yes, those are successful, but they are also basically shit. And that is an objective assessment.
Just provide a single source and get on with your day. It's Linux after all. No need for huge monolithic binary piles of crap from Poettering to start your system.
This was the motivation behind snap / flatpack / appimage. We're getting there. Not in the way I'd prefer, but for end-user apps it works.
Dinit has been booting my own system for a long while, and other than a
few hiccups on odd occasions it’s been quite reliable.
Ok, compared to Systemd it lacks some features. It doesn’t know anything
about Cgroups, the boot manager, filesystem mounts, dynamic users or
binary logging. For day-to-day use on my personal desktop system, none
of this matters, but then, I’m running a desktop based on Fluxbox and
not much else; if I was trying to run Gnome, I’d rather expect that some
things might not work quite as intended (on the other hand, maybe I
could Elogind and it would all work fine… I’ve not tried, yet).
On the plus side, compared to Systemd’s binary at 1.5mb, Dinit weighs in
at only 123kb. It’s much smaller, but fundamentally almost as powerful,
in my own opinion, as the former.
Follow the handbook, it's worth it. Once that gets too tedious, checkout https://github.com/jakeogh/sendgentoo
Slackware(1993!) has been around longer than Gentoo(2000), but USE flags, slots, _choice_ and control over the compilation stack are pretty nice. NixOS's package manager and portage hopefully merge sometime in the future. I havent tried Void.
We didnt need to have the init system debate, it was never a possibility that Gentoo would be monoinit.
[1]: https://www.shlomifish.org/humour/by-others/funroll-loops/Ge...
It was still a Linux distribution and back then, no one had ever thought of systemd.
Saying using systemd turns Linux into Lindows just shows how ignorant you are of linux history, of that "systemd" thing you've just heard of and of what makes Linux and Windows different.
Being a Gentoo user doesn't make one into a Linux guru. In fact, starting your comment by stating you're a Gentoo user as if it will give more weight to what follows is just plain arrogant. It shows that you're definitely not a linux guru, what distribution you use/have used don't matter at all for that.
I feel for Gentoo users, people like you make them look bad.