systemd is obsolete

[fr0xk]

But too many developers invest in the "not invented here"; "I don't care that your solution is technically superior, we didn't create it so it must be wrong"

Yup, something like that

 

[zirias@]

fr0xk I don't think it makes any sense to argue with systemd developers. It's just a broken design (IMHO), so I stay away from it as much as I can. I mean, they have some strong opinions that conflict with practical use, for example:

• A service in "systemd world" should not daemonize (fork, write and lock pidfile, start new session, close file descriptors etc...). If a service strictly follows this, you lose the ability to simply fire it up "ad hoc" without any help from the init system.
• A service shouldn't need commandline arguments for configuration. Well, quite some services still do, no matter what systemd devs think, so you end up copying and editing their stupid service files ...

 

[Ferocious1881]

Certainly not.

But first things first, you seem to have missed the usage of "obsolete" in the title was nothing but a reference to the famous Tanenbaum/Torvalds flame. The word isn't repeated anywhere. Still there are some similarities: Tanenbaum's main complaint about Linux was its monolithic architecture, which it kind of shares with systemd. Both aren't the horrible "big ball of mud"-style monoliths but "modular monoliths", which aren't generally considered obsolete but do have their uses.

Now, what's the difference to ZFS? In very short, ZFS is a "storage solution", similar to commercial and closed-source solutions that existed before. Some design goals for such a solution (performance, reliability, etc ...) more or less mandate a tighter coupling of components. You could say similar about a monolithic kernel like Linux (or just as well FreeBSD's kernel), it's hard do reach a similar level of performance combined with portability in a microkernel architecture which Tanenbaum claimed was the only sane way to do it.

But systemd? There's just no justifyable reason to couple all the stuff it does (log writing and reading, service supervision, session management, "blue screens"(!) ?, and so on) so tightly. Performance is rarely a factor here, for example. A collectionof tools not coupled at all could give you the same set of features with much more flexibility and reduced hard dependencies.

But monolithic kernels are indeed absolute, not you looked the performance of the seL4 kernel, they say security is no excuse for poor performance.

In all seriousness, the case for monolithic kernels is weaker than ever with mircokernels like the seL4 proving that in fact is possible to have performant microkernels, and with their unchallenged claim to be the fastest kernel.

For what I look the fowards plan for monolithic kernels is to anykernelize like NetBSD did, and possibly eventually microkernelize.

 

[Ferocious1881]

fr0xk I don't think it makes any sense to argue with systemd developers. It's just a broken design (IMHO), so I stay away from it as much as I can. I mean, they have some strong opinions that conflict with practical use, for example:

• A service in "systemd world" should not daemonize (fork, write and lock pidfile, start new session, close file descriptors etc...). If a service strictly follows this, you lose the ability to simply fire it up "ad hoc" without any help from the init system.
• A service shouldn't need commandline arguments for configuration. Well, quite some services still do, no matter what systemd devs think, so you end up copying and editing their stupid service files ...

Could your please develop in your first point, and explain the second one?

 

[fr0xk]

I find it more troubling that FreeBSD is getting launchd: http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years and that there are people in the FreeBSD camp who believe that FreeBSD should adopt PLists for configuration files. That is so anti-UNIX.

Linux on the another hand is beyond hope from a UNIX point of view.

PList is horrible btw. But I don't think everything has to be a file. Treating USBs as files has already produced horrible results because they are not, in fact, files. This approach leads to confusion and inefficiencies, especially since USB devices operate on a different layer of abstraction. They don’t behave like regular files in a filesystem. They’re not network interfaces either. Now, I don't exactly know what Unix philosophy is, and none of the conflicting philosophies written by Ken and Dennis states, "everything has to be a file."

In fact, the original Unix design principles states that not everything fits into the file abstraction neatly. When you look at Unix's architecture, many core components, like processes and sockets, exist outside this file paradigm. What Unix philosophy really says is that, during times of confusion, simple modular systems are easier to debug than complex ones; at least that's my interpretation. The idea is that keeping things straightforward leads to better maintenance and understanding. But that's just a mere guideline for building software, not a rule.

 

[Ferocious1881]

I find it more troubling that FreeBSD is getting launchd: http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years and that there are people in the FreeBSD camp who believe that FreeBSD should adopt PLists for configuration files. That is so anti-UNIX.

Linux on the another hand is beyond hope from a UNIX point of view.

Did FreeBSD not prefer jobd?
The alternative to everything is a file is everything is a capability like seL4.

 

[Ferocious1881]

But too many developers invest in the "not invented here"; "I don't care that your solution is technically superior, we didn't create it so it must be wrong"

Don't invented here does not have to be evil, and if fact it is not, is more like sunk cost fallacy.

 

[mer]

Don't invented here does not have to be evil, and if fact it is not, is more like sunk cost fallacy.

Absolutely, the problem is the default stance seems to be "it's not invented here so it must suck because we are smarter and won't make the same mistakes". I've run into that more than a few times in my career and when you're the new guy on a project and hear the team talking about something and you say "That's not going to work. Last place we did that and we ran into XYZ and lost all this time" I got told "Well we're much smarter here and won't make those same mistakes".

Guess what? About 3 months later I was starting to hint "Told you so".

It's about letting go of ego and actually listening.

 

[fr0xk]

This would be ok, the main concern about it being: the scope is just too HUGE. For me, even a "system and service manager" should do its work independent of init. init, as the very first userland process, that's ALWAYS running when the system is up, should be as simple and minimal as possible.

Most arguments against and in favour of systemd are philosophical and opinionated: "it's not UNIX," "not POSIX-compliant," "runs as PID1, so it must be minimal, it'll take down entire system with it etc"

Systemd bundled 69 (now 89) components in a single tarball and keeps them in one upstream repo with a unified release cycle. Build it with all options, and you get 89 binaries. Most daemons run with minimal privileges using kernel capabilities. Systemd doesn't care what the executable is—users can run shell scripts or any language as a service. Users control what gets built through compile-time switches. This modularity isn't much different from the Linux kernel. Systemd reintroduced UNIX multi-seat support, but with modern hardware—graphics, audio, webcams, all plug-and-play.

Now UNIX means something different to everyone. FreeBSD treat it as a codebase, others as ideas or APIs. Trying to satisfy them all these people is a waste of time. Whether something is "UNIX" or not shouldn’t matter imo. Take macOS for example, it is a certified UNIX by Open Group but I know a lot of *BSD users who will vomit looking at it. Users can still use syslog with systemd. Every D-Bus interface has a command-line tool like systemctl or loginctl, exposing the full API for scripts. During initial days, systemd's git had 16 committers, only six from Red Hat. The rest from Arch, Debian, Intel, Canonical, SUSE, and community contributors. 374 people have submitted patches from all sorts of backgrounds. Systemd’s `--with-rootprefix=` option lets users split components neatly. Almost any part of systemd can be replaced, except journald. D-Bus relies on sockets too for message passing; it’s just standardized serialization over them.

Not liking systemd would more to do with philosophical design decision. For example, I didn't like everything slammed at /bin and /lib by mainstream Linux distribution package managers. I don't like global interpreter lock in python, which limits concurrency in multi-threaded programs, whitespace indentation, tail calls, pip and dynamic typing. But that's more of a design disagreement rather based on technical bugs with these package managers or python. Now a days, I write better python scripts because I understand it's design flaws

 

[MG]

What's the difference with rc.d? I think both are intentionally not transparent to set a empirical standard. Sort of OSS "branding". For FreeBSD, what really happens if I type "service sshd onestart" ? That's a list of CLI-commands, including various checks on current conditions. I think system configuration should be procedural for clarity. No managing entities that require to read OS-bound documentation.

 

[fr0xk]

What's the difference with rc.d? I think both are intentionally not transparent to set a empirical standard. Sort of OSS "branding". For FreeBSD, what really happens if I type "service sshd onestart" ? That's a list of CLI-commands, including various checks on current conditions. I think system configuration should be procedural for clarity. No managing entities that require OS-bound documentation.

systemd # The init system that manages services and resources.
├── boot.target # The initial target reached during the boot process.
│ ├── system.slice # Contains system services.
│ │ ├── init.scope # Represents the initial process (PID 1).
│ │ └── user.slice # Contains user services.
│ │ ├── user@1000.service # Represents user session for UID 1000.
│ │ └── session-1.scope # Represents user session scope.
│ ├── multi-user.target # Target for multi-user operations without graphical interface.
│ │ ├── networking.service # Manages networking services.
│ │ ├── sshd.service # Manages SSH service.
│ │ ├── cron.service # Manages cron jobs.
│ │ └── httpd.service # Manages web server services.
│ ├── graphical.target # Target for graphical user interfaces.
│ │ ├── gdm.service # Manages the display manager.
│ │ └── display-manager.service # Manages display manager services.
│ └── local-fs.target # Mounts local file systems.
│ ├── local-fs-pre.target # Prepares for local file system mounts.
│ ├── var.mount # Mounts the /var directory.
│ └── home.mount # Mounts the /home directory.
├── shutdown.target # Initiated during system shutdown.
│ ├── reboot.target # Target for system reboot.
│ ├── poweroff.target # Target for powering off the system.
│ └── halt.target # Target for halting the system.
├── systemctl # Tool for managing systemd services and units.
├── journalctl # Tool for querying and displaying logs from the journal.
├── loginctl # Manages user logins and sessions.
├── timedatectl # Controls system time and date settings.
├── hostnamectl # Manages system hostname.
├── localectl # Configures system locale and keyboard layout.
├── networkctl # Manages network connections.
├── resolvectl # Manages DNS resolution settings.
├── systemd-analyze # Analyzes and debugs systemd boot performance.
├── systemd-tty-ask-password-agent # Prompts for passwords in the terminal.
├── systemd-nspawn # Lightweight container management tool.
├── systemd-cgls # Displays control group contents.
├── systemd-cgtop # Monitors control groups and resource usage.
├── systemd-run # Runs commands in transient units.
├── systemd-resolved # Provides DNS resolution services.
├── systemd-timesyncd # Synchronizes system clock with NTP servers.
├── systemd-sysusers # Creates system users from configuration files.
├── systemd-sysctl # Applies sysctl settings from configuration files.
├── systemd-ask-password # Prompts for a password.
├── systemd-journal-flush # Flushes the journal logs.
├── systemd-update-done # Marks units as up to date.
├── systemd-homed # Manages home directories for users.
├── systemd-logind # Manages user logins and sessions.
├── systemd-machined # Manages local containers and virtual machines.
├── systemd-userdbd # Manages user databases.
├── systemd-escape # Escapes names for use in systemd unit files.
├── systemd-tmpfiles # Creates and deletes temporary files.
├── systemd-volatile # Manages volatile filesystems.
├── systemd-gpt-auto-generator # Automatically generates units for GPT partitions.
├── systemd-suspend.service # Manages system suspension.
├── systemd-hibernate.service # Manages system hibernation.
├── systemd-pivot.service # Handles pivot_root operations.
├── systemd-sysusers.service # Creates system users at boot.
├── systemd-networkd.service # Manages network configurations.
├── systemd-resolved.service # Provides DNS resolution services.
├── systemd-timesyncd.service # Synchronizes system time with NTP.
├── systemd-journald.service # Collects and stores logging data.
├── systemd-logind.service # Manages user logins and sessions.
├── systemd-udevd.service # Manages device events and nodes.
├── systemd-cgls.service # Displays control group contents.
├── systemd-tmpfiles-clean.service # Cleans up temporary files.
├── systemd-udev.service # Manages udev device events.
├── systemd-oomd.service # Manages out-of-memory situations.
├── systemd-cryptsetup.service # Manages encrypted volumes.
├── systemd-homed.service # Manages user home directories.
├── systemd-networkd-wait-online.service # Waits for network to become online.
└── systemd-shutdownd.service # Handles system shutdown events.

# BSD Init (NetBSD) Features
├── rc # Initialization script that runs at boot.
├── rc.conf # Configuration file for enabling/disabling services.
├── rc.d # Directory containing service scripts.
│ ├── sshd # Script to manage SSH daemon.
│ ├── named # Script to manage DNS service.
│ ├── httpd # Script to manage HTTP server.
│ ├── cron # Script to manage cron daemon.
│ └── mountall # Script to mount all filesystems.
├── shutdown # Command to shutdown the system.
├── reboot # Command to reboot the system.
└── halt # Command to halt the system.

# Solaris SMF Features
├── svcadm # Command to manage services.
│ ├── enable # Enables a specified service.
│ ├── disable # Disables a specified service.
│ ├── restart # Restarts a specified service.
│ └── refresh # Refreshes a specified service.
├── svcs # Displays the status of services.
├── svcs -a # Displays all services, including disabled ones.
├── svccfg # Command to configure services.
│ ├── import # Imports service configuration.
│ ├── list # Lists service configuration.
│ └── setprop # Sets service properties.
├── smf(7) # Man page describing SMF features.
└── svc.startd # The service management daemon

 

[Ferocious1881]

I agree, if only because they are hard to parse with traditional tools. You need to use Python/Perl/Ruby/etc. and libraries to parse/modify them, which is a lot of programming overhead for system administration.

Not really a problem if you have a powerful shell like Microsoft's Powershell.

systemd's targets, sound like some kind of natural addition to Solaris SMF, very similar to run levels. Meanwhile things like resolvectl and loginctl woud be better as independent tools, which are provided the required APIs to be implemented by something like jobd.

 

[MG]

systemd # The init system that manages services and resources.

Type ls /etc/rc.d. What are those?

 

[zirias@]

What's the difference with rc.d? I think both are intentionally not transparent to set a empirical standard. Sort of OSS "branding". For FreeBSD, what really happens if I type "service sshd onestart" ?

See rc.subr(8), run_rc_command. service(8) is just a thin wrapper around running rc scripts, your example command will invoke /etc/rc.d/sshd onestart (which you could do directly just as well), which will pass onestart to the run_rc_command shell function from rc.subr(8).

There's no standard for system startup at all, except for the traditional Unix way: The kernel launches some init process, which will do nothing but ultimately own/reap all processes and launch some startup shell script (traditionally /etc/rc) once. Doing the whole startup in a single huge script doesn't scale and is very error-prone, so it was modularized to call individual scripts in /etc/rc.d (the .d suffix for a directory is a naming convention for splitting up larger scripts and similar). Unix System V came up with the "sysvinit" scheme to do that, which was adopted on GNU/Linux systems. BSDs did it differently, not using the "runlevels" sysvinit invented. FreeBSD's rc(8) is basically "Mewburn rc" as initially developed on NetBSD, which has a number of advantages over sysvinit, like ordering the individual scripts based on dependency metadata (instead of fixed by filename like in sysvinit), and providing a large shellscript library doing all the standard stuff every init script needs.

In a nutshell, FreeBSD's system startup is a carefully modernized and modularized flavor of the classic Unix startup. Systemd is something completely different.

Regarding the rest of this thread, it's really tiring to see all these well-known strawman arguments again ... like calling any architectural thought "philosophic" (no, it isn't, architecture doesn't exist for its own sake but to meet actual requirements, often of the non-functional kind, like reliability, flexibility, etc), like arguing about systemd's many binaries, so that's clearly modular (sure it is, but they're all coupled through systemd-specific communication means like APIs, protocols, ... making the whole thing still a monolith), etc pp ....

 

[Ferocious1881]

See rc.subr(8), run_rc_command. service(8) is just a thin wrapper around running rc scripts, your example command will invoke /etc/rc.d/sshd onestart (which you could do directly just as well), which will pass onestart to the run_rc_command shell function from rc.subr(8).

There's no standard for system startup at all, except for the traditional Unix way: The kernel launches some init process, which will do nothing but ultimately own/reap all processes and launch some startup shell script (traditionally /etc/rc) once. Doing the whole startup in a single huge script doesn't scale and is very error-prone, so it was modularized to call individual scripts in /etc/rc.d (the .d suffix for a directory is a naming convention for splitting up larger scripts and similar). Unix System V came up with the "sysvinit" scheme to do that, which was adopted on GNU/Linux systems. BSDs did it differently, not using the "runlevels" sysvinit invented. FreeBSD's rc(8) is basically "Mewburn rc" as initially developed on NetBSD, which has a number of advantages over sysvinit, like ordering the individual scripts based on dependency metadata (instead of fixed by filename like in sysvinit), and providing a large shellscript library doing all the standard stuff every init script needs.

In a nutshell, FreeBSD's system startup is a carefully modernized and modularized flavor of the classic Unix startup. Systemd is something completely different.

Regarding the rest of this thread, it's really tiring to see all these well-known strawman arguments again ... like calling any architectural thought "philosophic" (no, it isn't, architecture doesn't exist for its own sake but to meet actual requirements, often of the non-functional kind, like reliability, flexibility, etc), like arguing about systemd's many binaries, so that's clearly modular (sure it is, but they're all coupled through systemd-specific communication means like APIs, protocols, ... making the whole thing still a monolith), etc pp ....

Modular monoliths?
If those APIs, protocols, et cetera were standarized, you would still think it as a monolith?

 

[zirias@]

Modular monoliths?
If those APIs, protocols, et cetera were standarized, you would still think it as a monolith?

Certainly. "Standards" don't matter here at all, what matters is dependencies, many of systemd's jobs can't be done without other systemd components being available, so it's a modular monolith. There are even "distributed monliths" nowadays btw. That alone doesn't mean it's bad, as already mentioned. See above for why I think this design decision is bad for system startup.

Btw, you're also the one arguing with a lab-project kernel all over these forums, something Tanenbaum meanwhile understood was incomplete thinking....

 

[MG]

See rc.subr(8), run_rc_command. service(8) is just a thin wrapper around running rc scripts, your example command will invoke /etc/rc.d/sshd onestart (which you could do directly just as well), which will pass onestart to the run_rc_command shell function from rc.subr(8).

There's no standard for system startup at all, except for the traditional Unix way: The kernel launches some init process, which will do nothing but ultimately own/reap all processes and launch some startup shell script (traditionally /etc/rc) once. Doing the whole startup in a single huge script doesn't scale and is very error-prone, so it was modularized to call individual scripts in /etc/rc.d (the .d suffix for a directory is a naming convention for splitting up larger scripts and similar). Unix System V came up with the "sysvinit" scheme to do that, which was adopted on GNU/Linux systems. BSDs did it differently, not using the "runlevels" sysvinit invented. FreeBSD's rc(8) is basically "Mewburn rc" as initially developed on NetBSD, which has a number of advantages over sysvinit, like ordering the individual scripts based on dependency metadata (instead of fixed by filename like in sysvinit), and providing a large shellscript library doing all the standard stuff every init script needs.

In a nutshell, FreeBSD's system startup is a carefully modernized and modularized flavor of the classic Unix startup. Systemd is something completely different.

Regarding the rest of this thread, it's really tiring to see all these well-known strawman arguments again ... like calling any architectural thought "philosophic" (no, it isn't, architecture doesn't exist for its own sake but to meet actual requirements, often of the non-functional kind, like reliability, flexibility, etc), like arguing about systemd's many binaries, so that's clearly modular (sure it is, but they're all coupled through systemd-specific communication means like APIs, protocols, ... making the whole thing still a monolith), etc pp ....

Running a 300 lines rc script for years as only thing between init and vt login. The only problem I had with it was that some subsystems aren't fully up after the command for it finished, like if USB is coming up after loading the required kernel modules, it still takes different times in milliseconds before a device on it becomes approachable. It needs some backgrounding and delays during the startup process. 1 real advantage of only 1 script is that you can literally see what happens, redirect things to boot log files or insert a temporary shell to research the situation on a particular moment during startup.

 

[Ferocious1881]

Certainly. "Standards" don't matter here at all, what matters is dependencies, many of systemd's jobs can't be done without other systemd components being available, so it's a modular monolith. There are even "distributed monliths" nowadays btw. That alone doesn't mean it's bad, as already mentioned. See above for why I think this design decision is bad for system startup.

Btw, you're also the one arguing with a lab-project kernel all over these forums, something Tanenbaum meanwhile understood was incomplete thinking....

"lab-project kernel" is used in production.

 

[blackhole]

The concept of runlevels is flawed.

Most Linux distributions, didn't properly implement SysV runlevels anyway.

In Debian, for example, runlevels 2 - 5 were the same. 0 was system halt, 1 single user, 2 - 5 multi user and 6 reboot.

 

[Jose]

Could one just by the same argument declare ZFS obsolete?

Turns out "separation of concerns" isn't a bright line you can draw everywhere all the time. You have to consider the trade-offs of each approach in whatever problem you're solving. See the microservices hype, monorepos, etc. The only thing that is certain is that absolutely declaring that any particular approach is a silver bullet is wrong.

Having said that, I was skeptical of the approach of combining a volume manager with a file system. Boy was I wrong!

 

[PMc]

But you have to show these design flaws through tangible, reproducible technical terms with actual steps and patches to convince developers, also provide solutions that does everything systemd can but your way.

"I think X design is better than Y" is not going to cut through a team of opinionated developers ready to eat your each and every philosophical arguments for breakfast. I've told you I tried it, never worked

Sure, because it is a religious problem, not a technical one.

Western civilisation has an understanding that if there are two different solutions A and B, then if you manage to prove that solution A is right, you have thereby automatically proven that solution B must be wrong.

This shaped western thinking since the age of enlightenment, and while quantum physics shows that it is a flawed understanding, it will not go away so easily.

 

[RussellASC]

There's nothing wrong with database configuration, AIX is a testament to that

Just to throw a few points out, the AIX ODM is a binary database with a very strict schema used to configure core system services, system settings, and device driver attributes. It is a very low level C library, smaller than even Berkeley DB.

The best part about this is you don't have to be concerned about failing syntax in system configuration files. Most things can be customized on the command line via short commands, and invalid values aren't allowed.

If the ODM required many layers, additional interpreters like Perl or Python to function, then it'd be a problem. As it stands it's actually quite elegant for the portions of system configuration it affects.

On FreeBSD, tools like sysctl and sysrc are very close in functionality. Imagine tools like sysctl, camcontrol, usbconfig with persistence. Getting low level lego brick tools to automate system configuration is always a good idea.

 

[kpedersen]

But you have to show these design flaws through tangible, reproducible technical terms with actual steps and patches to convince developers, also provide solutions that does everything systemd can but your way.

"I think X design is better than Y" is not going to cut through a team of opinionated developers ready to eat your each and every philosophical arguments for breakfast. I've told you I tried it, never worked

Half agree. I think it is better still to just ignore the broken ideas and simply invest your time in better technology.

And then when people try to bring the broken ideas to your better technology, then just ignore them. Sure they might accuse you of "gate keeping" or being "old fashioned" and all the other undermining sleazewords but it still doesn't change the fact that you don't need to engage with their broken ideas and you can enjoy life.

 

[Ferocious1881]

There's nothing wrong with database configuration, AIX is a testament to that, but it's pretty clear that systemd is behind the times.

Svchost, on Windows, can survive being killed, in fact it has several processes running at once.

Systemd assumes that it's code is perfect and that exploits to the PID 1 binary, that is init and process manager, are impossible. This is bad design 101. No matter how much you bury it under mandatory access controls, namespaces, privilege separation, and other security systems you can't ignore the problems this oversight could present.

If does not matter If you formally verify your code, but maybe with the price maybe you are better just not doing what systemd does.