How is FreeBSD coping with a systemd future?

[LukeWolf]

I'm not interested in a debate over whether systemd is good or evil, I'm interested in the question of how is FreeBSD working to respond to the changes that systemd is creating in the open source software ecosystem, and what needs to be done.

Obviously *BSD has its own init system so SysV init going away doesn't effect that. FreeBSD just has to continue the work of supporting init scripts.

My understanding is that FreeBSD has a udev replacement in devd, however PC-BSD appears to be relying upon hald. Obviously hald has been long since abandoned by Linux, so does KDE SC for example have a solid backend for devd? What needs to be done to shift away from hald?

Logind is probably the biggest issue for the immediate future. Consolekit was deprecated by it's maintainer and as far as I know, nobody has stepped up to the plate to maintain it, nor has anybody implemented the DBUS API that logind presents. Meanwhile GNOME intends on using logind's DBUS API exclusively for wayland and long term I expect the various Consolekit backends are going to bitrot and break. What does FreeBSD intend on doing about this?

Session management is something I've seen discussed on both the KDE and GNOME side of things where systemd would manage the user session, while I expect such a thing to stay optional with KDE, what I've read of GNOME blogs indicate that they want to use it to eventually deprecate gnome-session, does FreeBSD provide some equivalent functionality or what is the plan?

Sorry if any of the above is a stupid question, but I'm a Linux user who recently decided to look into FreeBSD and was impressed by the exceptional documentation, ports system and what appears to be a generally better engineered approach to things (for example OSSv4 vs ALSA). I'm thinking about migrating at least one of my systems over, however I need to wait on Radeon to pick up dynamic power management for use outside of a VM, and I'm concerned by the lack of obvious movement towards actually doing something about the systemd future as opposed to just complaining about it. If it's not too difficult, I'd be willing to work on code myself however I'm a decent but rather inexperienced C++/Qt and C# programmer, and so would need a mentor to help me.

 

[Derydlus]

I'm not sure if FreeBSD is doing anything, but this intends to provide systemd replacements for ports that require it. More details here. Seems like there's little need to duplicate effort, although I'm sure help would be appreciated. I'm not sure about the logistics of helping out current GSoC projects. You may need to wait to contribute patches.

 

[ralphbsz]

What does systemd do for headless machines (those without X)?

If the answer is "nothing", then why make it the default? For servers, the existing SysV init is plenty.

 

[kpa]

What does systemd do for headless machines (those without X)?

If the answer is "nothing", then why make it the default? For servers, the existing SysV init is plenty.

This is incorrect. It offers a complete replacement for service management (service(8) under FreeBSD) including services that have nothing to do with X11 or graphical UIs and startup scripts that are traditionally handled by rc(8) on FreeBSD and usually by sysvinit under Linux.

 

[drhowarddrfine]

Linux is no longer a Unix-like system so why FreeBSD needs to care is beyond me when you consider some Linux distributions don't want to use it and others were dragged in kicking and screaming. It's no different than Windows having its own init system changing. How does that affect FreeBSD?

 

[Deleted member 13721]

Linux is no longer a Unix-like system so why FreeBSD needs to care is beyond me when you consider some Linux distros don't want to use it and others were dragged in kicking and screaming. It's no different than Windows having its own init system changing. How does that affect FreeBSD?

There are those who will stop at nothing to foist that thing onto this project too. They don't care about the UNIX philosophy, just that they get their way, at any cost. They may succeed eventually, so it would not be bad to have alternatives lined up.

 

[Crivens]

I would like to reprase the question a bit: How will the Linux world deal with what systemd will become in the future? And while we are at it - udev is a remake of devd.

So we would likely need to patch around the places where someone thought a hard dependency on systemd would be a good idea, and most likely will ignore anything that refuses to be changed in such a way. We are used to not getting it all on a silver platter, so why should we care too much?

Time will tell, and time and tide wait for no man.

 

[obsigna]

What does systemd do for headless machines (those without X)?

If the answer is "nothing", then why make it the default? For servers, the existing SysV init is plenty.

This is incorrect. It offers a complete replacement for service management (service(8) under FreeBSD) including services that have nothing to do with X11 or graphical UIs and startup scripts that are traditionally handled by rc(8) on FreeBSD and usually by sysvinit under Linux.

@@kpa, your answer is of course correct if we take the question "What does systemd do?" as being about the functionality of systemd. However, we could understand the question also like: "What are the benefits of systemd for headless machines (those without X)?" And in this case, your response is still lacking the answer.

systemd is mainly advertised because of giving performance gains when starting-up, isn't it? I raise my hand here, because I am particularly interested in the expected starting-up time savings. My low-end Atom Dual Core 1,67 GHz server (DNS/web/mail/file, ...) needs exactly 60 s. May I expect that systemd brings this down to 30 s? It is hard for me to believe this. On the other hand, a time saving of 3 s would for me mean almost the same as "nothing".

 

[kpa]

What does systemd do for headless machines (those without X)?

If the answer is "nothing", then why make it the default? For servers, the existing SysV init is plenty.

This is incorrect. It offers a complete replacement for service management (service(8) under FreeBSD) including services that have nothing to do with X11 or graphical UIs and startup scripts that are traditionally handled by rc(8) on FreeBSD and usually by sysvinit under Linux.

@@kpa, your answer is of course correct if we take the question "What does systemd do ...?" as being about the functionality of systemd. However, we could understand the question also like: "What are the benefits of systemd for headless machines (those without X)?" And in this case, your response is still lacking the answer.

systemd is mainly advertised because of giving performance gains when starting-up, isn't it? I raise my hand here, because I am particularly interested in the expected starting-up time savings. My low-end Atom Dual Core 1,67 GHz server (DNS/web/mail/file, ...) needs exactly 60 s. May I expect that systemd brings this down to 30 s? It is had for me to believe this. On the other hand, a time saving of 3 s would for me mean almost the same as "nothing".

The benefits are not in the area of performance. System start up times are irrelevant anyway because unless you suffer from ADHD you won't be restarting your machine ten times a day as a regular user. Where systemd and equivalents offer improvements is reliability and robustness in service handling including for example monitoring and crash recovery. This is an area where in my opinion FreeBSD and other open source OSes are still severly lacking because of shortcomings of tools that are used to implement the service framework, namely the Bourne shell.

I dislike MS Windows for many reasons but even I have to admit that they did something really right when they implemented their service framework. Other OSes are only now catching up.

 

[obsigna]

... The benefits are not in the area of performance. ...

How then shall I understand this:

...
Lennart Poettering and Kay Sievers, the software engineers who initially developed systemd, sought to surpass the efficiency of the init daemon in several ways. They wanted to improve the software framework for expressing dependencies; to allow more processing to be done concurrently or in parallel during system booting; and to reduce the computational overhead of the shell. ...

System start up times are irrelevant anyway because unless you suffer from ADHD you won't be restarting your machine ten times a day as a regular user.

Well, this statement throws the main goals of Lennart and Kay for systemd into the trash can.

Where systemd and equivalents offer improvements is reliability and robustness in service handling including for example monitoring and crash recovery.

1. The number of occasions my servers may be in need for this, are much much less than the weekly restart after the scheduled system update. I even cannot remember any of the many services were crashing in the middle of the operation.
2. I hate automatic crash recovery, because a crash means that something ran seriously bad, and I prefer that the crashed service stays offline, until I've had a chance to analyze what happened.
3. What reliability improvements are you talking about? 99.95 % to 99.97 %? That's even less benefit than an improvement in the starting-up time from 60 to 57 s.

 

[jb_fvwm2]

I recall, IIRC, seeing several [arch]forum topics weekly about systemd wrecking stuff (and/or at the ArchLinux Reddit subforum), but I know little or nothing about systemd other than reading a few threads a while back.

 

[Crivens]

For what it's worth, I was told that one of the driving forces behind systemd and the obsession with boot times is the automotive industry. Fast restarting of failed services or components is very important to them, also your "entertainment system" needs to be operational when you sit down in the driver seat. Boot starts when you click your key remote, and has to be almost over 3-5 seconds later. So go figure if debugging of custom tuned setups is on the agenda for these driving forces.

 

[owemeacent]

Linux is no longer a Unix-like system so why FreeBSD needs to care is beyond me when you consider some Linux distributions don't want to use it and others were dragged in kicking and screaming. It's no different than Windows having its own init system changing. How does that affect FreeBSD?

Linux is, as far as anyone's concerned, still a unix-like system, it mostly adheres to the POSIX specification, it uses mostly GNU userland, which is as close to Unix as Richard Stallman wanted it to be (and he wants it A LOT), and a lot of Linux distributions still don't use systemd: Debian doesn't (but it will), Gentoo is strictly against it, RedHat doesn't, and neither does Slackware, and many others don't use it either. It's just an init system, you could change it if you want, you don't have to fuss about it.

 

[scottro]

RedHat will be using it in its next iteration, RHEL7. One of the reasons systemd is becoming so ubiquitous is, IMO, because RedHat throws its not inconsiderable weight behind it. Slackware and possibly Gentoo are the relatively exceptional holdouts. With Debian and the *buntus going over to it, this means that the vast majority of Linux users will be using it.

Unfortunately, (again, IMO) it seems that various programs may have ties to systemd, and that means that porting these over to FreeBSD will possibly involve additional work. However, the previous sentence is based upon vague recollection, i.e. read it on the Internet somewhere, I think, so may be completely wrong. I can't name such a program (that is, a general userland program that in Linux will be tied to systemd).

 

[SirDice]

Linux is, as far as anyone's concerned, still a unix-like system, it mostly adheres to the POSIX specification,

POSIX != UNIX. Even Windows was at one point POSIX compliant. http://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

 

[drhowarddrfine]

And GNU userland isn't Unix either.

and a lot of Linux distributions still don't use systemd: Debian doesn't (but it will), Gentoo is strictly against it, RedHat doesn't, and neither does Slackware, and many others don't use it either.

That's my point. Why should FreeBSD be concerned about the Linux proprietary systemd when large swaths of themselves don't use it?

It's just an init system, you could change it if you want, you don't have to fuss about it.

Then why bring up the question?

 

[LukeWolf]

You know... I specifically said I wasn't interested in the complaining and fighting. Yet after the first reply, which was actually helpful, you guys dove right into doing that.

For those who think that "Oh the Linux ecosystem hasn't adopted it, why should we care?", guess what? You're wrong. All of the distributions except for Gentoo and Slackware either are or will be using it, and even in their camps a segment of the userbase is using it. This is not something you can just ignore.

Why should FreeBSD care about the systemd umbrella project? Well it's really quite simple, if you intend to use FreeBSD for desktop/workstation or mobile roles you better be paying attention to it. For example Consolekit is deprecated and unmaintained, and logind is its replacement, either you need to move to support OpenBSD in writing and maintaining a drop-in replacement for logind or give up on the desktop and mobile front because Consolekit support will be dropped by the desktop environments, and nobody will be writing new mobile environments on top of deprecated and unmaintained software, particularly now that a drop in replacement is being written. The other big two issues are going to be service files and session management. KDE is planning on swapping out the startkde script for a set of service files (although it will for the time being remain as a fallback option), and GNOME has spoken of using systemd to manage the user session as opposed to gnome-session. The launchd porting effort could solve this, and then it would just be a matter of providing all of the little dbus services that systemd provides so that the FreeBSD experience is not degraded versus the Linux experience.

The proper response right now is not complaining or trying to pretend it doesn't exist, but instead figuring out what can be done to ensure that FreeBSD will continue to be compatible with the leading desktop environments, and providing the best engineered solution to solve the problem. I am again more than willing to put my money where my mouth is and work on code, but I lack experience with C and systems level programming

 

[obsigna]

...
Why should FreeBSD care about the systemd umbrella project? Well it's really quite simple, if you intend to use FreeBSD for desktop/workstation or mobile roles you better be paying attention to it. ...

Perhaps you have more success with your systemd missionary on the PC-BSD forum. There, the server guys won't interfere by asking: "Why do I need systemd only to start Apache?"

 

[drhowarddrfine]

You know... I specifically said I wasn't interested in the complaining and fighting. Yet after the first reply, which was actually helpful, you guys dove right into doing that.

Speaking for myself, I find the question insulting. That we need to follow Linux' lead.

For that matter, let's all start a thread on a Linux forum asking how Linux is going to cope with the fact that they are no longer compatible with Unix.

For those who think that "Oh the Linux ecosystem hasn't adopted it, why should we care?", guess what? You're wrong. All of the distributions except

So all of them haven't. Someone else mentioned RedHat won't and one other big one.

The proper response right now is not complaining or trying to pretend it doesn't exist, but instead figuring out what can be done to ensure that FreeBSD will continue to be compatible with the leading desktop environments, and providing the best engineered solution to solve the problem.

And that truly is a problem for those who want to run FreeBSD as a desktop, which I also do. That some desktop environments may abandon all others in pursuit of Linux proprietary systemd is a problem with those people who make those desktop systems. I don't know that someone won't come up with a workaround to still make FreeBSD compatible with that, like it does now and, according to some, even faster and better than Linux does.

 

[ralphbsz]

This is incorrect. It offers a complete replacement for service management (service(8) under FreeBSD) including services that have nothing to do with X11 or graphical UIs and startup scripts that are traditionally handled by rc(8) on FreeBSD and usually by sysvinit under Linux.

I don't use service(8), and AFAIK there is no need to use it. Editing /etc/rc.conf is perfectly sufficient. So, let me re-ask my question: For a headless system (no X login, no X server), for which /etc/rc.conf is sufficient, what improvements does systemd offer?

systemd is mainly advertised because of giving performance gains when starting-up, isn't it?

• If your system is starting up a lot, then it is not a production system, but a toy (namely something that people play with). I'm interested in a stable, reliable, simple to manage production system.
• Want performance gains on starting up? Many things come to mind. Get a UPS, so a small power outage turns into a clean shutdown (without fsck) rather than a crash. Use file systems that don't have to wait for fsck, or where fsck runs. Remove unnecessary services and daemons from startup. And put the root file system on an SSD.
• On my system (a dual-core Atom, with a cheap SSD for root) the startup time is dominated by the BIOS, and it having to spin up and query five disks. The actual time from the kernel loading and init(8) starting to all services running and a login prompt on the console is probably 10 or 20 seconds. For a system that typically has an uptime of several months, that is not relevant.

Where systemd and equivalents offer improvements is reliability and robustness in service handling including for example monitoring and crash recovery. This is an area where in my opinion FreeBSD and other open source OSes are still severly lacking because of shortcomings of tools that are used to implement the service framework, namely the Bourne shell.

If services crash, the problem is much bigger than the need to restart them. It means that a service that the machine is SUPPOSED to provide is not working. Restarting a broken service is not the correct answer; hardening the service so it becomes reliable is the correct answer.

On the Linux religious war question: I have nothing against Linux. I use it, on probably two dozen machines at work, and a few at home. I even understand why some people select a *nix operating system for a graphical desktop (although I chose not to). However, I need an operating system for a server-class machine, which needs to be reliable and functional, with minimal effort. Replacing the functioning startup system we have today with something more complex is a step in the wrong direction, for my use pattern.

And to be clear: I have nothing at all against someone porting systemd to FreeBSD, and integrating it with KDE, GNOME, or whatever other software they want to integrate it with. But I have a serious problem with making it the default or only mechanism for starting services, unless someone can come up with a good argument for it. My main argument against it is: don't mess with a running system. The current rc setup functions well, and has a great balance between simplicity and easy of use, and functionality for its intended purpose.

EDIT: The spell-checker keeps changing "systemd" to "systems", and I have to keep going back to fix it. Sorry about that.

 

[SirDice]

If services crash, the problem is much bigger than the need to restart them. It means that a service that the machine is SUPPOSED to provide is not working. Restarting a broken service is not the correct answer; hardening the service so it becomes reliable is the correct answer.

I fully agree. And in case you actually need something like this there's always sysutils/daemontools. There are also projects like sysutils/fsc.

 

[Crivens]

The proper response right now is not complaining or trying to pretend it doesn't exist, but instead figuring out what can be done to ensure that FreeBSD will continue to be compatible with the leading desktop environments, and providing the best engineered solution to solve the problem. I am again more than willing to put my money where my mouth is and work on code, but I lack experience with C and systems level programming

Maybe it is only me, but putting "engineering" into the context of systemd does not sound right. The purpose of systemd seems not to be a solution to a problem but an attempt to be a problem as well, defying solution. Walled garden from inside, so to speak. Maybe it is neccesary to deal with systemd somewhere and somehow - by porting, emulating, or patching it out of any component depending on it.

If it gets completely impossible to work with any system but Linux due to the tentacles systemd spreads out, it will be time for me to set up virtual machines and use some other means of GUI and keep a headless FreeBSD to use.

Adapting systemd into any application or desktop environment will tie that code into Linux and leave it at the mercy of any decision which may come up in the developers there. That is what any author of such components needs to keep in mind. And this is something I, for one, would resist. So maybe we do not need to deal with it at that level but simply need to remind those authors that this might not be the best decision to make. But you never know.

 

[drhowarddrfine]

That is exactly my point.

 

[fonz]

I am again more than willing to put my money where my mouth is and work on code, but I lack experience with C and systems level programming

I suggest you start by evaluating exactly what the impact of systemd would be: which components of either ports or the base system does it replace? Which does it interact with? Which will be requiring it? Once there's a clear picture of the scope of the "project", it can be determined whether it's feasible and, if so, what would be needed.

 

[LukeWolf]

You know... I specifically said I wasn't interested in the complaining and fighting. Yet after the first reply, which was actually helpful, you guys dove right into doing that.

Speaking for myself, I find the question insulting. That we need to follow Linux' lead.

And your preference would be to continue using a deprecated and unmaintained project (Consolekit) that desktop developers are looking to drop support for? The fact is you don't even need to follow Linux (and in fact even can't because systemd is specific to the Linux kernel). What needs to occur for FreeBSD to continue to support the desktop environments of the future is to support a set of DBUS interfaces, which you can choose to handle however you want. It's not Linux that will be being followed but the desktop developers with their declared needs.

For that matter, let's all start a thread on a Linux forum asking how Linux is going to cope with the fact that they are no longer compatible with Unix.

For those who think that "Oh the Linux ecosystem hasn't adopted it, why should we care?", guess what? You're wrong. All of the distributions except

So all of them haven't. Someone else mentioned RedHat won't and one other big one.

systemd will be coming into RHEL7, RHEL6 only isn't using it because systemd wasn't around when it came out. Debian will be using it in their next major version, Ubuntu will be using it. Fedora, openSUSE, Maegia, and Arch already use it, and derivatives use what their parents use. This means that the only holdouts are Gentoo, and Slackware. Gentoo has systemd as a first-class (though not default) option, and there's a significant part of their community that uses it, and some members of the Slackware community have made it so that it works there too. Neither Gentoo or Slackware are significant enough to halt the adoption of the interfaces systemd provides, and so will also have to either work around them or shift to systemd.

The proper response right now is not complaining or trying to pretend it doesn't exist, but instead figuring out what can be done to ensure that FreeBSD will continue to be compatible with the leading desktop environments, and providing the best engineered solution to solve the problem.

And that truly is a problem for those who want to run FreeBSD as a desktop, which I also do. That some desktop environments may abandon all others in pursuit of Linux proprietary systemd is a problem with those people who make those desktop systems. I don't know that someone won't come up with a workaround to still make FreeBSD compatible with that, like it does now and, according to some, even faster and better than Linux does.

And just what did you think I was calling for? Bringing systemd to FreeBSD is impossible, however supporting the dbus interfaces it provides, and providing equivocal functionality when we're talking desktop configurations (in other words what you termed as workarounds) is completely possible and in fact required if FreeBSD desires to continue supporting the major desktop environments in the future. However the entire reason I started this thread is that until that OpenBSD GSOC project nobody was moving forward on said workarounds and Desktop Developers are already moving forward on shifting away from Consolekit (As far as I know Gnome is now shipping in degraded mode for systems not supporting the logind dbus interface) and distribution specific code towards systemd's interfaces.