Schedule job works when run manually, fails at scheduled time

flvinny521 · 20. August 2019

Recently, I began using a third-party SnapRAID script in place of the one packaged with the SnapRAID plugin. I used this on its own, called at 2AM through a Scheduled Job, for a week or so, until it began failing due to not having enough available memory. I realized that shutting down all my Docker containers freed up sufficient memory for the script to run, so I am now attempting to automate the whole process.

I have created a "master" script that executes three individual scripts to shut down all Docker containers, then run the SnapRAID script, and finally, to start the Docker containers again. I added a Scheduled Job to run this master script at 3AM every day. When I test it by running manually from the Scheduled Job tab, all three scripts are called in order and I receive output indicating successful completion of the process. However, at 3AM, I receive an email with the error message:

/var/lib/openmediavault/cron.d/userdefined-b5b64375-44ac-49f9-8c7f-b498c412336d: 4: /var/lib/openmediavault/cron.d/userdefined-b5b64375-44ac-49f9-8c7f-b498c412336d: /usr/sbin/ratsscript.sh: not found

Attached are the scripts: master (ratsscript.sh), shut down Docker (ratsscript1.sh), run SnapRAID (snapScript.sh, not my script), and start Docker (ratsscript2.sh). I am absolutely a Linux beginner and probably overlooked something simple. Any guidance would be appreciated. (Added .txt extensions to allow upload here).

Edit: Pasting my scripts here -

https://pastebin.com/kgs7kd9V (master)

https://pastebin.com/8mW02Uhy (script 1)

https://pastebin.com/G3rjgWpc (script 2)

Adoby · 21. August 2019

Where are the script when you try to have them execute automatically?

In the scripts it is specified that they are in /usr/bin. And the error message seems to imply that some is in /usr/sbin.

/usr/bin seem like an unlikely place for the scripts. As do /usr/sbin. Perhaps you have not specified any path at all and then /usr/sbin is used in the error message?

I would assume that the scripts run as root and are located in /root? Or possibly somewhere like /usr/local/bin. Then that path should be used/specified instead.

I don't use schedule jobs in OMV, so I'm afraid that I can't help you with details. But it seems that paths are missing or wrong.

Another common problem in this area is that wrong user is set to run the script or it is stored in a location (data drive) where scripts are not allowed to be executed, noexec set in fstab.

But from the error message and the scripts it *seems* to only be the paths that are wrong in your case.

I edit /etc/crontab directly. That is a method that is general for any(?) Linux system, not only a OMV-system. But then you have to get down and dirty using SSH and an editor.

flvinny521 · 22. August 2019

@Adoby, thanks for taking the time to respond. All of the scripts are located in /usr/sbin. I just looked again and didn't notice any reference to /usr/bin, if you could point that out I will correct it. To be honest, I don't know anything about the "proper" location for scripts so I just put them in the location of the SnapRaid plugin's script (that I am not currently using). The Scheduled job is set up as:

It appears that OMV takes this information and automatically adds an entry in the cron.d file mentioned in the error message. The contents of that file are:

Bash

#!/bin/sh -l
# This configuration file is auto-generated.
# WARNING: Do not edit this file, your changes will be lost.
/usr/sbin/ratsscript.sh

I have no problem using the command line via SSH, but I prefer to use OMV built-in features whenever possible since I know the OS can overwrite certain config files. Also, since everything is located on the OS drive, there should be no issues with running from a non-executable location. As I mentioned, if I manually run the script from the Scheduled Job tab, everything works perfectly fine. I just can't figure out why cron can't locate the file when it is clearly located in the correct place and is executable.

Code

rats@ratsvault:/$ find /usr/sbin -name "rats*"
/usr/sbin/ratsscript1.sh
/usr/sbin/ratsscript.sh
/usr/sbin/ratsscript2.sh
rats@ratsvault:/$

Adoby · 22. August 2019

I think I saw /usr/bin in one of the snapraid scripts, not relevant.

I do something very similar, for my backups, but directly in the OS, not in OMV.

I have all my scripts on the OMV backup server, in the same folder as where I store the snapshots. And I don't run the scripts directly but instead run bash with the scripts as a parameter. And the scripts are run as a normal user, not root. nas0 is backed up on nas1.

Here is my "master" script that runs all the backup scripts.

Code: nas1::/sharedfolders/nas1/snapshots/all.sh

#!/usr/bin/env bash


for f in *_snapshot.sh; do
    bash "$f"
done

And then, in the same folder, I have the actual backup scripts that updates snapshots of the remote folders shared on nas0 to nas1:

download_snapshot.sh
local_media_snapshot.sh
shared_media_snapshot.sh

And there is the line in /etc/crontab that start all.sh every night at 03:00.

0 3 * * * adoby cd /sharedfolders/nas1/snapshots && /bin/bash all.sh

As you can see it first cd to the snapshot folder, then it run /bin/bash that in turn run all.sh that is in that folder.

This works fine and is completely ignored by OMV. I do exactly the same to backup nas2 on nas3 and nas4 on nas5, all run OMV.

You could perhaps imitate the "trick" of first doing a cd into the folder holding the scripts and running /bin/bash with the scripts as an argument. That might help.

flvinny521 · 23. August 2019

Thank you, @Adoby. I was able to get the script working using your trick.

At 3 AM, snapcript is run as root using this command:

cd /usr/sbin && /bin/bash ratsscript.sh

And then ratsscript.sh looks like this (may be overkill, but it works for me):

Code

cd /usr/sbin && /bin/bash ratsscript1.sh


cd /usr/sbin && /bin/bash snapscript.sh


cd /usr/sbin && /bin/bash ratsscript2.sh

Jetzt mitmachen!