Systemd In Ten Years Has Redefined The Linux Landscape

[skeevy420]

30 years ago I was able to stick stuff in autoexec.bat and it started automatically when the computer booted.
20 years ago I moved to Linux and figured out the init system. Put stuff in there and it started automatically when the computer booted.
Today after my computer starts I get to manually start the database server and NFS. Then restart the web server.

No, systemd hasn't made my life better. The old init system worked, systemd doesn't.

Really? Here's my generic template.

It's this easy:

[Unit]
Description=A description

[Service]
Type=oneshot
ExecStart=/path/to/something
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

1. name that "foobar.service"
2. copy "foobar.service" to "/etc/systemd/system/foobar.service"
3. give it 644 permissions
4. treat it like any other systemd service; "sudo systemctl start foobar.service" to run once; "sudo systemctl enable foobar.service" to start on boot; etc)

Use Goolge or your search engine of choice to look up more advanced information, but that template works just fine to load up simple scripts on boot. Here's an actual one of mine for a working example (w/o the script it uses because you can generate your own with WattmanGTK).

[Unit]
Description=Apply WattmanGTK settings

[Service]
Type=oneshot
ExecStart=/usr/local/bin/Set_WattmanGTK_Settings.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[Tuxee]

30 years ago I was able to stick stuff in autoexec.bat and it started automatically when the computer booted.
20 years ago I moved to Linux and figured out the init system. Put stuff in there and it started automatically when the computer booted.
Today after my computer starts I get to manually start the database server and NFS. Then restart the web server.

No, systemd hasn't made my life better. The old init system worked, systemd doesn't.

You put quite some effort into breaking your setup. That's quite an achievement.

[pkese]

Thanks to whomever posted the link to https://www.youtube.com/watch?v=o_AIw9bGogo
It is a great and unbiased (FreeBSD perspective) look at systemd.

[Britoid]

I liked service status more than systemctl status, service scripts have less boilerplate now, the new security bugs should have been avoided with rust. otherwise systemd is not changed anything for me.

You're completely reliant on a shell script to implement the status functionality, so I don't know how you could prefer it given they're all different.

[bachchain]

That said, the thing I really do not like with systemd is the idea to put in one big software things that should be independent.

You must really not like GNU, then.

[Veto]

Really? Here's my generic template.
It's this easy: ...

Exactly! I never managed to get around to write one of these fragile ~50 lines shell scripts needed for the old init system, so I just had to make do with some small hackish scripts called from rc.local. But I recently tried making one of these ~10 lines systemd service files with success. It is really not hard!

... And rc.local still seems to work for the odd hack.

[ALRBP]

You must really not like GNU, then.

Ridiculous.
GNU software are independent.
glibc, GCC, Bash… all those things are independent.
GNU software works great independently, even on *BSD systems, unlike systemd.
Comparing systemd with GNU is absurd.

[Farmer]

You put quite some effort into breaking your setup. That's quite an achievement.

You put more effort in typing that post than was spent in messing with a setup. That's quite an achievement. You get a participation trophy.

:>systemctl enable mariadb.service
ok
:>systemctl start mariadb.service
ok
:>systemctl enable nfs-server.service
ok
:>systemctl start nfs-server.service
ok
:>systemctl enable httpd.service
ok
:>systemctl start httpd.service
ok


reboot. No database or NFS. Httpd running fine.

:>systemctl enable mariadb.service
"Your spell still has no effect."
:>systemctl enable nfs-server.service
"Your spell still has no effect."
:>systemctl start mariadb.service
ok
:>systemctl start nfs-server.service
ok
:>systemctl restart httpd.service
ok

* When systemctl enable httpd works
* But systemctl enable mariadb and systemctl enable nfs-server don't.
* But they start fine manually.
* The software is borked. Fanbois opinions not withstanding.

I'd write a bash script and hit that when the machine starts but I'd have to care more. I'd spend the time to figure out what's wrong but I'd also have to care more. Some of you missed the point. It works more poorly than the predecessors. That I refuse to spend the time and effort tracking it down notwithstanding. Much less effort just to start them on boot manually.

I do work on my computer. Instead of work on my computer. Whenever possible.

[oiaohm]

30 years ago I was able to stick stuff in autoexec.bat and it started automatically when the computer booted.
20 years ago I moved to Linux and figured out the init system. Put stuff in there and it started automatically when the computer booted.
Today after my computer starts I get to manually start the database server and NFS. Then restart the web server.

Really I don't know what you are doing wrong here. I have systemd start everything I need. Thinking systemd has sysvinit emulator so everything you did with sysvinit still works with systemd.

No, systemd hasn't made my life better. The old init system worked, systemd doesn't.

This is not fact that the old system init worked.

Lets do a corrected timeline without personal bias crap.

System V Unix appears 1983
1992 sysvinit appears for Linux what is basically reimplemention of a system that is 9 years old at this point. It was not designed for Linux either. http://git.savannah.nongnu.org/cgit/.../doc/Changelog
Yes sysvinit was design for a Minix kenrel. Yes Minix does handle PID/processes different to a Linux kernel.
All your early Linux distributions pick up and modify sysvinit because this is simpler than coding something that in fact works. Partly due to missing kernel features and bugs in way Linus implemented process handling making something that in fact works at this point is impossible and stays this way for a darn long time.

2001 daemontools appears because there is issues with service management. The defects at kernel level means this can never work exactly right on Linux at this stage it works well on freebsd and minix.

2004 Runit appears attempting to fix sysvinit defects using daemontools methods. Yes still still stuffed.

2005 Initng appears most distributions switch to this to fix the sysvinit single threaded start up and shutdown problem. This end up merged back into sysvinit by 2007. This has not fixed the process management problem in fact has made the race condition risk worse.

2006 Upstart appears attempting to fix problem with sysvinit and other init systems for Linux by using ptrace to track what processes service in fact started this fails hard. Yes upstart was picked up by majority of distributions before systemd appears.

2007 Cgroup feature that will come known as Cgroup v1. This provides another option to track processes that would not have the nightmares of ptrace.

2008 Openrc appears attempting to fix the problems with sysvinit and other init systems for Linux. Developers having a hard time getting anywhere to these developers cgroups v1 is appearing not to work right so they keep on back way from use it early on. Still suffering from once bitten twice shy problem over cgroups.

2010 Systemd appears with a developer willing to go all out to address the sysvinit problem even if it causes hell.

2013 Systemd is picked by distributions So yes 20 years latter compare to when we started using sysvinit. Note we are over a decade in to attempt to fix service management/sysvinit with failure after failure at achieving this goal.

2016 Cgroup v2 appears because from systemd usage of cgroup v1 its absolutely clear past any question in design is broken as cgroup v1 can completely lock up system. At this point the Linux kernel now has enough to finally be able to track what a service has in fact started safely as long as you use cgroupv2. Something you could do in Minix this complete time from 1987 in fact due to different process table implementation.

But there is still a problem. Killing processes are bring out a race condition in Linux and does under Minux as well. This problem is coming from the Posix standard so all Unix and related OS problem.

2019 we finally get pidfd for Linux https://lwn.net/Articles/794707/ at long last you can kill exactly the right process under Linux all the time.

So its taken 28 years ie 1991 to 2019 to get the Linux kernel to the point that the kernel provides all the features to write a init/service management system that works properly may be possible. Its going to take into next year for systemd to get pidfd usage in and another year for it to be in all common distributions. So 30 years to get at least 1 init/service management solution that technically works with the Linux kernel. Please note this is if pidfd does not turn out to be another cgroup v1 and have to be reworked. Fingers crossed we have made it finally to a functional kernel.

The foundations are now in place to make init/service management systems that may fact work properly on Linux instead of the broken crap we have had up until now.

This is something those anti-systemd people never do is see the time line to see that many people were in fact upset with sysvinit there have been 5 different groups who know what they are doing who have been upset with it. Like it or not change had to happen. If you don't like systemd you really do need to be coding on openrc or some new solution using cgroupv2 and pidfd that works the way you want.

[starshipeleven]

That said, the thing I really do not like with systemd is the idea to put in one big software things that should be independent.

systemd is a project composed by many daemons

What's next, complaining that "coreutils" (aka GNU command line tools) are one big software?