FreeBSD Needs a SystemD

[tuaris]

Yes, I know what I just said. In all seriousness, SystemD is good stuff, if it is done the FreeBSD way. It's a fully integrated way to manage the OS. The paradigm it sets makes sense with something like FreeBSD. I can understand why the Linux peoples hated it. They like the fragmentation and the requirements to build everything from pieces. Here in FreeBSD land everything is well integrated and base is separated from user. A design that fits perfectly with SystemD's intentions.

I find that the unit files are a much better approach and standardized way to write services. The ability to control everything through a single interface `systemctl` is wonderful. The way you can override things without touching the package installed files is great. Every time I need to work with it on Linux I feel envy. It's the piece that has been missing from the Unix world.

I think we are doing ourselves a disservice by not building something like it for FreeBSD.

 

[jbo@]

Which improvements do you think a systemd-alike would bring over what we currently have?

In all seriousness, SystemD is good stuff, if it is done the FreeBSD way. It's a fully integrated way to manage the OS.

I believe in here lies a conflict.
The FreeBSD way is to not have one tool to manage everything.

 

[rbranco]

Be my guest and contribute to https://github.com/InitWare/InitWare

We don't need PID 1 depending on 42 libraries though. This can be done by a PID 2.

I understand why Systemd was successful but still consider some parts of the architecture horrible. Also, lots or even most of the components are really not needed. That's what initware it's trying to address.

 

[tuaris]

Which improvements do you think a systemd-alike would bring over what we currently have?

There's a lot to unpack in that question and I'm always thinking of it, but never took the time to record my thoughts. Here's what I can (currently) think of in the moment

1. The unit files. Like I mentioned, the declarative approach to writing services. The SystemD developers have pretty much covered almost every edge case. There's no need to write bespoke functions and startup scripts. While the RC framework has come a long way, it still lacks in a lot of 'opinionated' out of the box features. Take a look at the documentation for how to write a unit file. The options and possibilities are really abundant: https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html.
2. Related to the previous, is the ability to override a unit file without changing the package installed version. You create a directory in the `etc/` directory, place your overrides, done. For example, If I want to change when the service restarts "Restart=on-failure" vs "Restart=always". I can just drop a file with only than line in the said directory.
3. While on the subject.... built-in monitoring. RC won't recover a failed service for you. Some people like it that way, other do not. That's why SystemD has the above option to override the behavior.
4. It's not shell script. From my perspective, the RC framework looks like it's mostly shell script. SystemD is written (mostly entirely) in C, that (in my opinion) allows for more capabilities with less workarounds/hacks. What's wrong with shell script? A lot. Some may disagree, but I've written enough shell script where I question my choice in using shell script.
5. Parallel startup. (yes I know this is being worked on with the RC framework to some degree of success).

That's all for now. Like I said, this is currently what's on my mind. If I remember more I will update the list.

 

[tuaris]

We don't need PID 1 depending on 42 libraries though.

100% agree, keep the dependencies down to 0. Happy to see that your "InitWare" thing is written in C. That's promising.

 

[cy@]

Which improvements do you think a systemd-alike would bring over what we currently have?


I believe in here lies a conflict.
The FreeBSD way is to not have one tool to manage everything.

As they move functions out of the Linux kernel into systemd.

 

[cracauer@]

I don't want to have to reboot a machine because of updates in userland. You can't restart FreeBSD's init, but it has very little functionality and is unlikely to get security updates, if any. If any of the runtime dependencies of systemd or any of its functionality get an update you have to reboot. That is a step in the wrong direction.

 

[freezmi]

They like the fragmentation and the requirements to build everything from pieces.
Every time I need to work with it on Linux I feel envy. It's the piece that has been missing from the Unix world.

you are talking about a piece of software that grew to 1.3 million lines of code, while it was initially created as an excuse to replace something like sysvinit that is two orders of magnitude smaller. I like my fragmentation, thank you very much. it makes it easy to install only the things you REALLY need thus minimizing the possible attack surface and avoid tight dependencies between seemingly unrelated subsystems.

please look up how libxz managed to create the openssh backdoor last year. that alone should make you understand what a bad idea systemd really is.

 

[jbo@]

While on the subject.... built-in monitoring. RC won't recover a failed service for you. Some people like it that way, other do not. That's why SystemD has the above option to override the behavior.

I might be more on the camp of "if your service crashes, there's something wrong in the software". Better to fix the underlying problem rather than relying on something restarting the service over and over and over without resolving the actual problem.

If that is not good enough for whatever reason, there is daemon(8) which can restart a program after it terminated (and you can wrap that in an rc script).

 

[cy@]

100% agree, keep the dependencies down to 0. Happy to see that your "InitWare" thing is written in C. That's promising.

You mean 48 different processes.

And BTW, /var/log/messages and much of rsyslogd is mostly useless. You'll need to use journalctl to query journald's log files it collects for each app.

Systemd is an overly complicated attempt to implement solaris style svc.

 

[cy@]

I work in a systemd world, professionally. It's a PITA.

 

[tuaris]

I might be more on the camp of "if your service crashes, there's something wrong in the software". Better to fix the underlying problem rather than relying on something restarting the service over and over and over without resolving the actual problem.

I'm in that same camp, but that's not always an option (when your software is written in crap languages like Ruby ).

If that is not good enough for whatever reason, there is daemon(8) which can restart a program after it terminated (and you can wrap that in an rc script).

Yes, you can do something like that, but I'm from the mindset of having a central tool control that through clearly documented config files.

 

[tuaris]

I work in a systemd world, professionally. It's a PITA.

Yes, it has it's implementation flaws, but I can't argue with it's design/intentions.

 

[shkhln]

declarative approach

From https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html:

# Reset all assertions and then re-add the condition we want
AssertPathExists=
AssertPathExists=/srv/www

 

[LibreQuest]

I moved all my systems away from Linux 2 years and 4 months ago. I had forgotten about SystemD. It's a dreadful thing and I hope such a system is never adopted by FreeBSD by default. However, having something created and in ports/pkgs is just fine. But please never subject FreeBSD users to such abuse as SystemD (directed to system devs).

 

[mer]

I think I may have found my first block list entry.

 

[jbo@]

I think I may have found my first block list entry.

I always thought you and I were getting along so well

 

[Krotti83]

I don't want to have to reboot a machine because of updates in userland.

It would be nice for both *BSD's and GNU/Linux systems when I don't must reboot the machine (also logout from the default shell doesn't help) when I add an user to a group as example. It's possible on Windows (at least Windows XP), but not on UNIX compatible systems.

 

[cracauer@]

My "favorite" recent landgrab by systemd is the OOM killer functionality. For some reason systemd can now do that instead of the kernel doing it directly. OK. What could possibly go wrong?

The result: what the systemd people came up with does not go into syslog. So you might never learn about it if you are used to the kernel OOM killer. But more importantly: instead of killing just one process like the kernel does it kills a whole group of processes (I don't know whether it is an actual process group in the Unix sense). In a recent case I had it kill the tmux session around the offending runaway program. That means:

• you can't read the output of the offending program anymore
• makes it much more work to build up that program again
• makes any programs suspended in tmux' tty unaccessible

And they activated that garbage in Ubuntu.

 

[shkhln]

I always say that systemd is not a fixed set of software, but rather a subscription plan.

 

[cy@]

Yes, it has it's implementation flaws, but I can't argue with it's design/intentions.

Solaris services is the correct approach.

 

[cy@]

I always say that systemd is not a fixed set of software, but rather a subscription plan.

A Red Hat subscription.

 

[rbranco]

100% agree, keep the dependencies down to 0. Happy to see that your "InitWare" thing is written in C. That's promising.

It's not a project of mine.

Saying "FreeBSD needs a Systemd" is not helpful. It'll only guarantee to start a long thread LOL.

I'll grab popcorn.

 

[cy@]

My "favorite" recent landgrab by systemd is the OOM killer functionality. For some reason systemd can now do that instead of the kernel doing it directly. OK. What could possibly go wrong?

The result: what the systemd people came up with does not go into syslog. So you might never learn about it if you are used to the kernel OOM killer. But more importantly: instead of killing just one process like the kernel does it kills a whole group of processes (I don't know whether it is an actual process group in the Unix sense). In a recent case I had it kill the tmux session around the offending runaway program. That means:

• you can't read the output of the offending program anymore
• makes it much more work to build up that program again
• makes any programs suspended in tmux' tty unaccessible

And they activated that garbage in Ubuntu.

And don't forget the stupid algorithm the OOM killer uses -- check out their "badness" value. OOM on Linux is broken and will become more broken as they roll out systemd's handling of OOM.

 

[shkhln]

Whatever you do, don't use ini files. They always start with a promise of a simple key=value format and then get extended with weird stuff like the variable mutation/assignment that I cited above (a completely imperative construct, by the way). I'd rather deal with a custom DSL than that.