Forgot your password?

Comment: Re:How about we hackers? (Score 1) 832

As I understand it:

1) If a daemon keeps failing, systemd just keeps restarting it. Admins prefer to be notified so that they can fix the root problem.

systemd doesn't restart crashed daemon unless configured to do. It is also really smart about restarting daemons with rate limiting and timers and what not. systemd can distinguish between manually stopped daemons, and those who have been SIGHUP'ed or those with a unclean exit code.

Look here under the "Restart=" option for more details:

2) If there is a problem with /etc/fstab, systemd will not allow the system to boot, and gives no reason for the failure. Admins prefer the system boot, and send a message. That way they have a running system, and can fix the problem.

Yes, systemd stops and goes into emergency mode if some hard disk in fstab doesn't show up. This is the right behavior. You can really mess up a system if you allow it to boot with missing mount points. SysVinit and similar init systems may allow booting of a broken system without any notification, but that is simply buggy behavior.

systemd does complain loudly about missing entries in fstab, a quick "journalctl -b -p err" would show that.

Mounting devices with "nofail" in fstab will allow systemd to continue to boot even if the devices are missing, since that implies the admin knows the system will be all right despite missing discs.

Comment: Re:Are you sure? (Score 0) 832

Number of executables which can parse systemd journal log files: 1
Number of executables which can parse traditional log files: >10000

Single points of failure are rarely a good idea.

systemd's journal is an open standard with a stable API and many language bindings. There already exist independent journal readers; they are easy to make.

Personally I don't care if there was forty trillions programs that could read legacy style text logs. If they don't provide the same power and ease of use as systemctl, I won't bother using any of them.

And the sad fact is, that old style text logging and parsing has several fundamental problems. They have a chaotic and messy structure where the actual wording of the error messages have become an API, so if a program changes the wording of its logging strings, it will break all kind of watch scripts.

Legacy style text logs don't have any rich meta data like monotonic time stamps etc. And if you try to extend the content of the log files they become more and more unreadable for humans, and it will break watch scripts.

There are many problems with text logs and as time goes by, and systems dump more and more info in the log files, the more these problems will be exposed.

I am fully aware that the systemd-hating techno-Luddites will deny that there are any problems with text logs, just like they will deny there are any problems with SysVinit. Everything is perfect and can't be improved according to them.

So sure, go ahead and use an unmodified SysVinit for the next 30 years too together with syslog text files. But don't complain that somebody else are tackling these problems like systemd does.

Comment: Re:Are you sure you're not a shill? (Score 0) 832

Why do you think you need to modify vi to edit systemd config files? All systemd config files are just text files.

I don't. It's a metaphor, you flid.

If I'd said "do I need to resolder my amplifier to connect different speakers in" would that have confused you less, or more?

Ah, so it was a made up story about systemd simply because you don't have the technical insight or knowledge about systemd to give are real example.

systemd requires modifications to many other programs. Or do you deny that?

Like what?
You do know that backwards compatibility was a primary design goal for systemd, so that it worked as a drop in replacement for SysVinit/Upstart. You don't have to modify your programs to work on a systemd distro, it will read SysVinit scripts just fine, and understand syslog style logging too.

That developers are starting to use systemd features, is simply because systemd help upstream projects solve real world problems. systemd is all about making things work better on Linux, for both the end users, distro makers, and developers. This is why it has gained such widespread popularity and adoption.

Comment: Re:Are you sure? (Score 0) 832

And you don't have to modify vi to edit their config files. That's one of the things that worries me - systemd needs modifications to all manner of other things..

Why do you think you need to modify vi to edit systemd config files? All systemd config files are just text files.

The basic lack of knowledge about systemd among those who dislike it is simply embarrassing for the Linux community; it is like people have forgot what a "man" page is, that sometimes you actually have to read up on stuff in order to understand it.

Seriously, try reading up on systemd: It is cool new Linux tech with lots of exceptionally fine features:

Comment: Re:Why not fork/wrap systemd to make it more sane? (Score 1) 832

As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon.

That is just wrong. Please read up upon the systemd project before having strong opinions on its design. Don't rely on people foaming at their mouth with rage for information on how systemd actually works. In the future, all major Linux distros will use systemd, so it is prudent to actually read and understand it. This is a good starting point:

What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. (...)

What's even more surprising is that someone with some sense hasn't done exactly that:

First, systemd is of course split up in multiple processes each running with their own PID.

Second, in those case where there is e.g. kernel feature integration, systemd follows the most logical way to design a system. The reason why you don't see a systemd re-implementation done in hundreds of little independent modules, is that is a bad design with a huge overhead, when a module needs to talk with 3 other modules, that again needs to talk to 3 other modules every time a daemon request whether it eg. have more cgroup slices available.

So systemd is designed the way it is because it is meant to solve real world problems better than anything else out there, not be a show case of some dogmatic design philosophy.

Comment: Re:benefits vs risks (Score 2, Informative) 832

What about systemd trying to do too much? Ie, someone earlier said it was great that systemd did ntp and dhcp, which seems ridiculous to me; if those services had problems then get better services, don't just wrap them up into systemd. Were those written as examples of systemd services to be emulated, or do the systemd devs really think it's their job to subsume services?

Interesting problem; if systemd had taken existing sNTP and DHCP clients, modified them so they fitted the systemd user case, the systemd developers would have been accused of "subsuming" other projects.

I think it is important to understand why systemd made a sNTPv4 and a DHCP client; in both cases it was user requests, and it was all about OS containers. Most sNTP and DHCP clients are made for stand alone systems, but the OS container density on a system is between 10 to 100 times that of a system running VM's.

That means a server, instead of booting 5 VM's will perhaps boot 250 OS containers. That is 250 instances of Fedora/CentOS/Debian that all wants a DHCP lease and syncing time at the same time.
Reducing the time for getting a DHCP lease means significant time savings. In this case systemd developers improved DHCP connections times by reducing the time spent in getting a lease by a factor of 1000. Very cool.

As it is now, you can now boot an entire Linux OS container from zero in 100ms, including getting a DHCP lease. That again means Linux OS containers on demand.

As you can see the DHCP client and server is implemented as a library, meaning everybody can use their work for their own super fast DHCP implementation.

Of course, no one is forced to use systemd's versions of sNTP or DHCP. Their versions are made for speed, not for features.

Comment: (Score 1) 555

by Peter H.S. (#48226563) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

I work on servers with systemd as the init system. Yes, it's quite possible to run a server with it. It does things that in fact make much more sense for a desktop. It's not terrible, but it's moving away from the simplicity and modularity we've come to expect.

I would say that out-of-the-box cgroups and kernel capabilities are making extremely much sense on servers. Being able to put hard limits on a service's CPU/IO/networking can only be a good thing, same with having defense in depth, by eg. preventing a service process /or any of its children/ from ever getting any privilege escalation (NoNewPrivileges). Combine it it with PrivateTmp=, and white-listing of what dir's it can read or write and you get some real hardening of the system in a very easy way.

Same with reliable killing processes, having a total supervision chain, including PID1 itself, being able to restart crashed processes, not by simplistic means, but using rate limiting, and perhaps based on exit signals too (only restart on unclean exit signals etc).

Regarding simplicity, then I am the opinion that the old legacy script based init systems where more "crude" and "primitive" rather than simple, and their total lack of features isn't so much a virtue, than a real downside to their use; even basic features had to be hacked and bolted on top of SysVinit.

I do agree though, that systemd is a rather hefty piece of software to understand, doing things in new ways, and lots of documentation to read. It also sucks to discard knowledge about e.g. boot sequences, and relearning everything again. But looking back, there was a lot of new tech that seemed extremely complex to begin with, that these days seem trivial, so I guess some of the seeming complexity of systemd will disappear once people "get it".

Regarding modularity; people may argue all day long that systemd isn't "really modular". But the point is in many ways moot; there is no real substitute for systemd's udev or logind or journald (syslog doesn't do all what journald does and vice versa), so what did it matter if systemd increased its internal complexity by supporting other modules than these; there simply haven't materialized any alternative despite years of warning from upstream projects.

Another thing I like about systemd and its wide acceptance in all major distros, is that it is a long needed reduction in needless fragmentation, being able to share knowledge about doing certain things on so many different distros is a boon.

Comment: Re:A rather empty threat (Score 1) 555

by Peter H.S. (#48199005) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

So it should be a piece of cake to show me the patch, but you failed. Perhaps you have no idea what is what.

Look at the changelog numbers. Each number after the release number points to a specific patch. "2.88dsf-53.4" decodes as upstreams version 2.88. "53.4" the fourth patch set to the version 53 (usually one patch per version). So "2.88dsf-42" or "2.88dsf-53.4" refers to specific patches.

Comment: Re:A rather empty threat (Score 0) 555

by Peter H.S. (#48198483) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

You ARE confused. Please do apt-get source sysvinit and point me to a patch that addresses a bug in the upstream code (hint, there isn't one).

An RFE is in no sense a bug.

What the patches DO show is startpar being added in. That is, the ability for the init to happen in parallel.

But note, I don't advocate staying with the old unimproved sysvinit forever, just until a truly superior solution that doesn't try to own the world is ready to go.

Have a look at the SysVinit changelog. There have been 53 commits since 2.88 was released years ago. Sure some of them are Debian specific, some are startpar, but others are not.

Dismissing RFE's as "not bugs" may mean dismissing request for making SysVinit work with other programs or take advantage of important new features. Thinking that init can live in its own little time bubble while the rest of the system evolves is wrong.

Comment: Re:A rather empty threat (Score 1) 555

by Peter H.S. (#48197355) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

I am not talking about bugs in SysVinit scripts used by daemons, but bugs in SysVinit itself. As you can see both Debian, RHEL, SUSE etc. all carry bug patches against the 2.88 release of SysVinit, none of them have made it back to upstream SysVinit. Notice how all development on SysVinit and releases stopped when upstream distros like SUSE, Ubuntu and Red Hat changed their init to Upstart.

And lets forget RFE's (request for enhancments) bugs; there simply aren't any work being done in that regard either, so they will languish away in the bug trackers too.

Again, sweep those problems under the carpet if they offend your eyes, but be assured that the reality of things will become apparent as time goes by.

Yes, there are alternative non-systemd distros out there, but if people don't start fixing the backlog of problems facing non-systemd distros, it is a question on how long they will survive. Being in denial of all the problems non-systemd distros are facing will only accelerate this.

Thinking that everything can go on as before without development and coordination is a failure in analyzing the situation.

Comment: Re:Binary log files? Really? (Score 1) 555

by Peter H.S. (#48197057) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

I don't like the ideal of binary log files, but I can get behind everything else.

Well, just use rsyslog/syslog-ng like you always have. That way you have the usual flat file text logs while having all the other benefits of using systemd.

Anybody having working with computers for a long time tends to be vary of binary formats. I have had a lot of bad experiences with binary formats over the decades. But using systemd's journal made me realize that what I really want is config files that are text based, and having binary data isn't such a big deal as long as it is an open standard and the tools are both standard and of high quality. systemd provides me with exactly that.

All the standard Linux text tools like "grep" and "wc" etc. works perfectly together with systemd's binary journal, by using the standard Linux concept of piping, so nothing is lost, but many new features like having monotonic timestamps are gained.

Comment: Re:Boot/init is a critical stage (Score 1) 555

by Peter H.S. (#48196907) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

have nothing against binary log files per sé, but they should not be the primary and only option. Instead of hanging rsyslog after journald, I'd rather see it reversed, first plain-text logging to syslog and eventually piped to binary logging afterwards (or parallel to both, whatever). That way, all the info is still available in case the binary log files get corrupted for one reason or another, and people still have their easily searchable binary logfiles.
Also it'd make it easier for other remote-logging tools to hook in with the already existing syslog infrastructure than hook on to journald.

It doesn't make sense to go from text to binary format as default. Remember that a key point in having a structured and indexed binary log file is that you can keep all kinds of rich meta data info in each log entry, like monotonic timestamps, high precision time markers, system UUID's, etc.. If you put all those meta data fields directly into the flat text file, every log entry line will become insanely long and complex, making it much less human readable.

The present solution with systemd making all the local log entries in binary form, and then use rsyslog for converting it to legacy flat file format, or placing it a database while preserving the rich meta-data is a really good solution with few drawbacks and many great advantages. In this way, systemd is actually enhancing rsyslog's capabilities. Using either journald-gateway or rsyslog to remote logging can now preserve the rich meta data too.

Comment: Re:UNIX Philosophy (Score 1) 555

by Peter H.S. (#48196229) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.

Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?

Good questions. The reasons are complicated, but I will try as best as I can.
When journald was made it was constrained by several design parameters: it should have total backward compatibility for those needing this, it couldn't require that any userspace program should be rewritten in order to work with it, including syslog implementations like rsyslog. It should simply be a drop in replacement, giving people the opportunity to use its enhanced features if they wanted to, or just use the usual rsyslog setup they always had used. It should also be as simple and fast as possible. In fact, the journal more or less an append text file with other newline delimiters and an added index.

And because journald worked with syslog, people could use rsyslog for all their advanced database logging needs. In short, journald makes it flexible for those who have advanced needs, instead of tying them down to a particular solution. Unlike rsyslog, journald isn't a log sink (and hopefully never will be).

All in all, making sweeping and complex changes like using a real RDBMS as a logging back end wasn't an option. Also, such RDBMS solutions already exist in a mature state in e.g. rsyslog, so there was no need either.

There are other design constrains concerning logging on Linux. At the moment everything goes into /dev/log, and only one program can read it a time. AFAIK, you have to rework both the way the kernel does logging and user space loggers in order to have more than one program reading log info from the source. The solution seems to requires using kernel namespaces and other low level systems, and are likely to require that both kernel version and user space loggers are synced to a certain version in order to work.
So AFAIK, it isn't easy to make a early-boot-log helper that hands over logging to syslog when it is done, at least not in a lossless way and certainly not if the helper logs are meant to be incorporated into the syslog flat text files (which is why eg. dmesg is a separate log file).

As for logging being "married" to init, the main argument was, that in order to have first class service and process management, you need a matching first class logging system. In order to have early and late boot log messages, the init system have to be aware of a lot of low level system stuff, and cooperate extensively with the logging system. They could have used rsyslog and changed it so it worked like the journald works, but that would have tied all systemd Linux distros to a particular syslog implementation.

Having them working together also makes it trivial to attach log messages to a service check.

Are binary log files a necessity of the systemd design? Absolute not. But then again, people who prefer flat text files for logs can just use rsyslog/syslog-ng as they always have. The binary log files are optional. But the binary, structured and indexed journal log do solve so many limitations of flat text files that I am glad it exist as an option. The systemd journal really is a joy to use.

Comment: (Score 1) 555

by Peter H.S. (#48195533) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

The distributions should be wary of putting all their eggs in the basket. Not all systems are desktops, and they shouldn't rely on desktop features at the expense of their own roles.

Dude, is just a code repo like github, so they also host e.g. an OpenCL compiler. Sure, the site is also used for inter distro discussions and informal work groups, but implying that systemd is a desktop thing only since it hosted on is just laughable.

When you got the time, please read up on the systemd project to see what it is all about:
This is an excellent starting point:

Comment: Re:A rather empty threat (Score 1) 555

by Peter H.S. (#48195325) Attached to: Debian's Systemd Adoption Inspires Threat of Fork

Or that there are no known bugs to fix and haven't been in ages.

That's what happens when you follow the KISS principle.

Just look at the Debian SysVinit bug tracker. Of course there are bugs. I don't claim that there are serious showstopper bugs, but they are there, and sometimes they are even fixed. Feeding such bug fixes back to the upstream project is normal Linux practice, but for the last several years, such bugfixes haven't been mainlined with upstream SysVinit, making SUSE/RH the de facto Upstream now, and both those distros are about to outphase SysVinit.

I don't say that eg. GNU/SysVinit is understaffed is a unsolvable problem. But what I do say is, that those who will continue to use SysVinit have the responsibility to make and maintain all the necessary code themselves for being able to do so, including helping out SysVinit.

The non-systemd camp can no longer rely on paid developers from commercial distros solving all their problems. There is a long list of stuff that needs to be done, right now and in the near future in order to run a SysVinit distro without it degrading slowly and falling hopelessly behind in features.

To thine own self be true. (If not that, at least make some money.)