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

 


Forgot your password?
Close
typodupeerror
×
Linux

Ask Slashdot: Feature Requests For Epoch Init System 1.3.0? 119

Posted by timothy from the kitchen-sink-with-dispose-all dept.
New submitter Ben Dibell writes: My name is Subsentient. I maintain the Epoch Init System, a single-threaded init system for Linux designed to be easy to configure and customize, as well as staying out of your way.
Epoch uses a numeric priority system to determine the boot order of objects, supports a wide range of customizability, and doesn't require much anything except libc and /bin/sh (though /bin/sh can be omitted, not recommended). Epoch also features advanced service status reporting features and has service supervision.

I'm just here to ask the Slashdot community what they'd like to see in the next release, 1.3.0 "Fluoxetine", before I wrap it up.

There are generally 2 things I can't consider:
* Parallel service startup, because that can be done manually, and implementing it would make Epoch too complex IMHO.
* Switching away from the numeric priority system to "true" dependencies. I implemented the priority system because I liked the freedom it gives the end user.

Despite these omissions, your feedback matters to me. I want to make something everyone will want to use.

-Subsentient
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Feature Requests For Epoch Init System 1.3.0? More

Ask Slashdot: Feature Requests For Epoch Init System 1.3.0?

Comments Filter:

  • systemd compatibility (Score:5, Funny)

    by Anonymous Coward on Saturday June 13, 2015 @05:12PM (#49905447)
    You need to support the standard service file format to be relevant.
    • I actually wish I had mod points right now...

    • Re: (Score:2)

      by drolli ( 522659 )

      No, i think it should have an interpreter translating the Systemd file formats to XML. The first thing started should be a Java web service which accepts these XML files, compiles them to JavaScript and send them to the build-in browser.....

    • Maybe he could integrate the code into systemd? Then it would use the standard service file format.

  • Sounds like the method Solaris used.

  • ... shouldn't be too difficult? Well, as long as you stay away from dependencies, and just limit concurrency to services with the same priority... What is it you worry about?

  • Dependencies (Score:5, Insightful)

    by afgam28 ( 48611 ) on Saturday June 13, 2015 @05:58PM (#49905643)

    Why do you think a numeric priority system gives "freedom" to the end user? To me, having to manually mess around with numbers is an annoyance, and it means that the init system is getting in the way.

    Having numbers means that some dependency info gets lost. If you have an S10 and S20 script, is there any dependency between them, or were they just arbitrarily numbered? It's impossible to tell unless you go and read through the script and figure out for yourself. This makes it hard to debug when things go wrong. You also just end up with a bunch of scripts that all start with S99 or K99.

    The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output. "Runlevels" were implemented with dummy scripts (i.e. scripts that just had dependency information in them, and didn't perform any actions).

    Other than that, it's as simple as the traditional sysvinit, but without meaningless numbers everywhere. You can read more about it here: http://www.mewburn.net/luke/pa... [mewburn.net]

    It's 2015, we should be naming things not numbering them.

    • The number system allows for priorities to have the same number, so you can group things in this way. Also, the DefinePriority attribute allows you to name priorities.
      • Sounds like you don't know what a topological sort is. Look it up. True, it's designed for a single processor, but the parallel approach is essentially the same: if you have a thread free, take the first thing in the list whose deps are all satisfied. It'll finish faster than a priority system, it's more robust, and much easier to configure.

        • Re: (Score:3)

          by thogard ( 43403 )

          The real tick is to manage things in a sane way when the system isn't working properly.

          Take the case of a system living in a rack far away. When it boots it needs to 1) bring up part of the network, 2) bring up sshd as soon as possible and 3) bring up user/vm/container disks. Once the disks are verified to be sane enough to continue, it might want to bring up the rest of the networking and it might want to bring up an sshd with a different config. Of course if the disks are screwed up, the best thing mig

          • Re: (Score:3)

            by jedidiah ( 1196 )

            This right here would be my big complaint about the "better alternatives" to init. For anything but the most trivial desktop use case, they fuck up the boot sequence. Sometimes it's just glitchy behavior where things get started up out of order but they do start. Other times the box will just get stuck during startup because of some bogus error.

            Manual tinkering is far more risky. The better-than-init options make it far to easy to render your system completely unbootable.

          • Re: (Score:2)

            by fisted ( 2295862 )

            So what is a sane init system to do in case of a broken disk? Pretend everything's good and mount its filesystems r/w so that we might get away with starting sshd anyway?
            A broken disk is a broken disk. Dropping into a single-user console makes sense because "broken disk" comes in too many machine-indistinguishable flavours for a program to meaningfully take care of and the consequences of "just trying something" could be severe.

            If you need this kind of robustness, use a RAID.

        • Topological sort is one way to do it. Another way is to use out-of-place ordering by starting from the outmost nodes and continue to the roots. Topological sort gives the same end result but worse parallelism.

          • Sure, better technology exists than topological sort ! Thanks for pointing out a better approach. OP's point, and mine, is that a few minutes of thought can be used to replace a horrible, unmaintainable cludge a graceful, robust approach. In fine Unix tradition, epoch wants to keep ritual animal sacrifice as a neccessary part of system administration. Good for the goat industry, bad for your coldroom floor.

    • If I was writing a script that depended on some service being started or some other condition before it could start, I would check for that condition within my script. I would not expect some external framework to figure out what my script requires and to coordinate its startup.

      • Thank you. It amazes me that after reams of random posts about all things init-ish here and in other discussions very few people point this out when discussing dependencies.

        A proper dependency check for service A within service B's start up can can also be shoe horned straight into something like Nagios for handling A if it goes sideways.

      • Comment removed based on user account deletion

        • So your service will randomly fail to start, depending upon whether the local system's "init" just happened to start the services yours depends upon before your's?

          That... doesn't seem like a good idea to me. While I'd certainly ensure my scripts handle the non-startup of dependencies gracefully, I'd definitely want a sane init system to actually know what to start up, and in what order.

          Uh, no, the whole point is that the service checks for the dependency, and if it's met, then all good, and if it's not met, it requests the dependency to be started.

          • Uh, no, the whole point is that the service checks for the dependency, and if it's met, then all good, and if it's not met, it requests the dependency to be started.

            That's insane. Possibly the worst possible way to do an init system I've ever heard of.

          • Re: (Score:3)

            by tlhIngan ( 30335 )

            Uh, no, the whole point is that the service checks for the dependency, and if it's met, then all good, and if it's not met, it requests the dependency to be started.

            And let's say something horrendous happened that the service fails to start, but takes absolutely forever to do so.

            SysVInit, this init, are single thread init systems. They can't block because they'd block the startup. Your dependent service starting the service continues to block startup. And let's say it only takes a second when it succeeds, b

      • Re: (Score:2)

        by fisted ( 2295862 )

        You should try and read the link in the comment you replied to

    • Re: (Score:2)

      by fisted ( 2295862 )

      The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output.

      Came here to say this.

      • Re: (Score:2)

        by Art3x ( 973401 )

        The NetBSD init system (which was introduced way back in 2001, and I think ended up being adopted by the other BSDs) has a simple way of solving this. There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script (it's tsort, essentially) and determines the order to run each script. If you wanted to debug something, you could run this yourself and check the output.

        Came here to say this.

        Ditto.

        SysVInit's numbering always struck me as a little hacky. But it's so simple it works. Plus everybody's used to it. When systemd appeared, I looked into FreeBSD and read about its init system [freebsd.org]. It's a total face-palm that so many years have gone by without Linux adopting something like BSD's way --- or just taking it. It's an even bigger face-palm that instead Linux adopted systemd.

        • Some init systems used on linux supported the LSB init script headers which do a similar thing. Some of them also supported parallel start-up (start all services whose dependencies are satisfied).

          For example, Mandrake/Mandriva/Mageia used prcsys from around 2004 to 2013 (when Mageia switched to systemd).

          But, there are a lot of advantages to systemd and most complaints about it are FUD that have been debunked.

          • Except for the many, many complaints about systemd that are not FUD, such as the overwhelming need by systemd developers to integrate non-init fucntions into the systemd suite such as logging, DHCP, and mounting attached media, the casual reworking of the file-system-hierarchy by ignoring all standards for "/run" and "/media", and insane inconsistencies of "using a symlink for /etc/resolv.conf into the DHCP substructure, except not resetting the symlink if the user puts a flat text file in /etc/resolv.conf

    • > To me, having to manually mess around with numbers is an annoyance, and it means that the init system is getting in the way.

      Just build a script to optimize the boot sequence. I'll leave my laptop or PC to reboot over the weekend as it sorts out dependencies and boot time.

      Boot everything sequentially. Measure exactly how much memory/CPU/time each app takes.

      Testing that is something computers are good at. Boring and repetitive.

      Give it a 'quit' criteria of 'any optimizations less than .5s, you can stop'.

      S

    • Re: (Score:2)

      by jedidiah ( 1196 )

      In other words, the absolute worst case of the priority system is the base case of the "more sophisticated" alternatives.

    • There's a tool called rcorder that parses REQUIRE and PROVIDE lines in each startup script

      Problem is that UNIX services doesn't actually tell you when they're ready to "provide", the init system is based on the notion of having told something to start, not actually having it available.

      So, until you address that any prioritization is going to be a kludge at best. It's no use telling a system that something requires something else, until you can actually guarantee that that something else is actually available.

      Fun fact, systemd doesn't address this either. Well, there are some kluges in the form o

      • Problem is that UNIX services doesn't actually tell you when they're ready to "provide", the init system is based on the notion of having told something to start, not actually having it available.

        [...]

        Fun fact, systemd doesn't address this either. Well, there are some kluges in the form of initd like behaviour, but by and large its still the old "spawn off a process and cross your fingers"-approach to service provisioning and dependency resolution. Only a lot more complicated for not much improvement.

        sd_notify.

        At least the systemd people know there is a problem, sysvinit has been burying their heads in the sand for how many years about this?

        (The discussion about this on the Devuan mailing list was funny -- people desperately trying to find some way of avoiding saying good things about systemd).

        • sd_notify.

          No, that doesn't really count, as it's outside the scope of the current start-up management. It's not something that could be done with start-up management alone today.

          Now of course, if we're allowed to fix the infrastructure, with hindsight there's a lot of things we could/should/would have done differently. But the world being what it is, that's unfortunately often not an option. I mean, Unix isn't that great, we could do a lot better today if we were allowed to start over. But again unfortunately we're n

          • sd_notify.

            No, that doesn't really count, as it's outside the scope of the current start-up management. It's not something that could be done with start-up management alone today.

            Now of course, if we're allowed to fix the infrastructure, with hindsight there's a lot of things we could/should/would have done differently.

            But that's what systemd is about. You can criticise the way they do it, but they are at least trying to fix these problems, rather than denying they exist or throwing up their hands and saying "you can't get there from here".

            (By the way, in what way is sd_notify "outside the scope of current start-up management"? systemd is "current start-up management" for lots of us).

            • With current start-up management I meant "as it's defined by history and hence the system we've got to work with". Systemd is, as you say, trying to change that, and hence, have to change everything around it to suit. (And that's not popular, to put it mildly. :-) ) So they're going outside the current scope as what they're trying to achieve can't effectively be addressed within it. If it could be, and they hadn't try to expand the scope, there wouldn't be nearly as much wailing and gnashing of teeth, don't

              • With current start-up management I meant "as it's defined by history and hence the system we've got to work with".

                Ah, by "current" you mean "historical". :-)

                Luckily for us software isn't carved in stone.

  • I'm perfectly happy with OpenRC over here (I'm a Gentoo user, mostly). It has parallel startup, a fairly straightforward configuration, it's possible to run multiple instances of a daemon, and it works with Linux and BSD systems.

    And most importantly, I can still run my own cron, syslog, and date systems.

    How is Epoch different?

    What problem is this solving, and how is Epoch uniquely solving those problems?

    • Epoch for one, doesn't require another init system like sysv to run on top of. It's also got fantastic service supervision, which OpenRC does not have. And it's easy to set up too.

    • Re: (Score:1, Informative)

      by Anonymous Coward

      > How is Epoch different?

      If it doesn't swallow higher priority syslog messages, stderr, and give a zero (not an error) exit statuses for services that fail to start, then it is simply better than systemd. Correctly doing those things would give it an advantage over systemd. systemd has some very nice features, but hiding syslog messages and stderr makes it very hard, or nearly impossible, to troubleshoot startup problems. Doing those things right would give it a competitive advantage.

      • Re: (Score:1)

        by Anonymous Coward

        swallow...stderr

        In my opinion, that part of systemd is what proves most that the angry children that make systemd, and ignore bug reports, is the best proof that Poettering just doesn't get it. He does not understand UNIX. stderr output should never be ignored, much less deleted. I'm the author of an analytics daemon that monitors connections to Elasticsearch. I lost a lot of customers, because while my init script outputs clear error messages to stderr, they couldn't tell why my daemon failed to start since systemd do

        • Comment removed (Score:4, Interesting)

          by account_deleted ( 4530225 ) on Saturday June 13, 2015 @11:22PM (#49906881)
          Comment removed based on user account deletion

          • Re: (Score:2, Insightful)

            by Eunuchswear ( 210685 )

            He does not understand UNIX. stderr output should never be ignored, much less deleted

            Here [redhat.com] is a link to a bug report dealing with the stdout / stderr problem. If you read through it, you will find that the systemd folks are very responsive, and fully agree that the bug existed and quickly had a fix.

            Amazing, a bug report that almost matches their paranoid fantasies.

            High points:

            1. stderr was lost because it was written to the terminal, just like it would have been with sysvinit -- someone had overriden the systemd default of logging to syslog.

            2. someone else found another case where errors were being lost due to a misconfiguration of selinux, an all-pervasive system written by the NSA, something the paranoid anti-systemd trolls never seem to worry about, even when they try to claim systemd is a NSA plot

      • Moderators on drugs? (Score:1)

        by Anonymous Coward

        Why was this marked a troll? These are very serious design flaws with systemd. Of course rather than fixing the problems, Poettering instead has his minions make personal attacks. I think it would take less effort to just fix the problems rather than constantly attacking those that point them out.

      • Re: (Score:1)

        by Anonymous Coward

        Interesting to see the systemd fanbois mark this as a troll rather than addressing the problems. As Linus correctly pointed out, they ignore bug reports. systemd is a disaster and is hurting Linux. Throwing away stderr, certainly syslog messages, and the exit status are all serious problem. This is just further proof that they are burying their heads in the sand rather than addressing the many issues they have.

      • Looks like a systemd fanboi has mod points (Score:1)

        by Anonymous Coward

        Why was someone that points out a bug in systemd attacked this way. It's sad to see, as Linus pointed out, people that point out bugs in systemd are attacked. Wouldn't it just take less effort to fix the bugs? I know systemd has made my life a living hell trying to manage a few hundred Red Hat systems.

  • Ask elsewhere as well. (Score:3)

    by hendrikboom ( 1001110 ) on Saturday June 13, 2015 @07:04PM (#49905985)

    I suggest you ask again on soylent news; there's quite an active technical community thers.

    Also on the devuan mailing list. They might end up being your users.

    -- hendrik

  • 1) Cgroups-based daemon handling. 2) No XML config files, for god's sake! 3) No nested dirs/subdirs in /etc, please... keep config in one single file

  • Does it ignore nonzero exit statuses, syslog... (Score:3, Interesting)

    by Anonymous Coward on Saturday June 13, 2015 @07:43PM (#49906133)

    message, and stderr like systemd? If it doesn't, then it is superior. The systemd guys just don't understand why those things are important.

    • Re: (Score:1)

      by Anonymous Coward

      Good point. The systemd guys just don't grok exit statuses or stderr. I've wasted many hours because systemd returns a zero exit status on a failed service start and even more because it swallows stderr. It doesn't save stderr messages to the journal. The journal, while a great idea, is useless because it doesn't log higher priority syslog messages or stderr. I've had several problems, that should have taken just a few minutes to solve, take most of a day because of systemd. For example, with the Mong

    • No it doesn't. If it returns nonzero, that's pretty much going to show as a failure and will be logged as such.

  • What does it do with stderr? (Score:2, Interesting)

    by Anonymous Coward

    I manage about two dozen sysadmins with around 80k virtual machines, and swallowing stderr is the biggest problem we now face. systemd doesn't log it or show it on the console. Most daemons give pretty good error messages, but systemd hides that from them. That means rather than taking a few minutes to troubleshoot a problem, they now waste hours because the systemd guys just don't understand stderr. If this init system doesn't hide stderr, then I'm very interested in it.

    • Re: (Score:1)

      by Anonymous Coward
      What distro are you using? 'stderr' for a service by default should go to the same place that 'stdout' goes to. http://www.freedesktop.org/sof... [freedesktop.org]

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        by default should go to the same place that 'stdout' goes to

        And, that's the bug. We run Fedora, and IIRC we've been using systemd for four years. stderr is most certainly dropped by systemd. It is not saved in the journal. I have been fighting our developers for years over this issue. They output to stderr and refuse to change. My ops guys can't tell why services fail to start since stderr isn't logged in the journal. I know it isn't since "journalctl -r" doesn't show the error output from our services. If stdout is logged, then systemd should also log, rather than

    • Epoch doesn't touch your stderr. Your apps are free to print to the console. A log of overall service start/failures is in /var/log/system.log

      • Re: (Score:1, Interesting)

        by Eunuchswear ( 210685 )

        You are responding to an insane troll. The incredibly tiny seed for their trollish lunacy is that, when configured incorrectly, services started by systemd can write error messages to the kernel instead of the systemd journal.

  • Suggested improvements (Score:1)

    by Anonymous Coward

    1. Increment your version.h
    2. Ship it. It's excellent. It's minimal. I love it.

    *Hugs*

  • Coreboot [coreboot.org] "is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems.</marketing>

    coreboot (formerly known as LinuxBIOS) is a free software project, aimed at replacing the proprietary BIOS firmware found in most computers with a lightweight system designed to perform only the minimum number of tasks necessary to load and run a modern 32-bit or 64-bit operating system. - https://en.wikipedia.org/wiki/Coreboot [wikipedia.org]

  • Adding this support should be quite easy. Just use similar approach as Puppet or those package dependency systems. Use a DAG (directed acyclic graph). There are ready solutions for manipulating a DAG, including NetworkX. And the DAG specific solution should be quite simple, around 15-20 lines of code (been there, done that). With a DAG you can utilize full CPU potential while still being maintain the correct execution order.

  • Init systems seem to model themselves on Makefiles, reading everything at startup and detecting dependencies on the fly then deriving ordering and parallelism. This should all be invariant stuff, instead model things on ninja, where you calculate a giant wad of info and mechanically grind through it at startup.

    https://martine.github.io/ninj... [github.io]

  • The real tick is to manage things in a sane way when the system isn't working properly. Take the case of a system living in a rack far away. When it boots it needs to 1) bring up part of the network, 2) bring up sshd as soon as possible and 3) bring up user/vm/container disks. Once the disks are verified to be sane enough to continue, it might want to bring up the rest of the networking and it might want to bring up an sshd with a different config. Of course if the disks are screwed up, the best thing migh

Slashdot Top Deals

If you think the system is working, ask someone who's waiting for a prompt.

Close