SysVinit 2.90 Released With Fixes & Better Support For Newer Compilers

[oiaohm]

Funny. Someone before you mentioned how straightforward sysvinit is, but it can't be straightforward is so many things are undocumented...

Straight forwards because sysvinit basically does not document very much. Result is you are depend on addons like LSB defines to make usable init system. Like under debian before systemd even most init scripts imported /lib/lsb/init-functions and LSB init information. Now of course since none of this is part of sysvinit distributions are free not have this stuff or rename this stuff.

Claim that sysvinit is straight forwards when you go across multi sysvinit distributions become bogus really quickly. If sysvinit was like bsd init system that is high documented it would be another matter.

Openrc support BSD init and sysvinit syntax. Sysvinit needs lot work on documentation and it still has other issues like depend in PID values not being reused in many script. Reality is sysvinit need to be got rid of and replace with something designed better and better documented. One of the reasons why BSD has held popularity against Linux in particular fields is rcorder so you have to include dependency information in you init scripts and they will be loaded on the right order. There is a lot of issues under sysvinit with init scripts starting in the wrong order then having to debug that.

Really anyone claiming sysvinit is straight forwards has never worked with it. BSD init and the inits like it has the right to be called straight forwards as they are truly straight forwards to use and documented. Heck the busybox init is better documented in one place than sysvinit.

That control protocol not being documented has resulted in sysvinit command line tools not working to shut system down because someone change something that change the protocol. Its only taken 20+ years to document something that need to be kept backwards compatible so that never version of sysvinit control tools work with older sysvinit PID1 loaded and the reverse. Those wishing to keep on using sysvinit should be put in a lot of effort fixing it or give up on sysvinit. Lot of distributions gave up on sysvinit and have gone systemd because they did not see a future where sysvinit was fixed and worked.

[oiaohm]

So how does someone use logind without systemd?

As what is said here but there is a error

You don't. You use an other implementation of the login1 D-Bus API, like elogind

Elogond is someone has extracted logind from systemd.

https://github.com/ConsoleKit2/ConsoleKit2/issues/10

Another implementation is ConsoleKit2. In fact logind protocol was first implemented as a prototype patch to consolekit before systemd even existed.

Sorry, "how does someone use <random program> without <its dependencies>" is a bullshit argument, as it can be used on anything that isn't... wait for it... monolithic.

logind relies on features provided by its dependencies, you can remove them or clone them from systemd init to logind (making it more monolithic),

Yes ladies and gents, elogind is more monolithic.

The fact logind protocol can be implemented under consolekit2 means as a protocol is not that bounded to systemd. Individual implementations of the logind protocol may be bound to different back ends. Like the ConsoleKit2 implementation depends on Consolekit2 being present

https://github.com/ConsoleKit2/ConsoleKit2

ConsoleKit2 is a framework for defining and tracking users, login sessions, and seats. It allows multiple users to be logged in at the same time and share hardware for their graphical session. ConsoleKit2 will keep track of those resources and whichever session is active will have use of the hardware at that time.

What ever is doing the job that matches the ConsoleKit2 description the logind protocol implementation has to be dependant on. Under systemd that role is integrated into systemd. Under sysvinit you would have historically used ConsoleKit for that role so you need to update to ConsoleKit2.

The idea of the logind protocol is those making display managers and the like don't have to make different individual backends for each of the user/login/session/seat tracking systems instead each of the systems doing that provide a single unified interface. Please note you can only have 1 thing in full control of user/login/session/seat at any one time. Logind protocol was first though about with consolekit to prevent two different versions loading at the same time and having a cat fight so locking users out of system.

Everyone should want the Logind protocol it prevents a problem. Everyone should be wanting to update to software that supports it. So that anyone who wants to implement there own console control system is not going to cause a cat fight event as long as they also implement logind protocol on dbus as this allows them to notice when they have a fatal collision. The first one to grab the dbus protocol address remains running the other one quits.

Please also note when logind protocol was first done it was thought that dbus due to heavy desktop usage would become a kernel feature. The reality is if you don't like logind protocol dependency on dbus a new protocol need to be made that does it role that consolekit2 and systemd logind at least agree on to prevent conflict problems and to keep those implementing display manager fairly simple. Yes this would most likely mean as well a generic wrapper from the new protocol back to logind protocol on dbus for compatibility.

Yes this is one of the cases where the anti-systemd people are completely stupid and being knee jerk thinking everything in systemd has to be wrong. Somethings are in systemd because they are required and are not really optional features logind is one of those things that is really required in some form and logind protocol is the best we have.

[Bsdisbetter]

Why would anyone use this horribly written, highly monolithic artifact from bygone ages?

Lol sysvinit is not monolithic by any definition. Old it may be, but so what?

[Bsdisbetter]

nah, most userbase is on Systemd these days.

Proves nothing other than more distributions use it and/or are forced to use it. For an end user who doesn't interact with systemd I can see no issue, but in my years-ago use of it it stank. Core dumps? Where are they hiding? Binary logs - crap can't forward them without installing rsyslog anyway. Now I understand its taken over everything from login management to dns. I avoid it like the plague.

[rtfazeberdee]

So how does someone use logind without systemd?

eh? a dependency makes something monolithic - i see your problem... comprehension. try running your distro without glibc (or similar)..... whooops that makes the distro monolithic. aahhhh abandon ship.

[oiaohm]

Proves nothing other than more distributions use it and/or are forced to use it. For an end user who doesn't interact with systemd I can see no issue, but in my years-ago use of it it stank. Core dumps? Where are they hiding? Binary logs - crap can't forward them without installing rsyslog anyway. Now I understand its taken over everything from login management to dns. I avoid it like the plague.

https://github.com/systemd/systemd-netlogd

The cannot forward over network bit kind of shows you something if a program is not put in the main systemd bundle users don't get it with a lot of distributions. So claim systemd does not have something. It magically shows what distributions are after as well.

As stupid as it sounds distributions like to build less packages for system initialisation . To make a working systemd distribution you have to build less packages than what you have to build to have a working sysvinit one. Also you don't find the systemd project extras.

[lostdistance]

Why not using busybox's light "init" instead? I don't think you need runlevels in embedded (which is the main difference, busybox's init does not support runlevels).

The Intel Braswell Qseven module has plenty of processor performance and memory capacity, so I was able to avoid busybox in favour of the full size utilities.

As it happens, I did use runlevels to boot the module into either a development system or a production system.

[rtfazeberdee]

Now I understand its taken over everything from login management to dns. I avoid it like the plague.

You understand wrong. people have already explained about logind, but things like DNS are optional as it most of the systemd components

[nomadewolf]

Am I the only one bothered (especially with systemd, but here too) by the "ctl" suffix short-hand for control? Seriously. It's CTRL on keyboards. initctrl sounds much better.

Yes!
Put an end to this madness!

[nomadewolf]

systemd completely supports System V Init, if you want to use it. Pretty surprising isn't? because if you listen to systemd haters you would think that System V support was taken away. But you can quite happily start services by SystemV files just as you always have. Thats why all of this systemd hating nonsense is nonsense, systemd doesnt take away any functionality, it just adds on additional functionality. I find systemd to be much easier to use because of the declarative file format, there is much less wheel reinventing and results in easier to read files than bash code. The start up model is different, because its more powerful and allows you more flexibility to determine when a service to start based on prerequisites rather than just a sequence based start up. You can absolutely use a sequence based startup, but systemd allows you to configure it to start services on a much more precise set of conditions. People are just afraid of whats different, once you learn it, its worth it because it is much more powerful

I speak only for myself, but i don't hate systemd because it took anything away.
I don't actually HATE systemd. It works surprisingly well.
But, i do believe in the Linux philosophy: do one thing, and do it well.
And systemd does not abide by that philosophy. It wouldn't surprise me at all if systemd announced today that they will ship their own office suit within systemd in the future...
All i'm calling out (and many others. maybe not all) is for systemd to be just an Init System. Everything else should be it's own project.
And, with that 'simple' change, i would (gladly) use SystemD. The difference being: gladly, becasue it's already 'my' init system.

It's not like we want it to die... we just want it to improve.