MX on Linux: Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search
9,252 bytes added ,  11:44, 12 June 2022
m
→‎Running MX: add link to new page
m (Removing duplicated paragraph)
Tag: Undo
m (→‎Running MX: add link to new page)
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=Using MX on UNIX-derived Operating Systems=
=Using MX on UNIX-derived Operating Systems=
 
[[Category:Cumulus MX]]
MX runs on any UNIX-derived operating systems (OS):
MX runs on any UNIX-derived operating systems (OS):
* including those found on Apple Mac computers,  
* including those found on Apple Mac computers,  
Line 58: Line 58:
=Preparing your computer for installing the Cumulus MX suite=
=Preparing your computer for installing the Cumulus MX suite=


Please see [[Preparing your Linux computer for MX]].
Please see [[Preparing your Linux computer for MX]] page if you have not installed MX on Linux before.


That page covers:
That page covers:
Line 67: Line 67:
** [[Preparing your Linux computer for MX#The various components to commands for installation|Commands]]
** [[Preparing your Linux computer for MX#The various components to commands for installation|Commands]]
* [[Preparing your Linux computer for MX#USB HID|Human Interface Devices]]
* [[Preparing your Linux computer for MX#USB HID|Human Interface Devices]]
* [[Preparing your Linux computer for MX#Installing Mono instruction|Installing Mono]]
* [[Preparing your Linux computer for MX#Installing Mono instruction|'''Installing Mono''']]
* [[Preparing your Linux computer for MX#Moving from Microsoft Windows to Linux|Preparing Microsoft Windows files for Linux]]
* [[Preparing your Linux computer for MX#Moving from Microsoft Windows to Linux|Preparing Microsoft Windows files for Linux]]
* [[Preparing your Linux computer for MX#File Names & Paths|Guide to file names and paths]]
* [[Preparing your Linux computer for MX#File Names & Paths|Guide to file names and paths]]


Please see


Please be advised some of the above is rather technical reading, but Mono is required to run the Cumulus packages described next.
 
Please be advised some of the above is rather technical reading, but ''Mono is required to run the Cumulus packages'' described next.  So do ensure that you installed Mono before continuing.
 
==Technical aside==
 
Please note this Wiki page talks about "folders" for compatibility with the [[MX on Windows OS]] page, but Linux prefers to call them directories.
 
Linux has a well defined filesystem, represented as a hierarchic tree starting at the root "/", that is divided into directories (one of which will be "/boot" and hold the kernel), each of those first level directories can be divided into second level directories, this second level is sometimes referenced to as defining the "scope", an indication that each is meant to be used for a specific purpose. The scope can be sub-divided again at lower levels representing "categories" (categories cover items like binary code, documentation, configuration, hardware, source code, runtime and content), and at a lower level still "applications" (i.e. related to specific programs) with further sub-levels for various options within those applications. Many Linux distributions will use logical links so references to a directory at one level in the hierarchy will actually redirect to files in a different directory, this might be because different programs expect to see files in different places or just to enforce ownership and writing rights.
 
For the purposes of this Wiki, the terminology "operating system" is used for the whole Linux distribution, you will find that Linux technical people prefer to talk about Linux distributions including:
# a "kernel" for the underlying handling of files, network and so on;
# one or more "shell" components for the handling of commands entered in terminal mode, including those that run programs (whether included in distribution or added later);
# an optional graphical user interface for simpler access to commands and programs.
 
For simplicity the terminology "terminal" is used for how you access the shell, this term refers to seeing the command prompt if your Linux is running without a graphical user interface, or to a window that you can open within the graphical interface where commands can be typed. Depending on your Linux, that window might be called "Terminal", "Konsole", "xterm", "gnome-terminal", "uxterm", or even something else. If you are accessing your Linux computer over a network from a computer running Microsoft Windows, then again you may encounter a number of terms for how to access the shell on your Linux computer, "Command Window", "Windows Powershell", or "Windows Terminal". Equally you may use software that calls it a teletype mode, e.g. PuTTY software.


=Cumulus packages=
=Cumulus packages=
Line 132: Line 145:
# '''CumulusMX''':
# '''CumulusMX''':
#* '''CumulusMX.exe''' is written in C#, that has been developed by Mark Crossley, but still contains some code by Steve Loft
#* '''CumulusMX.exe''' is written in C#, that has been developed by Mark Crossley, but still contains some code by Steve Loft
#* Download '''CumulusMX zip file’’’ from the link at[[Software#Latest_build_distribution_download]]
#* Download '''CumulusMX zip file’’’ from the link at [[Software#Latest_build_distribution_download]]
# [[Software#Create_Missing|'''Create Missing''']]:
# [[Software#Create_Missing|'''Create Missing''']]:
#* '''CreateMissing.exe''' is also written in C#, created, and developed, by Mark Crossley
#* '''CreateMissing.exe''' is also written in C#, created, and developed, by Mark Crossley
Line 147: Line 160:
As at 9 March 2020, another utility, '''CreateRecord''', has been initialised in the Github areas managed by the developer where Cumulus is worked on, although it appears to be just a concept on github.  This will, if my understanding is correct, read [[dayfile.txt]] and use that to update the various [[:Category:Ini Files|extreme record files]]. The developer is still aiming to make this available, but his work on it (on his computer) has been stalled by the level of pressure being applied for bug-fixes and changes to MX itself.
As at 9 March 2020, another utility, '''CreateRecord''', has been initialised in the Github areas managed by the developer where Cumulus is worked on, although it appears to be just a concept on github.  This will, if my understanding is correct, read [[dayfile.txt]] and use that to update the various [[:Category:Ini Files|extreme record files]]. The developer is still aiming to make this available, but his work on it (on his computer) has been stalled by the level of pressure being applied for bug-fixes and changes to MX itself.


===Alternative download link for older MX releases===
===Alternative download link for older package releases===


Because the developer uses Git Hub to manage releases, the older releases remain available.
====Old Cumulus MX packages====
Skip this subsection if either you have installed the "pre-built disc image", or the current MX release is stable (it has been available for a while and nobody has reported any bugs).
Skip this subsection if either you have installed the "pre-built disc image", or the current MX release is stable (it has been available for a while and nobody has reported any bugs).


Line 158: Line 174:
* Plus a whole host of optional features, and different external upload sites, (typically each of these optional features are only used by a sub-set of Cumulus users).
* Plus a whole host of optional features, and different external upload sites, (typically each of these optional features are only used by a sub-set of Cumulus users).


Anyway, '''you can download any earlier build, without the bug''', from [https://github.com/cumulusmx/CumulusMX/releases CumulusMX/releases].
Anyway, '''you can download any earlier MX build, without the bug''', from [https://github.com/cumulusmx/CumulusMX/releases CumulusMX/releases].
 
====Old utilities====
 
The zips for "CreateMissing.exe" and "ExportToMySQL.exe" utilities do NOT contain the '''''.dll''''' components that they need when they are running.
 
This means that each version of "CreateMissing.exe" and "ExportToMySQL.exe" utilities is dependent on it being used with a release of Cumulus MX that does have correct  '''''.dll''''' components in its release distribution.
 
That in turn means you can't use the latest version of the utility with older MX releases, nor can you use an old utility version with latest MX release. This is why [[Software#By_Mark_Crossley|utilities downloads]] make clear which MX release is the minimum for them.


You need to ensure that you use the right version of "CreateMissing.exe" and "ExportToMySQL.exe" utilities for the MX release you are running, so if you are using an old MX release, you will need to go directly to the [https://github.com/cumulusmx Cumulus MX github] page, and navigate to the utility of interest, to download an older version of these utilities that matches your older MX.
The older versions of these "CreateMissing.exe" and "ExportToMySQL.exe" utilities are available by going directly to the [https://github.com/cumulusmx Cumulus MX github] page, and navigating to the utility of interest. However, to use those older versions, you also need to download the corresponding older MX release, because the MX distributions contain the .dll files that the utilities require, they are not in the utilities zip.  Because of this complication, novice users are advised not to attempt to use the older utilities, even if the latest version appears to have a bug.  Technical users may be able to work out which .dll files are needed and can be safely added back (if they are not left over from when that past MX release was in use). An alternative is to create a new folder with the old release packages (MX and the utility of interest), a copy of the latest Cumulus.ini file, and a copy of all files from /data sub-folder; then afterwards copy back the changed files into original /data folder.


==Upgrading a Cumulus package==
==Upgrading a Cumulus package==
Line 181: Line 205:
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.
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==
==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.
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.
Line 238: Line 262:
'''MX interface''' --> Setting menu --> '''Station Settings''' --> Click on ''General Settings'' --> Click on '''Advanced Options''' --> Edit ''Records Began Date'' following instructions below that field
'''MX interface''' --> Setting menu --> '''Station Settings''' --> Click on ''General Settings'' --> Click on '''Advanced Options''' --> Edit ''Records Began Date'' following instructions below that field


==="data" sub-folder===
==="data" directory===


Please see [[:Category:Files_with_Comma_Separated_Values]], [[:Category:Ini_Files]], and [[Weather_Diary]], for information if you are moving from Cumulus 1 to MX.  Otherwise just copy files from any existing folder to your new one.
Please see [[:Category:Files_with_Comma_Separated_Values]], [[:Category:Ini_Files]], and [[Weather_Diary]], for information if you are moving from Cumulus 1 to MX.  Otherwise just copy files from any existing folder to your new one.
Line 252: Line 276:




==="Reports" sub-folder===
==="Reports" directory===


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.
Line 258: Line 282:
=MX can severely damage storage=
=MX can severely damage 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) or external drive (with a spining disc and moving head) that you might install MX on.
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) or external drive (with a spinning disc and moving head) 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 264: Line 288:
All Linux computers will have some random access memory chips (RAM) and it is worthwhile to define part of that RAM as a drive used for temporary files.  For a Raspberry Pi computer, a typical approach would be to edit the fstab file, adding the line ''tmpfs /run/tmp tmpfs nodev,nosuid,size=1M 0 0'', but the size you choose will depend on RAM available and what temporary files are being created.  For maximum life of the "high capacity micro-SD" card if that is what your computer boots from, you should create a symbolic link path that maps the '''/tmp''' folder used by the system to your '''/run/tmp''' you have just defined in RAM.  The difficulty will be that you cannot create a logical redirect on '''/tmp''' if the folder is already in use, so that makes it too complicated to explain here.
All Linux computers will have some random access memory chips (RAM) and it is worthwhile to define part of that RAM as a drive used for temporary files.  For a Raspberry Pi computer, a typical approach would be to edit the fstab file, adding the line ''tmpfs /run/tmp tmpfs nodev,nosuid,size=1M 0 0'', but the size you choose will depend on RAM available and what temporary files are being created.  For maximum life of the "high capacity micro-SD" card if that is what your computer boots from, you should create a symbolic link path that maps the '''/tmp''' folder used by the system to your '''/run/tmp''' you have just defined in RAM.  The difficulty will be that you cannot create a logical redirect on '''/tmp''' if the folder is already in use, so that makes it too complicated to explain here.


==web sub-folder==
==web directory==


All the files in this folder come from the download.
All the files in this folder come from the download.
Line 322: Line 346:
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 341: Line 365:


The simplest instruction to run Cumulus MX  is <code>cd CHOSEN PATH/CumulusMX && sudo mono CumulusMX.exe [optional parameters]</code>.   
The simplest instruction to run Cumulus MX  is <code>cd CHOSEN PATH/CumulusMX && sudo mono CumulusMX.exe [optional parameters]</code>.   
* This is two commands issued together, the first changes the working folder, the second actually starts the main executable
* This is two commands issued together, the first changes the working folder, the "&&" means that first command has to succeed before the second command is obeyed and actually starts the main executable
* Optional parameters are not normally needed, but available as listed in table earlier.
* This example has not included any optional parameters, as they are rarely needed, but the optional parameters available are as listed in table earlier.


When you want MX to stop, you must (for Linux) within your terminal session hold down the "Ctrl" button on your keyboard, and press "C". After that you can choose to close the terminal window.
When you want MX to stop, you must (for Linux) within your terminal session hold down the "Ctrl" button on your keyboard, and press "c". A word of caution here, if you are accessing your Linux computer over a network from another computer, do be careful about using any control sequences, as it is possible that your "Ctrl" "C" sequence will be applied to an application other than Cumulus MX, if that terminal session has started more than one application. The issue is that all running applications use the same terminator, it should be applied to whatever is regarded as the "foreground" application at the moment the control key sequence is used, which is guaranteed to be MX if that terminal session has only been used for running MX, and MX has not launched any external applications. After that you can choose to close the terminal window.


===Interactive advice===
===Interactive advice===
Line 367: Line 391:
Open a  terminal window, then navigate to the folder where you have installed the 3 Cumulus executables:
Open a  terminal window, then navigate to the folder where you have installed the 3 Cumulus executables:


To run "Create Missing utility" type <code>cd CHOSEN PATH/CumulusMX && sudo mono CreateMissing.exe</code>
To run "Create Missing utility" type <code>cd CHOSEN PATH/CumulusMX && sudo mono CreateMissing.exe</code>. It does not take any parameters, so that is all you need to know, although it is fully documented at [[Calculate_Missing_Values#CreateMissing.exe]] in this Wiki.


To run [[Software#Export_To_MySQL|Export To My SQL]], you change the name of the executable above and add the necessary parameters, follow that link for more details.
To run [[Software#Export_To_MySQL|Export To My SQL]], you change the name of the executable above and add the necessary parameters, follow that link for more details.
Line 382: Line 406:
The MX download includes a file that can be used as a starting point for the service definition.  Find this file at ''CHOSEN PATH/CumulusMX/MXutils/linux/cumulusmx.service''. You do have to edit this file, and then you have to copy it to a new location, before you start the MX service for the first time.
The MX download includes a file that can be used as a starting point for the service definition.  Find this file at ''CHOSEN PATH/CumulusMX/MXutils/linux/cumulusmx.service''. You do have to edit this file, and then you have to copy it to a new location, before you start the MX service for the first time.


# Open the file at ''CHOSEN PATH/CumulusMX/MXutils/linux/cumulusmx.service'' using an editor. On a Raspberry Pi, use the file manager to navigate to this file, right click the file named, and select "Geany's Programmers Editor".
# 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:
# Within the provided file you should find a [Service] section:
<pre>[Service]
<pre>[Service]
Line 389: Line 415:
ExecStart=/usr/bin/mono-service -d:/home/install/CumulusMX CumulusMX.exe -service
ExecStart=/usr/bin/mono-service -d:/home/install/CumulusMX CumulusMX.exe -service
Type=forking
Type=forking
ExecStopPost=/bin/rm /tmp/CumulusMX.exe.lock</pre>
ExecStopPost=/bin/rm -f /tmp/CumulusMX.exe.lock</pre>
 
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. 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.
*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.  


Do change "/home/install/CumulusMX CumulusMX.exe".  Replace that with "CHOSEN PATH/CumulusMX.exe".
: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 (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 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.




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):
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'''  
# Open the "File" menu, and select "Save as" and enter a new name '''cumulusmx_edited.service'''  
# Exit out of the editor you are using
# Exit out of the editor you are using
# Next, open a terminal session
# 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 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 "sytemd" that it needs to reload all service definitions because either one has changed, or a new one has been added
# Now type <code>sudo systemctl daemon-reload</code>, this tells "systemd" 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
# 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


Line 411: Line 440:
====Technical users - additional edits====
====Technical users - additional edits====


Look at the '''[Service]''' part of the file quoted above.
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.
 
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.
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).


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 releases 3.8.4 to 3.15.0: you will see one reference to '''network-online.target''' in <code>After=network-online.target</code>.
Line 421: Line 454:
For release 3.15.1 build 3170 (19 March 2022) onwards: you will see an extra line <code>Wants=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 this, you have to decide what is needed in your context.
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.


As an example, 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>. A standard raspberry pi computer does not have a real-time clock, so when you switch it on, the clock just continues from whatever the time was when it was switched off. If the computer has online access, then it can look up the correct time online and adjust its clock. We don't want MX to start until after the time has been synced, and we want the local file-system to be ready for MX to read/update/store files. The example extra line ensures (Requires) these events have happened before MX can 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 432: Line 470:
#* The terminology ''Requires'' tells  "systemd" that the "cumulusmx" service should not be started until the services specified on that line have successfully started
#* 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 '''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 either a real-time clock chip, or a time found on the internet (NTP), i.e. this will ensure that Cumulus obtains the correct time from the computer to control all its actions
#*# The '''time-sync.target''' specifies that the ''cumulusmx'' service requires the computer to have synced with some time source (see notes below), which could be useful if your weather station type does not time-stamp readings stored in the console, and you want to ensure MX reads correct 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.''
''Don't forget to save the file under a new name, and copy it as instructed in previous subsection.''


===Commands to start, stop, or restart (stop and start in one command) MX as a service===
====Technical Notes only relevant to Raspberry Pi====


You will need to start (or restart) MX after you have defined (or redefined) the service as instructed above.  The full set of commands to use with this service are at [[Raspberry_Pi_Image#systemctl_commands|systemctl_commands]], here I simply repeat the basic commands that can be used with any service (start, stop, and restart).
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.  


In all these commands, '''just replace [service_name] with ''cumulusmx''''' (or enter the name of another service).
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 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 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).


* sudo systemctl start [service_name]
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.
* sudo systemctl stop [service_name]
* sudo systemctl restart [service_name]


If you want MX to automatically start when your Linux computer is booted, just type <code>sudo systemctl enable [service_name]</code> once, and it will be activated on each reboot.  Change the "enable" into "disable" if you don't want an automatic restart.
In all these commands, '''just replace [service_name] with ''cumulusmx''''' (or enter the name of another service).
* <code>sudo systemctl status [service_name]</code>
** (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
* <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.
5,838

edits

Navigation menu