Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Replacing Systemd with OpenRC in Debian

danielcordova.me

Post reply on HN
Print view View original

81–90 of 168 posts

Re: Replacing Systemd with OpenRC in Debian

#81

Post by 0dayz »

LtWorf wrote: post #56
0dayz wrote: post #50

To this day I have not found a single modern argument against systemd that is a technical one (I tried systemd but it does not support x which openrc does), instead it's these vague bike shed arguments (Unix philosophy, anti-centralization and "bloat" ). I can't wrap my head around it, since those 3 are a "you" problem, systemd is just a service manager it's you who decide to use other systemd parts.

I found a few bugs where journald was losing data for example. I reported them and they got fixed in later releases. Of course I still got called a neckbeard and got told that I didn't like systemd because I'm a dinosaur and so on. So I have a really hard time to take positions such as your seriously to be honest.

If you mean that there are times systemd has a critical bug; sure the same way x11, kernel modules or drivers have critical bugs are annoying.

You can always point to where I said you are a neckbeard, so I do not get the "hard time" angle.

You can not like systemd, but the arguments for it is silly, and that is fine it's your machine and I don't care as long as people stop spreading FUD on such awful grounds.

Say in contrast with BTRFS or BcacheFS there are genuine issues with those and there are technical philosophical arguments (I want journaling, I do not want or need CoW features, snapshot? never heard of her).

Re: Replacing Systemd with OpenRC in Debian

#82

Post by Someone »

lukan wrote: post #40
wolvoleo wrote: post #36

Earlier quoted context omitted.

Fragmentation is what makes Linux great imo. I'm not against systemd per se but I am against monoculture.

And what are your thoughts on deploying software to a fragmented system?

Not the OP, but the historical answer was POSIX (https://en.wikipedia.org/wiki/POSIX, https://dl.acm.org/doi/10.1109/2.56856).

That didn’t work perfectly, but it did work to some extent.

Re: Replacing Systemd with OpenRC in Debian

#84

Post by adrian_b »

gf000 wrote: post #71
shevy-java wrote: post #29

Earlier quoted context omitted.

Agreed. But you still need to know what to enable/disable, so more complexity is the outcome. > And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts? Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code. > Guys, pick your fights reasonably. I don't see what is not reasonable here a…

Not all code are equal. There is an essential complexity you need , period. This is a fundamental truth that that can never decrease. And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc. So it's a hard problem, yet many parts are repeating. A network service and a file system mount…

Init scripts should not need significantly more than a few lines.

I do not think that I have ever used an init script longer than 1 page of text.

If bugs are feared, it is always possible to invoke a script written in another scripting language.

While some people like Python for this purpose, in the past I had good results by using scsh for complex scripts where one wants to avoid bugs.

"scsh" is a Scheme dialect specially designed for replacing shell scripts, i.e. where you have a convenient syntax to express the features of a shell scripting language, like writing command pipelines, file redirections, etc.

Even a zsh script can avoid the most frequent errors from bash scripts, which are caused by the incorrect use of quotation.

With any scripting language, it is possible and recommendable to use strictly declarative init scripts, which only contain definitions of variables and parameters for invocations, separating the procedure definitions in distinct files, which are common to any installation and which are not modified for a custom configuration.

Even when it may be desirable to implement some functions of the init system in binary executables, those must be extremely simple, as demonstrated by the small executables included in the daemontools of Daniel J. Bernstein, and not like the big monstrosities of Systemd.

Re: Replacing Systemd with OpenRC in Debian

#85

Post by nubinetwork »

gf000 wrote: post #54
hks0 wrote: post #43

I have a curious question. My local setup has worked for me for ages ever since arch decided to switch to systemd. Same on the servers I deal with, after Debian's switch. At the same time, I can say I'm not involved with inner workings of a Linux system enough, to be affected by init system change and the pain it might bring. In other means consider me an average Joe of the Linux world. Hence this question: If it suc…

It doesn't suck, people are just emotional beings and have some "football team" level takes on technical stuff as well. The very same people that hate systemd for "being a monolith" and limiting choice are usually also love X and hate Wayland where they can manage to explain how being a monolith is suddenly good. Especially that systemd is pretty modular - at least the actual systemd program running as PID 1. It also…

Both systemd and wayland were quite broken when they were first being pushed onto everyone... they're mostly fine now.

Re: Replacing Systemd with OpenRC in Debian

#86

Post by nubinetwork »

_flux wrote: post #8
atmanactive wrote: post #6

I'm confused... isn't Devuan exactly this?

Devuan us a separate Debian with its own repositories (and presumably many packages patched to improve systemd-less life), while this is just replacing Systemd with OpenRC on a Debian system, while keeping Debian repos etc.

You're going to have to make a separate repo for everything anyways, because you'll have to change all the init scripts and whatnot that get supplied with programs... well, unless you install both and just leave the useless systemd files laying around forever.

Re: Replacing Systemd with OpenRC in Debian

#87

Post by Someone »

FTA: “Before deleting systemd, need to be sure that OpenRC will be installed, to so the command will be

  sudo apt purge --allow-remove-essential systemd && sudo apt install openrc sysvinit-core
”

I don’t see that installing openrc before deleting systemd. It tries to delete systemd and, if that fully succeeds, to install openrc.

> Issue itself was that while uninstalling systemd somehow OpenRC was removed too or not installed at all.

I don’t see how “somehow OpenRC was removed” could be true if it wasn’t installed before. My hunch would be that uninstalling systemd failed halfway through.

Re: Replacing Systemd with OpenRC in Debian

#88

Post by simoncion »

gf000 wrote: post #71
shevy-java wrote: post #29

Earlier quoted context omitted.

Agreed. But you still need to know what to enable/disable, so more complexity is the outcome. > And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts? Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code. > Guys, pick your fights reasonably. I don't see what is not reasonable here a…

Not all code are equal. There is an essential complexity you need , period. This is a fundamental truth that that can never decrease. And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc. So it's a hard problem, yet many parts are repeating. A network service and a file system mount…

> OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.

Hey, hun. Here's an OpenRC service file that's nearly as small as it can get. [0] I don't know about you, but that OpenRC service file looks a whole hell of a lot like a Unit file to me. Do you disagree?

If you replace line 14 with

  supervisor=supervise-daemon
and remove the "-D" from 'command_args' to make avahi-daemon run in the foreground, then you don't have to deal with "icky" pidfiles, and you get daemon supervision and automatic restart on failure.

OpenRC also does parallel service start and stop. I've been using it for... ten years now with no problem.

[0] https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>

Re: Replacing Systemd with OpenRC in Debian

#89

Post by nubinetwork »

adrian_b wrote: post #35
globular-toast wrote: post #3

I find it fascinating how different people are with respect to being able to see the future, or at least caring about it. I find many people are like lumbering beasts in a forest complaining when a twig pokes them in the eye. While other saw the forest from miles away and just went around it. Gentoo is still home to a sizeable number of users who noped out of systemd more than 10 years ago. This is exactly the kind o…

I am one of the happy Gentoo users, who have escaped from systemd until now. Some years ago I have experimented with systemd for a month, by using Arch Linux. However I have encountered an ugly bug and eventually I wiped it out. The problem was not that there was a bug, I assume that the bug must have been solved years ago. The problem was that the bug was not something that could be attributed to a random error, lik…

That's funny, because I've been converting all of my Gentoo systems to systemd... from my point of view, the writing is on the wall, most distros use systemd already, so there's no sense in not learning it.

Re: Replacing Systemd with OpenRC in Debian

#90

Post by valentynkit »

Curious how you're handling supervision after the switch. The remoteproc unit you converted by hand is the part that gets interesting: when it crashes, what restarts it, and what guarantees it came up only after its dependencies were actually ready rather than just launched? That dependency ordering and the cgroup resource accounting are the real work, and OpenRC hands both back to you.
Post reply on HN