5,838
edits
MX on Linux: Difference between revisions
From Cumulus Wiki
Jump to navigationJump to search
m
→Running MX: add link to new page
m (A recent correction was muddling, made it clear) |
m (→Running MX: add link to new page) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 346: | 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 457: | Line 457: | ||
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 484: | ||
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 start | ===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). | |||
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. | |||
