Cron Job not running

I still had the issue with the cron jobs created in the GUI not running. It was puzzling that the jobs would run when manually executed from the GUI, but now when they were expected to run. I tried all the tips, even the ones that I found here. I modified the line to be executed to use absolute path to the binaries and not the name of the binary (/bin/chmod and not chmod), the jobs would still not run. I then had the great idea to run the scripts that OMV is creating in /var/lib/openmediavault/cron.d manually and I found that they were exiting with an error. I then realized that /bin/sh (specified in the scripts generated by OMV) is pointing to dash, even though I have specifically configured bash to be the default shell. This is a tiny, but crucial mishap that should be fixed somehow. OMV should generate those scripts using the default shell, not /bin/sh.

I changed the symlink /bin/sh to point to bash and I hope that now my cron jobs in the interface will be running when they are scheduled to. This is probably a Debian issue, but OMV should use the default shell when creating any automatically generated scripts.

Zitat von ryecoaaron

Uh, the default shell of Debian is dash not sh. This is why sh is symlink'd to dash. So, OMV was doing the correct thing.

Yes, I have changed the default shell to bash before doing this, I am always doing this. So, OMV is definitely not doing the right thing. I checked, the default shell was being reported as bash. This is what really puzzled me, /bin/sh was pointing to dash although the default shell was changed to bash.

Zitat von ryecoaaron

See above but I hope you changed the symlink the proper way. Otherwise, it will be reverted on upgrades (debian does this not OMV).
echo "dash dash/sh boolean false" | debconf-set-selections
dpkg-reconfigure dash

As for re-configuring or change being reverted, I hope it will not be the case. There is something fishy somewhere. This is a simple thing that should work out of the box and it is not working for a long time now (since 3.x, if I remember correctly).

Zitat von ryecoaaron

You changed the default interactive shell. The default non-interactive (scripting) shell is whatever /bin/sh is pointing to. It is defined very clearly here - wiki.debian.org/Shell. And since OMV uses /bin/sh, how is OMV doing the wrong thing?

I was expecting that /bin/sh would also be changed to the shell that I chose (different to the default shell). Maybe this is a Debian issue, since Debian did not change what /bin/sh was pointing to after the interactive shell was changed. I think this goes back a lot of releases for Debian/Ubuntu. I will probably change what /bin/sh is pointing to when I will have realized that cron jobs are not running anymore. Anyway, hopefully this will help others with the same issue. I will have confirmation that the issue is fixed only tomorrow.

I was just thinking that maybe OMV should check what the interactive shell is and not use /bin/sh as a source (as /bin/sh will always point to what the distro wants to use by default and not to what the user is actually using). Debugging was a little difficult because I had to run the generated script myself to actually see what was wrong. On any Debian/Ubuntu system, a regular script using /bin/sh and not running properly would have already thrown those issues immediately. I have encountered the issue myself as I am using Linux and some colleagues had the issue after a fresh install or an upgrade (we are using bash as the go-to shell).

Zitat von ryecoaaron

bash was user for interactive and non-interactive shells before squeeze.

I know, but it feels like it has been longer than that. Been using Ubuntu for work since 2011 now.

Zitat von ryecoaaron

So OMV should use the interactive shell for non-interactive purposes instead of the non-interactive shell?

It may be so, but apparently jobs running in the non-interactive shell are not executed successfully because the interactive shell has been changed. Adding a job should work out of the box even if the users change the shell to bash (which a lot of users are doing). Running them manually from the GUI does not yield the error. Do you see my conundrum now?

Zitat von ryecoaaron

and I hate dash

I cannot say I hate dash, but when a tool is causing more problems than it is useful, then I have a problem with that tool (especially if it has been forced by the distro).

Zitat von ryecoaaron

I think I finally see where you are going but I still don't think it is correct. Just because a user changes their login shell and you specify that user for a cron job doesn't mean it should use their login shell to execute the job. Running them manually must be user an interactive shell (didn't look).

Running a cron job manually through the GUI to have it finished successfully beats the whole idea of cron jobs. I am just saying that some people may encounter this because there are guides that tell people to change their login shells to bash. I am doing it manually on all the systems I am using. I have just checked and the cron job has been run successfully.