Using rc.local to automate apt-get update & apt dist-upgrade

[TechInMD]

Hello Folks,
Let me start by stating that I have scoured the forums and google for an article related to the specific situation that I am trying to implement. Please excuse me if the question has already been answered... and if it has, please send me the link so I can better understand the solution, without being ridiculed

I am currently running Linux Mint 17.1 (rebecca) using the XFCE interface.
I am using /etc/rc.local to automate system updates when the system is booted. I am able to get the following configuration to work:

Pasted /etc/rc.local:

Code: Select all

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
apt-get update && apt-get dist-upgrade -y
exit 0

The problem that I am facing is that the update takes place in the background, and I am not able to see which packages are being updated/installed (which makes me a tad uneasy for I am not able to examine the output for errors, etc.)

The end result that I am aiming for is to have this script launch in a terminal window so I can monitor the actions that are taking place.

First, I tried editing the line in rc.local to the following:

Code: Select all

xfce4-terminal -e "apt-get update && apt-get dist-upgrade -y"

I have tried creating a separate (executable) script in my users home folder named "update.sh"
Pasted update.sh

Code: Select all

apt-get update && apt-get dist-upgrade -y

I have referenced this script in rc.local by editing the command using the following:

Code: Select all

xfce4-terminal -e "/home/user/update.sh"

I have also tried creating an entry in the "Session and Startup/Application Autostart" referencing the update.sh script. All of which is to no avail.

I have attempted to be as descriptive as possible in my query, but if I am lacking some info that may be crucial to reaching a resolution to this issue, please do not hesitate to ask me.

Thank you in advance for any insight that you can provide to help me with this.

[xenopeek]

What's the point of monitoring these actions? The Linux Mint way is to consider your actions before taking them. It's not like you'll interrupt partially done upgrades, I think (unless you enjoy picking through broken pieces). If something goes wrong with an upgrade you'll most likely not find till out after next reboot. You can just consult your dpkg log (/var/log/dpkg.log) to see what actions were performed. Like listing all upgrade actions by date with this command:

Code: Select all

grep " upgrade " /var/log/dpkg.log

If you want to do something useful, I'd say it would be to redirect output of the commands to a logfile so you can consult that if and when you run into problems. Like by adding this command to head of your script:

Code: Select all

# redirect stdout and stderr to logfile
exec >>/var/log/mymess.log 2>&1

Anyway, you should not use dist-upgrade but upgrade.

BTW, not trying to ridicule but it seems a bit pointless to me to watch these things if you're blindly going to execute actions anyway Update Manager has a measure of help built in. It groups packages by source so you can't do an incomplete upgrade and need to go through but a short list of upgrades. It gives indication of how close to the hardware a package is, and thus how risky it is (a regression or new problem in a package close to the hardware may cause stability and boot problems; in other packages a regression or new problem affects probably just one program not working right).

[tadaensylvermane]

Anyway, you should not use dist-upgrade but upgrade.

So much this for automated upgrades. dist-upgrade is asking for trouble if you aren't monitoring it. I've run automated upgrades on my laptop every day at 2 am followed by a reboot. Instead of messing with rc.local I instead made a script and gave it passwordless sudo ability. Add it to cron and away you go.

Code: Select all

#!/bin/bash
#tadaen sylvermane | jason gibson
#mymanager

##### variables #####

SERVER=10.0.1.250
PROXYINFO=/etc/apt/apt.conf.d/02proxy # for apt-cache on $SERVER

##### begin script #####

case "$1" in
	upgrade) # updates and reboots server
		if ping -c 1 "$SERVER" ; then
			if [[ ! -f "$PROXYINFO" ]] ; then
				echo "Acquire::http { Proxy \"http://${SERVER}:3142\"; };" > "$PROXYINFO"
			fi
		else
			rm "$PROXYINFO"
		fi
		apt-get update
		apt-get -y upgrade
		apt-get -y autoremove
		apt-get -y autoclean
		reboot
		;;
	*)
		echo "usage $0 {upgrade}"
		exit 0
		;;
esac

The if statement + the PROXYINFO & SERVER is for my apt-cache proxy. I only use a caching server because I have multiple ubuntu machines here.

This is my sudoers addition... /etc/sudoers.d/customrules
Be absolutely sure you get the sudoers file right else you will lock yourself out of sudo. Will need a live disk to load up and fix it.

Code: Select all

jason failbox =NOPASSWD:/home/jason/bin/mymanager

This can easily be run on cron or put in startup of your DE.

[TechInMD]

Thank you for your insight, and quick response. You have provided me with an "outside of the box" approach to this situation (or maybe I am just the one outside of the box). I don't know why I never thought to examine the log files after the fact (I'll chock that one up to the newbie in me). Also, I did not know how to have the actions performed outputted to a separate log file... so that was very informative.

In response to the recommendation of using "upgrade" instead of "dist-upgrade":

In my previous experiences (and I may be mistaken), I found that just simply using "upgrade" does not retrieve kernel updates, etc. That is why I normally use dist-upgrade. But, now that I re-examine the situation, its probably not a good idea to have the kernel update automatically.

Nevertheless, you have helped me look at this from a different perspective and your input is greatly appreciated.

[Mute Ant]

Commands in /etc/rc.local run before the Xorg GUI system is started; equivalent to the old AUTOEXEC.BAT running before Windows started back in '98. So xfce4-terminal [a GUI application] has nowhere to display if you call it from rc.local.

The apt-get upgrade option is not allowed to remove packages, so it's more likely to leave you with a working system than apt-get dist-upgrade, which is allowed to remove packages and is not especially clever about resolving conflicts...example...brasero conflicts with the new python...solution...remove brasero . Or worse...python conflicts with the new brasero...solution...remove python