Fork of Systemd Leads To Lightweight Uselessd

kill -1 by Spazmania · 2014-09-21 02:39 · Score: 5, Insightful

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.

--
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.

Re:kill -1 by Spazmania · 2014-09-21 03:05 · Score: 3, Insightful

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

--
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Re:kill -1 by frooddude · 2014-09-21 03:30 · Score: 3, Interesting

Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.
Re:kill -1 by Barsteward · 2014-09-21 03:40 · Score: 3, Interesting

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...

--
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Re:kill -1 by arth1 · 2014-09-21 04:54 · Score: 4, Interesting

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 by unrtst · 2014-09-21 04:59 · Score: 4, Informative

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 by Anonymous Coward · 2014-09-21 05:33 · Score: 3, Informative

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 by arth1 · 2014-09-21 05:57 · Score: 5, Insightful

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 by Anonymous Coward · 2014-09-21 06:09 · Score: 5, Interesting

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 by hairyfeet · 2014-09-21 06:18 · Score: 3, Interesting

Systemd...its the Metro of Linux!

--
ACs don't waste your time replying, your posts are never seen by me.
Re:kill -1 by fnj · 2014-09-21 07:55 · Score: 4, Insightful

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 by fnj · 2014-09-21 08:12 · Score: 4, Informative

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 by macs4all · 2014-09-21 08:17 · Score: 3, Interesting

"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 by Smallpond · 2014-09-21 09:56 · Score: 4, Informative

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 by arth1 · 2014-09-21 11:28 · Score: 3, Insightful

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 by CaptnZilog · 2014-09-21 15:57 · Score: 3, Informative

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'.

Finally someone decides to do something by Skarjak · 2014-09-21 02:39 · Score: 5, Insightful

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 by Anonymous Coward · 2014-09-21 02:43 · Score: 5, Insightful

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 by DeHackEd · 2014-09-21 03:00 · Score: 5, Interesting

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 by Anrego · 2014-09-21 03:31 · Score: 5, Interesting

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 by chihowa · 2014-09-21 04:09 · Score: 5, Interesting

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.

--
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
Re:Finally someone decides to do something by phantomfive · 2014-09-21 04:18 · Score: 4, Insightful

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.

--
"First they came for the slanderers and i said nothing."

Re:uClibc removal hardly makes sense by luca · 2014-09-21 03:05 · Score: 4, Informative

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 by caseih · 2014-09-21 03:08 · Score: 3, Interesting

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 by dskoll · 2014-09-21 03:41 · Score: 5, Insightful

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 by Endymion · 2014-09-21 05:15 · Score: 4, Interesting

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.

--
Ce n'est pas une signature automatique.
Re:Not a boycott but a confirmation by Barsteward · 2014-09-21 07:36 · Score: 3, Informative

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."

--
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)

Re:udev by caseih · 2014-09-21 03:23 · Score: 5, Informative

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" by fidelleon · 2014-09-21 03:38 · Score: 5, Interesting

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... by ThePhilips · 2014-09-21 04:02 · Score: 5, Interesting

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.

--
All hope abandon ye who enter here.

at least the rationale is good by iggymanz · 2014-09-21 04:14 · Score: 3, Insightful

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 by visualight · 2014-09-21 06:56 · Score: 4, Insightful

"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...

--
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.

Re:launchd by Sri+Ramkrishna · 2014-09-21 04:33 · Score: 4, Interesting

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.

Re:Err... by ThePhilips · 2014-09-21 05:15 · Score: 3, Interesting

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.

--
All hope abandon ye who enter here.

Re:Err... by phantomfive · 2014-09-21 06:04 · Score: 4, Informative

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.

--
"First they came for the slanderers and i said nothing."

Re:Err... by Barsteward · 2014-09-21 07:28 · Score: 3, Interesting

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

--
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)

More FUD by antientropic · 2014-09-21 08:48 · Score: 4, Interesting

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:launchd by iggymanz · 2014-09-21 10:05 · Score: 3, Informative

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 by Endymion · 2014-09-21 11:13 · Score: 3, Interesting

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)".

--
Ce n'est pas une signature automatique.

Slashdot Mirror

Fork of Systemd Leads To Lightweight Uselessd

39 of 469 comments (clear)