[systemd-bugs] [Bug 90273] 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)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90273

--- Comment #3 from Lennart Poettering <lennart at poettering.net> ---
(In reply to Zbigniew Jedrzejewski-Szmek from comment #2)
> 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...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20150518/0d493145/attachment.html>