Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
From build 3044 the development baton passed to Mark Crossley. Mark has been responsible for all the Builds since. He has made the code available on GitHub. It is Mark's hope that others will join in this development, but at the very least he welcomes your ideas for future developments (see Cumulus MX Development suggestions).
SamiS wrote: ↑Wed 07 Dec 2022 8:15 pm
@Mark: How foolproof is the detection if first instance is run as service (maybe under root permissions) and second instance from commandline as different user? And if I am correct, this would actually cause processes to keep their own differently named logfiles in MXdiags folder?
It creates a system mutex based on a static GUID allocated to CMX. It seems to be a pretty robust mechanism, killing a process can leave the system mutex open and you will get a warning on restarting (MX can detect the difference between an open and an abandoned mutex). How well it works with processes in different security contexts I'm not so sure, but as it is a system wide lock I'd expect it to work.
Well sorry to report but under Mono/Linux I CAN start two copies of CMX just fine no errors at all, you solution does not work. I also just checked again and the stop second instance IS set.
That does NOT mean I did start two but it is possible that forcing off the console window could leave it running in the background but even that is a remote possibility and to my mind should not happen. If I ever have to do that I'll check first to make sure mono has stopped.
Stuart
Currently running CMX V4.4.2 4085 on Linux openSUSE Leap
Yep, I found that too, but it is out of date. They added support for mutexes later.
freddie wrote: ↑Thu 08 Dec 2022 12:40 pm
@mcrossley usage of systemd on Linux provides an immediate workaround. Best to run as a service rather than from the command line.
Yep, running as a service and starting another service isn't an issue, it creates a lock file containing the process id.
Maybe I need to look at something similar for MX, the file needs to be globally readable of course.
mcrossley wrote: ↑Thu 08 Dec 2022 1:55 pm
Yep, running as a service and starting another service isn't an issue, it creates a lock file containing the process id.
Yep I know that - I meant recommend running as a service. No disadvantage and it is only a one-time extra step.
