Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Open Source Operating Systems Software BSD Linux

Fork of Systemd Leads To Lightweight Uselessd 469

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.
This discussion has been archived. No new comments can be posted.

Fork of Systemd Leads To Lightweight Uselessd

Comments Filter:
  • kill -1 (Score:5, Insightful)

    by Spazmania ( 174582 ) on Sunday September 21, 2014 @10:39AM (#47958707) Homepage

    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.

    • by fisted ( 2295862 )
      Like that wasn't trivial to achieve already with the existing tools.
      • Re:kill -1 (Score:4, Insightful)

        by Spazmania ( 174582 ) on Sunday September 21, 2014 @11:05AM (#47958803) Homepage

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

        • How do you do it with systemd?
          • by thogard ( 43403 )

            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

        • Re:kill -1 (Score:5, Interesting)

          by arth1 ( 260657 ) on Sunday September 21, 2014 @12:54PM (#47959335) Homepage Journal

          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: (Score:3, Informative)

            by Anonymous Coward

            Then you will be delighted to learn that, according to uselessd website [darknedgy.net], 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 (Score:4, Interesting)

          by hairyfeet ( 841228 ) <bassbeast1968 @ g m a i l . com> on Sunday September 21, 2014 @02:18PM (#47959801) Journal
          Systemd...its the Metro of Linux!
    • Re:kill -1 (Score:4, Interesting)

      by frooddude ( 148993 ) on Sunday September 21, 2014 @11:30AM (#47958935)

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

      • Re:kill -1 (Score:4, Interesting)

        by Barsteward ( 969998 ) on Sunday September 21, 2014 @11:40AM (#47958985)
        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... [0pointer.de]
        • Re:kill -1 (Score:5, Interesting)

          by Anonymous Coward on Sunday September 21, 2014 @02:09PM (#47959761)

          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.

          • 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

        • Re:kill -1 (Score:4, Informative)

          by CaptnZilog ( 33073 ) on Sunday September 21, 2014 @11:57PM (#47962197)

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

      • by gwolf ( 26339 )

        I do not use kill -1, although its function is easy to understand — But sending a signal to a group of processes instead is quite useful. That's what kill -$PID achieves (instead of kill $PID — I agree the interface is not the most intuitive, but is well known and understood).

        • 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 sho

      • Re:kill -1 (Score:5, Informative)

        by fnj ( 64210 ) on Sunday September 21, 2014 @04:12PM (#47960461)

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

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

      What do you do that makes you need kill -1 regularly? I think I've only used it a handful of times in 30 years, and not at all in the last decade or so.

      • by drolli ( 522659 )

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

        • 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 (Score:5, Informative)

            by unrtst ( 777550 ) on Sunday September 21, 2014 @12:59PM (#47959357)

            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.

  • by Skarjak ( 3492305 ) on Sunday September 21, 2014 @10:39AM (#47958709)
    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.
    • by Anonymous Coward on Sunday September 21, 2014 @10:43AM (#47958723)

      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.

      • by DeHackEd ( 159723 ) on Sunday September 21, 2014 @11:00AM (#47958783) Homepage

        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.

        • by Anrego ( 830717 ) * on Sunday September 21, 2014 @11:31AM (#47958943)

          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.

        • by chihowa ( 366380 ) * on Sunday September 21, 2014 @12:09PM (#47959095)

          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.

          • by phantomfive ( 622387 ) on Sunday September 21, 2014 @12:18PM (#47959131) Journal

            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.

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

          • by sjames ( 1099 )

            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.

  • Over the past 3 decades, versions of the inittab syntax allowed for things in the 2nd and 3rd fields to say things could be run in the background or depend on other named states which is why the 1st field is a name.

    It is amazing how many properly run systems can cope with a "kill -1 -1" to reset everything without a reboot.

    • "It is amazing how many properly run systems can cope with a "kill -1 -1" to reset everything without a reboot."

      out of interest, just how many properly run systems need "kill -1 -1" and how often?
  • by devphaeton ( 695736 ) on Sunday September 21, 2014 @10:55AM (#47958773)

    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.

  • Should we take this seriously? The name is "use-less-daemon." Thoughts?
    • by fisted ( 2295862 )
      Ehm. Yes?
    • by fidelleon ( 3533731 ) on Sunday September 21, 2014 @11:38AM (#47958973)
      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/ [cpusa.org]).
      • Great, he has a political agenda well. So he basically things GNU is just a bunch of hippies. Why is he in Free Software/Open Source?
    • When I saw the headline I honestly did think that this project was someone creating a mockery of systemd, called "useless-d", which was built to take systemd's ideals to some kind of absurd extreme.

      Now that I know useless-d is a real software project I'm inclined to give it even less attention. If the developers cannot be bothered to take their own software seriously, why should I? There is a space for tongue-in-cheek names, cute names, and all the rest, but this one is just plain bad.

      • To me, it seems more like Google's BoringSSL. It's an unflattering name intended to brutally strike a philosophy of small, simple code. Use of self-deprecating humor doesn't imply that they aren't serious about the code itself.
  • by caseih ( 160668 ) on Sunday September 21, 2014 @11:08AM (#47958825)

    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.

    • by dskoll ( 99328 ) on Sunday September 21, 2014 @11:41AM (#47958995) Homepage

      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.

      • "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... [freedesktop.org]

        or am i missing something
  • What a fitting name! (Score:2, Informative)

    by t_hunger ( 449259 )

    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

    • Re: (Score:3, Interesting)

      by efitton ( 144228 )
      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.
    • 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.
  • by iggymanz ( 596061 ) on Sunday September 21, 2014 @12:14PM (#47959121)

    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.

    • a great load of well thought out and articulated reasons not to use "systemd" there... i'm sure it'll sway everyone to your point of view
      • 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.

    • by visualight ( 468005 ) on Sunday September 21, 2014 @02:56PM (#47960001) Homepage

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

  • I have no idea why Redhat made so many changes in their most recent release, but it is so vast that it may as well be a completely new distro. To name a FEW:

    Anaconda RHEL installer completely redesigned
    Legacy GRUB boot loader replaced by GRUB2
    Procedure for bypassing root password prompt at boot completely different
    SysV init system and all related tools replaced by systemd
    ext4 replaced by xfs as default filesystem type
    Directories /bin, /sbin, /liband /lib64are

    • OK, so you have to learn Systemd. But what is it that you can't do anymore? If you want ext4 then use ext4. If you want MySQL then use MySQL. If you want the old network interface names then use them, it's just a kernel parameter you pass with grub. And everything is now in /usr? Big deal. If you want GNOME 2 then sorry, things changes; we don't have GNOME 1 anymore either. Things change. New features come, old features go. That's how it is. Learn to live with it!

      • by kolbe ( 320366 )

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

  • launchd (Score:3, Insightful)

    by smash ( 1351 ) on Sunday September 21, 2014 @01:01PM (#47959375) Homepage Journal
    ... seems to work adequately for the 70+ million OS X installs out there.
  • 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.
  • by dshadowwolf ( 1132457 ) <dshadowwolf AT gmail DOT com> on Monday September 22, 2014 @06:07PM (#47969155)

    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!

She sells cshs by the cshore.

Working...