Fork of Systemd Leads To Lightweight Uselessd

An anonymous reader writes A boycott of systemd and other backlash around systemd's feature-creep has led to the creation of Uselessd, a new init daemon. Uselessd is a fork of systemd 208 that strips away functionality considered irrelevant to an init system like the systemd journal and udev. Uselessd also adds in functionality not accepted in upstream systemd like support for alternative C libraries (namely uClibc and musl) and it's even being ported to BSD.

Comments

kill -1

[Spazmania]

If it still doesn't adequately support the "kill -1" functionality of initd (which kills and resets all processes init manages, especially the getty processes on the terminals), I still don't want it.

Re:kill -1

[Spazmania]

Yes, it was trivial to achieve. With sysvinit. Lots of stuff is trivial with sysvinit and overly complicated with systemd.

Re:kill -1

[frooddude]

Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.

Re:kill -1

[Barsteward]

I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis? There seems to be so much whining about "systemd", you just can't work out how much is complete FUD and whats a genuine gripe. Most of the gripes seems to be neutered by the Myths page http://0pointer.de/blog/projec...

Re:kill -1

[swillden]

Yes, but in the times when i needed it, it was really helpful.

Meh. It's just a slightly-faster reboot that's only usable when you don't need to change the kernel.

Re:kill -1

[Barsteward]

How do you do it with systemd?

Re:kill -1

[arth1]

Which is why I don't see a systemd fork as a viable alternative. The whole idea is broken, as it breaks with the Unix toolbox approach, where tools work independently, and not as a clusterfuck of apps that engage in social networking under the dictatorship of an object-oriented leviathan.

I have turned down Red Hat EL 7 for my business systems, and install RHEL 6 with vaious 3rd party repos to get new packages, precisely because of systemd.
A leaner fork of systemd just won't do it.
Give me an init that only does init and does it well with a KISS philosophy. And give me hal back - systemd-udev cannot do what it does, which makes RHEL 7 unusable. I don't want a 90% system, when the 10% is used by my business to earn money.

Re:kill -1

[unrtst]

Meh. It's just a slightly-faster reboot that's only usable when you don't need to change the kernel.

If you rephrase that slightly, it makes a very different case:
It's just a slightly-faster reboot that's especially useful when you must ensure the kernel doesn't change (ex. unknown illo/grub state).

There are a handful of other times it's useful. My personal favorite is as a self destruct (secure delete almost all files and free space, then issue kill -1), though there are much better ways of doing that.

Re:kill -1

[Anonymous Coward]

Then you will be delighted to learn that, according to uselessd website, they dropped udev and systemd-udev and any dependency to it. They also dropped logind, journald (i.e. no idiotic binary logs), all of the fuckingd retardedd crapd.

Besides, they give clues (if not full explanation) about which existing third party programs you can use to achieve everything that systemd tried to replace.

In other words, they keep only what you asked for: the init part.

Re:kill -1

[arth1]

The compatibility is a main reason. Being able to run and configure all startup/shutdown processes independently of the overseer is nice. As a sysadmin, I get to do easy manual corrections, additions and deletions without giving init a thought.
i don't have to use the "service" command, and I spend far less time when seting up a new server or adding a service.

i don't give a crap whether the system boots twice as fast - reboots are years between, and in scheduled windows. I want something that lets me admin my systems without relying on anything more than a dumb terminal - and if need be, not even that.

Re:kill -1

[Anonymous Coward]

you just can't work out how much is complete FUD and whats a genuine gripe

Once upon a time I used to carefully go over all aspects of my system, and compile custom kernels, fine-tune startup, etc. I haven't bothered in the last decade or so when things work out of the box and I want to concentrate on what I am using the computer for instead of polishing the backend. That said, I've been following some of the systemd news, and responses to it seem to be a real mess and a huge amount of complaints that end up just being strawmen (probably not intentionally). There are legit idealogical complaints I can appreciate, but the vast majority of specific, detailed complaints I come across I later find out are just false. Too many complaints saying "It can't use X" or "It forces you to use Y", when it turns out there is a simple option to change to use X or not use Y... or in many cases where it flat out doesn't do Y or already uses X by default. It makes it rather difficult to take complaints seriously, talking about the "*nix way," when I thought RTFM used to be part of the *nix way.

Re:kill -1

[hairyfeet]

Systemd...its the Metro of Linux!

Re:kill -1

[squiggleslash]

Must admit that's news to me. Kinda fed up of the subtle changes to shell commands we've seen over the last few years especially as this one conflicts with the kill -{SIGNAL} syntax we're used to.

Either way, this sounds like a non-issue. (1) if we're routinely trying to determine how to kill EVERY CORE PROCESS ON THE SYSTEM then we have bigger fish to fry than whether init/systemd is capable of working with that.

(2) It sound scriptable to me, assuming systemd itself isn't capable of doing it. /proc should give you all the information you need.

I worry that this is the kind of concern holding back adoption of systemd. Good reasons I understand. Bad ones, that seek to blame systemd for major system problems that exist under init too, are bad.

Re:kill -1

[fnj]

reboots are years between

Really? You don't reboot after a kernel security update? I entirely agree that boot time is a non-issue, but your statement sounds either like hyperbole/exaggeration-for-effect, or you're not serious about security.

I want something that lets me admin my systems without relying on anything more than a dumb terminal

I entirely agree with this, and coming from not-a-fan of systemd, systemd can be administered with ssh just as effectively and probably as easily as sysvinit or bsdinit can be. What is necessary is some additional learning/training, as with any such change.

In sysvinit, the /etc/rc.d directories are full of symlinks to /etc/init.d scripts, with "magic" prefixes to control priority. In systemd, etc/systemd/user and /etc/systemd/system are full of symlinks to ... wait for it ... scripts in /usr/lib/systemd/user and /usr/lib/systemd/system. And the systemd scripts are simpler. In sysvinit, every single script reinvents the wheel by including a big bunch of the same boilerplate.

Like I said, I'm not a partisan fan of systemd, but (I hope that) any criticisms I have are based on reasonable grounds, not misconceptions.

Re:kill -1

[Barsteward]

"But then, they aren't you; so they are just stupid, right?" - unfortunately there seem to be a load of self-important old school admins who know it all who hate change and disparage other peoples efforts by making dubious "complaints"

Re:kill -1

[fnj]

Then consider yourself the recipient of valuable information. Signal #1 is SIGHUP ("hangup"). The naming is strictly historical at this point. It is probably easier to remember "kill -HUP <some-daemon's-pid>". Either way you issue it, the command restarts the daemon, or reloads the daemon's config. The precise behavior depends on the coding of the paricular daemon. There is no guarantee except what the man page for the daemon says. SIGHUP used on most non-daemon programs just terminates them. That is the default if a process is not coded to intercept and handle SIGHUP.

You're entirely right that you could go for an entire career without once using kill -1. Issuing "service <daemon> restart" strikes most people as much more natural. That will send the signal for you. Incidentally, it's high time somebody wrote "service" for systemd. A simple shell script will do it for some definition of "do it".

Re:kill -1

[macs4all]

"But then, they aren't you; so they are just stupid, right?" - unfortunately there seem to be a load of self-important old school admins who know it all who hate change and disparage other peoples efforts by making dubious "complaints"

Exactly.

OS X switched over to "launchd" (which is essentially "systemd") way back in 10.4 (Tiger) Days. I'm sure there was a bunch of whining within the Apple Developer Community from people who were crossover Linux and OS X Devs; but now, about 5 years on, it doesn't seem to have brought death and destruction to OS X. In fact, I recently played around with an SSD-equipped MacBook Air running OS X 10.9 (Mavericks), and it booted from a Cold Start in less than 10 seconds (and actually faster than a Restart!). Yes, the SSD is a part of that; but I gotta believe that launchd helps, too.

It's amazing to me how tech-savvy people can be such luddites; but there it is...

Re:kill -1

[fnj]

Heh. If you don't know the difference between "kill -1 1" and "kill -9 1", I don't want you ever touching the kill command on my systems.

Hint: one of them terminates init. The other restarts it. A highly consequential distinction.

As for "kill -9 -1", I had to look that one up. It is actually defined, though it looks like nonsense. What that one will do is kill every process in the system EXCEPT init.

Re:kill -1

[Smallpond]

Is OS X open? no. Is it put together in many different ways from parts from many different developers? no. Do we care whether it becomes a tightly integrated ball of proprietary software? no. So do you understand the issue? no.

Re:kill -1

[arth1]

unfortunately there seem to be a load of self-important old school admins who know it all who hate change and disparage other peoples efforts by making dubious "complaints"

The first ones making complaints are the users, if you kill their processes in a reboot. Even if it is was announced weeks in advance, with follow-ups.
The sane thing to do is to make sure you don't have to reboot. Not going the systemd route helps with that.

Re:kill -1

[thogard]

You can't do this with systemd. A kill to a process group is an atomic operation in Posix so that if you do a kill -9 -1 (i.e. send a SIGKILL to init and all of its children), the kernel will not return from the "kill" syscall until it has sent the signal to all of the processes. That syscall will also prevent any other task switches until it is done so the result is no process (other than init) ever runs again even if they are in the middle of a forkbomb. A kill -1 -1 (send SIGHUP to everything via init's process group) has traditionally told all user level programs that the user logged out and all daemons that they should reload their config files.

Killing a process group (the negative process id, which is what the original commentator was talking about, not a SIGHUP) is used all the time on systems. That is how apachectl (and most other forking deamons and their control programs) tell its children to reload the config file or end in a controlled way. It is used every time a user logs out to make sure all their processes do go away. Signals are the oldest and more reliable of the IPC mechanisms and are great when the number of messages you need to send is a tiny number of options.

Re:kill -1

[arth1]

On my PC with an Asus mainboard the Sleep and Hibernate simply don't work (and never worked with multiple distros and kernels). I need to reboot each day therefore boot time is important for *me*.

Then the solution seems to fix sleep and hibernate, not to break servers.

Re:kill -1

[KagatoLNX]

To be fair, I know what "kill -1" is for and I've never used it on purpose. Of course, that's because "kill -1" comes from the school of "fixing" the symptoms of the problem without understanding what's actually causing it.

Re:kill -1

[mysidia]

Really? You don't reboot after a kernel security update?

One word: KernelCare

Re:kill -1

[epyT-R]

Or, there's just more people using ad hominem attacks, appeals to emotion, and other fallacies as arguments, instead of rationality. Unfortunately, this disease is society-wide and getting worse.

Take a hint. Calling someone a 'hater' doesn't make an argument for or against anything. It is the ultimate dubious complaint.

Re:kill -1

[bjwest]

Hit the button, grab coffee, work.

More like hit the button, go to get coffee and get new mail notification before I get two steps away. My system gets put to sleep, not powered down at night, and it's up and ready for me within five seconds. The only time I reboot is for a kernel update.

Current uptime on my desktop: 23 days 4 minutes and 42 seconds.

Re:kill -1

[davydagger]

I don't think there will *never* be the "Year of The Linux Desktop", but it won't be in the next 5 years.

GNU/Linux on the desktop is a novelty for nerds, tinkerers, and techies.

GNU/Linux on the server is the bread and butter of the internet itself. Most people who actually use and rely on linux for work, and their life do so without actually knowing it, or dirrectly interacting with the operating system.(ever use google search, you've used gnu/linux).

people who do, in fact install and maintain linux on computers, tend to be running servers, and need a stable platform, more than anything else.

All the people with loads of cash, and manhours of talented developer time, to spend on GNU/Linux and dirrectly related projects are spending their resources on making GNU/Linux servers(and even embedded), better, and more reliable.

a GNU/Linux desktop will happen when a company like Red Hat, google, intel, nVidia, or one of the other many other large corporations gets their dick stepped on for the last time, by microsoft, and they decide to hit them where it hurts, the desktop.

And its going to be a slow, painful, uphill battle full of headaches and tears. No, it *will* happen eventually, but its not on anyone's timeline.

Oh, and I'm sick of bellyaching about systemd. Its a great system, it runs well, reliable as fuck, and most of the compaints are fear mongering. People hate it because its new(GNU even, dum dum tiss), and doesn't conform to the mantra of an OS written over 40 years ago for a system with 64KB of memory.

Re:kill -1

[CaptnZilog]

I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis?

Um, you "use" kill -1 *every* time you use "crontab -e", you also "use" it (the SIGHUP signal) for a lot of other things probably, like forcing apache httpd to re-read it's config file, or any number of other similar things where you can make an app/daemon re-read it's config. And if you drop your connection to your login shell without logging out first, it gets a SIGHUP as well.

It has nothing to do with linux/unix being 'unreliable'.

Re:kill -1

[AmiMoJo]

I think that's two words. At least one and a half.

Re:kill -1

[martin-boundary]

That's exactly what I want to use my computers for, too. But frankly, systemd and its devilspawn cousin pulseaudio just get in the way. But I'm not going to talk about that since others already do this well. What riles me most these days is X forwarding failures. I have a headless computer I want to do computations on and edit text documents in Emacs/LaTeX. For stupid reasons I shan't get into, I want to do this on a chromebook (I said it was stupid!).

So what, you say, just use an ssh client to log on and voila. Well, the state of ssh + terminal emulation on chromebooks (and android too!) is abysmal. They don't pass all keyboard combinations correctly, they all have issues or fail to implement everything correctly, and worst of all, there's no X forwarding to a decent X server. All I want to fracking do is type "plot" on the server and see a picture on my screen. Or type $\int f$ and see a typeset symbol. Without going through a third party "cloud" server which runs through a browser, takes ages to return data, tries to force me to use braindead keyboard combinations on their cloud "editor/IDE" wet dream which doesn't even handle the simplest regexes and knows a grand total of 2.5 syntactic highlighting modes. And without running a slow as molasses rdp/vnc style remote desktop, or screen switching constantly to a crippled Linux workstation installed on the hard drive.

Now, what has any of this to do with you? Fair question. The answer is that the sophisticated computing system we've had for 20 years is being eroded by imbeciles who think that anything old must be replaced, that new replacement software only needs to implement the tiny subset of features that the programmer actually understands, and under no circumstances can anything which said programmer is ignorant of, or fails to adequately appreciate, be important. And that's where the new stuff like chromeos, android, systemd, pulseaudio, etc is going. And people like you try to convince us that in fact this is great and as it should be, since you're tired of tweaking your systems and have given up control for peace of mind. Well it's ok to give up if you want. I'd rather you didn't attack the complainers though, because they haven't given up yet. They're the ones who just *might* do something, unlike you by your own choice. And they're the ones who, in complaining, share the old knowledge to everyone before the imbeciles wipe it all off the earth.

Finally someone decides to do something

[Skarjak]

That's how the free open source community works. If you don't like something, it's pointless to just spend a lot of time bitching about it (like many linux users have done about systemd). Just go out and make your own version. Everyone who's been complaining about systemd better contribute to this thing.

Re:Finally someone decides to do something

[Anonymous Coward]

Actually, that's a bad idea. They should go an support another init project that's already underway, like OpenRC. This is just protest software by a single guy.

Re:Finally someone decides to do something

[DeHackEd]

Ordinarily I would agree, but systemd's "MCP-like" behaviour (TRON reference, I honestly believe that's a valid simile) means that uselessd has a chance of being a replacement for systemd packages of existing distributions. If I can put this in place of systemd on centos7 and have it boot in an unprivileged container (currnetly impossible with stock) then that's a win in my book.

You can't just switch systemd for openrc in an existing distribution without some major resistance. Believe me, I wish it could or I would just install openrc or upstart. That's the problem - systemd is claiming distributions and the list of alternatives is unnervingly small.

Re: Finally someone decides to do something

[BarbaraHudson]

I think the name is probably going to help, not hurt.

It's in the long-standing tradition of weird/funny/pun names in *nix. Less is more, unix is kinda like multics, but with the gonads cut off", etc.

As long as nobody starts calling it "GNU/Useless" ... The whole "GNU/Linux" thing is so '90s, and it's just linux to the world.

Re:Finally someone decides to do something

[Anrego]

Not just that, but running a non-systemd system even if you use a distro that uses openrc by default is becoming more of a pain as more and more packages hook into it. As a Gentoo user who is trying to hold off for just a little while longer I've found myself doing a lot of package shuffling and using the package blacklist for the first time in the almost decade I've been a gentoo user.

Re:Finally someone decides to do something

[chihowa]

I agree and am happy to see this fork. As unpopular as it may make me, I actually like the initd functionality of systemd. I'm fine with using and writing the old init scripts, but systemd unit files are simple, concise, and powerful enough for my needs.

On the other hand, I find the kitchen-sink feature creep of systemd absolutely repulsive. Cramming all of that functionality into PID 1 as a unwieldy monolith seems like such a deeply flawed exercise. Uselessd seems like a perfect replacement for systemd: all of the benefits and none/less of the cruft.

Re:Finally someone decides to do something

[phantomfive]

I agree and am happy to see this fork. As unpopular as it may make me, I actually like the initd functionality of systemd. I'm fine with using and writing the old init scripts, but systemd unit files are simple, concise, and powerful enough for my needs.

This is understandable, but there are much, much simpler ways of achieving this goal than systemD.

One of the interesting things about systemD discussions. If you watch, people who criticize say things like, "that's an ugly hot mess of architecture!" People who support it answer by saying, "the features are so good!" You can see those two things are somewhat arguing past each other.

You captured both sides of the argument in a single post, so good job.

Re:Finally someone decides to do something

[stoploss]

You have my upmod if I had points.

This is exactly my perspective. Init has been in need of these features (like allowing true inter-daemon dependencies and not shoehorning everything into one runlevel or another).

But, yes, I'm not looking for an MCP—just an improvement on init. I wonder if this project will get any traction.

Re:Finally someone decides to do something

[visualight]

That pat answer again? Apples and Oranges...

Get this into your head: The fucking kernel is the fucking kernel alright? It is one fucking thing. Yes, people refer to it as a "monolithic kernel" to contrast with a "microkernel" but , it is one fucking thing. Got it? Next time someone complains about the monolithic design of systemd and you feel the words "but the kernel..." welling up in your throat, just slap yourself until you start to remember words like "context" ok?

Re:Finally someone decides to do something

[sjames]

That's more or less my feeling on it. Perhaps an early fork will afford the opportunity to assert a proper design on the thing and salvage a win. Some of the individual features of systemd are good in themselves and I believe most of the cons can be fixed with a proper design.

Why not support a current project instead?

[devphaeton]

All the contenders that didn't 'make the cut*' for the likes of Debian and recent converts to SystemD, namely Upstart and OpenRC... Why reinvent the wheel when the work is already half done?

Either way, I wish the project well. Though the name "Use Less D" or "Useless D" could have been better.

*I still don't see how SystemD is more ready for primetime than anything else (or sheesh, even sysvinit) but we've discussed that here already.

Re:uClibc removal hardly makes sense

[luca]

Ok, so the ARM is about to be poised to take over lots of systems (cell phones, etc), and you rip out (to save space) a portable embedded tiny clibrary?

In fact the article says that uselessd adds support for compiling it under musl and uClibc

Not a boycott but a confirmation

[caseih]

Phoronix take on this is hilarious. A "boycott of systemd" led to the development of uselessd? Rather it looks to me like the uselessd developers saw that systemd had some very good ideas, and they wanted to have that, minus some parts they didn't like, on systems that aren't glibc, and aren't linux. This is part evolution, part competition. Either way it enhances Lenardts' position all along, that traditional script-based system v init is horribly broken. For even uselessd now supports socket activation (systemd's main feature) and process supervision, the latter being sorely lacking from sys v init for many years.

In any event, this is all great news. If anything it paves the way to support modern operating system features on non-linux systems, and non-gnu systems. Part of what's required to finally port modern GUI systems like Gnome 3 to other platforms.

Re:Not a boycott but a confirmation

[dskoll]

systemd does have some very good ideas when it comes to the init system. Socket-based activation and process supervision are Very Good Things.

But when the systemd developers started trying to embrace, extend and extinguish other things like syslog, core dumps, etc. then systemd jumped the shark.

Re:Not a boycott but a confirmation

[Barsteward]

"But when the systemd developers started trying to embrace, extend and extinguish other things like syslog, core dumps, etc." - how are they doing that? you still get all those with systemd - http://www.freedesktop.org/sof...

or am i missing something

Re:Not a boycott but a confirmation

[Endymion]

That's the whole point of all of this mess: {,k}dbus

Neither an init system nor vertical integration are the goal. The one consistent thing in all of the "systemd mess" is to leave the actual implementation officially a moving target where the trditional .so based library APIs are either hidden and undocumented or they are left out entirely. This forces you to use an IPC mechanism (dbus/kdbus) instead of simply linking to the functions you need and calling them directly. Forcing data to be serialized/unserialized so it can be sent over IPC is not nearly as efficient as calling a dynamically loaded local function. The systemd people love fast thing ("boot time!", etc), so why would they require this slow IPC everywhere?

*** if you never need to link to a library to use it, you can "link" to and distribute GPL code without being bound by the GPL. Poettering's cabal and systemd is an attempt to enable a new form of "tivoization" ***

If you are technically only "using" a library (no linking, no modifications to the library), you have not "infected" your proprietary code with the GPL. It's slower, but computers got fast enough that it doesn't really matter.

The nasty part is that by forcing arbitrary incompatable interface with systemd, to run stuff like GNOME you have to provide the key dbus features even if you don't use systemd. The end-run around the GPL still works with uselessd or any other "systemd replacement".

Unfortunatley, Lennart's cabal has everybody discussing technical features so this obvious goal isn't even addressed.

Re:Not a boycott but a confirmation

[Sri Ramkrishna]

The problem with your analysis is that we're talking about system level code which is all GPL'd. You might be right if we were talking about applications that were linking to some libraries and using dbus or kdbus that way. But that's not what is going on here. There is no end run around the license since the pieces that systemd is connecting to are all GPL'd. Even GNOME which is part of the GNU project is also using licenses that are consistent with its mission.

I don't understand what you mean by 'arbitrary incompatible interface' in regards to GNOME. There is nothing incompatible, it's just a interface to logind that GNOME needs.

You realize that you can probably use the same argument to things to such base things as 'rpc' right? Which we use all the time for NIS and NFS.

Re:Not a boycott but a confirmation

[Anonymous Coward]

Binary logs. If they were simply testing to see if it's a bad idea then I could give them a pass. But it's already been proven to be a bad idea via the massive heap of poo called Windows.

It's like standing on train tracks to see if it's dangerous. Others have settled that issue already.

Re:Not a boycott but a confirmation

[Endymion]

The traditional RPC tools don't force a chane in API for local requests - they link against the same traditional .so file that any local app would use. That is very different from forcing dbus to be the only exposed API even for local use. Apache may provide features over sockets, but apxs(1) still exists and apr.h still exposes a traditional API.

I'm not a lawyer either, but this is obviously unexplored territory for the GPL (which doesn't have a lot of court precedent regardless of the current issue.

It's not like we'll ever find some smoking gun proof. This is simply the best theory I've heard.

Re:Not a boycott but a confirmation

[Barsteward]

You should do more, some even, investigation.

"20. Myth: systemd makes it impossible to run syslog.
Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service."

Re:Not a boycott but a confirmation

[Endymion]

That's exactly my point. I'm suggesting the goal is to avoid making a derivative work. The GPL describes various ways to recognise a project as having "derived" from covered code, and linking copyleft and proprietary code together is one of them. (with some variation depending on if we are talking GPL or LGPL).

Remember that one of Poettering's goals is, in his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".

The point is if I want to do (for example) some sort of user authentication, I may have to link against libpam.so. This is something that would be reasonably commoon in embedded systems, and linking covered code into your embedded device (and having to distribute libpam.so with your product) could easily be a derivative work. (details matter, ask your lawyer about specific projecs).

Once absorbed into Poettering's project, you avoid all that risk because you don't interface with the system features directly and instead use "local RPC". This changes the project from being a potentially infringing derivative work into something that merely uses the tool. Merely using a tool that is licenced under the GPL is explicitly excempted, as the GPL only coveres redistribution and not use. ("GPL is not an EULA") This is a major change in legal status for your typical embedded device, which often wants a minimal OS to host their embedded app. They would also really like to avoid having to deal with the handling anything GPL. Changing to "local RPC" for all system interaction neatly fixes that problem.

We don't run across this pattern with traditional RPL tools, because it's bad for performance to needlessly serialize everything when you could simply call a function directly.

Re:udev

[caseih]

FUD again. The udev module of systemd does not run under PID=1! Please take a look at how systemd is organized before you post something like this.

$ ps axf | grep systemd | grep -v grep
    1 ? Ss 0:47 /usr/lib/systemd/systemd --system --deserialize 16
  247 ? Ss 2:48 /usr/lib/systemd/systemd-journald
  603 ? Ss 2:20 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
19211 ? Ss 0:00 /usr/lib/systemd/systemd-udevd
19260 ? Ss 0:18 /usr/lib/systemd/systemd-logind

systemd encompasses many things that used to be separate, but that doesn't mean they all run in the same process. Functionality is still kept modular, and you can update systemd without requiring a reboot most of the time. systemctl --daemon-reexec will reload the updated modules.

I'm not a fan of *ctl commands (hard to type, they don't roll off the fingers), but they are okay.

Re:With a name like "use-less-d"

[fidelleon]

I thought it would be serious until I visited uselessd' site (http://uselessd.darknedgy.net) and saw such gem: "This has meant eradicating plenty of GNUisms" and GNUisms being a link to... USA's Communist Party (no, seriously: http://www.cpusa.org/).

Re:Err...

[Barsteward]

go and read this first http://0pointer.de/blog/projec..., there is a section on monolithic design

What a fitting name!

[t_hunger]

This project is indeed useless:-)

First it implements the PID1 part of systemd, cutting out things like hostname, date and time management and logind. So this does *not* ship the things that are needed to run Gnome (or soon any other desktop environment). So you need systemd anyway... or a systemd shim or systembsd or whatever to provide the functionality that is missing.

It removes journald... and with it really nice features like systemctl status whatever showing the last bit of output from that unit. That is a huge step back, especially since much of the journald code still needs to stick around: It is the "internal" logging interface used in systemd. It just feeds it on to syslog now instead of writing it to disk, something you could do with one line of configuration.

Removal of udev? You need that functionality, so again you will need to install "real" systemd or some other piece of code replacing that. Again you could just reconfigure the "real" systemd to use any alternative implementation in place of its own.

Then it advertises that it is portable. The developer apparently spend time to make this run on FreeBSD, which is nice, but has anybody in that came ever asked for that? AFAIK they are working on something like Apples launchd. Any other of the BSDs that want systemd? Not that I am aware of.

Then it is portable to other compilers but gcc. Systemd uses gcc extensions that make for more robust code (e.g. destructors for variables). Ripping that out will just lead to more bugs, especially in the error-paths. Not sure that is worth the trouble.

Finally it is portable to other libcs. That is actually somewhat nice... even though glibc is the dominant libc implementation on linux systems (that are not android:-).

Then it removes some really convenient functionality like the timer units. Do we really want to go back to the cryptic crontab syntax? If the job there is somewhat complex it will most likely start a systemd unit anyway (for the security features, resource management, the way better logging or just the better job control). PID1-systemd needs to know the time anyway, and it needs to start jobs, so why not have it start jobs based on the current time? That is definitely less code -- and probably better tested, too -- than running an extra daemon for that rather trivial job.

It also removes the support for the security frameworks... "to stick to a more clearly defined purpose, one that is agnostic of such elements". Wow, that is just plain stupid. If you want to use these frameworks, then you want to have them in use *everywhere*. That is the whole purpose of those frameworks.

Re:What a fitting name!

[efitton]

Most users could care less about running GNOME. We will see if Cinnamon, Mate and KDE make SystemD a hard requirement.

I know I do not have enough knowledge to critique SystemD, SysV or UselessD. That said, I want text logging to disk with no configuration. If I need to learn new commands to read the logs, I'm just not going to do it. At most I will have one Linux box running at home. Pushing 40 with a kid and another on the way configuring my computer has become a hassle and a headache that I don't need. Was there a time when I compiled kernels for fun? Yup, but that ship said over a decade ago. The few times I've needed the logs it is simple just to less or vi and just read the thing. Hopefully Mint will default to giving me my text files. I'm actually about to install Linux again after a multiyear break related entirely to desktop unusability.

Re:What a fitting name!

[Sri Ramkrishna]

If BSD is working on something to replace, where will these people who love init so move to? I suppose the whole "portable" thing is completely blown out of the water.

Re:What a fitting name!

[t_hunger]

Yes, some of the gcc extensions in the kernel are getting removed. On the other hand the clang compiler is getting extended to handle more gcc extensions. It already does quite a few.

Once clang builds the kernel it will most likely also build systemd:-)

Re:Err...

[ThePhilips]

Yes. No. Wait - yes. No... no. Uh....

The systemd has modular design.

But monolithic architecture.

Literally everything inside systemd is intertwined using the D-Bus.

So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.

The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.

On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.

at least the rationale is good

[iggymanz]

Regardless of the particulars of this project, it's good people are waking up and realizing what a bloated feature-creeped rube goldberg contraption systemd is, a non-Unix non-Unix-way solution no serious Linux/Unix admin wants, it hinders troubleshooting and configuration. Systemd is what happens when inexperienced people with high IQ fly off on a tagent without engineering ability.

Re:at least the rationale is good

[iggymanz]

Serious admins already have that point of view, no reason to sway. Kids who experiment and only worry about their desktop or hobby system might have another.

Re:at least the rationale is good

[visualight]

"Systemd is what happens when inexperienced people with high IQ fly off on a tagent without engineering ability."

Exactly. There is no doubt that he's a very smart person who can code, but his ideas suck. Dependencies, political pressure, and inexperienced young windows refugees are why we are where we are now...

Hear, hear.

[gwolf]

The reason why XFCE was mentioned as a possible default desktop in Debian is the install media size — In order to ship a self-contained distribution that can give you a functional desktop in one CD, GNOME is no longer an option.

But yes, there are several active discussions on how to better achieve this. It's not that Debian has decided XFCE suits us better than GNOME.

(said with a Debian Developer hat on — No, I'm not a desktop guy, nor work in the debian-installer, but do follow the discussions)

Re:launchd

[Sri Ramkrishna]

systemd is designed to use specific features of the linux kernel. That's why kernel developers as a group aren't up and arms about it. Sure you might get some occasional people like Ted Tso upset, but in general systemd exposes kernel features that a lot of people have worked hard on. Things like cgroups are using copiously in systemd.

launchd

[smash]

... seems to work adequately for the 70+ million OS X installs out there.

Re:Err...

[Anonymous Coward]

Yet I love XFCE4 and although I run Gentoo as a software developer who needs to freeze various C/C++ libraries in certain versions without crippling my systems update capability, I actually love XCFE4 for it's simplicity and ability to be modified.

I'd rather run XFCE4 and add a bunch of various extra toolbar plugins for a lot of eye candy. Because XFCE4 is lighter weight I don't feel bad having cpu graphs, temp sensors, mem/net/disk indicators, weather, etc all flashing away because it's still less load average than sitting idle on a Gnome3 desktop which oddly needs 6 mouse clicks to get anything to happen.

Gentoo + XFCE4 + OpenRC is how things have been for me and how things will remain.

I have many GCC/GDB versions installed, valgrind, a specific /etc/portage/package.mask which freezes various libraries I code against, yet I can still update my system and stop any changes I do not like. Since the distro is source based it works around these changes unlike a binary distribution where someone else hardcodes their C++ libs into your packages and crosses their fingers you haven't mucked with it.

I clearly used to think Gentoo was a joke in the server world purely due to it's update cycle but honestly I don't think RedHat or anyone else for that matter is really doing it better. I'm starting to think Gentoo with a manual portage overlay on a bunch of servers is what I will switch to next. CentOS isn't cutting it these days and systemd isn't coming to my servers. Not as long as my $$$$ are behind that risk.

Re:Err...

[ThePhilips]

But the kernel is monolithic, [...]

Wrong. Linux kernel has modular architecture, but monolithic design. The precise opposite of the systemd.

I know that the uninitiated see the kernel as a big black box. But actually Linux very well structured and highly hierarchical.

systemd can monitor dæmons (only if they use the systemd watchdog facilities) and automatically restart them if they stop talking.

The question here is about the case when systemd itself "stops talking".

Some time ago that would have been theoretical question, but actually there were already such bugs in systemd where it was simply stuck because the daemons which compromise it couldn't understand with each other. This is precisely the consequence of monolithic architecture in combination with modular design: the singular logic is spread across many "modules" (the *-systemd binaries) and when the modules do not agree with each other, things go south pretty quickly.

Re:Boycotting RHEL7's uselessd

[kolbe]

> What can't I do anymore?

Let me see, the top 3 I cannot do anymore include:
- More than half of my companies preferred vendor applications will not run on systemd (some of which will never support it)
- Majority of in-house scripts need to be rewritten
- Kickstart now REQUIRED since they removed "Full Custom Install"

The growing list of complaints are raising flags in my company so much so that we are looking at outright dumping Redhat and we have been a dedicated Redhat Enterprise customer since 1997. RHEL7 has ZERO TCO for everyone I've spoken with... Retraining, retooling, reconfiguring and reorganizing are absurd.

Re:Boycotting RHEL7's uselessd

[kolbe]

>>So, what alternative are you looking at?

Our vendors who have explicitly stated they will not support systemd in any way (due to +Priv, DoS and bypass issues/concerns) have stated that they recommend either staying with RHEL6 & Oracle Linux 6 until it is no longer supported or switching to AIX or FreeBSD. Two of these vendors are financial software suites, one is a Point of Sale system and the other is a CRM Suite that "may support it in the future". What the other vendors plan on recommending is still TBD for them. Simply put though, many companies are more invested in their applications than any flavor of *NIX.

>>I don't know about how you write scripts, but I find it amazing that a majority of them has to be rewritten.

Have you not seen the number of changes in management, monitoring & configuration commands made within RHEL7? Seriously, it borders on being a completely new distro the way everything has been retooled. Many of our SysAdmin scripts are written in Perl & Bash with remote get for everything from deployment to monitoring and analysis (netstat? gone. ifconfig? redirected. iptables? gone. lsof? switches changed. chkconfig? redirected. So many more...).

Re:Err...

[phantomfive]

That particular blog has been fairly well deconstructed in this thread.
In short, just because the author calls something a myth, doesn't mean it's actually a myth.

Re:Err...

[Barsteward]

it does trump most of the shit pumped out repeatedly - please explain what's irrelevant about his responses to the myths.

More FUD

[antientropic]

This is just more anti-systemd FUD very light on actual facts.

First you assert that it's somehow a bad thing that systemd uses a standard, established IPC mechanism (D-Bus). Would it have been better if it had invented its own?

Then you claim that a crash of one systemd daemon "might" cause deadlocks/hangs/crashes, but you don't give any example. What daemons are intertwined in such a way that a failure of one would bring down the system? As far as I know, you can kill any systemd daemon (other than PID 1, obviously), and systemd will notice and restart it. Daemons like systemd-journald even use systemd's watchdog mechanism to ensure that they get restarted in case of a hang. In other words, systemd provides a much stronger basis for a reliable system than SysV init.

Fun fact: I just did a "kill -9 -1" to kill every process in a NixOS VM except PID 1. Systemd restarted every system service perfectly. Try that on SysV init.

Re:Err...

[Barsteward]

You missed out some relevant bits in your redaction which illustrates the problem, detractor just cherry pick and take out of context the bits they want to fit their pre-conception. So i think he did a good enough job in his blog post to dispel the myths. Most of that so called deconstruction you linked to is full of personal attacks on him and full of things that are still wrong

Myth: systemd is difficult. This also is entire non-sense..."A systemd platform is actually much simpler than traditional Linuxes" ....systemd certainly comes with a learning curve.

Myth: systemd is a freedesktop.org project. yes, we host our stuff at [freedesktop.org] - "Well, systemd is certainly hosted at fdo, but freedesktop.org is little else but a repository for code and documentation".

Myth: systemd is not UNIX. There's certainly some truth in that. "systemd's sources do not contain a single line of code originating from original UNIX. However, we derive inspiration from UNIX, and thus there's a ton of UNIX in systemd."

Myth: systemd is complex. There's certainly some truth in that. "However, systemd is certainly not more complex than prior implementations of the same components".

Myth: systemd is a feature creep. Well, systemd certainly covers more ground that it used to......"but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want".

Re:Err...

[phantomfive]

I mean, just to go a little deeper, look at this example:

Myth: systemd is complex......rebuttal: systemd is certainly not more complex than prior implementations of the same components".

Do you see how that's not actually a rebuttal? All he's said is, "it's not complex." But the criticisms are that it is more complex. He hasn't said anything to address the criticisms, except that he disagrees with them!

Does it really surprise you that he disagrees? I hope not.

Re:launchd

[iggymanz]

we actually have a mac server, launchd doesn't always launch the 3fd party stuff (like nagios client for example) for whatever reason. I'd take init for it any day of the week

Re:launchd

[Endymion]

I'm not talking about *init systems* - systemd was never "just an init system". Remember, it's absorbed stuff like network management and system authentication. That kind of feature often requries linking to (L)GPL code, and you can trigger the GPL's requirements depending on how you do that.

So Poettering wants to move all those function calls to (k)dbus. In his own words, "... the primary interfacing between the executed desktop apps and the rest of the system is via IPC (which is why we work on kdbus and teach it all kinds of sand-boxing features)".

systemd fails at reliability and fault-tolerance

[octogen]

My main problem with systemd is the lack of robustness in its design and implementation. It seems like an attempt at reimplementing Solaris' SMF, but poorly. Even the SMF itself could probably be called 'overengineered', however, it is certainly a more sophisticated, less monolithic design that provides a much higher level of fault-tolerance.

systemd is basically a huge pile of modules compiled into the PID 1 init process. The problem with that is, that if PID 1 dies, the system stops (e.g., kernel panic). On Solaris, a small basic init process starts the SMF master restarter (svc.startd), which is responsible for starting, stopping or restarting the other components of the SMF as well as all services managed by the SMF. If a component of the SMF fails (maybe it just dies/SEGVs, or say, you kill it, cause it hangs), the master restarter will respawn it. Even if the master restarter goes south, that small basic init process will respawn the entire SMF, and you're still up and running.

Then, let's take a look at the implementation of systemd:
static int socket_spawn(Socket *s, ExecCommand *c, pid_t *_pid) {
_cleanup_free_ char **argv = NULL;
...snip...
r = socket_arm_timer(s);
if (r < 0)
goto fail;

...snip... (function call with lots of undocumented arguments, returning r)
if (r < 0)
goto fail;

r = unit_watch_pid(UNIT(s), pid);
if (r < 0)
/* FIXME: we need to do something here */
goto fail;

*_pid = pid;
return 0;

fail: s->timer_event_source = sd_event_source_unref(s->timer_event_source);
return r;
}

Actual code from systemd-216; see full source at src/core/socket.c

Most of the systemd source code looks like this.
Virtually no comments; lots of single-letter variable names, confusingly similar names like "_pid" and "pid"; throwing 'int' return codes back up five calls, where the original caller cannot even remember what all the possible return codes might be (how about enum?); lots of arbitrary goto- and return-jumps out of the middle of somewhere; lots of break and continue, even mixed in the same loop; even substantial amounts of three-star-programming (never heard of it? google it, it's funny); etc.

Okay, I have to add, that the code of lots of the "good, old, reliable UNIX codebase" does not look a lot better (and upstart, or even the Linux kernel, are guilty of at least some of the same bad coding habits). But we have paid the price for writing code that way numerous times, and it seems we did not learn from history.

Coding like that is probably okay if you're writing a nice, little command line utility. But if systemd wants to be THE new init system, it had better look like it had been written by the inventor of reliability engineering.

Right now, the systemd source looks like it violates virtually all of the best practices for writing reliable code. Take a look at what those people who know their craft recommend - e.g., the Federal Aviation Association, European Space Agency, Lockheed Martin's avionics section, etc. - and compare that to systemd's source.

It's like a disaster waiting to happen.

Quite the opposite.

[Medievalist]

Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis?

Quite the opposite!

Kill -1 tells a service daemon that is handling hundreds of thousands of simultaneous connections that it needs to re-read its configuration file, without interrupting service even momentarily.

Kiddie stuff doesn't need kill -1. It's only the ultra-reliable stuff in mission-critical roles that needs it.

Suppose you, personally, have a piece of software that controls your artificial heart. Your doctor has discovered that there's a security vulnerability in the silicon, but luckily it can be remediated with a change to the software configuration, so that you don't have to get your chest cracked to fix it. He uploads the new configuration and kill -1's the running software, and it picks up the changes between one beat and the next, never causing you to, you know, die.

OK, maybe that was an unnecessarily dramatic example. A more mundane one would be adding a new web site - you enter the new A, AAA, SPF and MX records, put the new config in the httpd.conf and access.conf files, then you kill -1 the DNS and httpd servers, and none of your other customers have to have their web sites shut down while the new one is being brought up. This happens ten thousand times a day at web service providers all over the world.

A perspective

[dshadowwolf]

It does not matter what Apple does - there is tight controls on the system and code contributed to Darwin might never see life as part of the actual Mac OSX released by Apple.

The init process in Unix and Linux is a very special thing - if it ever crashes, so does the whole machine. It is the first process started by the Kernel after it finishes initializing the system and mounting the root filesystem and is the "parent" of any process that deliberately orphans it's child-processes before exiting itself. It is also in charge of "reaping" any zombie processes. With each addition to its duties the area for an error to happen increases, which increases the risk that the system will just suddenly crash.

This is a problem that people lambasted Microsoft for from the birth of Windows through it's transition to a 32 bit system and still continues to this day for an extent - that they had one piece of the system doing a lot of work and having a wide surface for errors but still critical for everything to work properly. I am loathe to praise Microsoft for anything, but I must praise them for this - they have been moving away from that and I have actually found Windows 7 to be pleasantly stable - to the point of actually being able to recover from the graphics drivers crashing and managing to recover and re-load and re-initialize the system without losing any data. They have turned things around and begun to compartmentalize things to an extremely high degree - lowering the amount of code in each component, raising the ability of their programmers to actively find and fix the bugs during development and lowering the chance that a user will actually hit one of those bugs.

That compartmentalization and modularity (of the userspace, at least) was a hallmark of the design of Unix - each piece did exactly one job and did it well - as well as being as small as possible to reduce the amount of space there was for an error to be in. Yet with this "systemd" we see Lennart Poettering leading the charge to turn that around in order to save some small fraction of time during the boot process. That he created "Pulse Audio" - which appears to have flopped severely and, at least for me, was the cause of a lot of problems (not just for me - I remember finding thousands of people finding that problems were being solved when they got rid of Pulse Audio when I first started having those problems) - seems to be lost on people.

No, one mistake does not make everything someone does wrong, but in this case sacrificing simplicity and modularity so you can "do the boot process faster" is a wonderful idea. Extending the system that does that so it subsumes some of those processes it used to start in parallel for a faster boot time is just idiocy. What's next? Am I going to find that I can send a "draw an ASCII art of a kitchen sink" command to systemd and have it take over the current TTY to do just that?

If systemd was just a system for organizing the boot process, adding some complexity to simplify much more and making sure that daemons providing services get run in parallel to boot the systems boot time... Well, I'd have absolutely no objection to it. Instead it has subsumed separate projects and forced people to fork them or recreate them if they do not want to use systemd. Further, it appears that people that don't like systemd but like Gnome will soon lose the option to run new versions of Gnome because several key components of Gnome now have a hard dependency for systemd or one of it's sub-projects. Open Source is supposed to be about choice and by forcing people to use something that they might not want to that choice is being taken away.

So, with all the sarcasm I can muster, all those systemd supporters out there and it's creator have my hearty applause for doing something that goes against one of the key tenets of the Open Source movement. Bravo! You've successfully taken away something from people that you claim to be supporting. What a show of hypocracy!