Re: [systemd-devel] Debugging sd_notify / tracing notifications?
On Mon, 01 Mar 2021 at 10:20:31 -0500, John Ioannidis wrote: > I occasionally need to send a SIGINT to the process Have you tried this? systemctl kill --signal=SIGINT foo.service (Perhaps with --kill-who=main if you just want to kill its top-level process and not its child processes, if any) smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging sd_notify / tracing notifications?
On Mo, 01.03.21 10:20, John Ioannidis (systemd-de...@tla.org) wrote: > How can I trace what sd_notify(3) calls a program makes? strace. sd_notify() is just a wrapper around the sendmsg() syscall, and you'll see that in strace. > 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/fooRestart=alwaysUser=rootType=notifyNotifyAccess=execTimeoutStopSec=86400* Your mailer is really broken. > 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: Try: systemctl show -P MainPID foobar.service > *[Service]ExecStart=/usr/local/sbin/run-foo.shRestart=alwaysUser=root* > > *Type=notifyNotifyAccess=allTimeoutStopSec=86400* You'd need to update the $NOTIFY_PID en vvar to the child process' PID for this to work. > 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: Maybe the service actually checks if getppid() == 1 or so? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Debugging sd_notify / tracing notifications?
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/fooRestart=alwaysUser=rootType=notifyNotifyAccess=execTimeoutStopSec=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 =$!echo $pid > /run/foo.pidwait* and change the [Service] part of the service file to: *[Service]ExecStart=/usr/local/sbin/run-foo.shRestart=alwaysUser=root* *Type=notifyNotifyAccess=allTimeoutStopSec=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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
