You can log to syslog if you want, that's a trivial configuration edit. You can grep on journalctl output, or pipe it to any other commands you want--just like with syslog. I don't think journald vs syslog is about bootup speed; it's about including more information in the log and in a structured way. syslog entries are just plain text; more information is not available than what you see in the log. While journald's default view looks similar to syslog, there is a lot more information available for diagnosis or filtering. Things logged are which boot the message is from (with journalctl -b you can view the current boot messages, with journalctl -b -N you can view messages from N boots in the past); the PID, UID, GID, cgroup, command, executable, and command line of the process that logged the message; optionally the source file, line, and function the message was logged from; optionally the result of the command; and more. For amount of information to diagnose and filter, it's more complete than syslog while being as easy to work with if you need no more than what syslog gives you now (or, yes, you can log to syslog).amity88 wrote:The logs are in a binary format as I had mentioned earlier, that would also contribute to the speed BUT it also makes it harder to view/make changes in a non-standard way (e.g. when you're diagnosing the logs of a crashed system or when you're modifying the init system itself) I prefer the latter over minor speed gains during bootup.
Systemd
Forum rules
Do not post support questions here. Before you post read the forum rules. Topics in this forum are automatically closed 6 months after creation.
Do not post support questions here. Before you post read the forum rules. Topics in this forum are automatically closed 6 months after creation.
Re: Systemd
-
- Level 7
- Posts: 1517
- Joined: Wed Jul 31, 2013 6:29 pm
- Location: Kalamazoo, MI
Re: Systemd
conflict resolution
the thing I don't like about systemd is the conflict surrounding its development. no good comes of such conflicts. I have every confidence systemd will be controlled by the kernel development group.
the thing I don't like about systemd is the conflict surrounding its development. no good comes of such conflicts. I have every confidence systemd will be controlled by the kernel development group.
¡Viva la Resistencia!
Re: Systemd
@xenopeek,
Thanks for your input, I like some of the features of journalctl as I have mentioned earlier but let me elaborate on the problem that I faced in the past. I'd appreciate any ideas that you have on the matter.
I was optimizing Linux on a Raspberry Pi server and one of the things I did was to minimize writes to the SDHC flash memory to increase its life. For this, I mounted a tempfs volume to /var/logs with scripts to load/save logs from and to the flash memory each time I power cycled. I also had scripts to periodically save the logs to flash while it's running.
With sysvinit it was pretty easy, I just needed to add the scripts to the appropriate runlevels and also put one in crontab. While it's running, the log messages kept appending, during shutdown/save it overwrites the old files.
How do you implement something similar using systemd? I also would like to know how the journal can be rotated and how to read the journal messages of one linux install (say a crashed one) from another.
Thanks for your input, I like some of the features of journalctl as I have mentioned earlier but let me elaborate on the problem that I faced in the past. I'd appreciate any ideas that you have on the matter.
I was optimizing Linux on a Raspberry Pi server and one of the things I did was to minimize writes to the SDHC flash memory to increase its life. For this, I mounted a tempfs volume to /var/logs with scripts to load/save logs from and to the flash memory each time I power cycled. I also had scripts to periodically save the logs to flash while it's running.
With sysvinit it was pretty easy, I just needed to add the scripts to the appropriate runlevels and also put one in crontab. While it's running, the log messages kept appending, during shutdown/save it overwrites the old files.
How do you implement something similar using systemd? I also would like to know how the journal can be rotated and how to read the journal messages of one linux install (say a crashed one) from another.
Re: Systemd
I've had to read my journal while booted from a LiveISO. Easy-peasy. Mount the filesystem that has the journal, and call journalctl with this option:
As for minimizing writes, you could increase the sync period or set storage to volatile? (See `man logind.conf` for info.) For the latter then have a script to (periodically / at shutdown or reboot) copy the (changed) files from tmpfs to permanent storage, so you can access it after shutdown or reboot if needed. Using some load/save scheme with /var/log/journald might maybe also work, IDK--would need to run some tests
Code: Select all
-D DIR, --directory=DIR
Takes a directory path as argument. If specified, journalctl will operate on the specified
journal directory DIR instead of the default runtime and system journal paths.
Re: Systemd
@xenopeek,
Thanks for the input, now I'm tempted to test journalctl once again and test out those things. I always thought that volatile maintained the logs in memory without every writing to disk? I'll check it out. Also, from what I remember, saving/loading journald file didn't work for some reason, I think I was not able to view the older logs. I'm gonna test it all out again the coming weekend
Thanks for the input, now I'm tempted to test journalctl once again and test out those things. I always thought that volatile maintained the logs in memory without every writing to disk? I'll check it out. Also, from what I remember, saving/loading journald file didn't work for some reason, I think I was not able to view the older logs. I'm gonna test it all out again the coming weekend
Re: Systemd
volatile keeps the logs on /run; so in memory only, but these are still files that you can copy somewhere else.
As for saving/loading log files, you probably need to also update the catalog after loading log files. From the journalctl manpage:
Also, the default sync time (5 minutes) seems to be reasonable at reducing writes while ensuring critical errors are stored on disk immediately. From the journald.conf manpage:
As for saving/loading log files, you probably need to also update the catalog after loading log files. From the journalctl manpage:
Code: Select all
--update-catalog
Update the message catalog index. This command needs to be executed each time new catalog
files are installed, removed, or updated to rebuild the binary catalog index.
Code: Select all
SyncIntervalSec=
The timeout before synchronizing journal files to disk. After syncing, journal files are placed in the OFFLINE state. Note
that syncing is unconditionally done immediately after a log message of priority CRIT, ALERT or EMERG has been logged. This
setting hence applies only to messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The default timeout is 5 minutes.
Re: Systemd
Last few comments were off-topic and brimming with hate. A personal blog seems a better place to work out anger issues. Comments removed.
Not unexpected but with that there is nothing more useful to be gained here so locked the topic.
Not unexpected but with that there is nothing more useful to be gained here so locked the topic.