That's a bold strategy cotton, let's see how it plays out for them. ;-)
But seriously, I expect to see a lot of software lose the ability to be run on systemd because they don't ship a service file.
But seriously, I expect to see a lot of software lose the ability to be run on systemd because they don't ship a service file.
A systemd unit is a simple thing to rustle up. I have recently been informed that an OpenRC script is too these days and I'll fiddle up a VM and have another bash with Gentoo. My job as Managing Director of my company is to maintain an open mind!
I don't think that not shipping a systemd unit will crap out any piece of software. I've seen quite a few packages of code, source and that and an initscript in ./contrib probably works on Debian and farts loudly on SuSE or vv. Who cares? systemd can run it quite easily and with minimal pissing around. With logging and all the other useful stuff.
(Generators are arbitrary programs that generate systemd units at runtime dynamically. Eg fstab-generator parses /etc/fstab and generates .mount units. The sysv-generator generates a .service unit for each sysv init script it finds, and is what is being removed here. https://github.com/systemd/systemd/blob/main/src/sysv-genera... )
Distros that use it can maintain it for their needs; it's pretty logical.
There is very little reason for distro to support systemd and support sysv scripts.
I am surprised it comes from red hat to be honest, if anything I'd imagine them needing it for some legacy software their customers use that might come only with init scripts.
Then again, in most cases rewriting init script to run as systemd unit is very straightforward; but then I saw some fucked up init scripts too, like ones trying to start and manage multiple services at once (here hearthy "fuck you" to packetfence developer that thought that would be a good idea)
I guess my naive expectation is that it should be any effort, hence the question.
> Then again, in most cases rewriting init script to run as systemd unit is very straightforward; but then I saw some fucked up init scripts too, like ones trying to start and manage multiple services at once (here hearthy "fuck you" to packetfence developer that thought that would be a good idea)
LOL, now you've triggered an old memory of IBM WebSphere MQ and its... charming init scripts. It was almost easy to replace them with service files, except that IIRC template unit files can only use one variable to template and we needed two, so I did something ugly. (I don't even remember what, just the gross feeling.)
but you can use that variable to specify EnvironmentFile that has more variables :)
and it also neatly get per-instance config into separate file
or use configuration management to generate per-service files instead of using instances
I mean, you could, but when you really only had 2 variables that feels pretty kludgy.
> or use configuration management to generate per-service files instead of using instances
I suspect that's what I actually did, since ansible/chef/puppet/whatever is happy to nest for loops and template the result. It was just annoying that I couldn't do it in place.
This is so much nothing it can’t get nothinger.
So it's not as simple as "Just write a .service with ExecStart=/etc/init.d/whatever start", but it's also not too complicated, especially if someone forks the sysv generator and keeps it working like I said in another comment.
It just had batch job that solved the dependencies, ordered the init scripts numerically, and then started in batches all of those that started in same number (IIRC, there might've been a bit more fancy stuff there too).
It was kind of worse systemd but systemd wasn't around back then
There is no reason parallel start would be problematic; I even got stuff working that needed network access to get creds for encrypted partition that was required for database to start and it was handled flawlessly.
More than that, if for some reason that file system wasn't mounted it would be when I told systemd to start database, it would run the service retrieving the secrets, then the mount using it, then the DB.
The worse story is with shutdown; by default most distros will cut ssh access before services are closed so if some of them hang you can't debug that remotely. But that's mostly bad settings rather than bad design of the daemon
The pain point was never "generating a textual representation appropriate to the init system"; the problem was always the underlying startup and teardown of the service itself.
From my experience yes, even the legacy stuff is easy enough to convert.