Auto start service fails in b3182

[AndyKF650]

Hi Mark

Last week when the new build was released I mentioned that the auto start using sudo reboot appeared to have stopped working on the new build. I have spent some time trying to get it to function at all, to no avail. The 'sudo systemctl stop cumulusmx' instruction to get the service to stop works fine as does the corresponding start instruction. When I look at the service status it is 'enabled' so a restart on reboot should work.

I looked at the .service instruction and how it was loaded on my RPi and tweaked it about but I could not get MX to load from a reboot. All this work was on the build 3182.

Today I had another look at the problem and reloaded the previous build 3173 with my current data and checked how the .service functioned. The stop/start worked as expected and CMX loaded just fine, the next check was a stop CMX and reboot and this worked as expected with CMX auto starting .

Looking at the forum it does not seem to be a generally reported problem, is it just me? From my previous post on this issue, the log file showed a partial load of CMX and no further action.

Any thoughts on this issue?

[freddie]

I use restart on reboot and it works okay for me. What hardware are you using?

[AndyKF650]

My system is a RPi 4 model B with running Raspbian bullseye.

[freddie]

Okay, I'm running in an LXC container on Ubuntu 20.04. My unit file looks like this:

Code: Select all

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

[Service]
User=root
Group=root
ExecStart=/usr/bin/mono-service -d:/opt/CumulusMX CumulusMX.exe -service
Type=forking
ExecStopPost=/bin/rm /tmp/CumulusMX.exe.lock

[Install]
WantedBy=multi-user.target

Is yours similar?

As your problem only happens on reboot then I'm advancing that it may be down to an "After" or "Wants" statement in your unit file that isn't being satisfied particularly quickly on reboot. I'm assuming you have an "After" or "Wants" for the network being up? Perhaps you could use the delay function in MX to give it a bit more time? Settings -> Program Settings -> Start-up Options -> Start-up delay (secs).

[AndyKF650]

Hi Freddie

Thanks for your response, looking at my unit file it is very similar to yours but has a "Wants=network-online.target" instruction line which is the same as the basic MXutils linux code.

I will take out the "Wants" line and see just what happens.

[AndyKF650]

Hi Freddie

Well that was a fail, it still will not restart on reboot

[freddie]

Hi Freddie

Well that was a fail, it still will not restart on reboot

Have you tried the suggestion about a delay on MX starting up?

[AndyKF650]

Not yet, it is odd that this needs to be set since I have not previously needed a startup delay.

So should the delay be 5 10 secs or much longer?

[AndyKF650]

I tried 5 secs and the restart on reboot did not function but the systemctl stop/start works without issues.

[freddie]

I use 30 seconds. This isn't because MX specifically needs the network but more to do with the fact that MX stores "0" realtime values from my GW1100 if nothing is available from the GW1100. So I force it to wait those 30 seconds such that data is more likely to be available from the GW1100, and I have less editing out of the erroneous realtime values from my database table.

I don't know whether, if I remove my delay, I would get the same failure as you on reboot. I haven't tried it.

[sfws]

Beta 3180 reported Changes: internal changes to improve CMX start-up. So it might be this release does work differently on start up? I rarely do any reboot, and I certainly have not done one for the current release.

Assuming your Raspberry Pi does not have a real time clock, you might consider a delay more like at least 2 minutes rather than the few seconds you are trying, to give time for not just connecting to network, but also allowing for reading network to get correct time for MX to use.

For Mark's explanation on why he includes both "After" and "Wants" see this post. That topic also discusses the clock issues. You will also see a post there from me, where I say that on my RPi running MX, I have it set to "wait for network" on computer boot in the Raspberry Pi configuration, so I don't actually believe my MX needs any check for network. As it happens I have a RTC and a UPS on that particular RPi.

There is a technical section in the Wiki here that also explains those technical terms, based on me reading the Linux technical manual, it was updated for MX 3.15.1 build 3170 (19 March 2022) . That implies, if you have "Wants" that checks for network before running MX, so there is no reason to worry what happens "After"!
If there really is a need for MX to insist network is running before MX starts, then "Requires" might be what MX should use?

[freddie]

If you have an NTP client (I'm sure you do) to set the time on your host then that will trigger the network detection client. So "Wants" for MX is redundant IMHO. "After" assures that MX will not start until after the network initialisation has started. It doesn't guarantee that the network will be ready, though.

The difference between "Requires" and "Wants" is that MX will fail to start if the "Requires" conditions are not met, but will still start if the "Wants" conditions are not met. Note that the units (including network) are started in parallel, so if MX starts more quickly than the network then it still won't have the network from the get-go, regardless of whether you use "Wants" or "Requires". This is where the start-up delay comes in handy.

[sfws]

"After" assures that MX will not start until after the network initialisation has started.

I disagree - see manual - "After" is defining something that might happen after MX.

I agree with the rest of what you say (re "Requires" , "wants" and start up delay).

[freddie]

"After" assures that MX will not start until after the network initialisation has started.

I disagree - see manual - "After" is defining something to happen after MX.

Badly worded by me. I should have said "'After' assures that MX will not commence start-up/initialisation until after the network initialisation has started (that is, if you use 'After=network-online.target')".

[mcrossley]

If I remember, the MX logfile just "stops" in the middle of reading the ini file settings?
There is no shutdown, or exception raised.

MX reads the ini file upfront - that had completed OK.
Then it is just setting it's internal variables to match the file contents - nothing that I could see hanging there.

So the "halt" would *seem* to be external to CMX.