Auto start service fails in b3182

[AndyKF650]

Hi all

I have changed the delay start to 30secs and that had no effect on the restart at reboot, it still does not restart. I still think this is a red herring since the previous version has no issues.

I have put two log files on this message, one following the reboot ...308 and the other ...531 with the stop start routine.

Seems to me that whilst the first log file starts to read the .ini file it stops part the way through, when compared with the completed start up a couple of lines later confirms the .ini file is completely read.

[mcrossley]

I can't replicate this, the service starts OK on both my live and test pi's, and on the pre-built image - I just checked it again on an old pi 2.

[AndyKF650]

Hi Mark

Thanks for trying, I do not know the answer to this problem then.

I have just spent this afternoon rebuilding my RPi from scratch to see if that would help but no chance. As with any rebuild the system requires multiple reboots and none of them resulted in a restart. Always I needed to run the manual start process with sudo mono cumulusmx.exe which did work. Thank goodness for a data logger, even if CMX is not working the Davis console keeps on recording into the meteo-pi.

I have now reverted to the last version which accepts restarts on reboot with no problems. Maybe the problem will not be present in the next version, only you can guess at that one

The above niggles aside I am still really pleased with the software and its display within CUtils.

Keep up the good work.

[sfws]

In your latest post, you say starting MX interactively works, does sudo sytemctl restart Cumulusmx also still work? Both of these are starting MX in isolation from anything else, surely a confirmation that your issue lies with interactions with whatever else is starting at auto start time.
It appears the latest MX build is running for you, when you start it after everything else is running.

Looking at this as an outsider, rebuilding Pi is pointless, you know your Pi is okay for old MX release. I don't think changes to delay settings are sensible until the problem is isolated.

When a computer is rebooted, lots of processes are starting, and examination of syslog is probably needed to see interactions. Presumably, Mark can't reproduce your issue as he doesn't have your collection of services. If you need help with system log, then Freddie may have suggestions on what to look for, whether it is related to network starting or something else. I don't have time to try rebooting and then looking at my system log to make any specific suggestions.

You can stay on old release for now, but that is dodging solving the issue, and speculation about future MX releases is pointless unless the issue is identified.

[AndyKF650]

Hi there

I think I have traced the problem

I am working with the new build 3182 and tested sudo systemctl start cumulusmx.service which works and starts CMX with no problem, similarly with ..stop CMX service and ...restart CMX service. The issue comes with sudo reboot which does not result in a restart.

Further investigation of my set up with is a Davis Pro console connected to a meteo-pi logger through to a RPi model 4B showed that when I started CMX with the sudo mono CumulusMX.exe on a terminal session it started fine but when the terminal session was closed so did CMX.

Also when I rebooted the RPi the data logger appeared not to start completely so I assume that this is where my issue lies. This is all very odd since the hardware has not changed from the last version to this current version but the interaction appears to have changed.

The obvious work around is for me to remember that on RPi reboot I need to start the CMX service rather than relying on the enabled function of the systemctl.

[freddie]

Ah, so are you saying that the data logger is on the Pi?

[AndyKF650]

Hi Freddie

Yes the meteo-pi plugs onto the GPIO pins on the RPi and into the logger slot on the back of the console. A good solution up to now but I am sure I will get used to the lack of restart on reboot.

[freddie]

Not necessarily. If whatever software you are using to interface with the meteo-pi is started as a systemd service then you can make MX wait until that software is ready before starting. Do you know the name of the software used?

[AndyKF650]

Good thought, I have gone back to the suppliers ProData to see if they have a fix. As far as I am aware the software in the meteo pi is not generally accessible so may need a firmware upgrade.

[mcrossley]

The only problem with this theory is that CMX has got nowhere near the code where it starts the station up, that is when it would try and access the logger.

[bburns]

I had a similar situation after reboot with Debian bullseye running on an Intel NUC.
After a system "reboot" the cumulusmx.service failed to successfully start.
However, it would start successfully if I performed a "systemctl restart cumulusmx.service" on the command line after completion of bootup.

I resolved it by adding an "ExecStartPre=" line to delay the "mono" startup after reboot for 10 seconds in the file:
/etc/systemd/system/cumulusmx.service

Here is a listing of the revised file:

[Unit]
Description=CumulusMX service
Documentation=https://cumuluswiki.org/a/Main_Page
Wants=network-online.target
After=network-online.target

[Service]
User=root
Group=root
ExecStartPre=/bin/sleep 10 <<--- NOTE: THIS IS THE ADDED LINE ----->
ExecStart=/usr/bin/mono-service -d:/opt/CumulusMX CumulusMX.exe -service
Type=forking
ExecStopPost=/bin/rm -f /tmp/CumulusMX.exe.lock

[Install]
WantedBy=multi-user.target


Hope this helps...

[AndyKF650]

Hi @bburns

Thanks for the suggestion, it worked perfectly once I removed the insert note.
The systemctl command now stops, starts, restarts and restarts on reboot which is just what I wanted.

Thanks again

[HansR]

Interesting indeed.

[AndyKF650]

Update on this morning's testing.
I changed the delay to 5 seconds and all the systemctl functions worked and sudo reboot resulted in a restart. I also tested the stop and turn off RPi to see if that would restart automatically but this did not happen either with 10 sec or 5 sec delay. However a complete hardware shut down does not happen very often, we have a very stable power supply locally.

So I am now running with a 5sec delay and will run for the foreseeable.