The words belong solely to the blog owner at Sanity Free Coding. I'm reproducing the content of the article here for posterity.
That makes me worry that eventually it might disappear, and with it, the advocated solution. UPDATEĪs of, the article I linked to above is still active, but the blog hasn't been updated in a while. That's a very nice touch that the other Mutex solutions described here do not address. Second, the article shows how to bring the existing instance of the application to the foreground when the user tries to start another instance. But as it is, I do not use the Microsoft.VisualBasic assembly, and I'd rather not add an unnecessary dependency to my project. If my project already had a dependency on that assembly, I would probably advocate using the approach shown in another answer. The approach described by the article is advantageous for two reasons.įirst, it does not require a dependency on the Microsoft.VisualBasic assembly.
I am completely lost.Here is a very good article regarding the Mutex solution. Do you have any idea, what may cause the issue and what I may do to solve it? BTW: At this point (with the killed process) my satellite checks are still pending on the master.ĮDIT: I do see the same behaviour on my master. When I kill the process with the given PID the icinga2 daemon -X-command gives more information while the icinga2-service shows (code=killed, signal=KILL) (well, I killed it…^^).Īt the same time my icingaweb2-frontent is working. I cannot find any errors in my config files and the log-files don’t show any errors. critical/cli: Another instance of Icinga already running with PID 1699 Icinga2 daemon -X (on the satellite) prints the following line: Unfortunately on my master the satellite-checks are shown as “pending” and after some research on the internet I found out that I installed icinga2 and icingaweb2 on a satellite, from my logs I read that it is connected to my master (satellite configured such that it connects to the master, not the other way round!).
0 kommentar(er)
