Skip to main content


Started a little journey... running a debian vm installed with systemd and later on switching to OpenRC. The basic steps are done - /sbin/init is not a symlink to systemd's binary anymore and system booted successfully with OpenRC. Sadly runit is not yet well supported enough by debian to be pid 1 - but OpenRC is a very nice one, too :-)

I'm excited - have to figure out a few things now... like network scripts, etc. :-)

#init #linux #debian #openrc #sysvinit #systemd

Thanatos reshared this.

in reply to Rebeka Catalina

you might be able to find some help in the Gentoo wiki, since they support OpenRC and SystemD ;)
in reply to Rebeka Catalina

all right, that explains your motivation. Have fun then :) 👍
in reply to Rebeka Catalina

No offence intended, but what is the advantage of openRC for Debian? I am just an ordinary user, but always to learn about the developments.
in reply to (((Dirk Weber)))

@(((Dirk Weber)))
Well... I think on desktop it's totally ok to use systemd. On my desktop machine I use archlinux and I have no problems so far with systemd on that machine. On one of my servers I recently switched to Debian with systemd and had an issue. It could be solved, but I must say it is something that I dislike.
At boot time the v4 address got assigned and systemd reported "network is up" so the machine continued with boot process - nginx came up and was configured to listen to v4 and v6 - but v6 was not assigned yet. Again: There's a way to solve this, but... I really dislike this behavior.

That I now decided to try out to run debian with OpenRC is, because I thinking about to run the servers with it. With OpenRC I never had such issues and now I just play around sometimes with a local vm. I haven't yet made the decision to switch :-)
in reply to Rebeka Catalina

Tx, tbh I indeed had no idea. My chores as 'sysad' of our small home lan are not very sophisticated. Thus I can keep it simple.

The only issue is that I still did not set up a proper documentation. Yes, I plead guilty, that is no fun. Since the periods I have to stay in hospital tend to get longer the need is obvious.
in reply to Rebeka Catalina

To add to Rebeka's story, I've had the very same problem. With systemd on a virtualized Ubuntu server.

Asking around, systemd's answer to the problem was that software should not bind to specific IP addresses.

Which is condescending at best, as server administrators tend to have a reason to bind to specific addresses only.
That being said it means systemd has, by ignorantly "streamlining" the OS's boot process, taken away an important feature for server environments. And is now asking service software developers to follow their "lead" instead of fixing the problem they've created in the first place.

Mind you, while the behaviour to report the network as "up" as soon as possible in the boot process of a desktop system is essentially a good idea, with servers it might not be.
Also, and that probably hasn't been thought through by systemd proponents both at the software development as well as the distribution level, modern server systems take several minutes to boot their hardware before even starting the OS's bootloader in the first place – so systemd's boot speed optimization doesn't actually help much here anyway. For a virtualized system it's even worse, as in this case boot speed is defined by the number of services to be started – the less and smaller the packages in question the better.

I have an OpenRC-based server VM that reports "fully up" with all services running within a couple of seconds, while the bloated systemd-based Ubuntu server VM is still starting software of dubious value for the use-case.

As mentioned before: In a desktop environment, it's a good idea to assume responsiveness as early as possible; in a server environment, priorities tend to differ. It is sad this is apparently not understood by systemd's developers.