On Wed, 06 Nov 2019 22:43:55 +0100 deloptes <deloptes@xxxxxxxxx> wrote: > deloptes wrote: > > > David C. Rankin wrote: > > > >> You can look at: > >> > >> Quick-and-dirty way to ensure only one instance of a shell script is > >> running at a time > >> > > > https://stackoverflow.com/questions/185451/quick-and-dirty-way-to-ensure-only-one-instance-of-a-shell-script-is-running-at > >> > >> Whether you are starting the application from the shell or calling exec > >> from within an application, the process will be the same. > >> > >> That is the basic reason for the Linux /run directory. At its simplest, > >> form, to ensure only one instance is running you simply check whether a > >> pidfile exists in some directory, and if not start the app and write the > >> pid of the application to the pidfile. This provides the benefit of being > >> able to simply read the pidfile to get the pid of the current running > >> instance. > >> > > > > Yes I looked at /run. > > All of these scripting examples are not appropriate for the use case I > > have - in fact I find them ugly - I do not want to write pid files or lock > > files anywhere. TDE works very well with KUniqueApplication, when forked. > > The problem is after it is forked, I loose control over it from the > > application that started the process. I am also thinking of adding a dbus > > method stop() as the application is already present in dbus(). To me it > > looks the easiest way to control it. > > And while writing this I remembered that KUniqueApplication is unique > because it registers in dcop. DBus - dcop ... the light switched on and oh > wonder - there is a quit() method in dcop. > > I am just not sure if dcop is user specific or is global service for all > users. So can User A start something and User B stop it via dcop? According to dcop --help, it's one instance per user, but you can specify a user or session whose dcop you want to contact by using the appropriate options (or send to everyone). E. Liddell --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@xxxxxxxxxxxxxxxxxxxxxxxxxx For additional commands, e-mail: trinity-devel-help@xxxxxxxxxxxxxxxxxxxxxxxxxx Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
