Watchdog example to warn when station is not reporting for any reason

[Leon Shaner]

Hey, WeeWX'ers.

I've written a watchdog to notify via e-mail if WeeWX is not getting data from the station for any reason.  This is entirely based on weewx log records, so even if weewx has crashed out entirely, you can get notified.

This arose In my case out of a re-occurring issue on Raspberry Pi with my WMR300A, where weewx is generally running fine, but some combination of Raspian USB bug vs. flakey WMR300 firmware bug leads to loss of communication with the station, so records just stop coming in.

In addition to detecting lack of records / weewx crash, the watchdog script also runs wunderfixer periodically.  I haven't figured out why WU is often missing records -- I expect it is WU flakiness in that sometimes wunderfixer reports REST connection issues, and the WU website itself says there is an issue ("dark clouds pass" etc.).

I think WU is often just overwhelmed.  :-/

Since weewx_watchdog is just a script, of course you can tweak it all you need to remove any features that don't apply to you.  =D

Seeking feedback.

And if you need help getting the pre-requisite "mailx" working a la exim4 (default "sendmail" on Raspian), feel free reaching out to me off-alias.

The weewx_watchdog is over here, for now:

https://github.com/UberEclectic/weewx/tree/master/examples/watchdog

Regards,

\Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

[pligg...@gmail.com]

Hi Leon,

could this be used as a complement to Constantine Samaklis script you helped me with yesterday?
Sometimes the wh1080 freezes USB-connection to my raspberry pi but the weewx service is still running so Constantines script wont have any effect in this case?
I think this issue with whxxxx is well known.

BR Mikael

[Leon Shaner]

Hi, Mikael,

My watchdog script could certainly be "complimentary" to Constantine's script, and with minor modifications could potentially replace it.   IIRC, isn't mine at least the third script recently mentioned on the alias to address nearly the same issues?

For sure these scripts shouldn't be necessary, but things happen, and bugs that can be fixed may eventually be fixed, but in the mean-time, I'd rather have a script notify / remediate / workaround issues than keep randomly discovering that my station isn't reporting only hours after it "went offline."   :-/

So, anyway, in my weewx_watchdog script I am merely sending an e-mail notification when the station hasn't reported, but there is an example included (commented out) that initiates a reboot, which is the only remedy I have found for when my WMR300 stops communicating on my RPI.

Instead of the "shutdown -r now" it would be very easy to instead use "systemctl status weewx" to check if the service is running and then "systemctl start weewx" to start it (or "systemctl restart weewx").

With a little more work, I could do a series of remediation steps, like first attempting to restart weewx, then IFF the station still is not reporting, do the reboot the next time.   I didn't bother, because never once ever did a simple restart of weewx fix the USB issues with my WMR300 on RPI.   Also, I didn't bother to check if weewx was running, because my weewx has never actually stopped running.  It's always the USB issue at fault in my case.  :-/

If there is interest I could add a weewx restart remediation and even put some simple toggle's at the top to control which remediation steps are desired, such as restart_weewx vs. reboot_host, and maybe even do the logic to first try one and then the other if both are enabled.   Could put a toggle for whether to do the wunderfixer steps, too.   I'm going to write a separate post about that in a minute.  ;-)

Incidentally, I had to move the script.  It's in its own branch now:

https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog

Regards,

Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pligg...@gmail.com]

Hi,

I now have this script running. 

Indeed this shouldn't be necessary but I've had both issues (Weewx crash and USB issue) so I think these scripts are nice to have in case something goes wrong until these issue are ironed out. Of course we should provide TF with logs from these events.

I still have commented out the settings that initiate a reboot, so I will have to do that manually in that case, for now.

So it's good to have those scripts sending email at errors.

Yes it would be great to have these functions in the same script, with toggle's, so I would appreciate it. Lets see if there are someone else that would like it. 

Well, thank you so far for all help! Learning all the time now :)

BR Mikael

Den onsdag 1 maj 2019 kl. 16:26:33 UTC+2 skrev Leon Shaner:

Hi, Mikael,

My watchdog script could certainly be "complimentary" to Constantine's script, and with minor modifications could potentially replace it.   IIRC, isn't mine at least the third script recently mentioned on the alias to address nearly the same issues?

For sure these scripts shouldn't be necessary, but things happen, and bugs that can be fixed may eventually be fixed, but in the mean-time, I'd rather have a script notify / remediate / workaround issues than keep randomly discovering that my station isn't reporting only hours after it "went offline."   :-/

So, anyway, in my weewx_watchdog script I am merely sending an e-mail notification when the station hasn't reported, but there is an example included (commented out) that initiates a reboot, which is the only remedy I have found for when my WMR300 stops communicating on my RPI.

Instead of the "shutdown -r now" it would be very easy to instead use "systemctl status weewx" to check if the service is running and then "systemctl start weewx" to start it (or "systemctl restart weewx").

With a little more work, I could do a series of remediation steps, like first attempting to restart weewx, then IFF the station still is not reporting, do the reboot the next time.   I didn't bother, because never once ever did a simple restart of weewx fix the USB issues with my WMR300 on RPI.   Also, I didn't bother to check if weewx was running, because my weewx has never actually stopped running.  It's always the USB issue at fault in my case.  :-/

If there is interest I could add a weewx restart remediation and even put some simple toggle's at the top to control which remediation steps are desired, such as restart_weewx vs. reboot_host, and maybe even do the logic to first try one and then the other if both are enabled.   Could put a toggle for whether to do the wunderfixer steps, too.   I'm going to write a separate post about that in a minute.  ;-)

Incidentally, I had to move the script.  It's in its own branch now:

https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog

Regards,

Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

On May 1, 2019, at 4:13 AM, plig...@gmail.com wrote:

Hi Leon,

could this be used as a complement to Constantine Samaklis script you helped me with yesterday?
Sometimes the wh1080 freezes USB-connection to my raspberry pi but the weewx service is still running so Constantines script wont have any effect in this case?
I think this issue with whxxxx is well known.

BR Mikael

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

[Leon Shaner]

Hi, Mikael,

I've added the simple toggles at the top of the script to control remediation actions.

The script will always notify, but the restart weewx and reboot host actions are completely optional and controlled simply by the variables at the top of the script.

If both restart weewx and reboot host actions are enabled, these become nested in that first the restart weewx will be tried one time and if after watchdogsecs the station is still not reporting, then the host reboot will occur.  You can enable one or the other or both.

I also added logic to check if the host was rebooted within 2x watchdog secs to avoid reboot loops.   I strongly recommend not lowering the watchdogsecs below 600 (10 minutes).

It's important to note that my approach isn't actually checking whether the weewx process is running, rather, the loss of communications checking is based on whether weewx has written any records to the database lately. 

You'll find the update over here:

https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog

BTW, if you use my script don't run another kind of weewx restarter script, or they will step on each other.  (Or at least be sure to disable the weewx restart toggle in mine).

Regards,

Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[pligg...@gmail.com]

Hi Leon,

Just installed the updated script now.

Seems to be running fine dispite on thing that occured, see part of log here:

May  2 16:21:08 raspberrypi weewx[2209]: cheetahgenerator: Generated 10 files for report Sofaskin-FW2205-master in 6.93 seconds
May  2 16:21:10 raspberrypi weewx[2209]: imagegenerator: Generated 9 images for Sofaskin-FW2205-master in 1.03 seconds
May  2 16:21:10 raspberrypi weewx[2209]: copygenerator: copied 8 files to /var/www/html/weewx/Sofaskin-FW2205-master
May  2 16:21:10 raspberrypi weewx[2209]: GaugeGenerator: Generated 6 images for Bootstrap in 0.55 seconds
May  2 16:21:10 raspberrypi weewx[2209]: historygenerator.pyc: Generated 9 tables in 0.18 seconds
May  2 16:21:13 raspberrypi weewx[2209]: cheetahgenerator: Generated 10 files for report Bootstrap in 2.86 seconds
May  2 16:21:13 raspberrypi weewx[2209]: copygenerator: copied 3 files to /var/www/html/weewx/Bootstrap
May  2 16:21:17 raspberrypi weewx[2209]: cheetahgenerator: Generated 6 files for report Bjurdammen in 4.13 seconds
May  2 16:21:17 raspberrypi weewx[2209]: copygenerator: copied 3 files to /var/www/html/weewx/Bjurdammen
May  2 16:21:19 raspberrypi weewx[2209]: cheetahgenerator: Generated 6 files for report SeasonsReport in 1.46 seconds
May  2 16:21:19 raspberrypi weewx[2209]: copygenerator: copied 3 files to /var/www/html/weewx
May  2 16:22:28 raspberrypi vncserver-x11[438]: Connections: rejecting blacklisted connection: 217.61.106.100
May  2 16:27:01 raspberrypi CRON[2616]: (root) CMD (/var/www/html/scripts/Watchdog/weewx_watchdog2)
May  2 16:29:14 raspberrypi crontab[2636]: (root) BEGIN EDIT (root)
May  2 16:29:24 raspberrypi crontab[2636]: (root) REPLACE (root)
May  2 16:29:24 raspberrypi crontab[2636]: (root) END EDIT (root)
May  2 16:29:41 raspberrypi systemd[1]: Stopping LSB: weewx weather system...
May  2 16:29:41 raspberrypi weewx[2209]: engine: Main loop exiting. Shutting engine down.
May  2 16:29:41 raspberrypi weewx[2209]: engine: Shutting down StdReport thread
May  2 16:29:41 raspberrypi weewx[2209]: engine: Terminating weewx version 3.9.1
May  2 16:29:46 raspberrypi weewx[2683]: Stopping weewx weather system: weewx..
May  2 16:29:46 raspberrypi systemd[1]: Stopped LSB: weewx weather system.
May  2 16:30:01 raspberrypi cron[304]: (root) RELOAD (crontabs/root)
May  2 16:30:01 raspberrypi CRON[2727]: (pliggen) CMD (/usr/bin/php7.0 /var/www/html/weewx/smhi_warnings_bjurdammen.php > /dev/null 2>&1)
May  2 16:31:01 raspberrypi CRON[2741]: (root) CMD (/var/www/html/scripts/Watchdog/weewx_watchdog2)
May  2 16:31:01 raspberrypi root[2748]: weewx_watchdog: 661 seconds have passed since weewx logged any records!
May  2 16:31:01 raspberrypi root[2759]: weewx_watchdog: 1556807461 seconds have passed since weewx logged any records!  Rebooting!
May  2 16:31:17 raspberrypi systemd-modules-load[85]: Inserted module 'i2c_dev'
May  2 16:31:17 raspberrypi fake-hwclock[88]: tor  2 maj 2019 14:31:15 UTC

I stopped weewx via service weewx stop.

Then I had the script to run by cronjob.

It first tried to restart and wrote that 661 seconds have passed since weewx logged any records, and that is correct, I have it set to archive_interval = 600 in weewx.conf. Or should I change this time?

the the script wrote that 1556807461 seconds have passed since weewx logged any records! Rebooting!

Is this correct behavior? Because weewx logged 660 seconds erlier...

Thanks for the update and I will continue to try it and hope to have it running :)

BR Mikael

Den torsdag 2 maj 2019 kl. 06:35:20 UTC+2 skrev Leon Shaner:

Hi, Mikael,

I've added the simple toggles at the top of the script to control remediation actions.

The script will always notify, but the restart weewx and reboot host actions are completely optional and controlled simply by the variables at the top of the script.

If both restart weewx and reboot host actions are enabled, these become nested in that first the restart weewx will be tried one time and if after watchdogsecs the station is still not reporting, then the host reboot will occur.  You can enable one or the other or both.

I also added logic to check if the host was rebooted within 2x watchdog secs to avoid reboot loops.   I strongly recommend not lowering the watchdogsecs below 600 (10 minutes).

It's important to note that my approach isn't actually checking whether the weewx process is running, rather, the loss of communications checking is based on whether weewx has written any records to the database lately. 

You'll find the update over here:

https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog

BTW, if you use my script don't run another kind of weewx restarter script, or they will step on each other.  (Or at least be sure to disable the weewx restart toggle in mine).

Regards,

Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

[Leon Shaner]

Hey, Mikael,

Nice catch.  That message about 1556807461 seconds is a left-over from the earlier version.  It is not only redundant, but also incorrect, due to what amounts to re-use of an earlier variable.  :S   I have removed it.

https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog

Your weewx.conf archive interval of 600 seconds is not really a problem, it's up to you what to put there, but in that case you probably want to increase my watchdogsecs by a factor that approximates how long it takes your system to boot and for weewx to post the first record.  My RPI boots in under a minute, so if yours is similar, even watchdogsecs=660 should suffice.

Hmm.  Maybe longer.  Please check your syslog and see if you can approximate how long after a reboot it takes before this type of message to appear from weewx:

weewx[9809]: manager: Added record 2019-05-02 06:24:00 EDT (1556792640) to database

To your next questions...

It isn't 100% clear to me which way you have the toggles set.

Did you ultimately enable both remediation actions steps, before seeing the erroneous message?

doweewxrestart=1

dohostreboot=1

Even that erroneous message shouldn't have appeared unless you have dohostreboot=1 but you are mentioning mainly that you tried the doweewxrestart=1  first.  Not sure if you mean that after trying the restart option you then went on to also try the dohostreboot=1 and saw the erroneous message?

Just want to be sure, because the logic is the most important thing, and I did test that extensively.  =D

I didn't notice the erroneous message because it only goes to syslog and I was mainly watching the more interesting log in the case of weewx_watchdog, which is at /var/log/weewx.log.  Would be helpful to see that log if there are any other issues.

Cheers! =D

\Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

Regards,

Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[pligg...@gmail.com]

Hi Leon,

Ok, good to hear that it was a left-over and that you updated it!

I did a reboot of the system and found that it took aprox. 2min to get the first "added" message from weewx, so I set the watchdogsecs to 720. Would that be ok? What could happen if the time is set to early och to late?

I had toogled them both to 1 at the same time.

Here's the part of var/log/weewx.log when it occured:

tor  2 maj 2019 15:45:06 CEST Missing records:
tor  2 maj 2019 15:45:06 CEST 2019-05-02 12:37:05 CEST (1556793425); 29.224";  47.1F;  65%; 3.8 mph; 135 deg; 5.4 mph gust;  36.0F;  N/A  rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 12:47:05 CEST (1556794025); 29.231";  46.6F;  63%; 6.0 mph; 225 deg; 7.6 mph gust;  34.7F; 0.00" rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 13:16:53 CEST (1556795813); 29.231";  48.2F;  57%;10.7 mph;  45 deg;14.5 mph gust;  33.7F;  N/A  rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 13:36:47 CEST (1556797007); 29.240";  48.2F;  51%; 8.3 mph; 315 deg; 9.8 mph gust;  30.9F;  N/A  rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 13:46:47 CEST (1556797607); 29.241";  48.0F;  51%; 5.4 mph; 225 deg; 7.6 mph gust;  30.8F; 0.00" rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 14:17:05 CEST (1556799425); 29.251";  49.3F;  45%; 3.8 mph;   0 deg; 6.0 mph gust;  28.8F;  N/A  rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 14:37:05 CEST (1556800625); 29.249";  50.0F;  44%; 3.1 mph; 270 deg; 6.9 mph gust;  29.0F;  N/A  rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 14:47:05 CEST (1556801225); 29.248";  49.3F;  43%; 6.0 mph;   0 deg; 8.3 mph gust;  27.7F; 0.00" rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 15:17:00 CEST (1556803020); 29.244";  51.3F;  41%; 2.2 mph; 315 deg; 3.8 mph gust;  28.4F;  N/A  rain  ...published.
tor  2 maj 2019 15:45:06 CEST 2019-05-02 15:40:00 CEST (1556804400); 29.247";  51.5F;  40%; 5.4 mph; 267 deg;10.7 mph gust;  28.0F; 0.00" rain  ...published.
tor  2 maj 2019 16:12:01 CEST WeeWX: Watchdog warning notification sent to xxx...@xxxxxx.xxx
tor  2 maj 2019 16:12:01 CEST WeeWX: Watchdog Restart event timestamp: (1556806321)
tor  2 maj 2019 16:12:01 CEST WeeWX: Watchdog Stop message: Stopping weewx (via systemctl): weewx.service.
tor  2 maj 2019 16:12:01 CEST WeeWX: Watchdog Start message: Restarting weewx (via systemctl): weewx.service.
tor  2 maj 2019 16:31:01 CEST WeeWX: Watchdog warning notification sent to xxx...@xxxxxx.xxx
tor  2 maj 2019 16:31:01 CEST WeeWX: Watchdog Restart was NOT attempted (last restart was too recent).
tor  2 maj 2019 16:31:01 CEST WeeWX: Watchdog REBOOT event timestamp: (1556807461)
tor  2 maj 2019 16:31:01 CEST WeeWX: Watchdog REBOOT notification sent to xxx...@xxxxxx.xxx and REBOOT initiated.
tor  2 maj 2019 16:39:01 CEST WeeWX: Watchdog warning notification sent to xxx...@xxxxxx.xxx
tor  2 maj 2019 16:39:01 CEST WeeWX: Watchdog Restart event timestamp: (1556807941)
tor  2 maj 2019 16:39:01 CEST WeeWX: Watchdog Stop message: Stopping weewx (via systemctl): weewx.service.
tor  2 maj 2019 16:39:01 CEST WeeWX: Watchdog Start message: Restarting weewx (via systemctl): weewx.service.
tor  2 maj 2019 17:12:02 CEST WeeWX: Watchdog warning notification sent to xxx...@xxxxxx.xxx
tor  2 maj 2019 17:12:02 CEST WeeWX: Watchdog Restart event timestamp: (1556809922)
tor  2 maj 2019 17:12:02 CEST WeeWX: Watchdog Stop message: Stopping weewx (via systemctl): weewx.service.
tor  2 maj 2019 17:12:02 CEST WeeWX: Watchdog Start message: Restarting weewx (via systemctl): weewx.service.

Hope that helps!

And let me know if you need som more info or log from my system, and I'll try to help out :)

I have the new script running now and will update how it goes.

Is it possible to send the email from watchdog some other way and not with mailx? 

In constantines script i got the mail sent, but not in your script, oh well I get a mail that says:

"/var/www/html/scripts/Watchdog/weewx_watchdog2: rad 101: mailx: kommandot finns inte (no such command)

/var/www/html/scripts/Watchdog/weewx_watchdog2: rad 120: mailx: kommandot finns inte (no such command)

So maybe the mail works but there something else wrong? :/

Btw, one off topic question, could you explain to me how I can make my USB-stick auto-mount when the system makes a auto reboot?

I usually run this command "sudo mount /dev/sda3 /backup", but when the reboot is unattended this is not mounted until I run the command.

BR Mikael / noob =D

Den torsdag 2 maj 2019 kl. 17:55:04 UTC+2 skrev Leon Shaner:

Hey, Mikael,

Nice catch.  That message about 1556807461 seconds is a left-over from the earlier version.  It is not only redundant, but also incorrect, due to what amounts to re-use of an earlier variable.  :S   I have removed it.

https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog

Your weewx.conf archive interval of 600 seconds is not really a problem, it's up to you what to put there, but in that case you probably want to increase my watchdogsecs by a factor that approximates how long it takes your system to boot and for weewx to post the first record.  My RPI boots in under a minute, so if yours is similar, even watchdogsecs=660 should suffice.

Hmm.  Maybe longer.  Please check your syslog and see if you can approximate how long after a reboot it takes before this type of message to appear from weewx:

weewx[9809]: manager: Added record 2019-05-02 06:24:00 EDT (1556792640) to database

To your next questions...

It isn't 100% clear to me which way you have the toggles set.

Did you ultimately enable both remediation actions steps, before seeing the erroneous message?

doweewxrestart=1

dohostreboot=1

Even that erroneous message shouldn't have appeared unless you have dohostreboot=1 but you are mentioning mainly that you tried the doweewxrestart=1  first.  Not sure if you mean that after trying the restart option you then went on to also try the dohostreboot=1 and saw the erroneous message?

Just want to be sure, because the logic is the most important thing, and I did test that extensively.  =D

I didn't notice the erroneous message because it only goes to syslog and I was mainly watching the more interesting log in the case of weewx_watchdog, which is at /var/log/weewx.log.  Would be helpful to see that log if there are any other issues.

Cheers! =D

\Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

Regards,

Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

[Leon Shaner]

Mikael,

I would say watchdogsecs=720 is more than conservative.  It is just to catch a case where loss of comms happens very close to the cron execution and another cron event fires just before your first record is posted after a reboot.  Even that seems unlikely because the cron interval aligns with the reboot and you should have a record within 2 mins after that.  So 720 will always be fine, but even 600 should almost always be fine.  I'd have to think a lot harder for a definite case where exactly 600 would cause a problem.  Rare to never, most likely.

As for mailx it would get pretty complicated if I had to add support for lots of different mail utilities, none of which agree on the arguments or how to pass the body.

It's kinda the point of mailx, to abstract away from whatever is happening underneath.

Easier for me to just to recommend:

$ sudo apt-get install mailutils

=D

See if that's enough for you and I can add it to the readme.  =D

I can put a check for it in the script, too.  =D

About the USB auto mount, I expect there is a media manager package tied to the graphical login on the RPI.   If you are running without the graphical login, there may be other options.  I will do some research and contact you off alias.

Regards,

\Leon

--

Leon Shaner :: Dearborn, Michigan (iPhone)

Regards,

Leon

--

Leon Shaner :: Dearborn, Michigan (iPhone)

https://twitter.com/AEtherZcythe

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

[pligg...@gmail.com]

Hi Leon,

Ok I will stick with 720 watchdogsecs, and today I have stopped weewx service several times just to see if the script starts the service again, and it did everytime! 

One time it did a reboot and that was because it directly stopped weewx after a restart of weewx before it had reached the archive time so no new post was made and your script did a reboot as intended, right I suppose?

Installed mailutils and now the mail works :)

For people like me it's great to have setup instructions as describing as possible so yes, put it in the readme and maybe also a in the script.

So I will now let it run as it is and I will get back here if something happens that seems to be wrong, and hopefully the script will have nothing to do as Weewx are running fine now!

Also, thanks for looking in to the usb question I had, and we'll see if you find something that can manage that. 

Again, great to have people like you here to help out :)

BR Mikael

Den fredag 3 maj 2019 kl. 00:43:42 UTC+2 skrev Leon Shaner:

Mikael,

I would say watchdogsecs=720 is more than conservative.  It is just to catch a case where loss of comms happens very close to the cron execution and another cron event fires just before your first record is posted after a reboot.  Even that seems unlikely because the cron interval aligns with the reboot and you should have a record within 2 mins after that.  So 720 will always be fine, but even 600 should almost always be fine.  I'd have to think a lot harder for a definite case where exactly 600 would cause a problem.  Rare to never, most likely.

As for mailx it would get pretty complicated if I had to add support for lots of different mail utilities, none of which agree on the arguments or how to pass the body.

It's kinda the point of mailx, to abstract away from whatever is happening underneath.

Easier for me to just to recommend:

$ sudo apt-get install mailutils

=D

See if that's enough for you and I can add it to the readme.  =D

I can put a check for it in the script, too.  =D

About the USB auto mount, I expect there is a media manager package tied to the graphical login on the RPI.   If you are running without the graphical login, there may be other options.  I will do some research and contact you off alias.

Regards,

\Leon

--

Leon Shaner :: Dearborn, Michigan (iPhone)

Regards,

Leon

--

Leon Shaner :: Dearborn, Michigan (iPhone)

https://twitter.com/AEtherZcythe

[Leon Shaner]

Hey, Mikael,

If I am understanding what you did, yes it sounds like you've proven my logic works correctly.  You're a good tester! =D  Thanks!  =D

The question about RPI and usb automount w/out graphical login is off-topic, but to close that out, try the following, and if you get stuck, contact me directly (off-alias).

Firstly, if you will ever use the graphical login on your RPI, you will want to disable the built-in File Manager feature that auto-mounts USB drives, or it will likely conflict with the usbmount / system service way.  You can still use File Manager to access drives that get mounted by the system (independent of the graphical login).

Go to the RPI menu -> Accessories -> File Manager

In File Manager, go to Edit -> Preferences -> Volume Management

Disable all three "auto-mount" options and click CLOSE.

Now for the actual instructions.  =D

How to use the usbmount utility + system service to automatically mount USB drives on RPI:

1) If you have already mounted the USB drive manually, then umount and DISCONNECT it now.

2)  Install the usbmount package:

$ sudo apt-get install usbmount

3) OPTIONAL step...

If you are using FLASH storage (like a basic USB thumb-drive) you probably want to disable the "sync" option in /etc/usbmount/usbmount.conf -- see the comments there, about why...

The default settings are as follows:

MOUNTOPTIONS="sync,noexec,nodev,noatime,nodiratime"

For FLASH drives, remove the sync part as follows:

MOUNTOPTIONS="noexec,nodev,noatime,nodiratime"

In that case, keep in mind NEVER just yank the USB cable out without first syncing and umounting, or use the "pumount" command to handle both in one step without the need of root/sudo.

Always use "pumount /media/usbN" (as a regular user) and it will automatically do a "sync" and will then umount the drive safely.

HINT:  /media/usbN is just an example, use whatever the "mount" command shows for the desired device

If you need to make the above change mentioned, use the following method:

$ sudoedit /etc/usbmount/usbmount.conf

Either way, to continue with the usbmount installation...

4)  Edit the systemd-udevd service control file and change:

MountFlags=slave

to

MountFlags=shared

Make the change using the following method:

$ sudoedit /lib/systemd/system/systemd-udevd.service

5)  Reload the systemd-udevd service for the above changes to take effect:

$ sudo systemctl daemon-reload

$ sudo systemctl restart systemd-udevd

6)  Plug in your USB drive, and look for it under the following (most likely) path:

/media/usb0

It could be /dev/usb1, etc.   You can always use the following command after connecting a drive to find the path:

$ grep /media/usb /var/log/syslog

Remember, if you are using FLASH storage and you disabled "sync" in the usbmount.conf, then...

Always use "pumount /media/usbN" (as a regular user) and it will automatically do a "sync" and will then umount the drive safely.

HINT:  /media/usbN is just an example, use whatever the "mount" command shows for the desired device

NOTE:  The pumount also accepts the sd?N device name, such as sdb1 instead of /media/usbN.  Again check "mount" listing for /media devices so you know which one to use with pumount before disconnecting a drive.

Regards,

\Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.