Devuan 1.0 Officially Released - Letting Debian Live Without Systemd

[Gusar]

I've installed OpenRC on Devuan. I've installed Runit as well (both under classic init or Runit PID 1).

But are they choices at install time, like Gentoo's Handbook prominently features systemd even though the default init for Gentoo is OpenRC (click)? And how many services in the Devuan repos that have sysvinit scripts also have openrc-run scripts and/or runit scripts? If you have to do a lot of manual work to get either of these inits running, then you could just as well start with Debian and go through the same lot of manual work, making Devuan nothing special in this regard. My point is, supporting an init system is more than just providing a package.

[nomadewolf]

And call the distro SystemDevuan

Badum, tsss
One cookie for this man, please!

[timtas]

On servers it can get there. Of course if you are on a home PC it's unlikely to matter.

AFAIK it's Devuan the most prominent one, others all have something less stupid where they add a plethora of scripts on top of sysvinit to extend its functionality.

Even OpenWRT/LEDE uses procd that is a poor man's systemd for init and processs tracking.

In modern days it's also about security and sandboxing, and good logging and decent process tracking. I mean, you might not care for your boxes, but that's what an init system must do in modern times.

Most end users should never need to interact with the init system, and even then it's not more complex than what sysvinit does. It's just new. Most people will learn how to operate it in like a weekend tops.

https://bugzilla.redhat.com/show_bug.cgi?id=726596 this is one of the examples why scripts can fail hard when using PIDs. (script writes down PID, does not notice its own application segfaulted and died, PID is reused by other process, script is triggered to kill application, script kills wrong application)

Your described problem regarding PIDs is real, but can be easily solved without systemd (checking the process name against the pid), so it's just another straw-man's argument.

As to what an init system is about: I guess it has become very clear that opinions differ on this matter. I guess for younger people coming from OSX or Windows, systemd is really cool, but for others familiar and comfortable with sysv init, it is often a solution looking for a problem, e.g. it solves already solved problems.

As to devuan in general: I don't mind it, but there is already an easy, documented way to disable systemd on debian, so I don't really see the point at the moment. Maybe in the future, when this is not possible on Debian anymore.

[unixfan2001]

Your described problem regarding PIDs is real, but can be easily solved without systemd (checking the process name against the pid), so it's just another straw-man's argument.

Yea. Not how software design works. Not how any of this works!
If you want to write shell scripts checking the process name, be my guest. But that's in no way reproducible nor sane. It's a hack.

As to what an init system is about: I guess it has become very clear that opinions differ on this matter. I guess for younger people coming from OSX or Windows, systemd is really cool, but for others familiar and comfortable with sysv init, it is often a solution looking for a problem, e.g. it solves already solved problems.

Read: People stuck in their way are perfectly fond of a broken mess and would rather it be left alone, so they can feel superior in their intense knowledge of shell hacks.

PS: The only reason people are "familiar" with sysvinit is that it's a broken mess people constantly had to tinker with.

[oiaohm]

Your described problem regarding PIDs is real, but can be easily solved without systemd (checking the process name against the pid), so it's just another straw-man's argument.

This is a straw-man counter argument.
1) It does not address the existing pile of sysvinit script that when told to stop a service just kill PID number that may no longer be the service.
2) Does not work safely where you running a service more than once. Because the process name where you are running a service more than once can be absolutely identical.
3) the suggest is a pure hack.


Comfortable with sysv init right that is openrc it puts a wrapper around starting the sysvinit files so that this existing fault cannot happen. You need the init system to assign a truly unique value per running service be this on some OS are tty assignments or linux cgroup/namespace assignments .

Another problem is called break away. This is where a parent of a process dies and that process now ends up connected to PID 0. Now what service do those processes own to under sysvinit can you tell the answer is hopefully. Again this is solved by the init system putting unique tag on a service. This issue can cause files to be locked so prevent you starting/restarting a service because parts of the service are still running disconnected.

runit avoids the PID fail issue gets caught by the break away issue. docker, openrc and systemd all avoid this problem because they are using namespaces/cgroups.

Debuan has gone to sinit but that makes no difference it has all the same defects as sysvinit except it not single threaded. Reality is broken.
runit is also broken due to not handing break away also not sysvinit syntax.
So the only part working by design init system in Debuan is openrc that is incomplete.

The list they are looking at include
1) s6 like runit does not handle break away so is broken, Is also not sysvinit syntax.
2)shepherd this one may be ok this when cgroups are used does handle breakaway issues again not sysvinit syntax.

So the only one that stands a chance of working that has sysvinit syntax in scripting openrc.

--leaving the best options, in our opinion, off the table--
This claim by Devuan is bull. The reality is most of the options on the table for init systems are broken bits of garbage. They have been built cross platform and complete ignore how the Linux kernel behaves.

So a init system starting services requires the following
1) need to make sure there is a system so that a service management kills what owns to the service.
2) handles breakaway events so that when you terminate a service all of that service gets terminated.

If a init system does not do those currently either need to be updated so it does or the init system need to go in the scrap bin never to be seen again.

I want to see efforts going into init system that can work. Not efforts going into init systems that should be let die.

[starshipeleven]

Your described problem regarding PIDs is real, but can be easily solved without systemd (checking the process name against the pid), so it's just another straw-man's argument.

Neat, then if the process name is wrong what you do? grep through the open processes and add a sapient AI to guess who among the 300 same-name processes is the one you wanted to kill? And what if it is the same name? How do you think servers hit PID limit in the first place?

Other inits solved this issue, I'm not claiming systemd is the only one, but please don't post this bullshit as it only shows you're a "Veteran Unix Admin".

As to what an init system is about: I guess it has become very clear that opinions differ on this matter. I guess for younger people coming from OSX or Windows, systemd is really cool, but for others familiar and comfortable with sysv init, it is often a solution looking for a problem, e.g. it solves already solved problems.

I'm familiar with sysvinit and
I can testify that nope, just fucking nope.

I've had to reverse-engineer pages and pages of scripts to find why that shit was failing to do its job, and it is almost always because of shell's idiosyncrasies and/or plain bad coding.
People doing sysadmin aren't programmers and should not be programmers, it's already hard enough to deal with other shit like the usual Windows programs breaking every other week.
If it was written in systemd units it would have been like 4 lines and it would NOT be code, just a simple config file with 0 ambiguity.

People that wanted to get the job done hailed systemd like the second coming of Sliced Bread.

[timtas]

Yea. Not how software design works. Not how any of this works!
If you want to write shell scripts checking the process name, be my guest. But that's in no way reproducible nor sane. It's a hack.

I know very well how software design works. But I wouldn't call an init script "software". And yes, I've written those hacks, but nowadays, this is all nicely wrapped in /lib/lsb/init-functions under the name killproc. Works like a charm.

Read: People stuck in their way are perfectly fond of a broken mess and would rather it be left alone, so they can feel superior in their intense knowledge of shell hacks.

PS: The only reason people are "familiar" with sysvinit is that it's a broken mess people constantly had to tinker with.

No, they are familiar with it because they know the shell language. It's obvious to me that in your opinion, shell scripts are pure evil, but I quite like them for small automation stuff. Which an init script actually is.

[timtas]

Neat, then if the process name is wrong what you do? grep through the open processes and add a sapient AI to guess who among the 300 same-name processes is the one you wanted to kill? And what if it is the same name? How do you think servers hit PID limit in the first place?

This usually means that the process has already died for some reason. If it hadn't died, the PID could not have been recycled. That's a kernel thing.

Other inits solved this issue, I'm not claiming systemd is the only one, but please don't post this bullshit as it only shows you're a "Veteran Unix Admin".

No, I'm actually an "Aged Software Developer" (C,PL/SQL,Java,PHP) and have done sysadmin stuff only for fun. But I'm running a few web and mail hosting server and they run quite fine with all this inferior sysvinit bullshit. Granted, they only run a webserver, an smtp server, an imap/pop server, a dns server, an ldap sever and two different rdbms'es on one machine, so I never got all those corner cases you constantly expierienced.

I've had to reverse-engineer pages and pages of scripts to find why that shit was failing to do its job, and it is almost always because of shell's idiosyncrasies and/or plain bad coding.
People doing sysadmin aren't programmers and should not be programmers, it's already hard enough to deal with other shit like the usual Windows programs breaking every other week.
If it was written in systemd units it would have been like 4 lines and it would NOT be code, just a simple config file with 0 ambiguity.

People that wanted to get the job done hailed systemd like the second coming of Sliced Bread.

I'm a "people that want to get the job done", too, and I didn't hail it. But I agree that sysadmins maybe shouldn't write init scripts. Where I worked, they always were part of the server software or the linux distribution, so mostly done by people that knew what they were doing.

[oiaohm]

I know very well how software design works. But I wouldn't call an init script "software". And yes, I've written those hacks, but nowadays, this is all nicely wrapped in /lib/lsb/init-functions under the name killproc. Works like a charm.

Really LOL. You have missed what is totally wrong with this.

Neat, then if the process name is wrong what you do? grep through the open processes and add a sapient AI to guess who among the 300 same-name processes is the one you wanted to kill? And what if it is the same name? How do you think servers hit PID limit in the first place?

As you said to this the process has died for some reason has been recycled and know you hack in /lib/lsb/init-functions has become a random number generator of failed.

You solution does not work because
1) not all sysvinit init scripts call killproc
2) You have not attached anything to the process to correct ID.
Name is not usable because you will have Sod law happen.
Sod law "if something can go wrong, it will".

Is is possible for two services to have the same name the answer is yes. Bad design does not allow for Sod law.

Also it not only killproc that is wrong. Status from sysvinit scripts using PID are going to tell you that a service is up when it already down due to recycling. Of course a recycle is going to happen at the worse possible time.

The idea that Linux distribution sysvinit note how timtas said mostly done by people that knew what they are doing. A percentage from distributions is done by a pack of people who don't know what they are doing. This is something where systemd come into it own reducing number of idiot mistakes.

The more lines of code that people have to type the higher the error count.

The conner cases that you may not have seen should not be there as flaws to come up on administrators.

Really I am sick to the back teeth of people suggest hey will we just add this extra to /lib/lsb/init-functions and that will magically fix it. I would not be saying go openrc if that would fix it. The reality mess with /lib/lsb/init-functions all you like it cannot fix this problem properly. All it does is hack over and make the conner case happen more rarely its never fixed the conner case.

[starshipeleven]

This usually means that the process has already died for some reason. If it hadn't died, the PID could not have been recycled. That's a kernel thing.

The issue is explained better by the other poster above, you are plugging only a tiny bit of the actual hole.

No, I'm actually an "Aged Software Developer" (C,PL/SQL,Java,PHP) and have done sysadmin stuff only for fun. But I'm running a few web and mail hosting server and they run quite fine with all this inferior sysvinit bullshit. Granted, they only run a webserver, an smtp server, an imap/pop server, a dns server, an ldap sever and two different rdbms'es on one machine, so I never got all those corner cases you constantly expierienced.

Most of the stuff I have to babysit has like 2 services at most, a frontend (usually webserver) and a backend (java or whatever), plus ssh server because reasons. May also be split with webservers on their own and backends on their own server, depending on what is decided by others.

The issue here is not the amount of server applications but the amount of requests served per second.
In many cases the server application is supposed to fork a process for each request.
It's not uncommon to see hundreds of processes with the same name at any given moment, and they usually don't last more than 5 minutes.

If it's a home server the init is irrelevant. If it's a generic dumb webserver it's also usually irrelevant, if it is an internet-facing system dealing with 2-way communication you don't want to lose (payments, database communication, social networks, ads system, and so on), then sysvinit's limitations are a problem.

I'm a "people that want to get the job done", too, and I didn't hail it. But I agree that sysadmins maybe shouldn't write init scripts. Where I worked, they always were part of the server software or the linux distribution, so mostly done by people that knew what they were doing.

Sysadmins need to write initscripts or systemd config because they run custom, unique, or their own company software that isn't in the distro's repo.
And this software is often a piece of shit so it needs uncommon babysitting, and the scripts to do that get long long long and complex.

I assume that to install the webserver/smtp/mail/dns/whatever above you just used your distro's package manager and adjusted some minor options, as that stuff is usually mostly pre-configured anyway. That isn't different with systemd. Debian and OpenSUSE for example ported the "service" command line program to work with systemd too.

Really I'm not saying you should migrate now to systemd if you don't really need it on your home server, just know that its limitations make it unfit for serious use.
What you are doing above is saying that since Arduinos can have/control nearly as many IO ports then you don't need the PLC boxes used in industrial automation, which is a nope.