Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 pacman is 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.

share|improve this question
    
The first thing I would do is remove the yaourt tag, both from your question and your conceptual model: trying to do this with the official repos will be difficult enough, adding random packages from the AUR to the mix will make it quixotic... –  jasonwryan Jun 25 at 8:20
    
Oh, and this isn't a stupid idea; but it very much pushes against the way Arch works. Using checkupdates and -Syuing once a day is a pretty trivial task; I don't see any actual benefit for all the work your proposal would entail. –  jasonwryan Jun 25 at 8:25
    
@jasonwryan I meant to expand on that, but I do actually have some AUR packages I would like to fit in the same workflow. I currently make extensive use of yaourt and sorely miss the fact that there is no dry-run support for package management operations! :/ –  Caleb Jun 25 at 8:26
1  
The DNA of Arch is getting your hands dirty: this is just not the way it is intended to be run; you may get there, but it will be a Pyrrhic victory and, if documented here, will just lead a whole lot of newbies to the edge of a cliff that they are completely unprepared for... –  jasonwryan Jun 25 at 8:29
    
I spent a while trying this last year and came to the conclusion that the only way to achieve upgrades without regularly killing systems was to build new images (which seems to be the base testing point and more reliable in Arch) then transplant service's with a config management tool. Maybe updates have settled down a bit but there were 3-4 in a 6 month period that would hose a system without manual intervention. –  mtm Jun 25 at 8:42

1 Answer 1

I want to be clear for both you and any other person who might happen upon this thread. What you want to do is not possible. Arch makes no secret of the fact that it expects you to administer your system. Part of that responsibility is being present for the update cycle.

Now, there are steps of the update process that you can automate responsibly, but it will never amount to an automated -Syu. You simply need to be there for the upgrade.

What you can do, for example, is to set up a cron job that downloads any packages that need to be installed (but not install them). The following is an excerpt from the pacman documentation:

SYNC OPTIONS
...
-w  --downloadonly
    Retrieve all packages from the server, but do not install/upgrade anything.

You could then, setup a cron job to run sudo pacman -Syuw. I'm not terribly familiar with cron or it's scheduling abilities. However, if it is capable of only running a job after a particular condition has been met (for example, a command returning a particular value), then it would be fairly trivial to trigger the downloading of new packages as needed.

I would imagine running a check against checkupdates | wc -l, for example. If it returns any number above zero, you could trigger the download. Again, however, this will not replace running an -Syu when you are present and ready to deal with the upgrade.

For the final part of your question, where to get output of what happened during an upgrade, you're looking for /var/log/pacman.log. It includes all error information that might interest you.


There is a tool that is meant to make pacman a little more friendly for unfamiliar users. If I'm not mistaken, it also provides a notification about news items if there should be an update that requries manual intervention.

This tool might make your life a little simpler in the short run, but it will never be a replacement for sensibly and diligently following the Mailing Lists.

share|improve this answer
1  
Actually, for notices about official packages that will require manual interventions, I would recommend that you follow arch-dev-public and arch-general. –  HalosGhost Jun 27 at 2:22
    
Also, @jasonwryan is entirely correct. Doing this with pacman might be possible. Doing it with yaourt is not feasible. –  HalosGhost Jun 27 at 5:07
    
yaourt actually does a slightly better job of this than pacman, though, as i think you mean, its default configuration as little more than an aur helper would almost certainly wreck things in the long run. It is, however, extremely configurable, and can be made to maintain source trees very effectively. Both yaourt and pacman only wrap alpm anyway. –  mikeserv Jun 29 at 4:47
    
Or, i guess it is truer to say, yaourt wraps pacman and some additional alpm functionality and pacman wraps alpm. In any case though, yaourt extends pacman. –  mikeserv Jun 29 at 5:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.