I'm a bit of a newcomer to Arch Linux and still getting used to some of its paradigms. I come with a lot of habits from another distro that was quite a bit more structured and in some ways predictable.
One thing I would like to do with a few systems¹ is enable a cron job to do automatic updates of all system packages. This seems like it would be pretty easy except I also want some meaningful feedback from the system telling me how things went that was not so verbose that I end up ignoring it until I discover the system is acting up.
- The full output of
pacmanis unnecessary. I don't care how long the downloads took or that it is on update 46 of 53.
- For the most part I don't care about successes.
- I do care about errors. If an update run fails I want to know about it and any specific error messages should be patched through.
I do care about the "notices" given off during install. For example today's systemd update said:
:: coredumps are no longer sent to the journal by default. To re-enable: echo >/etc/sysctl.d/50-coredump.conf \ "kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e"
Or filesystem produced this:
warning: /etc/group installed as /etc/group.pacnew warning: /etc/passwd installed as /etc/passwd.pacnew warning: /etc/shadow installed as /etc/shadow.pacnew
This last category is actually what prompted me to ask this question because it seems these are very inconsistent across the package set. Some of these seem to be generated by
post_upgrade(), others by
install(), etc. Sometimes they are written to stdout, sometimes to stderr. The format of the messages varies widely: sometimes a whole block is prefixed on indented in some way, other times there is just a bare echoed string.
I want to know about things that may require my intervention on a system but not be bothered otherwise. Is there a tool out there that intelligently manages this data and simplifies the system administration? Is there any way to get the output generated by packages separately from the pacman process installing them? Or am I on my own to write some kind of parser that filters out benign stuff from the install log?
¹ Before you jump all over how stupid this is please note that I'm smart enough to not do this on production servers and not without snapshot based full system backups that would make recovery easy in the event of a catastrophe.