Uselessd: A Stripped Down Version Of Systemd
Collapse
X
-
Originally posted by TheBlackCat View PostFrom 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.
- 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).
Leave a comment:
-
-
Originally posted by phred14 View PostSomewhere 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.
Leave a comment:
-
-
Originally posted by TheBlackCat View PostAny 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.
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.
Leave a comment:
-
-
Originally posted by phred14 View PostWrong! 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.
Leave a comment:
-
-
Originally posted by interested View PostRubbish. systemd's journal is logging finally done right on Linux.
Leave a comment:
-
-
Originally posted by highlandsun View PostGood to see that journald was dropped from uselessd. journald is a steaming pile of cr@p. https://www.linkedin.com/pulse/artic...tering-systemd
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.
Leave a comment:
-
-
Originally posted by cynyr View PostMy 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?
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.
Leave a comment:
-
-
Originally posted by cynyr View PostPlease 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?"
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.
Leave a comment:
-
-
Originally posted by cynyr View PostMy 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?
Leave a comment:
-
Leave a comment: