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.