Ask Slashdot: Feature Requests For Epoch Init System 1.3.0?

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

Comments

systemd compatibility

[Anonymous Coward]

You need to support the standard service file format to be relevant.

Re:systemd compatibility

[ZG-Rules]

I actually wish I had mod points right now...

Re: systemd compatibility

[buchanmilne]

Don't use Type=simple (the default) in a service unit if you don't want the 'simple process intended for use with inetd-style systems' behaviour. See the relevant man page (I think systemd.service) for other options that would be more appropriate for your use case (but I am not sure there is one for "anti-systemd FUD").

Re:systemd compatibility

[drolli]

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

Re:systemd compatibility

[davester666]

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

Solaris

[ArchieBunker]

Sounds like the method Solaris used.

Re:Solaris

[Eunuchswear]

Solaris used sysvinit, then moved to SMF (in some sense one of the ancestors of systemd).

Re:Incorporate other stuff

[thinkingrodent]

I think I'll just add a web browser.

Parallel startup...

[andremerzky400]

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

Re:Parallel startup...

[Eunuchswear]

Actually the lesson from systemd is that dependencies have been screwed since the beginning and only "work" by accident.

What systemd is doing is forcing people to deal with the whole "when is a service started" problem that everyone has been sweeping under the carpet. The same problem was also visible in parallel sysvinit (Debian) and Upstart, but to a lesser extent.

Dependencies

[afgam28]

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

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

Re:Dependencies

[thinkingrodent]

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.

Re:Dependencies

[nuckfuts]

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.

Re:Dependencies

[belthize]

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.

Re:Dependencies

[squiggleslash]

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.

Re:Dependencies

[Garridan]

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:Dependencies

[fisted]

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:Dependencies

[GigaplexNZ]

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.

Re:Dependencies

[Art3x]

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

Re: Dependencies

[buchanmilne]

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.

Re:Dependencies

[0100010001010011]

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

Set up a website to submit results to and you can download the 'boot profile' closest to your use and

Hell let the cloud and VMs autotune it. You could have an EC2 appliance rebooting 24/7 optimizing the boot sequence. [It'd be NP-hard but](https://en.wikipedia.org/wiki/Travelling_salesman_problem) to test to completion but you should be able to get a pretty decent ball park.

Re:Dependencies

[Eunuchswear]

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:Dependencies

[thogard]

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 might be to bring up part of the system or leave parts of it shutdown even if their normal dependancies are all met. Too bad most systems sit at a console prompt waiting for a human to tell them what to do with the broken disk.

Re:Dependencies

[tlhIngan]

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, but 10 minutes when it fails. If it happens before a chance to get to a prompt (e.g., before networking), it could easily take hours for the system to get to a usable state.

A multithreaded startup would let your script attempt to start up (in fact, your script would point out the dependency, while the init system would handle satisfying them), and block on the failing service, while starting up other services so you have an attempt at fixing the problem.

Re: Dependencies

[Antique Geekmeister]

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 and never updating it again"

One of the announced goals of systemd is to "create a stateless Linux", to essentially clear away or prevent any modifications to "/etc" and "/var" and set all local system configuration withing systemd itself. This _breaks_ decades of system configuration work, including every Linux compatible system management tool such as puppit, CFengine, chef, BladeManager, and even installation systems such as Debian'a .dev system, RPM's packaging, and commercial software installation tools. /etc/resolv.conf is merely an example of breaking such tools, but it's a fundamental example of the disdain for non-systemd based system components. It's an example of the chaos being engendered is from such broad goals that have_nothing to do_ with an init system, and that erratically and unpredictably break decades of well-written software that followed the published file system hierarchy standards in favor of underdocumented, non-portable, rapidly evolving and functionally unnecessary switches to a new layout.

Those are only a few of the well documented issues: so overall, there's a lot to like about systemd. But the tendency of its proponents to characterize concerns about it as "FUD" is disingenuous.

Re:Dependencies

[olterman]

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.

Re:Dependencies

[jedidiah]

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

Re:Dependencies

[jedidiah]

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:Dependencies

[fisted]

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.

Re:Dependencies

[fisted]

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

Re: Dependencies

[Bengie]

which is what causes single user fsck requirement.

An FS that needs fsck is broken by design. Use a modern FS. If you need a reliable boot volume, just use ZFS and do a 4 way mirror or something outrageous, two disks on one controller and 2 on another. If that gets corrupted, there is no hope, like a damaged CPU or bad motherboard.

Re:Dependencies

[Garridan]

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.

Re:Dependencies

[lars_stefan_axelsson]

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 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. "Lots of screaming for little wool, said the woman that sheered the pig..." as the Swedish saying would have it.

P.S. Of course, whether you number or name these things doesn't make one bit of difference. But with numbering at least, you're not fooling yourself into thinking that you're getting something you're not.

Re:Dependencies

[Eunuchswear]

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

Re:Dependencies

[lars_stefan_axelsson]

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 not. So sd_notify while being "obvious" also falls far short.

Not that I'm married to SysV startup, it's a bit of a kludge. Likewise I'm not impressed with systemd either, it's arguably worse than the problem it's trying to solve. But again, that's not saying that SysV starup wasn't due for replacement.

Re:Dependencies

[Eunuchswear]

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

Re:Dependencies

[lars_stefan_axelsson]

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 you agree?

Re:Dependencies

[Eunuchswear]

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.

Re:Dependencies

[lars_stefan_axelsson]

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

Yes, if you will. History is after all that which happened just before "now"... :-)

Re:Incorporate other stuff

[JWSmythe]

Make sure it's it's not compatible with any current technology or formats.
Maybe you can write it all in Java. We all love Java running on our servers. Maybe with a non-intuitive touch screen console with no real functionality. You'll make a fortune. :)

Re:Portability with non-commercialised *nixes

[thinkingrodent]

It'll already run on anything with a Linux kernel.

Re:How fast or slow is it?

[thinkingrodent]

For my own system, it boots in around 15 seconds to SliM login manager, which then takes me to XFCE 4.12.

Re:Incorporate other stuff

[PPH]

Don't forget an email client

What problem is this solving?

[diamondmagic]

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?

Re:What problem is this solving?

[thinkingrodent]

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:What problem is this solving?

[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:What problem is this solving?

[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 doesn't log stderr to the journal. Their journal is great in many ways, and I really like it in general, but it fails because of their policy to not log higher priority syslog messages or stderr. That makes it nearly impossible for my customers to troubleshoot start-up problems. I lost many customers because of systemd.

Re:What problem is this solving?

[geoskd]

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

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

I'm sorry that you lost customers relating to systemd, but if they switched to systemd, and the only failures they had were your code, then I have to ask why that is. If they had other failures in the conversion, and still insisted that you were the problem (enough to drop you as a service provider), then I would worry that there was some other agenda going on.

If, on the other hand, you were the one who switched to systemd, and managed to have unstable code make it to a client... Thats a whole other ball game.

Re:What problem is this solving?

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

Re:What problem is this solving?

[Eunuchswear]

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

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

I'm sorry that you lost customers relating to systemd, but if they switched to systemd, and the only failures they had were your code, then I have to ask why that is. If they had other failures in the conversion, and still insisted that you were the problem (enough to drop you as a service provider), then I would worry that there was some other agenda going on.

If, on the other hand, you were the one who switched to systemd, and managed to have unstable code make it to a client... Thats a whole other ball game.

I very much doubt he has any customers.

Ask elsewhere as well.

[hendrikboom]

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

Re:Ask elsewhere as well.

[Eunuchswear]

I would hardly call Devuan a "failure". They're currently in Alpha, and I'm running it on a system now.

I still don't know what devuan are trying to do. Make a version of Debian Jessie that doesn't use systemd? But Jessie can already be run without systemd. Make a system without libsystemd0? Why?

Re:Incorporate other stuff

[LesFerg]

And how about a bluetooth interface to a watch app, so I can monitor the services on my wrist... all the trendy gadgets are getting that nowdays

Well...

[Kormoran]

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

[Anonymous Coward]

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:Does it ignore nonzero exit statuses, syslog...

[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 MongoDB package for Red Hat 7, if it doesn't shutdown gracefully, it leaves behind a /var/lib/mongo/mongod.lock file that keeps MongoDB from restarting. If you attempt to start MongoDB from the command line then you get an obvious error message about the lock file. It takes only a matter of seconds to determine the problem and to fix it. With systemd's policy to ignore exit statuses and stderr, you could be guessing for hours or even days what the problem is. systemd is a disaster made by kids that aren't experienced enough to grok UNIX.

Re:Does it ignore nonzero exit statuses, syslog...

[thinkingrodent]

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

Re:Does it ignore nonzero exit statuses, syslog...

[geoskd]

It doesn't save stderr messages to the journal.

It most certainly does.

There have been several bugs that have cropped up from time to time relating to logging, but they get fixed as soon as they are found. The far more common problem is that by default the logging now goes through journald, and rather than rtfm, people often seem inclined to claim its broken rather than seek out the answers. You can find a good description for how to find the logs here

Re:Does it ignore nonzero exit statuses, syslog...

[thinkingrodent]

I meant the Epoch Init System. It handles exit codes properly. I am the guy who wrote it.

Re:Does it ignore nonzero exit statuses, syslog...

[geoskd]

Systemd doesn’t throw away stdout or stderr. If you have a case where you believe there is a bug, and those streams are being lost, submit the bug report. You might have found a legitimate bug. You might not. A lot of logging changed with Systemd, and some things are less than obvious. This is nothing intrinsic to Systemd, its just different from what you're used to. Drop any newbie into CentOS, and they would have just as much trouble finding the logs...

*BSD

[tepples]

What holds up a port to the kernel of FreeBSD?

Re:*BSD

[thinkingrodent]

/proc mostly. That's how Epoch does process supervision.

Re:*BSD

[fisted]

It might be the fact that the BSDs already have a mature and sound dependency-based init system.

What does it do with stderr?

[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:What does it do with stderr?

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

Re:What does it do with stderr?

[thinkingrodent]

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:What does it do with stderr?

[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 ignore, stderr. It isn't output to the console or to the log. As the chief architect, I am constantly put between my developers and my ops guys that argue about this. It has made my life miserable.

Re:What does it do with stderr?

[Eunuchswear]

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.

Re:What does it do with stderr?

[Eunuchswear]

Duh, typo, terminal, not kernel.

Re:What does it do with stderr?

[Eunuchswear]

Wow, you systemd fanbois are all so rude.

Aw, diddums.

Various(*) anonymous trolls repeatedly lying is not rude?

(* Actually I suspect there is only one troll, he's getting boringly repetitive).

Suggested improvements

[Anonymous Coward]

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

*Hugs*

Moderators on drugs?

[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:Moderators on drugs?

[geoskd]

Poettering instead has his minions make personal attacks

Here is a sample bug report relating to the stderr/stdout problem I see nothing by the way of personal attacks. In fact all I see are genuine interest in a bug, and a quick bug fix being pushed upstream. In fact, the only personal attacks I have seen on anyones part have come from anti-sysetmd people who are clearly not involved in any way in the decision making process, nor the systemd code maintenance process.

Looks like a systemd fanboi has mod points

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

Re:Portability with non-commercialised *nixes

[dweezil-n0xad]

posting to undo a moderation misclick on the above post, sorry

Coreboot. Get to init ASAP.

[0100010001010011]

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

Re:Coreboot. Get to init ASAP.

[evilrip]

That's the first sane post this entire thread ;)

Re:Incorporate other stuff

[Eunuchswear]

Well, you'll be one up on systemd then, it only has a web server.

Multithread/multiprocessor support

[olterman]

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.

Re:Dependencies :)

[Eunuchswear]

No it is not. It's not the service itself that starts required services, it is systemd that does it.

  GigaplexNZ was suggesting that every service start out by starting all the dependencies it requires.

Precalculate your dependencies and parallelism.

[shess]

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

dependency injection

[PricekhanLinuxbean]

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 might be to bring up part of the system or leave parts of it shutdown even if their normal dependancies are all met. Too bad most systems sit at a console prompt waiting for a human to tell them what to do with the broken disk. Compare price here is the best websitewww.pricekhan.com