Systemd In Ten Years Has Redefined The Linux Landscape

[oiaohm]

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.

Welcome novice stop blaming systemd for you problems. Be thankful for it.

This totally reads like a total novice screwup.
https://dev.mysql.com/doc/refman/8.0...sk-issues.html
One its not recommend to have mariadb or mysql on nfs share.

I don't see you checking you systemctl for a failure status information. I would suspect that nfs-server is failing because the network it need is not starting up.

Starting manually is starting after the networking and everything is up. Could be that network manager is only like connecting your wifi network after you are logged in. Setting mistakes or lack of settings cause these problems even with the older sysvinit systems.

Please note I have had nfs-server not start when using sysvinit systems for the same kind of reasons. I have also had the case where mariadb fails to start on a sysvinit system on system start up then will not start manually at all. Why a process has leaked and its now locked a file so mariadb cannot start. Systemd cgroups around services means if a service fails to start properly it in fact stops it all so you can manually start it latter without issue. Basically since systemd did that for you and you don't thank systemd that you can even start the service manually latter instead want to blame it for your problems.

"systemctl start nfs-server.service" << this manual line of yours may not have been required.

I guess you did not run systemctl between commands to see what was started. Systemd can be quite smart you ask for "systemctl start mariadb.service" it sees attempted access to where nfs share should be and auto attempts "systemctl start nfs-server.service" since it was enabled but failed before. So systemd will allow you do things out of order to address problems at times.

Exactly why were doing the "systemctl enable mariadb.service" lines when something had started before doing a "systemctl" to see the status of your services. If they are listed they are already enabled.

More useful of course would have been "systemctl status mariadb.service" and "systemctl status nfs-server.service" yes you had status check options under sysvinit and you had to use them as well.

I would not say the software is borked in this case the "Problem Exists Between the Keyboard And the Chair." The PEBKAC wants to blame systemd instead of admit its a configuration error that can happen with any init/service management system that has to be diagnosed leading to a configuration alteration that needs to be done.

I see this a lot lets blame systemd instead of having to learn how todo stuff properly.

PS you can alter system with systemd that the http server does not come up unless the database server is started as well to prevent those accessing site getting access to a webpage in broken state due to missing database. This can be highly important at times with login databases.

[aht0]

That's not what happened. They looked around. They for instance had a look at Apple's launchd..

They obviously didn't look beyond launchd or were blinded by NIH syndrome. Or were very afraid to actually find something.
Fuckin' article is 8 years old. By then, daemontools had been around over a decade. And it's not the only of it's kind either..

https://isotope11.com/blog/manage-your-services-with-daemontools

[k1e0x]

No hate here.. but I just believe it was the wrong choice for Linux. It caused me to stop using Linux personally and focus on FreeBSD as an alternative. (and I'd been a full time linux user since 1994) All my personal servers were running FreeBSD by 2012, something I don't regret.

I think OpenRC does 99% of what systemd does/should do and it's clearly just a simple init system. This was the right choice and they missed it.. It almost reminds me or Apple Pink/Blue.. where every idea is valid and ok because the project has no scope.

[Britoid]

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.

If that is true that is almost certainly down to misconfigured units then anything actually wrong with systemd itself. systemd is used in mission critical envrionments (as part of RHEL), so I doubt a bug like that would exist in systemd itself.

[Britoid]

No hate here.. but I just believe it was the wrong choice for Linux. It caused me to stop using Linux personally and focus on FreeBSD as an alternative. (and I'd been a full time linux user since 1994) All my personal servers were running FreeBSD by 2012, something I don't regret.

I think OpenRC does 99% of what systemd does/should do and it's clearly just a simple init system. This was the right choice and they missed it.. It almost reminds me or Apple Pink/Blue.. where every idea is valid and ok because the project has no scope.

OpenRC does maybe 5% of what systemd does.

[k1e0x]

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.

I was there during this entire timeline.. and I can see that just fine that it's a strawman. (maybe you believe this is true, who knows) I don't like sysvinit, nor do I like systemd. Just because one is bad doesn't mean the other is good.

Perhaps we can reconcile some of the systemd hate here.. It's the holidays. I simply believe it was the wrong choice. OpenRC is the correct approach. (or other highly functional, modern limited scope init, I'm not solely sold on one thing)

The problem with systemd is the same problem with btrfs (not to start another flame up)
Too much code was written too fast without any direction or scope. That is a plague in Linux with it's popularity now.

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.

This is his own opinion. FreeBSD may get a new init system, and no.. that wouldn't be bad.. but you can be assured that it will look nothing like systemd.. again.. OpenRC was already ported to FreeBSD and is used by default for TrueOS, GhostBSD, Project Trident and others. (Possibly FreeNAS uses it too) FreeBSD takes a lot of time and care when implementing stuff.. they do so from a "entire OS" engineering perspective. It isn't various companies trying to one up eachother.

Also OpenRC was originally a NetBSD thing anyhow before Gentoo started using it..

[k1e0x]

OpenRC does maybe 5% of what systemd does.

*should* do.
Ironically systemd also does about 5% of what it should do.

[k1e0x]

I had been working with launchd some and where as I don't like it really.. if Linux decided to use it, I wouldn't have as much of a problem with that as I do systemd because it has a limited scope. The problem is actually much larger than systemd itself though.. it is that Linus' Unix being controlled by powerful corporate companies has lost all reverence for history. It has no overall direction other than the goal of RedHat (IBM) corporate server dominance and vendor lockin.

I've been looking at the development of a new Unix like system Redox, and it's really refreshing to see they are able to look at other systems and do seem to be taking the right approach. https://youtu.be/G4VlHzyKZeE?t=798

[oiaohm]

I was there during this entire timeline.. and I can see that just fine that it's a strawman. (maybe you believe this is true, who knows) I don't like sysvinit, nor do I like systemd. Just because one is bad doesn't mean the other is good.

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 the correct approach. (or other highly functional, modern limited scope init, I'm not solely sold on one thing)

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.

The problem with systemd is the same problem with btrfs (not to start another flame up)
Too much code was written too fast without any direction or scope. That is a plague in Linux with it's popularity now.

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.

I've been looking at the development of a new Unix like system Redox, and it's really refreshing to see they are able to look at other systems and do seem to be taking the right approach.

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.

I had been working with launchd some and where as I don't like it really.

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.

*should* do.
Ironically systemd also does about 5% of what it should do.

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.

[Paul Frederick]

This should be a calm and non-controversial topic.
Let's all post only our thoughts on the technical merits of systemd and how it has improved our lives.

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?