Journal-brief now in Fedora

Tuesday, November 3rd, 2015

The journal-brief package is now available in Fedora (22+)!

Also, the 1.1.2 release adds a ‘systemd’ output format to report on failed systemd units:

$ journal-brief -o systemd

Failed systemd units:

 7 x NetworkManager.service
 33 x abrtd.service
 1 x configure-printer@usb-001-008.service
 1 x dnf-makecache.service

For more about journal-brief visit the GitHub page.

Using journal-brief to watch for errors

Monday, October 19th, 2015

It’s pretty easy to see what error messages have been logged on a machine with systemd installed: just run journalctl -p err. But this will show you all of the messages of priority “err” or higher, starting from the beginning of the log. What if you only want the most recent ones?

Again, that’s pretty easy: journalctl -p err -e will do it. The -e parameter tells it to start at the end, not the beginning.

But what if you specifically want to know about error messages that have been logged since you last looked? Enter journal-brief, which keeps a bookmark so that it will only show you messages logged since you last ran it.


Headless encrypted boot with Fedora Server

Thursday, April 9th, 2015

Here is a recipe for using encrypted boot on a Fedora Server system that does not have a monitor or keyboard attached during normal use.

I’ll use Fedora 21 Server, and will have a dedicated encrypted volume group for data but leave the main operating system volume group unencrypted. The encryption key will be stored on a USB memory stick. When it is connected the system will boot normally; otherwise it will wait for a while for it to be connected and finally fall back to emergency mode.


The portreserve problem: is systemd the solution?

Wednesday, February 15th, 2012

Quite a while ago I wrote portreserve, a utility to prevent ports getting stolen at boot time by portmap. This would happen with CUPS, for example: portmap starts first (to allow for NFS-mounted filesystems), and calls bindresvport(). If the privileged (i.e. in the range 512-1023) port it allocates happens to be 631, when CUPS starts and tries to bind that port it fails. This didn’t just affect CUPS, but any service with a well known port in the privileged range.