Description:

 

When booting unRaid in Safe Mode, the update_cron script is still being executed.  This can have undesired effects by spamming the syslog with cron errors, sending out multitudes of emails, and even possibly executing scripts present on the flash drive, etc.

 

How to reproduce:

Install any plugin that has a .cron file on the flash drive then reboot into safe mode

cat /etc/cron.d/root

 

Expected results:

No entries should be present other than the system cron entries

 

Actual results:

All .cron files on the flash drive are parsed

 

Other information:

IMHO the best solution is to simply disable the update_cron script if the system is running in safe mode (or only have it scan /boot/config/dynamix system folders).  While this may have undesired effects should the user install a plugin while in safe mode, I think that its reasonable for a user to expect that while in safe mode certain features of plugins will not work should they be installed.   Probably a banner on the plugin tab should appear when in safe mode

 

Edited March 2, 20179 yr by Squid

This is a design flaw having cron entries stored on the flash device.

3 hours ago, limetech said:

This is a design flaw having cron entries stored on the flash device.

Except we can't really store it anywhere else can we? Probably need an environment variable for safe mode... or do we already have that?

4 minutes ago, ken-ji said:

Except we can't really store it anywhere else can we? Probably need an environment variable for safe mode... or do we already have that?

The webUI knows that its in safe mode (it says so).  Just takes update_cron to check that its in safe mode, and then either return not doing anything, or only process the base system config folders for .cron entries   

Ok we can change update_cron to use the basename of the symlinks in /var/log/plugins to generate the list of directories in /boot/config/plugins to search for cron entries.

Speaking of Safe Mode ... I'd like to add the characteristic that array will not auto-Start if set to do so.  Meaning, it won't change the config setting but instead override it.  This way it gives a user opportunity to Start in Maintenance mode, e.g., to do device file system checks.  Anyone see a problem with this?

15 minutes ago, limetech said:

Speaking of Safe Mode ... I'd like to add the characteristic that array will not auto-Start if set to do so.  Meaning, it won't change the config setting but instead override it.  This way it gives a user opportunity to Start in Maintenance mode, e.g., to do device file system checks.  Anyone see a problem with this?

Sounds like a good idea to me.

5 hours ago, limetech said:

Speaking of Safe Mode ... I'd like to add the characteristic that array will not auto-Start if set to do so.  Meaning, it won't change the config setting but instead override it.  This way it gives a user opportunity to Start in Maintenance mode, e.g., to do device file system checks.  Anyone see a problem with this?

 

On 3/3/2017 at 6:35 AM, limetech said:

Ok we can change update_cron to use the basename of the symlinks in /var/log/plugins to generate the list of directories in /boot/config/plugins to search for cron entries.

 

Alternatively you can change update_cron to read only from the 'dynamix' subfolder to do selective enabling of cron entries in safe mode.

 

6 hours ago, Squid said:

 

 

I agree that safe mode should be expanded with not starting of Dockers and VMs too. As Squid suggests, it can be considered to have different safe mode choices to do more selective enabling/disabling of plugins, dockers and VMs.

5 hours ago, bonienl said:

 

I agree that safe mode should be expanded with not starting of Dockers and VMs too. As Squid suggests, it can be considered to have different safe mode choices to do more selective enabling/disabling of plugins, dockers and VMs.

I don't think you really need to complicate the boot menu with multiple SAFE modes. Just don't start anything and the user can go from there to start or install whatever. Might be good to disable auto start of any containers so the user could start the docker service and then deal with the containers one at a time.

What about keeping the current Safe Mode option, but without starting the array as was suggested, then add a second Start button ...  One Start would be Start Full, which is the normal full startup.  The second would be a Start Safe or Start Clean, which starts the array but does not start any plugins, Dockers, or VM's.  That could be very useful for troubleshooting, the ability to on-the-fly switch between them, after a stop.  It would be nice to have that option whether the system had booted into a full Safe Mode or not.

On 3/3/2017 at 12:35 AM, limetech said:

Ok we can change update_cron to use the basename of the symlinks in /var/log/plugins to generate the list of directories in /boot/config/plugins to search for cron entries.

FYI, this behavior of all .cron entries being parsed is still happening on 6.4.0  At the very least, this defect throws a bunch of errors in the syslog.  At worst, undesired behaviour can happen should the .cron entry refer to commands / scripts that happen to be built-in.

 

Starting my server in safe mode, 

root@Server_A:/usr/local/sbin# ls /var/log/plugins
unRAIDServer.plg@

root@Server_A:/usr/local/sbin# cat /etc/cron.d/root
# Generated cron settings for docker autoupdates
0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1
# Generated cron settings for plugin autoupdates
0 1 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1
# Generated file integrity check schedule:
10 0 * * 0 /boot/config/plugins/dynamix.file.integrity/integrity-check.sh &> /dev/null

# Generated local master browser check:
*/1 * * * * /usr/local/emhttp/plugins/dynamix.local.master/scripts/localmaster &> /dev/null

# Generated ssd trim schedule:
0 1 * * * /sbin/fstrim -a -v | logger &> /dev/null

# Generated system data collection schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null

# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
0 3 * * * /usr/local/sbin/mover |& logger

# Generated parity check schedule:
0 0 * * 0 [[ $(date +%e) -le 7 ]] && /usr/local/sbin/mdcmd check  &> /dev/null

# Generated unRAID OS update check schedule:
11 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null

 

Edited January 14, 20188 yr by Squid

Weird, cause update_cron seems right.

cron_files() {
  plugins=("/var/log/plugins/*.plg")
  plugins=("${plugins[@]##*/}")
  plugins=("${plugins[@]%.*}")
  for plugin in "${plugins[@]}" ; do
    cat /boot/config/plugins/$plugin/*.cron 2> /dev/null
  done
}

 

Yeah, I hate bash and trying to work my way through it.  (If the file was available on GitHub, I'd just switch it to PHP that would work and be understandable) The first line does give the correct installed plugins.

/var/log/plugins/unRAIDServer.plg

The second line gets rid of the basename

*.plg

But the contents of $plugin during the loop is:

create_network_ini diagnostics emhttp emhttp_event emhttpd in_use inet installplg installzip mdcmd mount_image move mover newperms plugin powerdown publish qemu samba set_ncq shfs update_cron zenstates

 

The intention is good but the execution is bad

 

I've made a update. Thanks

1 minute ago, bonienl said:

The intention is good but the execution is bad

 

I've made a update. Thanks

Must be nice to have access to files that us mere mortals do not  

This will get into next point release.