SysVinit 2.90 Released With Fixes & Better Support For Newer Compilers

[trek]

I'm pretty sure I installed it in Debian Woody and I was sure I did not change the init at all. But at this point I'm not sure anymore.

you remember correctly, debian shipped a sysv init script to call daemontools supervise/svc

[starshipeleven]

may be too old for you, but runit is the reimplementation of daemontools, required by qmail

I may be too old actually.
I'm pretty sure I installed it in Debian Woody and I was sure I did not change the init at all. But at this point I'm not sure anymore.

[trek]

did Openrc and runit even exist in 1999? qmail was used with sysv back then.

may be too old for you, but runit is the reimplementation of daemontools, required by qmail

[oiaohm]

did Openrc and runit even exist in 1999? qmail was used with sysv back then.

netqmail (which is the updated version) has a systemd unit, and before that it also had a sysv script https://packages.debian.org/jessie/qmail

rough times of first used releases in somewhere production around the world.
1997-2001 daemontools Yes there are disputes on when that classed as functional. Yes 1999 with qmail you saw daemontools around qmail trying to address sysvinit limitations.
runit 2004
Upstart 2006
Openrc 2007
systemd is 2010

GPL sysvinit is somewhere around 1992.

https://blog.darknedgy.net/technology/2015/09/05/0/

For a long time ever few years someone attempted to write a new init system. Majority have disappeared into history. Yes qmail developers have been known to try quite a few of them.

[starshipeleven]

Coming from environments that are unix-lke it breaks every rule imaginable, from the hijacking of pid 1

It's an init, it's supposed to use PID1.

to core dump 'management'. Having to debug code was horrid. Having to spend hours reading up on where systemd hides core dumps

It takes around 3 minutes to find that info.

So yes, mr passive aggresive, I do have issues reading documentation and learning how to specify 400 options in order to read a simple log.

Are you trolling? just writing "journalctl" dumps all the events on stdin, from there you can hack around to filter the output with pipes to grep and awk just like you did with older syslog.

Main difference is that you can use journalctl arguments to filter stuff instead, which is faster, much faster if you have a ton of logs.

Oh and go learn about syslog forwarding - try reading sone documentation.

I asked because it's something trivial to me, maybe you were talking about something else.

change ForwardToSyslog= to "yes" in /etc/systemd/journald.conf, then systemctl restart systemd-journald

[starshipeleven]

qmail?

did Openrc and runit even exist in 1999? qmail was used with sysv back then.

netqmail (which is the updated version) has a systemd unit, and before that it also had a sysv script https://packages.debian.org/jessie/qmail

[oiaohm]

Let me reiterate for those who have trouble understanding, i dont care what others think of it, i only care about my exposure to it. In an enterprise environment having to work on a systemd server WAS a nightmare. Coming from environments that are unix-lke it breaks every rule imaginable, from the hijacking of pid 1 to core dump 'management'. Having to debug code was horrid. Having to spend hours reading up on where systemd hides core dumps and the commands used to extract/view etc them is time wasting in the extreme. Similarly binary logs are laughable (and broke our audit rules to boot). So some maintainers of a distro like it, more likely because it's common than it's great, doesnt make it great for all. The average click & point user doesnt care anymore than a windows user does of svrman.exe.
Some of us get paid to fix problems and when they occur on linux systems running systemd i baulk at doing them. I simply dont have the time to spend hours reading countless documents to accomplish a task on any non-systemd system that could take me minutes.

So yes, mr passive aggresive, I do have issues reading documentation and learning how to specify 400 options in order to read a simple log.

Oh and go learn about syslog forwarding - try reading sone documentation.

For me it solved more problems that systemd caused. Yes it took awhile to get use to the differences but having everything nicely cgrouped so known that services had properly stopped instead of having the random lost process holding a file somewhere causing service to bust.

I found systemd no worse than changing from sysvinit Linux to freebsd and their bsd init. Both required a lot of documentation reading. I guess you were not taking care of a mix of BSD, Solaris and Linux.

[trek]

I can't think of a single program that has only openrc or runit script at all, much less those that I would run in a server.

qmail?

[Bsdisbetter]

It proves that the distro maintainers, (the people who actually care the most about their distro and the time they spend working on it, have decided to use it.

To the contrary of most users that just take and don't understand, the maintainer know and are invested in the distro.

you have issues reading documentation?

What do you mean with "forward them"?

Let me reiterate for those who have trouble understanding, i dont care what others think of it, i only care about my exposure to it. In an enterprise environment having to work on a systemd server WAS a nightmare. Coming from environments that are unix-lke it breaks every rule imaginable, from the hijacking of pid 1 to core dump 'management'. Having to debug code was horrid. Having to spend hours reading up on where systemd hides core dumps and the commands used to extract/view etc them is time wasting in the extreme. Similarly binary logs are laughable (and broke our audit rules to boot). So some maintainers of a distro like it, more likely because it's common than it's great, doesnt make it great for all. The average click & point user doesnt care anymore than a windows user does of svrman.exe.
Some of us get paid to fix problems and when they occur on linux systems running systemd i baulk at doing them. I simply dont have the time to spend hours reading countless documents to accomplish a task on any non-systemd system that could take me minutes.

So yes, mr passive aggresive, I do have issues reading documentation and learning how to specify 400 options in order to read a simple log.

Oh and go learn about syslog forwarding - try reading sone documentation.

[starshipeleven]

But, i do believe in the Linux philosophy: do one thing, and do it well.
And systemd does not abide by that philosophy.

Yeah, it does not split the init, the logger, the login manager, the boot loader and anything else into different processes, which have their own damon name and their own source code, and communicate over standard and stable interfaces.

If systemd does not abide to "do one thing, and do it well", then neither GNU coreutils do.

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.

Unix philosophy never said each thing should have its own project though (see coreutils above), they were talking about software and best practices for software. Not politics. So while you're allowed to make these requests, it's just your own personal needs.