Cumulus Wiki

MX on Linux: Difference between revisions

Page Discussion

MX on Linux (view source)

Revision as of 12:24, 22 May 2022

1,356 bytes added ,  22 May 2022
m
added "Technical Notes only relevant to Raspberry Pi"
mNo edit summary
m (added "Technical Notes only relevant to Raspberry Pi")
The alternative is to install in a new folder (or rename the old one), and copy across files not in the release from old location to new location, but in that alternative you might forget some files.
 
==Changing location of Cumulus MX==
 
If your install, or upgrade, is creating MX in a different place to where you previously ran Cumulus, then you will want to copy files across that are not in the zip extract distribution.
 
# Open the file at ''CHOSEN PATH/CumulusMX/MXutils/linux/cumulusmx.service'' using an editor (see [[Preparing_your_Linux_computer_for_MX#editing_files|editing_files]]).
#* On a Raspberry Pi with a graphical interface, use the file manager to navigate to this file, right click the file named, and select "Geany's Programmers Editor".
#* If you are accessing from another computer, using a terminal session, then "nano" is a suitable editor (explained at link just mentioned).
# Within the provided file you should find a [Service] section:
There is more in the file, but for now focus on the line including "ExecStart=/usr/bin/mono-service -d:".
 
Don't change any of the bit I just quoted.
Don't change any of the bit I just quoted. Note the mandatory parameter "-service", you must leave that untouched, but you can add -lang, -port, or -debug, as in table earlier after the -service as per example below.
 
Do change "/home/install/CumulusMX CumulusMX.exe". Replace that with "CHOSEN PATH/ CumulusMX.exe".
 
The final line, with all possible parameters, could read: <code>'ExecStart=/usr/bin/mono-service -d:CHOSEN PATH/CumulusMX CumulusMX.exe -service -debug -port 999 - lang el-GR</code>
* Note the space between the path and the executable file,
* Note the mandatory parameter "-service" that follows a space after the "CumulusMX.exe", you must leave that untouched,
* Note you can remove/keep the rest of the line after the -service i.e. -lang, -port, or -debug, (as defined in table earlier) are all optional.
 
 
Technical user may do other edits on the file, these will be described later, for now save the changed file under a new name (so it won't be lost when you do a MX upgrade that replaces original file) within your MX installation:
# Open the "File" menu, and select "Save as" and enter a new name '''cumulusmx_edited.service'''
# Exit out of the editor you are using
# Next, open a terminal session
# Now copy file to where it is needed to run the service <code>sudo cp EXISTING_PATH/CumulusMX/MXutils/linux/cumulusmx_edited.service /etc/systemd/system/cumulusmx.service</code>
# Now type <code>sudo systemctl daemon-reload</code>, this tells "sytemdsystemd" that it needs to reload all service definitions because either one has changed, or a new one has been added
# Finally, '''optionally''', create a symbolic link to that file using <code>sudo systemctl enable cumulusmx</code> if you want the service to automatically start after a reboot
 
====Technical users - additional edits====
 
Novice users, skip this subsection. The changes in this subsection have to be made with other changes that are not covered here (they depend on your weather station type, and your computer type, so are not appropriate to a Wiki page trying to generalise, and anyway your contributor is not a technical expert).
Novice users, skip this subsection.
 
:Look at the '''[Service]''' part of the file quoted above.
 
This states Cumulus should use root for both the user it runs under and for the group permissions it uses. If you have the technical expertise, you might choose to run MX in a different user, if your weather station type allows MX to run in a different user. If so, replace the "root" in its two locations. (Please Younote maysome alsoweather wishstations torequire addother anchanges extraoutside linethis afterfile thebefore "Group"Cumulus linecan <code>ExecStartPre=/bin/sleepmake 5</code>contact, thisone example is todiscussed delay[https://cumulus.hosiene.co.uk/viewtopic.php?t=20413 theon startingsupport offorum MXhere], bybut 5there seconds whileare other servicestopics startthat (onmay abe reboot of your computerrelevant) that might affect MX. (For some users, change 5 into 10, it all depends what else is being started).
 
You may also wish to add an extra line after the "Group" line <code>ExecStartPre=/bin/sleep 5</code>, this [https://cumulus.hosiene.co.uk/viewtopic.php?p=163754#p163754 is to delay the starting of MX by 5 seconds while other services start] (on a reboot of your computer) that might affect MX. (For some users, change 5 into 10, it all depends what else is being started).
Note that this delay on reboot in the [Service] part of the file is not enough of a delay to cope with the Raspberry Pi being switched off and later switched on, so this is why an edit is also needed in the [Unit] part of the file to fully cope with dependency on other services, so that will be described next. Look at the rest of the file, the '''[Unit]''' part.
 
:Look at the rest of the file, the '''[Unit]''' part.
 
For releases 3.8.4 to 3.15.0: you will see one reference to '''network-online.target''' in <code>After=network-online.target</code>.
For release 3.15.1 build 3170 (19 March 2022) onwards: you will see an extra line <code>Wants=network-online.target</code>
 
If you are a technical user, you might decide to edit the [Unit] part of the file, you have to decide what is needed in your context, only you know what other services are started by systemd on your computer, you can list all items using something like <code>systemctl list-unit-files</code> to see the services, but you still need to understand what each does.
 
AsIf anyour examplecomputer has online access, then it can look up the correct time online and adjust its clock. However, it might not even try to do that for say 10 minutes after being booted, and so there may be a benefit in making MX wait until after systemd has asked for the time to be synced, and asked that the local file-system is made ready so MX can read/update/store files. To achieve this, you might choose to add a blank line after '''<nowiki>Documentation=https://cumuluswiki.org/a/Main_Page</nowiki>''' and in that blank line, type <code>Requires= time-sync.target local-fs.target</code>. AUsing standard"Requires" raspberryensures pithese computerrequesting does notevents have ahappened real-timebefore clock,MX socan whenstart, youif switchthey it onfail, theMX clockwill justnot continuesbe fromstarted, whateverthis theexample timehas wasnot whenspecified ita wastime switchedthat off,MX asshould MXwait usesfor the timeother takenservices fromto your computer, all MX actions will use this "stale" timestart!
 
If the computer has online access, then it can look up the correct time online and adjust its clock. The extra line in the example should be added if we don't want MX to start until after systemd has asked for the time to be synced, and asked that the local file-system is made ready so MX can read/update/store files. Using "Requires" ensures these requesting events have happened before MX can start, if they fail, MX will not be started, this example has not specified a time that MX should wait for the other services to start!
 
 
#* The terminology ''Requires'' tells "systemd" that the "cumulusmx" service should not be started until the services specified on that line have successfully started
#*# The '''local-fs.target''' specifies that the ''cumulusmx'' service requires the file service to have started, i.e. checks your computer can read files before it attempts to start the ''cumulusmx'' service
#*# The '''time-sync.target''' specifies that the ''cumulusmx'' service requires the computer to have synced with eithersome a real-time clocksource chip(see notes below), orwhich acould timebe founduseful onif theyour internetweather (NTP),station i.e.type thisdoes willnot ensuretime-stamp thatreadings Cumulusstored obtainsin the correctconsole, timeand fromyou the computerwant to controlensure allMX itsreads actionscorrect time from your computer
#*#* If you are using a weather station type that does not time-stamp the readings it supplies to a Raspberry Pi, adding that target reference is important
#*#* A standard RPi does not include a real time clock chip (it can be added via connections available), therefore when the RPi boots it initially uses a dummy clock, and this sets the time to when the RPi was last running.
#*#* That means without this target being included, a newly booted-up RPi will tell Cumulus MX the time is just after when the computer was shut down, that might be very different to the true current time. It means your Cumulus MX on restarting will skip the catch-up of historic data (should your weather station settings make that available). Subsequent measurements will then get logged against the wrong time.
#*#* When the Raspberry Pi does do a time-sync, the time will suddenly jump, this is serious if this means the "rollover" time has been skipped over, as it implies the "dayfile.txt" will miss a line, and many measurements will be logged to wrong day.
 
''Don't forget to save the file under a new name, and copy it as instructed in previous subsection.''
 
====Technical Notes only relevant to Raspberry Pi====
 
This Wiki page has tried to avoid being too specific to particular hardware, but to avoid misunderstanding the last subsection, a little does need to be said to justify the claim that only technical users, who understand all the other changes needed, should make changes mentioned there.
 
A standard Raspberry Pi computer does not include a clock chip. Instead one of the packages it loads as a service on booting is called "fake-hwclock", and that sets the clock to what the date/time was when it was last running, irrespective of how many days/hours it has been off. That counts as a time sync for the purposes of instruction specified above. You can buy and fit a real-time clock chip, and configure your computer to use that, but even that RTC will only keep time when it is kept powered, and even then it will drift off unless periodically able to be corrected by a time from internet.
 
The issue is your Cumulus MX on restarting will skip the catch-up of historic data (should your weather station settings make that available), because the dummy clock makes MX think the computer was not off for long. Subsequent measurements will then get logged against the wrong time until the correct time is found on the internet (NTP). At that moment, the time will suddenly jump, this is serious if this means the "rollover" time has been skipped over, as it implies the "dayfile.txt" will miss a line, and many measurements will be logged to wrong day. In my experience it can be anything from 2 minutes to 10 minutes after switch on before my RPi does a time sync over the internet.
 
You might expect <code>sudo systemctl disable fake-hwclock.service</code> (or remove the service, and modify the scripts that call it) could ensure the computer (if online) has to get a time found on the internet (NTP). Nothing is as simple as it might seem!
 
 
===Commands to start, stop, or restart (stop and start in one command) MX as a service===
Sfws
5,838

edits

Retrieved from "https://www.cumuluswiki.org/a/Special:MobileDiff/10446"