Devuan 1.0 Officially Released - Letting Debian Live Without Systemd

[oiaohm]

In systemd you need to create your scripts to run on a systemd service..no the systemd service file is simpler, but your script that will be executed its almost the same..
The amount of work needed in sysVinit to do the same is almost the same as in systemd, no gains on that regard.

Once you are putting cgroups and namespaces around you services sysvinit scripts don't come fun any more. For the Linux kernel default scheduler to work right you need cgroups. Yes sysvinit is less work when you are not meeting what the Linux kernel scheduler requires. Manually allocating cgroups to services in sysvinit is path to human error and massive failures. Systemd .service file process by something smart enough to avoid incorrect allocations in cgroups is a massive improvement.

But you will have to create the scripts systemd services call...so in the end...the same capability, but worst..compiled code and a init system that pretends to be a Operating System..

I have a problem here majority of services converted to systemd I have seen directly call the executable binary no scripts. This is like you have never read systemd .service files to see what they normally contain.

Yes when systemd is coverting sysvinit service scripts to systemd tracked you have scripts called a lot. But when you have native systemd services very little script usage. Also I guess you have never used systemd a lot just pure avoid it.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-managing_services_with_systemd-unit_files

.service files of systemd has a lot of human error reduction. You need to add something to a .service file under systemd you don't need to edit the service file instead you create a .conf file in a .d directory of that service file.

Systemd service files design is designed so human error is controlled. Yes this .d usage had come standard in lots of other services just never made it into the init system. .d extending does not suit scripted files.

/etc/init.d/rcS on inittab
will go after all scripts in /etc/init.d

Pure systemd system those directories don't exist. Pure systemd systems are using .service files only.

[tuxd3v]

Pure systemd system those directories don't exist. Pure systemd systems are using .service files only.

Of course they don't exist..._EXPLICITLY_,
BUT they exist somewhere in the code, not in the exact same form, but happens to do the same thing, plus a lot more things that are avoidable.

Seems that you do not adapt Big Midleware Infraestructure products..to your operating systems..
In that products, you do need to deal with some thousands of lines, could be bash, ksh,csh,perl,C or whaever, and in the majority of the cases you don't have that "binary thing"..that you have in desktops..
By the way, lots of that machines could be running AIX5,6,7, or Linux in a variety of forms, and arch's

With systemd you need to create the script, them create the service, and only then, its the same as SysVinit...enabling the service.
But even then you get always systemd messing with your stuff..

Its the same garbage as Network Manager that in fact come from the same 'dark-side' company called RedHat..
Yes unfortunately, I deal with hundreds of servers RedHat too, unfortunately..

[oiaohm]

[QUOTE=tuxd3v;n1052797]
Of course they don't exist..._EXPLICITLY_,
BUT they exist somewhere in the code, not in the exact same form, but happens to do the same thing, plus a lot more things that are avoidable.

Seems that you do not adapt Big Midleware Infraestructure products..to your operating systems..

Some are systemd aware some are not. So no its not that I don't use Big Middleware infrastructure I would guess I would have a broader experience with it.

In that products, you do need to deal with some thousands of lines, could be bash, ksh,csh,perl,C or whaever, and in the majority of the cases you don't have that "binary thing"..that you have in desktops..

Lot of the cases when you covert to systemd those thousands lines drop to less than 200 lines in service files. If you have never done the process of full conversion from script start up to systemd service files you don't understand the differences.

Like you would not have done

https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html

Setting up the environmental variables from the service files.

By the way, lots of that machines could be running AIX5,6,7, or Linux in a variety of forms, and arch's

This most likely means you have not spend enough time researching the Linux kernel to understand how it different.

With systemd you need to create the script, them create the service, and only then, its the same as SysVinit...enabling the service.
But even then you get always systemd messing with your stuff..

Majority of the time if you have created a script with a systemd .service you have made a critical error.

You should only have 1 service per unit/.service file. This is not about a systemd limitation. Each .service gets it own cgroup. The Linux kernel standard schedulers designed for servers in Linux depend on cgroups around your services. Yes a script inside a systemd .service file starting multi services starts you losing system performance like you lost when you were using SysVinit.

Even under Sysvinit linux where you are falling back on autogroup(what is a system to attempt to auto assign cgroups) you don't want large multi service starting init scripts. Yes multi service init scripts don't cause trouble under AIX but they are a big thing you should avoid where you are running on a Linux kernel.

If you read docker documnetation

https://docs.docker.com/config/containers/multi-service_container/

You will also see multi service per container are not recommended this is the same problem.

Under the default Linux kernels in all server distributions cgroups are always messing with your stuff the question is do you have any control over it or understanding of the rules.

Generally Linux kernel compatible sysvinit scripts should not be longer than 500 lines majority should be less than 200 lines. Systemd service files most should be less than 50 lines with no scripts straight up starting the required binaries.

Just by correcting this stuff I have seen even with sysvinit 20 to 30 percent through put gains on particular workloads. This is why I am not anti systemd I know systemd like it or not used right gives you control over the cgroups system that will be messing with your performance anyhow.

Now openrc need to be filled out more. But the many thousand of line start up scripts you see in a lot of middle ware needs to die its Linux incompatible crap.

Also when a person says that for systemd to be the same as sysvinit it need to run a script means they have not read though the conditional options of service files or many other features. Once you cut a sysvinit file to what it should be it translates into .service files. Only reason why something does not translate to .service find most of the time is that you have multi things in your sysvinit files that you should not have. Features in sysvinit files that harm Linux performance.

[tuxd3v]

[QUOTE=oiaohm;n1053029]

Some are systemd aware some are not. So no its not that I don't use Big Middleware infrastructure I would guess I would have a broader experience with it.


Lot of the cases when you covert to systemd those thousands lines drop to less than 200 lines in service files. If you have never done the process of full conversion from script start up to systemd service files you don't understand the differences.

Like you would not have done

https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html

Setting up the environmental variables from the service files.


This most likely means you have not spend enough time researching the Linux kernel to understand how it different.

Who told you that I was thinking that Linux Kernel is equal to Aix kernel..?

You need to control the environments were you work..A zillion scripts plus a zillions service files in unmanageable.
More over, majority of big products are NOT systemd aware, and I don't think that will change fast..

For the sake of simplicity you should do it in one place only..systemd fails big here!
It also fails when I want to look into the flow of the code..its compiled...what is there?A bank company should be happy with that?
SysVinit by itself is ways more adaptable, open and less introsive..

[QUOTE=oiaohm;n1053029]

Majority of the time if you have created a script with a systemd .service you have made a critical error.

You should only have 1 service per unit/.service file. This is not about a systemd limitation. Each .service gets it own cgroup. The Linux kernel standard schedulers designed for servers in Linux depend on cgroups around your services. Yes a script inside a systemd .service file starting multi services starts you losing system performance like you lost when you were using SysVinit.

Even under Sysvinit linux where you are falling back on autogroup(what is a system to attempt to auto assign cgroups) you don't want large multi service starting init scripts. Yes multi service init scripts don't cause trouble under AIX but they are a big thing you should avoid where you are running on a Linux kernel.

If you read docker documentation

https://docs.docker.com/config/containers/multi-service_container/

You will also see multi service per container are not recommended this is the same problem.

Who told you, that I do my scripting inside the systemd services..?

You need to Follow protocol Rules, compliance's, that the majority of the products brake, and they know nothing about systemd..
When you deal with Big products, you need to adapt,and when are errors you need to look into the Scripts...here is were SysVinit is great.
And if I have to choose to only have one Script, why should I have: one script and a systemd service file...2 separated things..why?
Plus the blackbox of compiled code..

[QUOTE=oiaohm;n1053029]

Under the default Linux kernels in all server distributions cgroups are always messing with your stuff the question is do you have any control over it or understanding of the rules.

One of the problems starts when RedHat tries to force systemd into free distributions, with a lot of damage to the Opensource world..
A lot of interference from systemd, in the way the things work...pretending himself to be the Operating system...
It should be only a init system, nothing more..
systemd is a stone in the path of progress...it could be something a lot better, if RedHat was listening..

[QUOTE=oiaohm;n1053029]

Generally Linux kernel compatible sysvinit scripts should not be longer than 500 lines majority should be less than 200 lines. Systemd service files most should be less than 50 lines with no scripts straight up starting the required binaries.

Just by correcting this stuff I have seen even with SysVinit 20 to 30 percent through put gains on particular workloads. This is why I am not anti systemd I know systemd like it or not used right gives you control over the cgroups system that will be messing with your performance anyhow.

You can't dictate the size of a Script...
Some company by a product, and its what it is..you need to adapt..

You are too much focused in one reality, the containers world..probably applications which have 1 binary, and less dependencies than some other people..
And because of that, you think systemd is the Saint Grall.

I am not against systemd...
let those guys do what they want, _inside their own garden_,
BUT they should not interfere in the Opensource world, in the way RedHat has been doing for quite some time..

And if you look around, you will see that nobody is against systemd( providing that it doesn't get in their paths ).
The problem is the interference, that systemd causes, and the vendor-lock-in introduces..

[QUOTE=oiaohm;n1053029]

Now openrc need to be filled out more. But the many thousand of line start up scripts you see in a lot of middle ware needs to die its Linux incompatible crap.

Also when a person says that for systemd to be the same as sysvinit it need to run a script means they have not read though the conditional options of service files or many other features. Once you cut a sysvinit file to what it should be it translates into .service files. Only reason why something does not translate to .service find most of the time is that you have multi things in your sysvinit files that you should not have. Features in sysvinit files that harm Linux performance.

I agree, that lots of the products need to change..but that thousands of lines you see..."they are not there, just for fun.."
In majority of cases, they are their for compatibility reasons..you can't take them from their not even in 10 years

You can do a lot with systemd...but you can also do it without it...so its some sort of "undesirable gift", for some people.

New product started from zero,
Yes they should be adapted in a way that make life easier, but at same time, don't depend too much from a init system( portability )..

But any one "should pick you poison.."

[oiaohm]

You need to control the environments were you work..A zillion scripts plus a zillions service files in unmanageable.
More over, majority of big products are NOT systemd aware, and I don't think that will change fast..

Really I have found that lot of big products have over init files that if you submit a bug they will fix.

For the sake of simplicity you should do it in one place only..systemd fails big here!
It also fails when I want to look into the flow of the code..its compiled...what is there?A bank company should be happy with that?
SysVinit by itself is ways more adaptable, open and less introsive..

Problem here sysvinit was not built for the Linux kernel. Places like facebook build their own systemd.

By the way your shell is also a C based binary blob running you sysvinit script do you bother checking that? You will find out auditing the shell you use is way more complex than auditing the systemd ini/service file processing system and does less.

Basically don't ignore the elephant in the room. This is what people do when they say shell scripts are auditable. The reality if it audited you need to have audited from top to bottom. So that is the shell that runs you init scripts in sysvinit has to be inspected as well to make sure code flow will go where it meant to.

Sorry I have done work with banks. Yes they insist that everything is audited. That when you wake up just auditing scripts is not enough.

You need to Follow protocol Rules, compliance's, that the majority of the products brake, and they know nothing about systemd..
When you deal with Big products, you need to adapt,and when are errors you need to look into the Scripts...here is were SysVinit is great.
And if I have to choose to only have one Script, why should I have: one script and a systemd service file...2 separated things..why?
Plus the blackbox of compiled code..

Service file is placing predictable cgroup around your service. Instead of depending on Linux kernel random luck with the CFS group scheduling.

The code is not blackbox on debian and other distributions that has reproducible builds. So maybe now you have to have some skill in C and be able to read and in fact audit the start up correctly. Not get away with doing a half job.

You can't dictate the size of a Script...
Some company by a product, and its what it is..you need to adapt..

Sorry you can dictate the size of the script. What it means is you have to submit issue with supplier and be about bench the problems.

You are too much focused in one reality, the containers world..probably applications which have 1 binary, and less dependencies than some other people..

This is not it. The problem first started appearing in 2007 with the introduction of CFS group scheduling.

I agree, that lots of the products need to change..but that thousands of lines you see..."they are not there, just for fun.."
In majority of cases, they are their for compatibility reasons..you can't take them from their not even in 10 years

Majority of the reason why those massive sysvinit files are in /etc/init.d is
1) People you don't bench it. So don't see that the file split into multi service files in fact performs better even in sysvinit.
2) The first init file was written before 2007 when it was common to start as much as possible in a single file.
3) No one has complained to get it rewritten correctly.

Yes we are over 10 years in yet people like you still let these application ship you broken init setups that don't in fact work properly on current Linux kernels. \

Lets be blunt most of those massive messes of scripts still exist because customers have administrators that are pure incompetent or over worked.

New product started from zero,
Yes they should be adapted in a way that make life easier, but at same time, don't depend too much from a init system( portability )..

If you want performance portability is the least of your problems. Your performances are linked very much to having the tools to control the kernel you are running on. The big thing systemd gives you over sysvinit is proper control over the information the Linux kernel need for CFS and other parts to perform properly.

Sysvinit has to die it was based off the ideas of sysv not how the Linux kernel is in fact implemented. Openrc is a maybe because it could be extend to set the information the Linux kernel needs.

[tuxd3v]

Really I have found that lot of big products have over init files that if you submit a bug they will fix.

Really?
That is not the way it works..
They will not change a product because you ask them too..sure in the OpenSource world, there are tendency to change things at request...
But not Big Products, that is a massive pile of work to do that..
Sure they can change,with that, they redesigned their entire application stack,and there are the risk factor here...years of development and so on..
but you need to show them your "Big Wallet", then, they provide the product to other company's at zero plus cost...

In OpenSource Applications you can do that, in a better way, because everybody gets the improvements , but in closed source no way..
How can you then, be competitive in the Market?

Problem here sysvinit was not built for the Linux kernel. Places like facebook build their own systemd.

Places like Facebook are shit Chat companies, with zero value...
And you continue to be focused on that type of companies, with ZERO real value...

By the way your shell is also a C based binary blob running you sysvinit script do you bother checking that? You will find out auditing the shell you use is way more complex than auditing the systemd ini/service file processing system and does less.

Hummm...I don't think so...
Even more when lots of user-space tools are provided under the respectful GNU Umbrella..

And please don't compare, GNU with RedHat bad reputation, they are in opposed poles..
Its almost a Sacrilege..

Basically don't ignore the elephant in the room. This is what people do when they say shell scripts are auditable. The reality if it audited you need to have audited from top to bottom. So that is the shell that runs you init scripts in sysvinit has to be inspected as well to make sure code flow will go where it meant to.

Sorry I have done work with banks. Yes they insist that everything is audited. That when you wake up just auditing scripts is not enough.

I use to work in places were that happens!
Sysadmin is responsible only for its tasks, OS is audited by Security Teams directly..
I don't even install a image, that was not authorised by the Security Team...

But that happens in some places,
The majority of places don't have the resources to do that, and so they install what comes in the downloaded image...its a blackbox.
It is always difficult because there are tons of compiled code...

2 wrongs don't make one right..
A init system, seems to me, too much important to be running in compiled code Sincerely..its easier in editable( interpreted ) code.

Service file is placing predictable cgroup around your service. Instead of depending on Linux kernel random luck with the CFS group scheduling.

The code is not blackbox on debian and other distributions that has reproducible builds. So maybe now you have to have some skill in C and be able to read and in fact audit the start up correctly. Not get away with doing a half job.

Again...
You continue too much Focused in Containers..!
Yes cgroups in contaires is a must...

BUT there are tons of places were the OS runs only a application user, cgroups has almost ZERO impact here.
Because OS is minimal, the user that will be using the system will be the Application User, forget cgroups in this places...
Sure you tune, but is has minimal impact here.

You can only use debian in some places, not everywhere, and systemd comes from RedHat..
debian has we saw, is not independent like it was in the past...now RedHat seems to rule in debian, which by its turns, turns the best OS, in something very inferior.

Best Debian ever was version 7, SysVinit based very fast,low resources, very stable.

Sorry you can dictate the size of the script. What it means is you have to submit issue with supplier and be about bench the problems.

Like I said..in places with Minimal OS, and a user...forget cgroups...
in containers, or in places were you have lots of users, yes ofcourse..

Sometimes submitting issues, don't solve a application architectural diference..
Application will continue like it his, no one will change it.. because that means years of development and test.

Big money and time, resuming..

This is not it. The problem first started appearing in 2007 with the introduction of CFS group scheduling.

Majority of the reason why those massive sysvinit files are in /etc/init.d is
1) People you don't bench it. So don't see that the file split into multi service files in fact performs better even in sysvinit.
2) The first init file was written before 2007 when it was common to start as much as possible in a single file.
3) No one has complained to get it rewritten correctly.

Yes we are over 10 years in yet people like you still let these application ship you broken init setups that don't in fact work properly on current Linux kernels. \

Lets be blunt most of those massive messes of scripts still exist because customers have administrators that are pure incompetent or over worked.

They are only Broken Setups, in your mind..
Each one should speak by itself..
SysAdmin can do only the best it can to adapt things..it cannot rewrite the entire stack application...that's crazy.
Also the Application to be adapted could have to suffer big changes, and maybe that company is not very pleased to that..

The fact that, you have multiple scripts, don't per-sé, turns the application faster....
For it, you need parallelism, but if one part depends on the other...this type of parallelism cannot scale..

I like only one Script per service...config in one place, no mess around, no Buggy scripts + service things..one thing to rule them all..CLEAN.
And you can always launch things in parallel, without having multiple scripts or service + scripts, what systemd have, I call it a MESS..

But here depends..
I have also saw lots of craziest things..made by SysAdmins too, to be honest that things makes me upset!
Because you will have to try to improve it..
And by that, would mean that you would have to convince clients, mesure the risk, convince Security Teams, convince your bosses, and so on...and after that...
You can make a draft, then will be exposed to all entities involved, and it will be approved or not..
So its lots of work, to correct one bad thing..and a lots of times is rejected because of the risk factor, or because the way the security teams have though the security is not compatible..

I am not talking about fake companies like Facebook, that they say the companys value is tremendous, but that is only in WallStreet..
No reputation, no credibility, no value as a trade mark, all is imaginary..no serious business there..
And in this Companies business it could make a lot of sense,because of the amount of parallelism, containers, or access times for zillion users..

That is not the case with the majority of companies, but all tend to massively change, I also see that in some companies..

You don't change the OS image because you want too, here, it depends on the company, and so on..
Lots of places only allow you to change the image when they want/or Client want..
There are down times, adjust, Hardings to be done( Above initial Harding made by Security Teams when they build the image first time), and this all costs money, and above all Reputation...
Moreover, in some countries...downtime...you pay it with big money...
YES there are countries where the Legislation don't allow you to have DownTime( depending on the business ), or you will be sued by State Organisms..

you don't dictate nothing here, "its not like disneyland.."
If you are in a Real Company, you will play with lots of obstacles, its not like when you run websites..that you can shutoff one server in the backend, and maybe only the sessions there suffers..and you change what you want..

This is a complex factor, and will not change at once...will be changing with time..
Also some changes that come to the Linux kernel, do not favor the work this Real Companies do, only the work that the people are working there submit..

We cannot blame SysVinit, because of cgroups, an example is the embedded world, you could be running only one app.
In lots of spaces, cgroups don't actually translate in something important..when you run a OS minimal and a user..

If you want performance portability is the least of your problems. Your performances are linked very much to having the tools to control the kernel you are running on. The big thing systemd gives you over sysvinit is proper control over the information the Linux kernel need for CFS and other parts to perform properly.

Sysvinit has to die it was based off the ideas of sysv not how the Linux kernel is in fact implemented. Openrc is a maybe because it could be extend to set the information the Linux kernel needs.

SysVniit will not die, because it his needed in lots of places..
It will reduce its share, but not die..

I don't see systemd, after 10 years more.. its a stone in the path of progress, to much interference in other areas that should not do, and so on..
But I also acknowledge that something have to come up, that restrain systemd, to a init system, and takes what is best from sysvinit, with already developed ideias and formats...do not reinvent the wheel..

[oiaohm]

Really?
That is not the way it works..
They will not change a product because you ask them too..sure in the OpenSource world, there are tendency to change things at request...
But not Big Products, that is a massive pile of work to do that..

Really maybe you have not been in companies pay half a million dollars+ a year on a support contract on a big product support contract.

Its suprisng how fast they move when you mention performance and that it may cause you to look at competitors..

Sure they can change,with that, they redesigned their entire application stack,and there are the risk factor here...years of development and so on.. but you need to show them your "Big Wallet", then, they provide the product to other company's at zero plus cost...

Most of reordering the init process does not have large risk factors. Improves performance a lot.

Like I said..in places with Minimal OS, and a user...forget cgroups...
in containers, or in places were you have lots of users, yes ofcourse..

This is wrong. A lot of IOT is find cgroups critical.
cgroups put proper tracking around you minimal OS so when something crashes it can be properly watchdog and restarted. Even minimal OS and user using Linux not using cgroups causes you trouble.

SysVniit will not die, because it his needed in lots of places..
It will reduce its share, but not die..

There is no question SysVinit need to completely die or grow cgroup support. Using PID and other things for track services is bug prone.

I don't see systemd, after 10 years more.. its a stone in the path of progress, to much interference in other areas that should not do, and so on.. But I also acknowledge that something have to come up, that restrain systemd, to a init system, and takes what is best from sysvinit, with already developed ideias and formats...do not reinvent the wheel..

Really I see keeping sysvinit alive as just taken resources away from what should be going into making openrc fully functional.

You what you service init system using tracking around services that truly do track if they are up or not.

If you don't like how systemd works. You still need a init service system that has cgroup support on Linux so you always have proper tracking.

Linux recycling PID numbers and break away processes means without using cgroups you have incorrect tracking on what your services are upto.

Yes you get performance by having control over cgroups. I find performance issues get better response that we had to reboot the complete server because some service part lost. For some reason even when you are paying half a million+ on a product having to reboot server to restart their product is classed as acceptable. Yet they get upset when you can document a 10 to 20 percent performance problem and then fix it. Both are the same problem.

The reality here with the Linux kernel cgroups is critical to anything needing reliability so that you can watchdog it correctly and when you shut a service down you know some random fragment of the service is not running somewhere. If there is some random fragment of a service still running it can preventing you from restarting that service.

Cgroups give many advantages once you get use to having them not having them comes a major problem.

Basically those arguing for sysvinit mostly don't get they are unable to deliver the same level of dependability those using solutions based on cgroups can on the Linux kernel. Sysvinit no matter where you look is a noncompetitive solution because the issues around not tracking your services leading to not being able to restart services and performance issues make it useless.

Of course I am not saying people cannot hate systemd. That fine. But make sure you are investing time into a solution who design contain support for cgroups so that long term you have something that is competitive on dependability.

[tuxd3v]

cgroups is a nice thing..
it was made so that you can slice your machine...the principal purpose containers, the "Saint Grall of virtualization"..

It does not make sense in lots of places.
Everything has its nice things and its bad ones, or less important..
But its an important thing if you want to slice..
It can also be a big problem for example with page cache pressure, and several namespaces..if not very well set.

But I can control cgroups without systemd, in a plain script, and only one place.. with SysVinit

This is how I see systemd:

I understand that some kids used to windooze before, discovered linux...and they though "this is so nice...lets make things here...we are mans already..linux whoot whoot"

Part of the problem...
The only reality they knew before was windooozee, and desktops( unique place where systemd makes some sense.. ),
So they designed a desktop init system...
But the real part of the problem that interests me is:

Linux is not the bigger Desktop OS on the planet...
it has not been chosen, in the server...because it his good in desktop( contrary of windooze case ... ),
But because it can deliver..

And this is one big problem for systemd..
For Desktop, yes you can use it, and it seems to be a good alternative there, but it should be open, editable code..

On Server...I don't see systemd as a feet, it needs to scale down, a lot, or one day linux ends like windooze, and then it will be a big problem..
Its fastest than a shell, but its compiled code, I prefer the good old SysVinit simplicity.

A simpler way to describe would be..

SysVinit for mans
Zillions of lines of code in a alien like ancient language, that makes your eyes red( only for looking at it ), that almost nobody understands, but really works.
Lots of zigzag code, god knows what they do, in the end.. all works..
systemd for kids
lots of penguin pictures on the screen, a nemo fish at the botton, and some icecream with chocolate around kids mounths..


Do you agree?