SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
No matter who you are or who you're talking to this is not appropriate.
If you can't handle a post like you should call in a moderator.
Please do not do that again.
The initial implementation is only part of the story; the fat lady is still singing and Lennart and co aren't done yet with their grand design. Maybe it turns out I'm wrong. Only time will tell.
Funny fact:
The "initial implementation" was already available in "Wheezy".
People just ignored it because it because it wasn't on TV yet ...
Could you please then inform me as to what benefits there are for a Desktop SOHO system?
This is all gathered via a google search (not all are unique to systemd, but none are currently a part of Slackware's init system). I have not had any actual experience with systemd and I don't plan to unless it's included in Slackware in the future. This is to the best of *my* understanding. If I misunderstood something, please let me know.
Logging - Say what you will about binary logs, if they do function properly, you get immediate logging as soon as the init RAM disk is started all the way to the final shutdown of the system. (How many times have you tried to glean information from the boot process only to have it go by too quickly?) It can also store non-text, like memory dumps, which can be used later in further debugging. The old syslog can be used in place without the extra benefits of binary logs and without the possibility of corruption. Do the benefits of binary logging outweigh the possibility of corrupted logs? To me, no.
Unit files - Easy to make config files using declarative language used to start up system daemons. This replaces the various rc.* files. They are simplistic to make and seem to have little to no downsides (other than ReaperX7 stating that it could lead to people not learning proper scripting techniques). It still supports running shell scripts if needed (although, I believe it would require a basic unit file). Benefits outweigh the costs? To me, yes.
Dependencies - Services are able to be started once a certain set of dependencies are met. This is different than rc.* when startup is based on location in the script. The dependencies can be more than just a program/service starting, it can be based on udev, dbus, sockets, etc. One example of this is to mount the network harddrives after the network comes up, but mounting any physical discs before. The possible benefits from this are there, but I have no idea how well it works in practice. It could cause dependency circles when two things are waiting for each other to start. I don't know the likelihood of this, so do the benefits outweigh the costs? To me, unknown.
Parallelization - Allows the startup sequence to occur in parallel. This allows two or more services to start at the same time. Because of unit files and the dependencies specified, this should prevent programs from starting too early. This does usually equate to a boot speed increase and I am not aware of downsides of parallelization (short of the downsides listed in dependencies. Benefits outweigh the costs? To me, probably.
Cgroups - Cgroups containerizes a process and all child processes. This allows systemd to keep track of child processes even when the parent exits and shut them down if needed. This, in theory, is much better than using a PID, since we've all ran into the issue when a process won't start because an old PID is left in /run. It seems you are also able to limit resources to certain containers, meaning that you can limit how much RAM or CPU usage. I could see this adding complexity to the system, but the tradeoffs may be worth it. Benefits outweigh the costs? To me, undecided.
Additional Core Components - Replaces startup shell scripts, pm-utils, inetd, acpid, syslog, watchdog, cron, and atd with systemd components. This makes it easier for maintainers to provide the features those programs do, since they will all be included and won't need to be gathered separately and require verification they all work together. They also fall under a unified release schedule and come in the same tarball. Some replaced abandoned software, like logind replacing consolekit. However, all of this also causes feature creep and creates a larger amount of code to debug. This is probably one of my biggest complaints about systemd. The combination of many programs that don't need to be combined. It creates the possibility for more problems and works to prevent you from using alternatives if desired. You can see what it has taken over when you look at its ancillary components: consoled, journald, logind, networkd, timedated, udevd, and libudev. Adding more services to systemd seems very reminiscent of Windows and its svchost.exe file. Bug reports are sometimes ignored. Benefits outweigh the costs? To me, no.
The benefits (and the costs) are there and it is up to the individual if the benefits outweigh the costs.
Quote:
Originally Posted by ReaperX7
So with units one doesn't have to learn command structures and such as with proper scripting techniques. How convenient...
How is it different than config files? It could be done either way, but if you look at it from their perspective, a "config" file isn't much different than a unit file. It is a config file telling systemd how to run a service and what it relies on.
I don't generally write too many startup shell scripts, but I do still create scripts for other things.
I'll only add that it's quite possible (in theory) to log non-text, including memory dumps and complex data structures, to text logs, by using a structured logger. I prefer JSON logs for this.
Admittedly, I'm not aware of a JSON logger for system startup, but in principle one could be developed.
The point I have is that systemd takes away a users' choice and freedom to choose not only an init system, but a network daemon, ntpdate, login tracker, etc I could write a ream about what systemd replaces. I think a system like Gentoo's is best - have a reliable base system with whatever init system you want (Yes, Gentoo uses sysvinit, through OpenRC) and have systemd as an option. I'm not against something like systemd existing, but I don't want it to become the status quo - that's what I have an issue with.
For as many benefits systemd brings I can name just as many downsides:
Less secure: By using D-BUS to message and communicate with all of the systemd-* processes, any exploits to D-BUS can potentially affect the entire systemd infrastructure. Also, any race conditions that arise in the process supervisor can automatically affect init, the one process which should be as small and simple as possible.
More memory intensive: I had an Arch system prior to the systemd change. With the system, its 1GB of RAM and Prescott P4 was able to run Cinnamon with a Radeon 9000. When I let systemd update the system, I started having progressively worse OOM problems from the system to the point I had to roll back Arch to using initscripts to make it even usable.
Binary logs have no atomic or transactional consistency. Also, some of us may not want coredumps inside our logs.
Not portable: Until recently there were many issues with using systemd on non-x86 architectures. This has been somewhat resolved, but I still hear from PowerPC Linux users about occasional segfaults which go on ignored in bug reports. In addition, you cannot use systemd with musl, uclibc, dietlibc or other alternative libraries. If the situation continues, then Linux may be less lucrative for embedded purposes as non-systemd init systems, device node managers etc. all go unmaintained.
Repeated restarts of processes leads to "flapping": This extends to Upstart and other process supervisors, but it isn't well documented on how to tell systemd to give up after one attempt to restart. Flapping can fill logs with useless data, cause alerts across the board etc.
Massive dependency chain and monolithic design: Why does one need D-BUS, on a server? It just reinvents a very simple concept - sockets. Seriously, we aren't Windows and we don't need a centralised IPC system that resembles Windows in ANY shape or form. Furthermore, why the hell does udev, logind, networkd, consoled, timed, hostnamed, etc. all need to be in the same project and part of the same hunk. Sure you can change it at build time, and it is technically modular, but still. Uselessd is something I am looking at with a nod of approval - if you're gonna design an init and process supervisor, please, please please do not do what RedHat did with systemd and make it into this massive mess.
Rude, surly and conceited people running the project. I've had nasty emails from Kay Sievers when I sent him a piece of my mind regarding him passing the buck on the whole debug kernel/systemd issue - I had to block his emails when I genuinely sent him some constructive criticism regarding the way he behaved towards Torvalds, he sent back several harassing emails. I will not share them to protect my privacy, however. Lennart has been equally rude, unprofessional and absentee when sometimes important issues are brought up - on binary logs he effectively told everyone to shove it if they have issues with corruption.
For systemd to be effective as a platform, the system will need to be rebuilt around it with packages that utilize libsystemd protocols and setup their own unit file.
This is what is not being said on Debian's end trying to do two platforms in one package. You can't built for traditional GNU/Linux and build equally for systemd. These two platforms are NOT interchangeable.
Either you end up with what amounts to a bunch of packages with libsystemd as a dependency or you have traditional Linux library using packages to what would amount, more or less to:
Thank you Bassmadrigal for your time and effort. I am actually quite familiar with systemd both in theory (I've spent many hours in research) and in practice (I've been running 3 test distros for perhaps a total of 200 hours usage, 2 of which began as not-systemd and which were subsequently "upgraded" to systemd) but I wanted to see what you considered benefits. What I am mostly seeing is a list of features, not benefits.
Because SolydK and Kubuntu are Debian based and have kept to as minimal adoption as they can get away with and OpenSuse is a strong supporter of systemd and also since I installed it before it "went systemd" I will confine my comments to it since it seems most revealing and relevant.
First a general comment about parallelization. IMHO it is not a given that parallelization is a good thing in binary systems as problems are vastly more complicated to debug. The most basic truth that can be said about computers is that they are dumb but very, very fast. You likely have noticed that parallel ports, busses and processes have all but been eliminated on motherboard hardware in favor of serial and the reasons for this is reflected in software generally for similar reasons.
Some of the features you mention above can and probably should be combined since they are essentially the same thing or part of the same basic process(es). I'm glad that I asked you because you did indeed do a good job of being objective and factual rather than wild hand-waving. Kudos. That said, I still don't see one serious theoretical advantage to a Desktop/SOHO user or admin and most definitely not commensurate with cost, let alone risk.
In practice it is even clearer. My OpenSuse install is only slightly negatively impacted by often hanging on boot as compared to SysVinit, but there is not one single thing I can do now that I could not do before of any import and there are a few things I cannot do at all or as easily. Again, it isn't a deal-breaker so far. I can in all good conscience say that OpenSuse is a solid, respectable distro that can deliver the goods to many kinds of users. I prefer the older ways very much in theory and a little bit in practice. However I strongly resist forced adoption especially as it seems to me that continued spread only increases room for error and it is more likely that such errors have heavier consequences.
So at this point things haven't changed much. I am still left scratching my head wondering exactly why systemd spread so far so fast, especially on Desktop/SOHO systems. I do see that some features like cgroups have advantages on servers such as regular system-wide upgrades as opposed to incrementals and massive yet speedy deployments. It is interesting that CentOS admins are resisting the move. I was already poised to watch their responses and will continue since that seems where "the rubber meets the road".
Parallelization is only as effective as the trunks of dependency trees and branches ability to be launched correctly before the services that depend on them. Even, by effective comparison with my Runit work, parallelization works, but unless things are handled appropriately, the tree of services will collapse each and every time until you get it right.
To me, I often find it to be overly complicated to the init approach to have parallelization when serialized startup allows for much greater simplicity by either using numbered symlinks (sysvinit) or ordered in script (bsdinit). It's the old case of no fuss, no mess.
I see the benefits of things like service supervision being able to keep services going and monitor them effectively, but parallelization is a mixed bag. You can parallel start some things in sysvinit using inittab and instance based startup, but even then, you're still working off some serialization. You could even use runit/s6 with reformulated init scripts to start service run files in a preset order using standard sysvinit/bsdinit structuring.
However, to me, the over complexity makes parallelization less inviting. Faster is nice, but if slower works better, I'd rather have the slower foolproof method.
Repeated restarts of processes leads to "flapping": This extends to Upstart and other process supervisors, but it isn't well documented on how to tell systemd to give up after one attempt to restart. Flapping can fill logs with useless data, cause alerts across the board etc.
I will just address this one, regarding the documentation of systemd behavior.
This is from the man page of systemd.service, which describes the options commonly used in .service files:
Code:
Restart=
Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. The service process may be the main service process, but it may also be one of the processes specified
with ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=. When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted. Timeouts
include missing the watchdog "keep-alive ping" deadline and a service start, reload, and stop operation timeouts.
Takes one of no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted. If set to on-success, it will be restarted only when the service
process exits cleanly. In this context, a clean exit means an exit code of 0, or one of the signals SIGHUP, SIGINT, SIGTERM or SIGPIPE, and additionally, exit statuses and signals specified in SuccessExitStatus=. If set to
on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementiond four signals), when an operation (such as
service reload) times out, and when the configured watchdog timeout is triggered. If set to on-abnormal, the service will be restarted when the process is terminated by a signal (including on core dump, excluding the
aforementioned four signals), when an operation times out, or when the watchdog timeout is triggered. If set to on-abort, the service will be restarted only if the service process exits due to an uncaught signal not
specified as a clean exit status. If set to on-watchdog, the service will be restarted only if the watchdog timeout for the service expires. If set to always, the service will be restarted regardless of whether it exited
cleanly or not, got terminated abnormally by a signal, or hit a timeout.
Table 1. Exit causes and the effect of the Restart= settings on them
┌──────────────────────────┬────┬────────┬────────────┬────────────┬─────────────┬──────────┬─────────────┐
│Restart settings/Exit │ no │ always │ on-success │ on-failure │ on-abnormal │ on-abort │ on-watchdog │
│causes │ │ │ │ │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Clean exit code or signal │ │ X │ X │ │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Unclean exit code │ │ X │ │ X │ │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Unclean signal │ │ X │ │ X │ X │ X │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Timeout │ │ X │ │ X │ X │ │ │
├──────────────────────────┼────┼────────┼────────────┼────────────┼─────────────┼──────────┼─────────────┤
│Watchdog │ │ X │ │ X │ X │ │ X │
└──────────────────────────┴────┴────────┴────────────┴────────────┴─────────────┴──────────┴─────────────┘
As exceptions to the setting above the service will not be restarted if the exit code or signal is specified in RestartPreventExitStatus= (see below). Also, the services will always be restarted if the exit code or signal
is specified in RestartForceExitStatus= (see below).
Setting this to on-failure is the recommended choice for long-running services, in order to increase reliability by attempting automatic recovery from errors. For services that shall be able to terminate on their own
choice (and avoid immediate restarting), on-abnormal is an alternative choice.
Seems pretty extensive to me, what are you missing from this?
Using the service supervision schematic, the problem with using the supervision method regardless of system, is the fact bringing down services cleanly isn't as cut and dry as sysv is. Whereas you have all in one function scripts with start, stop, restart, and status functions, with supervised services usually these require a stop mechanism such as a finish or some type of termination script in terms of daemontools, runit, and s6 to execute when the kill signal is given by the service supervisor, but not all services stop from these. Some have to be stopped from tools like pkill, killall5, and such or else the system will generate an error during shutdown stating the root filesystem could not be dismounted cleanly due to a process still in execution. Because the service supervisor often is blind to the process itself, if the service can not be cleanly stopped problems can occur. This has been a problem on just about every init system.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
