Debugging sd_notify / tracing notifications?

[John Ioannidis <systemd-devel@xxxxxxx>]

How can I trace what sd_notify(3) calls a program makes?

Obviously, I don't have the source, and running strings on it does reveal a READY=1 line, but it is unclear whether the code makes it to the point where that gets sent.

Here is what I am *really* trying to accomplish; maybe I am going about it the wrong way:

I have some vendor code that is invoked by the following service file:

[Service]
ExecStart=/opt/vendor/bin/foo
Restart=always
User=root
Type=notify
NotifyAccess=exec
TimeoutStopSec=86400

I occasionally need to send a SIGINT to the process, but finding it with the equivalent of ps ax | grep foo is annoying and maybe not terribly reliable. My first workaround was to create this script:

#!/bin/sh
/opt/vendor/bin/foo &
pid=$!
echo $pid > /run/foo.pid
wait

and change the [Service] part of the service file to:

 

[Service]
ExecStart=/usr/local/sbin/run-foo.sh
Restart=always
User=root

Type=notify
NotifyAccess=all
TimeoutStopSec=86400

the idea being that the original program will still send the sd_notify(), and I would have its pid.

However, this is not happening; systemctl start foo.service hangs for about 30s, and then exits with:

Job for foo.service failed because a timeout was exceeded.
See "systemctl status foo.service" and "journalctl -xe" for details.

The relevant lines are:

systemd[1]: foo.service: start operation timed out. Terminating.

systemd[1]: foo.service: Main process exited, code=exited, status=143/n/a

systemd[1]: foo.service: Failed with result 'timeout'.

systemd[1]: Failed to start Foo.

Clearly I'm misunderstanding something about how sdnotify is supposed to work. It would also help if I could *see* what is actually being sent.

Help?

Thanks,

/ji

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel