[systemd-devel] type=notify not working as intended

[Lennart Poettering]

On Di, 15.08.17 09:29, Kalpa Gunarathna (kalpa at sigscale.com) wrote:

> Hello all,
> 
> I have scripted a service unit as follow.
> 
> [Unit]
> Description="A test service"
> After=epmd.service epmd.socket
> 
> [Service]
> ExecStart=/home/otpuser/bin/start
> Type=notify
> NotifyAccess=all
> WorkingDirectory=~
> User=otpuser
> Group=otp
> Restart=always
> RestartSec=3
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> ExecStart directs to a shell script which starts a Erlang run_erl daemon.
> This daemon is forking a process which is the BEAM virtual machine. In the
> forked process Im sending "READY=1\nSTATUS=Initialized\nMAINPID="
> <<Forked-Process-Pid>> "\n to systemd via sd_notify. The problem is service
> is getting restarted constantly.

When you use Type=notify, then the main process of the daemon defines
the runtime of your service. That means you probably want to use the
shell's "exec" command to replace the shell script with your erlang
daemon. if you instead just fork it off, and exit in the shell script,
then systemd will notice that it exited and will consider the service
dead.

> journalctl give this
> 
> abc.service: Service hold-off time over, scheduling restart.
> Stopped "A test service.".
> 
> 
> Is it required to send READY=1 from the daemon it self ? or can systemd
> allow forked process of the daemon to send REDAY=1 notification?

It needs to come from any process that is witelisted using
NotifyAccess=. Note though that there's a bit of a race: if you send
READY=1 and immediately exit from the process doing that, then systemd
can't properly relate the message to the service (that's a race we
can#t fix without kernel support), except if the process is actually
the one systemd forked off. Hence, sd_notify(READY=1) works reliably only if either:

1. it is invoked by the immediate process systemd forked off

or

2. the process is long-running and stays around for longer after
   sending READY=1

Lennart

-- 
Lennart Poettering, Red Hat