Thanks David and Zbyszek
Yes with BindsTo parameter it works
David
I was trying out the options in the unit file hence PID parameter came
in. I forgot to remove that later :-(
some more questions in the same thread -
1. How do I trace the heartbeat message - or rather can I capture the
systemd-notify messages being sent by the process.
2. Is there any way I can see whether systemd captured the notification
or missed it. The reason why I am asking this is - my process runs for some
time and all the while it sends WATCHDOG notification in every 5 seconds.
But systemd made the process failed saying watchdog timeout.
3. One more use case I can think of is - if the process fail to send
heartbeat message ( WATCHDOG ) for some time and later it starts sending -
because of some time. So during the time WATCHDOG notification is missing
process can be marked as failed and the moment notification start coming,
can it be marked as active-running ?
4. Is there way systemd can notify me in case a watchdog timeout
happens for a service - like systemd calls some program or write to some
socket etc. So basically in case any service fails because of watchdog
timeout, I would like to know asynchronously. Is there any way I can
configure this.
Thanks
Salil
On 21 November 2013 09:02, David Timothy Strauss <da...@davidstrauss.net>wrote:
> The service configuration is strange. Normally, this is how they work
> with dependencies:
>
> * Type=simple considers the service started immediately on exec()
> with no respect for PIDFiles or sd_notify. This can cause dependent
> services to come up too early.
> * Type=forking considers the service started when either the file
> specified in PIDFile= appears or when the service completes a double
> fork.
> * Type=notify is like Type=simple, except that it relies on sd_notify
> to indicate final startup.
> * Type=bus is like Type=simple, except that it waits for the dbus
> listener to indicate final startup.
>
> You have PIDFile= specified, which is for Type=forking. I think
> PIDFile= just gets ignored for Type=simple (the default). So, for one,
> I'd pick a more coherent startup-detection configuration.
>
> More interesting is how Myservice gets marked "failed" but isn't
> forcibly stopped. That may be why systemd isn't bringing down
> dependent services. Most services only get marked "failed" after
> stopping (because of a non-zero exit code, for example).
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
