Upgraded to Fedora 32 and some local mail tips

Posted on .

Fedora 32 was released a few days ago and I have already upgraded my home computers to it. The upgrade process was as short and smooth as always, so congratulations to everyone involved and also congratulations to everyone behind RPM Fusion, who had their Fedora 32 repositories ready from day 1. From my particular point of view this upgrade required adjusting a few things after installing and some of them are worth mentioning.

mDNS breaks after upgrading

As explained in the “Common F32 Bugs” wiki page, there’s a bug present if upgrading from Fedora 31 to Fedora 32 that will not happen when installing the system from scratch. If I recall correctly, two packages will fight to modify /etc/nsswitch.conf and that will probably result in mDNS being removed from that file as an option to resolve host names. It will not make much of a difference to many people but some others may experience problems because of it. For example, in my case the networked work printer stopped “working” in the sense that CUPS wasn’t able to properly contact the printer, which led to confusing situations.

This upgrade bug, as far as I know, was already present when upgrading from Fedora 30 to Fedora 31. I recommend you to take a look at /etc/nsswitch.conf just after upgrading and adding the mDNS options if not present, as described in the wiki.

EarlyOOM is now enabled by default in Fedora

EarlyOOM is a nice thing to have that will try to kill offending processes if you are about to run out of memory, but before actually running out of it so your system will not become unresponsive. It’s one of those relatively simple solutions to a complex problem that will work well for 90% of the cases out there. It prioritizes killing web browsers and other programs known to use a lot of memory while preserving programs that are considered essential for a workstation session if they’re running.

If you didn’t have the package installed before, you may be missing it after upgrading, so it’s worth taking a look. You could check if the package is installed with rpm -qa | grep earlyoom. Once installed, you can verify it’s running with sudo systemctl status earlyoom. If not, you can enable the unit with sudo systemctl enable earlyoom and start it with sudo systemctl start earlyoom.

Periodic TRIM is now enabled by default

Before Fedora 32, I used to mount all my filesystems with the discard mount option. This is called continuous TRIM, but it turns out to have some limitations, like only being able to trim blocks that change from used to free and having some potential or theoretical security problems with disk encryption. In this situation, as mentioned in the Arch Linux wiki, both Debian and Red Hat recommend to use periodic trimming if possible and the circumstances allow it. Periodic trimming is achieved by running fstrim from time to time, a utility provided by the util-linux package, which can be used via a systemd unit and timer file that are also provided there.

If you were using the discard mount option before, you can remove it from /etc/fstab and the default filesystem mount options, if present, and enable the fstrim.timer unit if not enabled.

Some Python 2 packages were purged

With Python 2.x reaching its end-of-life, Fedora has completed the essential purge of Python 2 packages. Many people will not be too affected by this as most outstanding Python packages have been ported to Python 3 or have supported Python 3 for a long time now, but a few of them will be lost. In my case, the getmail package was removed and I was using it as part of my mail forwarding script that you can see here, to receive mail both locally and forwarded to my main FastMail account when a problem happens in my system and a daemon wants to send me an email message (think smartd).

Fortunately, Postfix allows configuring several destinations in ~/.forward, one per line, so I changed my mail forwarding script to skip local mail delivery and added an extra line in my ~/.forward file, like this:

/var/spool/mail/rg3
|/home/rg3/bin/mailforward

This will keep both delivery destinations.

Bonus: local mail tip

Related to this, if a daemon generates email output before the network is completely available, the local delivery part will work but the mail forwarding part may not, so I consider it essential to be notified of local mail delivery. As you may know, many shells like Bash will allow you to set a mail spool file to be checked from time to time using the MAIL and MAILCHECK environment variables, the latter being used to specify the checking period. See man bash for more details. However, when a new mail message is detected, this will only print “You have new mail” before the prompt is displayed. If the command you just ran was a bit verbose it’s easy to miss the line, and it will not be printed again until you log in or a new mail message arrives.

In my opinion, a superior solution is to check for local mail availability every time the prompt is displayed, and to put something in the prompt itself when local mail is available. This way, the notification will stay in the prompt as long as needed and it’s not as easy to miss, specially if you use colors. You will probably want to use an mbox spool in this case, and remove every message from it after reading them (either deleting them like I do or moving read messages to another mail box).

To achieve what I explained above, I set MAIL to my local mail spool in mbox format (/var/spool/mail/mbox) and MAILCHECK to zero to disable periodic checks using bash. Then, I set PS1 like this:

PS1="$( printf '\001\033[93m\002$( test -s "$MAIL" && printf "[mail] " )\001\033[96m\002\\[email protected]\h:\001\033[95m\002\w\001\033[92m\002\$\001\033[0m\002 ' )"
export PS1

As you can see, I use printf as a more portable and shell-independent echo alternative to generate escape sequences for the prompt colors. The important part is that, as show above, I run a command in the prompt by generating a literal “$(…​)” in it. This command checks if the mail spool exists and is not empty, printing [mail] before the prompt in a different color when it does. Due to the “$(…​)” sequence being included literally in the PS1 value, this is run every time the prompt is displayed. The notification about pending mail stays with the prompt until I read and delete the message, making it much harder to miss.

Load comments