Systemd In Ten Years Has Redefined The Linux Landscape

[arokh]

Recently, I had to set up some service on my personal server (Debian) that required several processes to be started and kept active. To do it in the systemd way (I wanted to do so), without any script, I had to create several services with dependencies. Systemd service files are less convenient than good old init scripts when you want to do something complicated (but I must say that, once set up correctly, it works great).

This is ridiculous, here we have one more guy that just don't know how to read the manual and blame it on systemd. You realize that keeping services and it's dependencies running is it's ace right? Less convenient when doing something "complicated"? Incredible.

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.

Your opinion on something you are unable to even operate isn't that interesting, it's like listening to someone who can't drive a car explain about car engines.

[oiaohm]

My favorite Desktop Environment failed to work with SystemD so it caused me to go back to using a Window Manager I'd used over 10 years ago. I'm not sure how going backwards is an improvement. Oh SystemD idling at ten times the RAM I used to use has justified having more RAM today. Another win?

One learn to type systemd right. Also I don't get where you come up with that ten times the ram idling. Something those found in embedded space is systemd in fact results in less memory management than upstart, sysvinit and busybox init. There is something horrible wrong with the way the non systemd options does things lots of crap is put into environmental variable that end up replicated with most service started so eating more memory. Yes systemd shows some large processors in your process tree but its also caused almost all your services to shrink in memory usage so horrible as it sound systemd is lighter in memory usage over all.

This is what happens when someone looks at a process table not total system memory usage. Yes this systemd is heavy in memory usage is one of those commonly pulled out bogus arguments that is totally false. Systemd makes it a lot clearer to see how much memory you service management solution is in fact using instead of hiding it in every service started.

[Britoid]

My favorite Desktop Environment failed to work with SystemD so it caused me to go back to using a Window Manager I'd used over 10 years ago. I'm not sure how going backwards is an improvement. Oh SystemD idling at ten times the RAM I used to use has justified having more RAM today. Another win?

Did you go into a dictionary and pull out random words?

[F.Ultra]

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

And instead of Googling you can also just type "man systemd.unit". systemd is documented like no other piece of open source software.

[Paul Frederick]

Did you go into a dictionary and pull out random words?

Where did you pull your words out of? Wait, don't tell me!

[oiaohm]

Where did you pull your words out of? Wait, don't tell me!

Get the point already. You don't mention the Desktop Environment that had problem by name maybe cause if you did we would know that you were fibbing. You could not type the Systemd name right. You make a non fact claim about memory usage.

Basically what was in your post that was possible right. Basically it was a underhanded comment that you basically posted random garbage that most appears to be complete fiction written by someone who really knows nothing and has never used linux because they are just some paid troll to cause trouble.

[Paul Frederick]

Get the point already. You don't mention the Desktop Environment that had problem by name maybe cause if you did we would know that you were fibbing. You could not type the Systemd name right. You make a non fact claim about memory usage.

Basically what was in your post that was possible right. Basically it was a underhanded comment that you basically posted random garbage that most appears to be complete fiction written by someone who really knows nothing and has never used linux because they are just some paid troll to cause trouble.

What difference does it make what DE I was using? It was the DE I was using. How about you be more wrong.

[k1e0x]

The timeline is not 100 percent pro systemd. It what has got us where are are now. Please go back and read carefully. Its not a strawman arguement the problem has been visible for quite some time.



OpenRC is not complete yet in it cgroups around services or its usage of pidfd to make sure it kills the right process. Its close but not ready.



You are wanting to make something to test out a subsystems in a kernel to make sure they work. What systemd has done is ideal for this. This is what gives us the proper foundation today to build on top of. We would not have stable cgroup v2 today without systemd giving it a heavy work out. Will we always need systemd going forwards maybe no. But we need that event to happen.




Yes I do like Redox they have real policy that everything is a file and mean it. This include process interfacing. So Redox comes out box with pidfd equal that is important. Lot of Unix and Unix like lake the means to use a handle to interface with a process instead you only have PID that can have race condition ie your application is attempting to send kill to PID 100 but what happens at PID100 is it crashs and the OS reuses PID100 for some other process now you send kill signal to completely wrong process. https://lwn.net/Articles/794707/ Also Redox has namespaces design fairly close to cgroup v2. So Redox is on the right track to a proper good OS.

But its going to be if Redox gets the hardware support.

Linux kernel is on path to a proper good OS kernel by being dragged kicking and screaming in that direction.


You don't have equals pidfd or cgroups on OS X. So launchd is fairly much screwed from providing stability as well.

Basically there is a list functionality you need to make good service management.

1) You must be able to kill the right process no matter what happens and must fail correctly if that process is already dead when you send signal(no kill any other process that has got the same process id number). This means you must have some solution so you can use a handle to a process that you can use to identify that is the correct process and send a kill signal to it. PID number is not this. pidfd is or like Windows process handles. Linux kernel only gets this year. OS X does not have this. Most Unixs don't have this. Redox does have this. Freebsd does have a different means of doing it as well

2) You must be able to tell what processes were started by a service. cgroup give this under Linux. namespacing under Redox gives this as well. You don't have this under Windows or OS X properly yet. Windows developers are working on sandboxing stuff to give them this in time..

3) Your Service management system has to take advantage of this stuff. This is why Openrc is not ready yet.

4) You need service logging that cannot be lied to.

5) you need service watchdog so key services can be detected as failed when they have not in fact crashed.



This is wrong about 25% of systemd is what you need for properly managed services. The 5% roughly of what systemd does is what Openrc does is right . Problem here is your idea that 5% of systemd is required todo what it should do is wrong. Openrc is still lacking lot of the cgroup support and proper protection to prevent log faking and is still missing the pidfd stuff and finally where is your service watchdog. Fix all this up and Openrc could be one good competitor.

So 5% claim against systemd of what it should to is wrong. Please note I am not saying that systemd is not doing too much. 75% of systemd could go away no problems. Openrc is not quite doing enough yet. Openrc does have the foundations that it could be good in time with enough investment in development to close that feature gap.

There is no point getting these claims wrong because it only means you don't see the work that needs doing.

This is a good post!

(% talk is all a joke, thought it was ovis)

Yes. I agree with a lot of that. I think Linux cgroups and namespace is part of the problem. That needs to be re-engineered honestly a lot more like Solaris Zones (something that is the model for Redox) and true process isolation and containerization. FreeBSD has jails and separate PID's in them, that is a better model, but it's not quite as robust as Zones. (still much more so than cgroups and namespace though) - Linux is kind of working with a cobbled together solution to provide this when they need to go back to the drawing board and get it right in the first place. They are building on top of a wobbly foundation.. again.. as usual. It's really a shame they are trying to fix this stuff with systemd upstack instead of solving the hard problems.

Determining if a pid has gone down, needs to go down, or has been reused is a much larger topic and a philosophical one. I find I'm often of the opinion that if a process dies it should not be restarted, it should core dump and be investigated to find out why it went down and fixed as it isn't operating as intended and therefore needs a fix. Restarting it is very "windows sysadmin esque" and that bothers me a lot that Linux seems to think this is ok. That's a major point of contention I have with systemd and Linux in general. - There are some things where this behaviour is ok, necessary and good.. but those are edge cases and should not be the norm.. In my opinion.

One of those edge cases might be automotive.. yes, you want the service to restart.. but would you want this restarting behaviour to be occurring all the time in your car or your airplane or would you want the software to be well tested so it does not restart at all? Making it the norm makes failing services the norm and I don't want to be on a plane with failing services. Outside of that in server space we have HA practices that generally make the need unnecessary.

It feels to me a lot of this stuff is coming out of the Desktop Linux department, where that behaviour is more ok. I have a problem with that.. Linux is a server OS primarily. Just like FreeBSD and Solaris. Sorry if thats not OK with some people and you want "the year of the Linux/*nix desktop" (really that is macOS anyhow) .. I run FreeBSD on the desktop. Do I expect it to not act like a server? no.. I'm on my own.. and that is something I expect.

I think the moral of this story is OS development and improvement still has a long way to come.

[pal666]

Nice idea. Awful implementation. Megalomaniac developer.

imbecilic haters

[finalzone]

Paul Frederick
Tell the name of the Desktop Environment you use. You started the claim related to systemd so the burden of proof is on you.