<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - RFE: make it easy to plug in monitor tools that are run after completion of specific services and can process their logs (example: sendmail tool that mails service logs)" href="https://bugs.freedesktop.org/show_bug.cgi?id=90273#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - RFE: make it easy to plug in monitor tools that are run after completion of specific services and can process their logs (example: sendmail tool that mails service logs)" href="https://bugs.freedesktop.org/show_bug.cgi?id=90273">bug 90273</a> from <a class="email" href="mailto:lennart@poettering.net" title="Lennart Poettering <lennart@poettering.net>"> Lennart Poettering</a> <pre>(In reply to Zbigniew Jedrzejewski-Szmek from <a href="show_bug.cgi?id=90273#c2">comment #2</a>) > I wonder is we should have a generic SYSTEMD_UNIT_INSTANCE=<uuid> field > (better name needed), which systemd (PID 1 and the --user instances) would > add to all messages about a given a service. It would be reset when the > service is stopped or restarted. Then journalctl could do something similar > to --list-boots, and gather all the intervals between when <uuid> was first > and last seen, and then use that to construe a time-range limit. This time > limit would then be combined with normal filtering for a unit. This would > give generic support for doing > journalctl --unit=<...> --unit-run=<n> Yeah, that sounds like a really good idea to me. I think a "unit runtime id" would make a ton of sense, to correspond with the boot id of the system, which one could also call a "system runtime id" after all... Ideally we'd assign one when we change from INACTIVE to ACTIVATING of a unit, and would provide APIs to query it for any running service, and make it non-fakable. Then, we could add "int sd_pid_get_runtime_id(pid_t pid, sd_id128_t *ret)" to sd-login.h to query it. I think the runtime id should be unique across units, so that it would suffice to use "journalctl _SYSTEMD_UNIT_RUNTIME_ID=..." to match the runtime of one specific service. (i.e. no need to combine this with --unit=) Of course, the question is how to best attach the id to a service, so that we not only can read it via dbus, but also synchronously via direct fs access for usage in sd-login.h. One option would be to maintain a set of symlinks in /run/systemd/units, that are named after the unit, and point to the runtime id (using symlinks here has the benefit that we can easily create them atomically...). Another question is how to best add support for this to the stream protocol spoken between pid 1 and journald, so that we avoid breaking compat for it (this isn't crucial, but still kinda nice to make live upgrades not worse than necessary, in particular since the --user instances of systemd speak the protocol with the system journald too.) One option could be to encode this in the same line as the unit name, but seperate it with a slash or so (since a slash cannot be part of a unit name). Then, journald would look for the slash, if it is there it parses out the unit runtime id, otherwise it would consider it unset. As long as we restart journald on upgrades we should be fine then...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>