Hello Michael, On Sunday 28 October 2012 11:28 PM, Michael Biebl wrote: > Is the forking/polling process the main process that stays around? > Do you have more then one long running process? > For a Type=forking service systemd tries to get the MainPID so it can > properly monitor the service and detect crashes. > Usually you supply a PIDFile option, telling systemd the PID of the main > process for Type=forking services. >
LMT is not a daemon. It is a script which runs and then exits. Earlier, it used to be invoked through acpid (and also through pm-utils during swsusp resume) events, but lately, if prefer udev much more. The only exception is the lm-polling-daemon script, which gets invoked (and backgrounded), if LMT senses that the machine is on battery. THis is done to check the machine state every 120 secs. The initscript option was given for a manual invocation by the user. Of course, the user could have also invoked the script directly. Providing it as a init script also portrayed it as a service. What I am looking with LMT + systemd support, is a plain an simple service which runs at boot and then just exits. Further invocation will simply be handled by events daemons like udev/acpid. Do you think Type=forking would be a fit here? > It could be, that in your case systemd was not tracking the correct > process. If PIDFile is not set, systemd will try to guess the main pid. > You can try changing the parameter to > GuessMainPID=no I will try it now. > Or you can record the pid of the polling process in a /var/run/foo.pid > file and tell systemd that via the > PIDFile option. See systemd.service. > > That all said, it seems you are doing some overly complex and brittle > stuff with shell. > If you need a monitoring daemon, maybe another solution then polling > shell processes would be better. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature
