diff options
author | Michal Sekletár <msekleta@redhat.com> | 2020-08-24 11:21:44 +0200 |
---|---|---|
committer | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2021-06-15 18:28:28 +0200 |
commit | b428efa54bc9f8851514c595f14020a99fcf62a7 (patch) | |
tree | a35d19685554bf3e3bc100afe896d17226dc47ce /src/udev/udev-event.c | |
parent | b2e8fdc89604fc68f14c13c70191659140b85d92 (diff) | |
download | systemd-b428efa54bc9f8851514c595f14020a99fcf62a7.tar.gz |
udev: add basic set of user-space defined tracepoints (USDT)
Debugging udev issues especially during the early boot is fairly
difficult. Currently, you need to enable (at least) debug logging and
start monitoring uevents, try to reproduce the issue and then analyze
and correlate two (usually) huge log files. This is not ideal.
This patch aims to provide much more focused debugging tool,
tracepoints. More often then not we tend to have at least the basic idea
about the issue we are trying to debug further, e.g. we know it is
storage related. Hence all of the debug data generated for network
devices is useless, adds clutter to the log files and generally
slows things down.
Using this set of tracepoints you can start asking very specific
questions related to event processing for given device or subsystem.
Tracepoints can be used with various tracing tools but I will provide
examples using bpftrace.
Another important aspect to consider is that using tracepoints you can
debug production systems. There is no need to install test packages with
added logging, no debuginfo packages, etc...
Example usage (you might be asking such questions during the debug session),
Q: How can I list all tracepoints?
A: bpftrace -l 'usdt:/usr/lib/systemd/systemd-udevd:udev:*'
Q: What are the arguments for each tracepoint?
A: Look at the code and search for use of DEVICE_TRACE_POINT macro.
Q: How many times we have executed external binary?
A: bpftrace -e 'usdt:/usr/lib/systemd/systemd-udevd:udev:spawn_exec { @cnt = count(); }'
Q: What binaries where executed while handling events for "dm-0" device?
A bpftrace -e 'usdt:/usr/lib/systemd/systemd-udevd:udev:spawn_exec / str(arg1) == "dm-0"/ { @cmds[str(arg4)] = count(); }'
Thanks to Thomas Weißschuh <thomas@t-8ch.de> for reviewing this patch
and contributions that allowed us to drop the dependency on dtrace tool
and made the resulting code much more concise.
Diffstat (limited to 'src/udev/udev-event.c')
-rw-r--r-- | src/udev/udev-event.c | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/src/udev/udev-event.c b/src/udev/udev-event.c index f40b3120ca..8a01e2512e 100644 --- a/src/udev/udev-event.c +++ b/src/udev/udev-event.c @@ -603,6 +603,8 @@ static int on_spawn_timeout(sd_event_source *s, uint64_t usec, void *userdata) { assert(spawn); + DEVICE_TRACE_POINT(spawn_timeout, spawn->device, spawn->cmd); + kill_and_sigcont(spawn->pid, spawn->timeout_signal); log_device_error(spawn->device, "Spawned process '%s' ["PID_FMT"] timed out after %s, killing", @@ -648,6 +650,8 @@ static int on_spawn_sigchld(sd_event_source *s, const siginfo_t *si, void *userd log_device_error(spawn->device, "Process '%s' failed due to unknown reason.", spawn->cmd); } + DEVICE_TRACE_POINT(spawn_exit, spawn->device, spawn->cmd); + sd_event_exit(sd_event_source_get_event(s), ret); return 1; } @@ -785,6 +789,8 @@ int udev_event_spawn(UdevEvent *event, (void) close_all_fds(NULL, 0); (void) rlimit_nofile_safe(); + DEVICE_TRACE_POINT(spawn_exec, event->dev, cmd); + execve(argv[0], argv, envp); _exit(EXIT_FAILURE); } @@ -1014,10 +1020,14 @@ int udev_event_execute_rules( return r; } + DEVICE_TRACE_POINT(rules_start, dev); + r = udev_rules_apply_to_event(rules, event, timeout_usec, timeout_signal, properties_list); if (r < 0) return log_device_debug_errno(dev, r, "Failed to apply udev rules: %m"); + DEVICE_TRACE_POINT(rules_finished, dev); + r = rename_netif(event); if (r < 0) return r; |