I'm not sure whether this is the right place to ask about this, but I've gotten scripting help in the past here, so I thought I'd give it a try. First off, I really have very little knowledge about how to do these sorts of things, having only created a few extremely rudimentary bash scripts in my life. So bear in mind you're dealing here with a rank novice.

In any case, here's the task I'm trying to accomplish. I'm an Arch user and have found that I am just way too lax about performing the standard Arch drill, anywhere nearly as frequently as I should, of pacman -Syu (should be done at least weekly, I believe). For those unfamiliar with what that command does, it synchronizes the package database, then upgrades all packages for which newer versions have been released. I'm trying to come up now with a semi-automated way of doing that, one which will at least prompt me on a regular basis to run the dreaded command.

I thought this might be fairly easy: simply run a cron job that opens a terminal that echoes some informative text like "Beginning full system upgrade," then runs sudo pacman -Syu. Once you've entered the superuser's password, the update/upgrade runs, completes, and the terminal exits.

Well, my efforts have so far met with only modest success. To begin with, I am unable, for reasons I don't understand, to invoke a terminal with a cron job. No problem, I thought, since I also run the remind program in daemon mode and can make the terminal open at the appropriate date/time using it. I got a little further with that, but it's still not working very well.

To make that work, I've called xterm from remind using the command xterm -e sudo pacman -Syu. That comes close, although I've found that, if I'm not at the terminal to enter the admin password, the terminal will just close itself after a couple of minutes. And there are likely to be many instances in which I will not be at the computer screen to do that, so the terminal needs to stay open longer--preferably until the password is entered.

I also tried the hold option when starting xterm, with mixed results. First, that does keep the terminal open longer than 2 minutes. But in an experiment I tried where I left the terminal awaiting input (superuser password) for a lengthy interval, I found that the xterminal had become unresponsive: it wouldn't accpet any sort of input at all, and I had to simply kill it. But even when I do enter the password after a shorter interval of the terminal being open, the synchronize/update/upgrade process doesn't seem to conclude normally: the output that typically notifies you that the process has successfully completely does not, for some reason, appear, and you're simply left with a frozen terminal that you have to kill manually. So, even if I could manage to be at the terminal to enter the password before it froze (which might be about 50% of the time) it's not a very elegant solution.

Can anyone help me to resolve the issue I'm facing by aiding me in the creation of a script that will invoke a terminal (xterm preferred), echo text like "Starting full system upgrade," then run sudo pacman -Syu, and finally exit cleanly once the process has completed successfully? The script should either be capable of running as a cron job or, if not, then by using remind.

Thanks in advance for any input.

James

Just something to throw out there - maybe instead of launching your program with sudo right off the bat, maybe you could have it present a menu first. That way sudo won't time out or anything. For instance:
Hope this helps!

1 members found this post helpful.

That looks like an interesting start, casualfred. And I certainly have no objections to the enhancements you've introduced--they seem like improvements to me. What I'm not understanding, though, is how to make this script run inside the terminal that's getting invoked (xterm would be my choice). If I just try to run that script from the command line it seems to work as advertised and looks close to what I want. But how do I cause an xterm to open and have that script run inside it? Like I said, I'm not real conversant in these things. In any case, thanks much for your input.

James

You start it the same way as before:from your reminder program.

But you really shouldn't do that. It is essential for Arch users to have a look at the website before doing an upgrade, so that you will be warned about possible caveats.
So it would be better to not automate this task, at least not without launching a browser window with Arch's homepage to make you aware of problems.

Thank you for your input, TobiSGD: I'll give that a try. I actually consider what I'm trying to do as semi-automatic updating: nothing gets updated without user input. And I've recently subscribed to the Arch news RSS, so I do look at Arch headlines every day (though I've discovered they certainly do not post news every day). Under these circumstances, what I'm trying to do seems to me pretty safe and not in violation of Arch principles. Of course not everyone may agree with me . . .

James

Cool, yeah I would probably put what I suggested earlier into a script somewhere, maybe calling it upgrade.sh. For the cron job, however, I would make a separate script:
The -rv option just makes xterm text white on black. When the script is done running in that xterm window though you'll have to close it manually with the window manager because of the -hold option. You have to tell cron what display you want it to show the xterm on, thus the "DISPLAY=:0.0". Also all the locations of programs and files should be absolute.

I haven't tested this, so it might not work...

This script has been doing the job for me for a few days now, so this issue is solved. I have not tried running it as a cron job, invoking it rather with the remind program. Many thanks to casualfred for the help he rendered in this. I hope others may benefit from it as well.

James

Actually, I've thought of a needed improvement to this script. It is likely to happen, for example, that the script will run when I am away from the computer for an extended period--say, on vacation. Since I have it running every other day, the result will be that, when I return, several xterms will be open, awaiting input. While I can't see why that would cause any serious problem it is, at the least, not very desirable.

The improvement I envision, then, is a check on whether the script is already running. If it is already running, it should either be killed before a new instance runs, or it should simply abort and not start a second instance. The former, i.e,, killing the current instance and starting a new one, seems preferable to me. Any input on how that sort of check could be implemented in this script?

Thanks,
James

Hi. I have a similar situation with an automated backup script. What I am doing is that it creates a lock file at an appropriate location (using the touch command) which is removed right before the end of the script.

If at the beginning of the script execution the lock file is already present I abort execution.

On a completely separate note: For things like reminders etc. I also like to use conky. You could use a big red "Get your system upgrade" warning in conky if the last one is too long ago. Just an idea...

Good suggestion, joe_2000. I researched this issue again recently and ran across the lock-file way of doing this. But in the end I found something simpler and that performs the function sufficiently for my needs. It involves using the timeout utility. I have the system set up to simply invoke periodically the update script, prefaced by the line timeout 23h. My script never runs more than once a day, so if the machine is unattended and no user input is given, the window will stay open for 23 hours, then simply exit if the task does not get completed. I'm not a conky user so that option, though an effective one in its own way, is not so attractive for me.