systemd not able to run some bash scripts

Question

(Update with more info May 16, see end of post for journalctl messages)

I've created a systemd timer and service with the purpose of running a handful of bash scripts. In particular I'm aimed at mounting an external hdd at a given time, then mounting an veracrypt volume, in order to run some offsite backup actions.

Each of the scripts works correctly when run by my own admin user e.g.

sudo /path/to/script.sh

However, some scripts work and some scripts fail when the systemd service runs. Namely, the mount scripts fail, but the unmount script succeeds.

I'm pretty sure this is either a permissions issue, or a run-as-user issue... but I'm new to systemd, and I can't seem to trace it down. I'd rather avoid using systemctl --user mechanisms, since that relies on a special "linger" type that I'm not familar with... but if that's the only solution, I'll take it.

The high level view of the functions is this...

mountup.timer --> mountup.service --> mountup.sh --> mountusb.sh

A similar workflow is in place for the reverse operation

Here's the code...

/etc/systemd.system/mountup.timer

[Unit]
Description=run the mountup.service on a given schedule

[Timer]
Unit=mountup.service
OnCalendar=*-*-* *:00,30:00
#this means any day, month, year any hour... each 00 and 30 minute
Persistent=true

[Install]
WantedBy=timers.target

/etc/systemd/system/mountup.service

[Unit]
Description = Runs the mountup.sh script

[Service]
Type = simple
User = adminuseraccount
ExecStartPre = /bin/bash -c 'echo "systemctl says...mountup service triggered at $(date)"  >> /usr/local/bin/mountlog.txt'
ExecStart = /usr/local/bin/mountup.sh

/usr/local/bin/mountup.sh

#! /bin/bash

# the fancy function below pipes the echo messages through a function that preprends the timestamp, then sends the output to the logfile

logit() {
    while read
    do
        printf "%(%Y-%m-%d %T)T %s\n" -1 "$REPLY"  >> /usr/local/bin/mountlog.txt
    done
}


#the line below redirects standard output to logfile, along with standard error to the same, 
#after routing them through the fancy function above
exec 3>&1 1>> >(logit) 2>&1

echo "mountup.sh says ... starting mountusb.sh..." &&
/usr/local/bin/mountusb.sh && 
echo "mountup.sh says ... mountusb.sh has been run" &&

/usr/local/bin/mountusb.sh

#! /bin/bash
usbuuid=9743y934y943

mount --uuid $usbuuid  /mnt/targetlocation

Many thanks, I've been at this for about 2 weeks, off and on, and it's finally time to throw in the towel and learn what I'm doing wrong.

Edit: relevant output from sudo journalctl for the mountup.service attempt...

Starting Runs the mountup.sh script...
mountup.service: Control process exited, code=exited, status=1/FAILURE
mountup.service: Failed with result 'exit-code'.
Failed to start Runs the mountup.sh script.

relevant output from sudo journalctl for the mountdown.service attempt...

Starting Runs the mountdown.sh script...
Started Runs the mountdown.sh script.
root : PWD=/ ; USER=root ; COMMAND=/usr/bin/umount /mnt/targetlocation
pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
pam_unix(sudo:session): session closed for user root
mountdown.service: Main process exited, code=exited, status=32/n/a
mountdown.service: Failed with result 'exit-code'.

From what I gather, exit code 32 on a umount command simply indicates a failure to unmount a volume, nothing more specific than that.

Answer 1

First, you should set a one-shot service, because your scripts exits when it's done:

[Unit]
Description = Runs the mountup.sh script

[Service]
Type = oneshot
User = adminuseraccount
ExecStart = /usr/local/bin/mountup.sh
RemainAfterExit=true
StandardOutput=journal
StandardError=journal

You can then see the output with journalctl -u mountup.service

With the log in the journal, I would also forgo all the redirection of file handles. Plus, your /usr/local/bin/mountlog.txt needs root access to write to. Generally, it's bad practice to write there. But again, I would not use the redirection at all.

And, because you chain commands with &&, you can think about doing set -e. This way, the script aborts on error. There are caveats to that (mis-contructed if-greps could abort your program for instance), but in your case it looks like a good option.

This is not the solution per se, because we don't see the error, but it should help you on your way.

Also, I think I would put it all in one script. Put an 'exit trap' in it to do sync; umount /foo/bar afterwards, so you're sure that when it's done, you have at least flushed file system buffers and the drive is unmounted. This makes it safe to unplug. The reason I tend to call sync in these situations as well, is in case the umount fails.

About umount failure: if that's your/a problem, you may be keeping the location open, if you cd into it, for instance.