44
edits
MX on Linux: Difference between revisions
From Cumulus Wiki
Jump to navigationJump to search
→MX can severely damage storage
| (6 intermediate revisions by 2 users not shown) | |||
| Line 280: | Line 280: | ||
By default MX now creates monthly and annual reports that are in the style used by NOAA in USA. If you have been using this functionality before (and it is optional) then you need to file transfer, or copy, all the files that were in the old [[Reports folder]] into the new folder of that name. Do look at that cross-reference, and read about the encoding default differences between Cumulus 1 and MX. | By default MX now creates monthly and annual reports that are in the style used by NOAA in USA. If you have been using this functionality before (and it is optional) then you need to file transfer, or copy, all the files that were in the old [[Reports folder]] into the new folder of that name. Do look at that cross-reference, and read about the encoding default differences between Cumulus 1 and MX. | ||
=MX can | =MX can cause problems with storage= | ||
MX now assumes by default that you are going to use its [[New Default Web Site Information|Default Web Site]]. That means that by default MX will re-generate temporary files in its [[Web folder|/web sub-folder]] on a frequent time-scale. That number of files writes will considerably shorten the working life-time of the "high capacity micro-SD" card that is the default storage for the Raspberry Pi. It will also considerably shorten the life of any flash memory (e.g. memory card | MX now assumes by default that you are going to use its [[New Default Web Site Information|Default Web Site]]. That means that by default MX will re-generate temporary files in its [[Web folder|/web sub-folder]] on a frequent time-scale. That number of files writes will considerably shorten the working life-time of the "high capacity micro-SD" card that is the default storage for the Raspberry Pi. It will also considerably shorten the life of any flash memory (e.g. memory card) that you might install MX on. | ||
The expected life of any storage device, and the extent to which its life is shortened depends on the actual device. The external devices that have the longest life (and therefore can cope most easily with multiple read/write actions) are solid state discs (SSD). Also the larger the capacity of the storage device, the more places on the device where files can be stored and the storing algorithm will try to spread the storing evenly across the entire storage area, so wear at any one location is reduced. | The expected life of any storage device, and the extent to which its life is shortened depends on the actual device. The external devices that have the longest life (and therefore can cope most easily with multiple read/write actions) are solid state discs (SSD). Also the larger the capacity of the storage device, the more places on the device where files can be stored and the storing algorithm will try to spread the storing evenly across the entire storage area, so wear at any one location is reduced. | ||
| Line 307: | Line 307: | ||
* "CHOSEN PATH" is defined in [[#Where to install all packages?]], but basically it starts with a "/" and defines the path to get to where "CumulusMX" is a sub-folder. | * "CHOSEN PATH" is defined in [[#Where to install all packages?]], but basically it starts with a "/" and defines the path to get to where "CumulusMX" is a sub-folder. | ||
* The text "websitedata.json" is just one file in the set of files linked from [[:Category:JSON Files]]. | * The text "websitedata.json" is just one file in the set of files linked from [[:Category:JSON Files]]. | ||
=Running MX= | =Running MX= | ||
| Line 346: | Line 344: | ||
Once you have got all the files sorted out as described above, you need to run MX. | Once you have got all the files sorted out as described above, you need to run MX. | ||
On the first run of MX, unless you have run a recent release before, you need to work through either the '''Config wizard''' or all the individual settings pages (or both) as accessed from "Settings" menu. It is suggested you run MX interactively (see below) to do this, as you will then need to close MX, and then start it up again. | On the first run of MX, unless you have run a recent release before, you need to work through either the [[First_Run_of_MX|'''Config wizard''']] or all the individual settings pages (or both) as accessed from "Settings" menu. It is suggested you run MX interactively (see below) to do this, as you will then need to close MX, and then start it up again. | ||
Information about settings is on other Wiki pages ([[MX Administrative Interface]] and [[Cumulus.ini]]). | Information about settings is on other Wiki pages ([[MX Administrative Interface]] and [[Cumulus.ini]]). | ||
| Line 416: | Line 414: | ||
Type=forking | Type=forking | ||
ExecStopPost=/bin/rm -f /tmp/CumulusMX.exe.lock</pre> | ExecStopPost=/bin/rm -f /tmp/CumulusMX.exe.lock</pre> | ||
Don't change any of the bit I just quoted. | *Be aware that what quoted above applies from MX 3.16.0 (b.3182, 30 Apr 2022) onwards, earlier releases did not include the "-f" flag in final line quoted above. | ||
: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. | |||
Almost certainly you will need to change "/home/install/CumulusMX" on that line. Replace that with "CHOSEN PATH/CumulusMX", i.e. the full path to the directory that the executables are being stored in. | |||
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> | 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 space between the path (just looked at) and the executable file, | ||
* Note the mandatory parameter "-service" that follows a space after the "CumulusMX.exe", you must leave that untouched, | * 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. | * Note you can remove/keep the rest of the line after the -service i.e. the other parameters (some with their values) -lang, -port, or -debug, (as defined in table earlier), are all optional. | ||
| Line 440: | Line 438: | ||
====Technical users - additional edits==== | ====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. ''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). | ||
:Look at the '''[Service]''' part of the file quoted above. | :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 note some weather stations require other changes outside this file before Cumulus can make contact, one example is discussed [https://cumulus.hosiene.co.uk/viewtopic.php?t=20413 on support forum here], but there are other topics that may be relevant). | 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 note some weather stations require other changes outside this file before Cumulus can make contact, one example is discussed [https://cumulus.hosiene.co.uk/viewtopic.php?t=20413 on support forum here], but there are other topics that may be relevant). | ||
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). | 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). | ||
| Line 457: | Line 455: | ||
If your computer 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>. 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! | If your computer 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>. 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! | ||
For that ''time-sync.target'' to work, you need to '''enable''', by creating the symbolic links needed, the appropriate services outside this edit: | |||
<pre>sudo systemctl enable --now systemd-timesyncd.service | |||
sudo systemctl enable --now systemd-time-wait-sync.service | |||
</pre> | |||
| Line 479: | Line 482: | ||
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! | 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 | ===Commands to do actions on a service=== | ||
You will need to start (or restart) MX after you have defined (or redefined) the service as instructed above. The | You will need to start (or restart) MX after you have defined (or redefined) the service as instructed above. The specific commands to use with MX service are at [[Raspberry_Pi_Image#systemctl_commands|systemctl_commands]], here I simply repeat the basic commands that can be used with any service (status, enable, disable, start, stop, and restart). | ||
Don't forget you may need to type <code>sudo systemctl daemon-reload</code> to tell "systemd" that it needs to reload all service definitions whenever either one has changed, or a new one has been added. | |||
In all these commands, '''just replace [service_name] with ''cumulusmx''''' (or enter the name of another service). | In all these commands, '''just replace [service_name] with ''cumulusmx''''' (or enter the name of another service). | ||
* <code>sudo systemctl status [service_name]</code> | |||
* sudo systemctl | ** (displays whether named service has started, whether it has failed, whether it has stopped, also whether enabled, extra information will be added should status change) | ||
* | ** type the single character "q" to quit updating status display and return to prompt | ||
* sudo systemctl | * <code>sudo systemctl enable [service_name]</code> | ||
** (typed just once, and service named will automatically start when your Linux computer is booted) | |||
** the confirmation message says a link has been created | |||
* <code>sudo systemctl disable [service_name]</code> | |||
** (used when you don't want an automatic restart of the named service) | |||
* <code>sudo systemctl start [service_name]</code> | |||
** (will start the named service) | |||
* <code>sudo systemctl stop [service_name]</code> | |||
** (will stop the named service) | |||
** Closing MX with "cumulusmx" as the named service this way does a proper shutdown | |||
* <code>sudo systemctl restart [service_name]</code> | |||
** (issues a stop, then start, command to named service) | |||
** You can upgrade MX by installing new files over the existing ones, while MX is left running, and then use this command to pick up new release with minimum downtime. | |||
