Hi!
> > Yes, in my usecase this would be used at the place where sd_notify()
> > is used if the service runs under systemd. Then periodically executed
> > watchdog could check the service makes progress and react if it
> > doesn't.
>
> If a single notification step is enough for you, i.e. the se
Petr Malat said on Tue, 19 Oct 2021 09:41:19 +0200
>Yes, in my usecase this would be used at the place where sd_notify()
>is used if the service runs under systemd. Then periodically executed
>watchdog could check the service makes progress and react if it
>doesn't.
>
>The question is how to imple
Yes, in my usecase this would be used at the place where sd_notify()
is used if the service runs under systemd. Then periodically executed
watchdog could check the service makes progress and react if it
doesn't.
The question is how to implement the watchdog then - it could be either
a global serv
Yes, in my usecase this would be used at the place where sd_notify()
is used if the service runs under systemd. Then periodically executed
watchdog could check the service makes progress and react if it
doesn't.
The question is how to implement the watchdog then - it could be either
a global servi
Is this some genre of continuous readiness notification, or so?
On 19 October 2021 07:20:41 UTC, Petr Malat wrote:
>Hi,
>I'm using the busybox implementation of runit to manage services and I
>miss some kind of a watchdog in runsv. I though about extending
>supervise/control pipe by a status comm
Hi,
I'm using the busybox implementation of runit to manage services and I
miss some kind of a watchdog in runsv. I though about extending
supervise/control pipe by a status command which would allow to publish
a status, for example 's Running'. Runsv would then append a monotonic
timestamp when it