March 4, 201511 yr unRAID OS Version: 6.0b14b (probably all versions with Dynamix) Description: The notification system does not initialize until the user logs into the UI after a reboot (and the .ini files stored in /var/local/emhttp are also not created) How to reproduce: Reboot the system without loading the UI. Expected results: The standard Dynamix boot up emails are sent (disk x has y reallocated sectors, etc) Actual results: No emails arrive Other information: I've let the system sit for 20 minutes, and no notifications arrive (and the files are still not in /var/local/emhttp there prior to loading the UI.) The second that I login to the UI, the files are created, and 10-15 seconds later emails begin to be sent out. I would think that the system would not require an initial login to the UI to get everything up and running for notifications, etc. The easy work around is that on every reboot to simply log into the UI, but why should I be forced to?
March 4, 201511 yr The easy work around is that on every reboot to simply log into the UI, but why should I be forced to? ... and if this is an unattended boot following a power cut, then 'logging in' may not be possible.
March 4, 201511 yr Author ... and if this is an unattended boot following a power cut, then 'logging in' may not be possible. When there's been problems with my server while I'm out of town, I've logged into my desktop remotely so that I can reboot the server for her, but I usually can't be bothered to sit and wait for the system to get up and running and then log into the UI while I'm at work.
March 4, 201511 yr The intention is indeed that notifications start immediately upon reboot. What settings are you using, is all default or did you do some adjustments ?
March 4, 201511 yr Author What settings are you referring to? System notifications: enabled Plugins - check once per day Array status - never send Notifications entity set to all emails (no browser) * Also tried it with browser enabled I noticed it because I'm using your notification system for a custom script. But, the same result happens whether I run the script or not. "Go" modified to wait for the network to be active prior to loading emhttp, and then performs some network mounts my last test was 25 minutes. Nothing happened until I loaded the UI (was running a tail on syslog to confirm)
March 4, 201511 yr What is the archive path, defaults to "/tmp/notifications" or changed to a disk or share location ? I need to look into this. Upon reboot the system checks for the existence of .cron files under /boot/config/plugins and loads them in crontab, this works independently from the GUI. Once in crontab notifications can be generated, but there might be a race condition when they are archived on disk, as this may not be mounted yet.
March 4, 201511 yr Author Its still at /tmp/notifications And nothing in /var/local/emhttp get generated either. Including monitor.ini
March 4, 201511 yr Its still at /tmp/notifications And nothing in /var/local/emhttp get generated either. Including monitor.ini After a reboot can you check and post the content of the file /etc/cron.d/root (it should contain the various cron jobs) ?
March 4, 201511 yr Author You gave me an idea. I'm also adding a cron job in go. I'll try removing it tomorrow and try it again
March 4, 201511 yr Fwiw, I have the same issue. Notifications do not get sent until I log into my web GUI. I have all default settings except I have both browser and email turned on for all options.
March 4, 201511 yr You gave me an idea. I'm also adding a cron job in go. I'll try removing it tomorrow and try it again I noticed this problem as well last night when I rebooted my server to solve some Plex problems. Reboot, no usual emails about disk smart attributes that I've come to expect for about 10 min, then I logged in and recieved the web notice and got an email shortly after. I have a go triggered script that adds a trim for my cache to my daily cron jobs. Do you suspect that making custom changes to cron is what’s causing this issue?
March 4, 201511 yr Author After a reboot can you check and post the content of the file /etc/cron.d/root (it should contain the various cron jobs) ? I disabled adding in my cron jobs, and no change The cronjob list doesn't make a difference whether or not browser is enabled or not. Also, the files in /var/local/emhttp are not being generated root@Server_B:/var/local/emhttp# cat /etc/cron.d/root # Generated system data collection schedule: */1 * * * * /usr/lib/sa/sa1 1 1 &> /dev/null # Generated system monitoring schedule: */1 * * * * /usr/local/sbin/monitor &> /dev/null # Generated parity check schedule: 0 0 1 * * /root/mdcmd check &> /dev/null # Generated plugins version check schedule: 10 0 * * * /usr/local/sbin/plugincheck &> /dev/null Tonight I'll try playing with disabling the various Dynamix plugins (the only other things running on that system) and see if it makes any difference
March 4, 201511 yr I have a go triggered script that adds a trim for my cache to my daily cron jobs. Do you suspect that making custom changes to cron is what’s causing this issue? Well I do not have anything in my GO script that adds anything to cron but I do have various things added to mine... On a side note, could I see what you added to your GO script for daily trim support?
March 4, 201511 yr Author Still doesn't work with NO plugins at all (stock system) root@Server_B:/var/local/emhttp# cat /etc/cron.d/root # Generated system monitoring schedule: */1 * * * * /usr/local/sbin/monitor &> /dev/null # Generated parity check schedule: 0 0 1 * * /root/mdcmd check &> /dev/null # Generated plugins version check schedule: 10 0 * * * /usr/local/sbin/plugincheck &> /dev/null
March 4, 201511 yr Ok, I found the error/reason why notifications do not start upon reboot. The directories need to be created first, which is done when the GUI is opened. As a temporary workaround you can place in your go file the line: /usr/local/sbin/notify init
March 4, 201511 yr Another update ... When opening the webGUI only then the /var/local/emhttp/*.ini files are created by emhttp. Prior to this the monitor (notifications) script fails due to missing files ... unless the webGui is opened at least once. Need some more pondering here !
March 4, 201511 yr Author Another update ... When opening the webGUI only then the /var/local/emhttp/*.ini files are created by emhttp. Prior to this the monitor (notifications) script fails due to missing files ... unless the webGui is opened at least once. Need some more pondering here ! Which is exactly how I noticed the problem. One of my scripts is scraping some info from var.ini and it drove me nuts why it wouldn't work. At least I can scrape the info elsewhere, but var.ini was the easiest place to get it.
March 5, 201511 yr I have a go triggered script that adds a trim for my cache to my daily cron jobs. Do you suspect that making custom changes to cron is what’s causing this issue? Well I do not have anything in my GO script that adds anything to cron but I do have various things added to mine... On a side note, could I see what you added to your GO script for daily trim support? Sure it's actually pretty of simple. First I made a script file with nano (or whatever you want as long as it's set for Linux characters) with the following: #!/bin/bash fstrim -v /mnt/cache | logger Saved it as DailyCacheTrim.sh and made it executable then I put it in a folder I created on the flash (might already exist) /boot/custom Then in the go script I added #Run Trim on Cache cp /boot/custom/DailyCacheTrim.sh /etc/cron.daily You could tweak this some by putting it in a different cron location (monthly etc.)
Archived
This topic is now archived and is closed to further replies.