Cron Job not running

    • OMV 2.x
    • Must be an environment variable issue. That is something the script or your command would have to fix.
      omv 5.0.14 usul | 64 bit | 5.0 proxmox kernel | omvextrasorg 5.1.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • That is what scheduled jobs basically does. Neither of them set environment variables like logging in.
      omv 5.0.14 usul | 64 bit | 5.0 proxmox kernel | omvextrasorg 5.1.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • 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.
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)
    • tmihai20 wrote:

      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.
      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.

      tmihai20 wrote:

      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.
      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
      omv 5.0.14 usul | 64 bit | 5.0 proxmox kernel | omvextrasorg 5.1.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      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.

      ryecoaaron wrote:

      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).
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)
    • tmihai20 wrote:

      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.
      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?

      tmihai20 wrote:

      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).
      It is the case with the non-interactive shell. I have run into many times but it should only happen on release upgrades. The debian configuration is upgraded during the release upgrade and it gets reset.
      omv 5.0.14 usul | 64 bit | 5.0 proxmox kernel | omvextrasorg 5.1.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      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).
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)
    • tmihai20 wrote:

      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.
      Why? What is good for a human is not always good for a machine. Having two settings is a feature.

      tmihai20 wrote:

      I think this goes back a lot of releases for Debian/Ubuntu.
      bash was user for interactive and non-interactive shells before squeeze.

      tmihai20 wrote:

      I was just thinking that maybe OMV should check what the interactive shell is and not use /bin/sh as a source
      So OMV should use the interactive shell for non-interactive purposes instead of the non-interactive shell? Maybe it could be a setting in the web interface but I disagree that it should use the interactive shell (and I hate dash).
      omv 5.0.14 usul | 64 bit | 5.0 proxmox kernel | omvextrasorg 5.1.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      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.

      ryecoaaron wrote:

      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?

      ryecoaaron wrote:

      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).
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)
    • tmihai20 wrote:

      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?
      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).

      tmihai20 wrote:

      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).
      It isn't forced. You can change it. I gave you the two lines to change it.
      omv 5.0.14 usul | 64 bit | 5.0 proxmox kernel | omvextrasorg 5.1.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      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.
      Riddle me this, riddle me that
      Who is afraid of the big, black bat?
      I write on a blog (Romanian mostly)
      Testing (latest) OMV 4.x on an oDroid H2 (currently with kernel 4.19.x)