Weekly updates not working in crontab

Support & Help Requests Raspberry Pi
1

Under the root account, I have a script that reads like this:

#!/bin/bash

apt-get update
sleep 2
apt-get upgrade -y
sleep 4
apt-get autoremove -y

In root’s crontab I have this:

0 0 * * 7 /root/bin/update.sh > /root/update.log 2>&1

When the crontab runs it doesn’t seem to complete the updates. I see this error:

Hit:1 http://ports.ubuntu.com xenial InRelease
Get:2 http://ports.ubuntu.com xenial-updates InRelease [102 kB]
Get:3 http://ports.ubuntu.com xenial-security InRelease [102 kB]
Get:4 http://ports.ubuntu.com xenial-backports InRelease [102 kB]
Hit:5 http://ppa.launchpad.net/flexiondotorg/minecraft/ubuntu xenial InRelease
Hit:6 http://ppa.launchpad.net/gnome-terminator/ppa/ubuntu xenial InRelease
Hit:7 http://ppa.launchpad.net/ubuntu-mate-dev/welcome/ubuntu xenial InRelease
Hit:8 http://ppa.launchpad.net/ubuntu-pi-flavour-makers/ppa/ubuntu xenial InRelease
Fetched 306 kB in 16s (18.2 kB/s)
Reading package lists…
Reading package lists…
Building dependency tree…
Reading state information…
Calculating upgrade…
The following packages have been kept back:
_ raspberrypi-sys-mods ubuntu-mate-welcome_
The following packages will be upgraded:
_ libssl1.0.0 openssl_
2 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 1,197 kB of archives.
After this operation, 1,024 B of additional disk space will be used.
Get:1 http://ports.ubuntu.com xenial-updates/main armhf libssl1.0.0 armhf 1.0.2g-1ubuntu4.8 [712 kB]
Get:2 http://ports.ubuntu.com xenial-updates/main armhf openssl armhf 1.0.2g-1ubuntu4.8 [485 kB]
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
_dpkg-preconfigure: unable to re-open stdin: _
Fetched 1,197 kB in 1s (927 kB/s)
dpkg: warning: ‘ldconfig’ not found in PATH or not executable
dpkg: warning: ‘start-stop-daemon’ not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root’s PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Sub-process /usr/bin/dpkg returned an error code (2)
Reading package lists…
Building dependency tree…
Reading state information…
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

This has happened two weeks in a row.
Can someone tell me what I am doing wrong in scheduling weekly updates?

2

[quote=“t3kg33k, post:1, topic:13696”]Can someone tell me what I am doing wrong in scheduling weekly updates?[/quote]The log is clearly telling you some things that are wrong and even includes possible solutions:

pkg: warning: 'ldconfig' not found in PATH or not executable
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin

Secondly, I personally would highly advice against doing automated updates with the -y option. Simply because there is the risk of an update causing a dependency issue in installed software. Basically, you’re always going to want to keep an eye on what exactly is updated. To avoid having crucial packages break and your system or at least what you’re using on your system becoming unusable.

And, minor note – the sleeps aren’t really all that necessary. They’re not a bad idea or anything, just not really required. We’re using a journaled filesystem, it’s not going to miss stuff simply because you’re doing back to back update into upgrade.

3

I’m not smart enough to understand what it’s telling me.
I guess what I’m not getting is that if I were to run that script from command line it would run without issues whereas if I schedule it in cron it does not.

4

The key message is:

Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin

It’s unable to execute certain parts of the upgrade process because it cannot find the required executable files as a result of that key message – the PATH variable is not what you want it to be if you want to run that script.

Unless I am horribly mistaken, a fairly simple fix should fix it.

Let’s go back to your original script:

#!/bin/bash

apt-get update
sleep 2
apt-get upgrade -y
sleep 4
apt-get autoremove -y

I’m fairly confident that if you add a single line to it, it will work:

#!/bin/bash
PATH="/usr/local/sbin:/usr/sbin:/sbin:$PATH"
apt-get update
sleep 2
apt-get upgrade -y
sleep 4
apt-get autoremove -y
5

Thanks. I’ll try it out.