Cumulus Support

Posted: **Fri 28 Aug 2020 5:41 am**

I did:

update-rc.d mono-xsp4 disable

Thinking xsp4 was not required (I think it isn't because manual start afterwards makes CumulusMX run fine).

Apparently this also disables the start of cumulus during a reboot as well. I simply had added cumulusmx.sh to the init.d directory and everything worked fine but at the deactivation of xsp4 it also deactivates cumulus. When reactivating xsp4 I get:

Aantekening 2020-08-28 072727.png

Before starting to mess things up: what is going on here, not being an init.d specialist?

When I start cumulus manually by

Code: Select all

/etc/init.d/cumulusmx.sh start

everything is OK, but I am missing the automatic start/stop by init.d

I think - as far as I researched this - the cumulus-script for Linux/Debian needs to comply to LSBInitScripts.
(other OSs on RPi are on their own I guess)

Posted: **Fri 28 Aug 2020 5:57 am**

The issue here is that init.d is deprecated and has been for quite a while. systemd is the replacement, and it is good practice to tailor control scripts for this environment. systemd has been adopted by most if not all flavours of Linux for about 5 years now.

Posted: **Fri 28 Aug 2020 6:04 am**

So, what's the instruction for CumulusMX then?
(as btw everything including mono, starts via init.d)

Posted: **Fri 28 Aug 2020 7:41 am**

No, systemd starts everything, and those things that haven't been updated from init.d are included in that via an adaptor. It's much better to use systemd natively. There are plenty of resources online covering it. If I get a minute on Saturday I will put something together.

Posted: **Fri 28 Aug 2020 7:58 am**

freddie wrote: ↑Fri 28 Aug 2020 7:41 am No, systemd starts everything, and those things that haven't been updated from init.d are included in that via an adaptor.

I can't see any of that on my (pretty much default) install of Raspbian Buster.

freddie wrote: ↑Fri 28 Aug 2020 7:41 am There are plenty of resources online covering it. If I get a minute on Saturday I will put something together.

Would appreciate that.

Posted: **Fri 28 Aug 2020 8:28 am**

Some background stuff:

Posted: **Fri 28 Aug 2020 8:31 am**

HansR wrote: ↑Fri 28 Aug 2020 7:58 am I can't see any of that on my (pretty much default) install of Raspbian Buster.

Hans, please try

Code: Select all

systemctl list-units

and

Code: Select all

ls -l /lib/systemd/system/

Posted: **Fri 28 Aug 2020 10:15 am**

Thanks for the info guys, a bit late because I was updating my OS and that was a large update.
Thnx @rogerthn for the commands. The second I had already found just searching the directories.

Though there may have been some confusion about init and systemd, it was clear to me that it was not a System V ini which ruled. But it is also clear that there are many init.d scripts in the system and they are executed by systemd, though I was not aware of the wrapper doing that. What the roger-commands show is that that is the system booting, not user programs running as a deamon.

OK, whatever the situation is: the init.d scripts are still executed.

And that means my starting message is valid: the script as supplied by Mark in the CMX distribution requires LSB tags. That's what the system is saying. I don't know what it takes to make a systemd native start/stop of CMX (I am curious what freddie comes up with), but the init.d mod seems understandable, easy and quick. And perfectly legal within the whole initialisation of the systemd.

I think it is up to @mcrossley to decide how to do this, but as a user I require a simple script to start/stop CMX both at reboot/shutdown as well as manually. If that goes through systemctl - fine. If it is a script in init.d - fine. As long as it is non-confusing and understandable for just plain not so technical users as well: don't make this a system manager issue.

Cheers, Hans

Posted: **Fri 28 Aug 2020 10:28 pm**

All this is outside my knowledge area, if someone can come up with an improved init.d script, or a systemd solution, then I'm more than happy to replace what I knocked up!

Posted: **Sat 29 Aug 2020 2:28 pm**

For a systemd service, its configuration is stored in a file known as a unit. To create a unit for Cumulus MX, create a file called cumulusmx.service in /etc/systemd/system/. Pop this code into the file:

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:/home/install/CumulusMX CumulusMX.exe -service
Type=forking
ExecStopPost=/bin/rm /tmp/CumulusMX.exe.lock

[Install]
WantedBy=multi-user.target

[Service] section notes: you should modify the ExecStart line to suit your system. /usr/bin/mono-service is the path to the mono-service executable (should be pretty standard across all systems, but I would double-check it is there). -d:/home/install/CumulusMX is the location of your Cumulus MX installation. Also, modify User and Group to suit your local setup. Lastly, ExecStopPost=/bin/rm /tmp/CumulusMX.exe.lock is for systemd to remove the lock file created on service startup in order to signal successful startup/shutdown.

Cumulus is started and stopped with the following commands:

Code: Select all

systemctl start cumulusmx
systemctl stop cumulusmx

Status and restart are available too:

Code: Select all

systemctl restart cumulusmx
systemctl status cumulusmx

If you make a change to the unit file, you need to run the following command so that systemd re-reads your file:

Code: Select all

systemctl daemon-reload

There is no need to do this when you first create the unit file.

To have Cumulus start on reboot, issue the following command:

Code: Select all

systemctl enable cumulusmx

Finally, to stop the service running on reboot, use the following:

Code: Select all

systemctl disable cumulusmx

NOTE:
All the above systemctl commands should be run as root (or prefixed with sudo) - except for status which can be executed by a normal user.
The unit file can be called whatever you want, provided it is suffixed with .service. If you do decide to use another name then you will need to use this name with your systemctl commands.

Posted: **Sat 29 Aug 2020 3:59 pm**

@freddie:

Thnx. Looks good. Tried it (adjustment for path) and works for all commands.

The status command is satisfactory.
We only now must know where to find the console output and how to read it. Can that be done through the systemctl as well?

Had some questions but upon implementation they disappeared. Afaiac this may be the solution to start/stop for CumulusMX. Only the cumulusmx.service file needs to be in the distribution with a small instruction (where to put and to adjust the CumulusMX path).

Posted: **Sat 29 Aug 2020 4:09 pm**

HansR wrote: ↑Sat 29 Aug 2020 3:59 pm @freddie:

Thnx. Looks good. Tried it (adjustment for path) and works for all commands.

Fab. Thanks for trying it.

HansR wrote: ↑Sat 29 Aug 2020 3:59 pm We only now must know where to find the console output and how to read it. Can that be done through the systemctl as well?

It is in the MXdiags folder - I forget the file name. Mark mentioned it in his release posting, so I guess the setting is internal to the application.

Posted: **Sat 29 Aug 2020 4:22 pm**

From the 3.8.0 release notes:

When running as a service the normal console output is logged to a file: \MXdiags\ServiceConsoleLog.txt

Posted: **Sat 29 Aug 2020 4:25 pm**

freddie wrote: ↑Sat 29 Aug 2020 4:09 pm It is in the MXdiags folder - I forget the file name. Mark mentioned it in his release posting, so I guess the setting is internal to the application.

Yes, I know and easy enough to get, was just wondering if you could get it after the status command as a kind of extension. Or maybe even a [selfmade] command of its own: showconsole. Or is this too demanding?

Never mind. As is is good enough I think.

Posted: **Sat 29 Aug 2020 4:37 pm**

HansR wrote: ↑Sat 29 Aug 2020 4:25 pm
freddie wrote: ↑Sat 29 Aug 2020 4:09 pm It is in the MXdiags folder - I forget the file name. Mark mentioned it in his release posting, so I guess the setting is internal to the application.
Yes, I know and easy enough to get, was just wondering if you could get it after the status command as a kind of extension. Or maybe even a [selfmade] command of its own: showconsole. Or is this too demanding?

Never mind. As is is good enough I think.

Just curious Hans, were you running the CumulusMX Start|Stop - Management Script(s) for RaspberryPi/Linux Systems" script before you moved to systemd?

I am still running this on my Ubuntu, handy to do a backup, restart, stop, start, update etc. now if the systemd could do all that...... well.

Cumulus Support

Cumulus as a server - start/stop through init.d

Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d

Re: Cumulus as a server - start/stop through init.d