Uselessd: A Stripped Down Version Of Systemd

[cynyr]

Systemd IS modular. Read http://0pointer.de/blog/projects/the-biggest-myths.html, first Myth.
But most distros just do not bother with this because most elements are very handy for them.

Please explain in detail how to download, compile, and install only the modules I want/need? See "How do I install udev without also downloading and compiling all of systemD?"

Honestly i just can't be bothered to learn a new init system at the moment. That is probably the biggest reason i'm still using gentoo. I know and like openRC. I agree that tracking processes so that init can auto restart a failed service is nice, but not at all needed for me at home. Same goes for tamper proof logs (for the most part). My biggest issue with the binary logs, and other binary files used as configurations, is that I cannot hand edit them from a minimal recovery disk to restore the machine to working when things go wrong. Can I slap in sysrescuecd, chroot into my system and get it working again if a change to some configuration has hosed up the system, such that systemD no longer works correctly? DO i have to scrap my whole config and start over?

[tomegun]

My biggest issue with the binary logs, and other binary files used as configurations, is that I cannot hand edit them from a minimal recovery disk to restore the machine to working when things go wrong. Can I slap in sysrescuecd, chroot into my system and get it working again if a change to some configuration has hosed up the system, such that systemD no longer works correctly? DO i have to scrap my whole config and start over?

Good news: systemd does not use binary configuration files, and a broken .journal file is simply ignored, so will not break your system.

[tomegun]

Please explain in detail how to download, compile, and install only the modules I want/need? See "How do I install udev without also downloading and compiling all of systemD?"

That is pretty easy to do (git clone && ./autogen && make systemd-udevd <...>). However, that has not much to do with modularity. The point is that the software itself is modular, not whether its build-system is. The point of modularity in systemd is that individual components could be shipped separately and only installed/enalbed/ran when needed. Obviously, if component A depends on component B (through a generic and well-defined API), then obviously component A will have reduced functionality when component B is not around. However, you could still replace either of them with something else using the same API (I'd say replacing the provider of an API is something one should only do with great care (if at all), whereas replacing the consumer is obviously a sane thing to do).

Following that (i.e., replacing things higher up in the stack is sane, lower in the stack maybe not): Unless otherwise stated, or great care has been taken, all daemons systemd daemons should be run with systemd as PID1 (as mentioned earlier in this thread, you probably can get around that, but you should know what you are doing). PID1 depends on udevd (to be notified about devices) and journald (to have somewhere to send the logs). Apart from that you can pretty much do as you wish (timesyncd and resolved work best when networkd is used, but this is not crucial).

I hope that gives you an idea how things work.

[interested]

My biggest issue with the binary logs, and other binary files used as configurations, is that I cannot hand edit them from a minimal recovery disk to restore the machine to working when things go wrong. Can I slap in sysrescuecd, chroot into my system and get it working again if a change to some configuration has hosed up the system, such that systemD no longer works correctly? DO i have to scrap my whole config and start over?

"sysrescuecd" would work with editing all the systemd config files, since they are just text files. Typical examples are the fstab, since systemd doesn't allow proper boots unless all disk present in fstab work (unless mounted with nofail). Allowing broken disk setups to boot is such an old bug on SysVinit/Upstart distros, that people think it is normal.

But "sysrescuecd" doesn't have systemd support as such yet, and AFAIK, they haven't included a journal reader like "journalctl" as a temporary stop gap, so you can't read the journal from it.

It is trivial to read the journal otherwise, either from a proper boot media, by remote by using ssh, or by simply copying the files to another system, or mounting the journal directory and export it to another system (cifs etc).

systemd's journal have powerful support for using multiple journal log files from multiple systems at the same time, since each and every log entry is indexed with unique system UUID's. By using the monotonic time stamps, you can compare the exact progress of the boot sequence on two different machines at the same time. Really cool stuff.

[interested]

Good to see that journald was dropped from uselessd. journald is a steaming pile of cr@p. https://www.linkedin.com/pulse/artic...tering-systemd

Rubbish. systemd's journal is logging finally done right on Linux. Just like systemd is superior to any other alternative as a init system, the journal is superior to anything else available on Linux and BSD. Structured and indexed log files with rich meta-data are simply the correct way of doing logs.

In fact, within the next decade, every Unix, and Unix like system like Linux and BSD, will have a systemd-like init-system and a journal-like logging system.
The "systemd way" of doing things will simply out compete all legacy script based init systems and simple text logging without meta-data.

[phred14]

Rubbish. systemd's journal is logging finally done right on Linux.

Wrong! Leaving everything else aside for the moment, and leaving aside the detailed technical description of why it happens, journald can produce corrupted logs during a crash. This has been considered NOTABUG, because a non-corrupted log will be generated on reboot, and that is Wrong! too. When a system crashes the log is your first line of figuring out what the heck happened, and how to prevent it from happening again. If the log is corrupt then that diagnostic information about the crash for analysis is gone.

[TheBlackCat]

Wrong! Leaving everything else aside for the moment, and leaving aside the detailed technical description of why it happens, journald can produce corrupted logs during a crash. This has been considered NOTABUG, because a non-corrupted log will be generated on reboot, and that is Wrong! too. When a system crashes the log is your first line of figuring out what the heck happened, and how to prevent it from happening again. If the log is corrupt then that diagnostic information about the crash for analysis is gone.

Any logging system can produce corrupted logs, including text-based ones. The reason it is considered NOTABUG is because the log will be fully readable up to the point where the corruption occurred, and a new log will be available and readable from the point after the corruption occurred.

[phred14]

Any logging system can produce corrupted logs, including text-based ones. The reason it is considered NOTABUG is because the log will be fully readable up to the point where the corruption occurred, and a new log will be available and readable from the point after the corruption occurred.

Somewhere in the various discussions I got the impression that the log entry was written, then the index at the front of the journal was updated. If the crash occurs or if anything else goes wrong during the update of the index, the entire journal would be corrupted, and recreated upon reboot.

As for my own text logs, one step I take on every machine is to enable the Magic SysRq key, so that if there's any life at all in the kernel I can sync the filesystems and then remount the ro before rebooting. Of course that doesn't work for a server without keyboard access. On one circumstance where I had a machine spontaneously power down (bad power supply) I set up remote logging so I could be guaranteed to get those last log entries.

[TheBlackCat]

Somewhere in the various discussions I got the impression that the log entry was written, then the index at the front of the journal was updated. If the crash occurs or if anything else goes wrong during the update of the index, the entire journal would be corrupted, and recreated upon reboot.

From what I have read, including from people who have what are reported as corrupted logs, losing the index isn't all that big of a deal. The log is mostly still readable. A new journal is created because doing any additional writes to the journal is a bad idea, but reading from it generally works.

[DrYak]

From what I have read, including from people who have what are reported as corrupted logs, losing the index isn't all that big of a deal. The log is mostly still readable.

Speaking of real-world usage:
- journald itself can still forward messages to syslog (and is setup so in distribution that currently ship with systemd like openSuse which I am using)
- so, in practice, in every day situation, you still get your usual text files
(and you can even remotely forward the syslog over the network).

So basically, the usual work-flow isn't disturbed, (I still usually investigate what I need by simply looking at /var/log/messages. It feels my needs despide systemctl/journalctl containing more data. I just happen not to have needed it yet).