Debian and Docker compose upgrade script

Question

I'm running Debian 12 and Docker compose containers. Once a day, crontab should start the script, but the script should also be called manually. Could you rate my upgrade script file or recommend an alternative approach?

Requirements for the script:

• Debian 12 should be (fully) upgraded
• Docker compose container should be stopped, pulled an updated
• Docker compose should then be restarted automatically
• docker system prune should be called afterward
• If a system reboot is required, the script should reboot
• The normal and error output should be to appear in console AND in an output file
• Between several steps there, should be a time waiting

#!/bin/sh
spath="/home/<...>/<folder>/"
sname="script_all.sh"
if [ $# -eq 0 ]
then
    sh "${spath}${sname}" "arg1" 2>&1 | tee -a "${spath}log_$(date +%F_%T_%N).txt"
    exit
fi
cd $spath || exit
docker compose down
sleep 5
sudo apt update && sudo DEBIAN_FRONTEND=noninteractive apt upgrade -y && sudo apt autoremove -y && sudo apt autoclean
sleep 5
if [ -f /var/run/reboot-required ]
then
        at now + 2 minute -f "${spath}${sname}"
        sudo reboot
else
        docker compose pull
        docker compose build --pull
        docker compose up -d
        sleep 5
        docker system prune -a -f
        docker system df
        sleep 5
        docker stats --no-stream | sort -k 2
fi

Thanks in advance.

Answer 1

shebang

#! /bin/sh

No bash ? Ok, suit yourself. Bash definitely offers more builtin functionality than Bourne shell.

---

uniformly capture errors

cd $spath || exit

I like the sentiment, here. Consider making set -e -o pipefail the second line of this script. Then cd would bail with error status if there's trouble.

If you had run the shellcheck linter, I imagine it would have asked for extra quotes around the spath expansion. Not a problem, here. But you should probably be linting, if this is code you care about.

---

log file

    sh "${spath}${sname}" "arg1" ...

The literal arg1 is odd. You might have helpfully called it logging. But the whole approach is odd, better to avoid it.

You can grab the output of several commands with (cmd_1; ... ; cmd_N) | tee ..., where the commands may span several lines.

Better, package the body of the script as a function, perhaps named upgrade. And then upgrade 2>&1 | tee ... suffices.

---

magic numbers

docker compose down
sleep 5

That 5 tuning parameter makes me nervous. Couldn't we sleep 1 in a while loop that keeps asking docker "is it down yet?", "is it down yet?" Similarly when we're waiting for it to come up.

The apt stuff looks fine. But then, why are we sleeping after it? With no explanatory comment? It's all synchronous, there's nothing going on in the background.

There's a bunch of sudo calls, and maybe that's what you want, for auditing. Consider consolidating them with sudo bash -c " ... "

The now + 2 minute thing is just weird. Is that to give you a chance to manually poke around at the last moment? Reboot at once and be done with it. The larger system is composed of machines + people, and its reliability goes down when people invent mythologies about what's happening at the moment and what will hopefully happen "soon".

        docker system df
        sleep 5

Again, offer a # comment describing why a sleep is required at all, and why 5 is exactly what's needed there. Consider replacing it with a looping test, similar to awaiting docker down / up transitions.