 2️⃣0️⃣ Here's the 20th post highlighting key new features of the upcoming v257 release of systemd. #systemd257 systemd-journald is systemd's log service that collects logs from system services, acquires some metadata and then stores all that in a mostly append-only linear database on disk, keyed by a multitude of metadata fields. One such field is the "invocation ID". The invocation ID is a 128bit randomized ID that every systemd unit gets freshly assigned whenever it enters its start phase. 3 comments
…(which is: identifying a specific reboot cycle universally and uniquely), the invocation ID does for an individual unit (which is: identifying a specific start cycle universally and uniquely). Because of the conceptual similarity between boot IDs and unit invocation IDs, in v257 we decided to expose them in a similar way as boot IDs in journalctl. Or in other words: for boot IDs you can use journalctl --list-boots/--boot=/-b to enumerate or filter, or focus on most recent boot. And for invocation IDs you can now use journalctl --list-invocations/--invocation=/-I to enumerate or filter, or focus on most recent invocations. (You might combine this with --unit=/-u depending on context.) Simple example: "journalctl -u systemd-hostnamed -I". And that's all for today. Enjoy! |
Gregory's Server
Thus, if the same service gets started 5 times iteratively, it will have 5 different invocation IDs assigned. And if you want to pinpoint a specific invocation of a service, it's the invocation ID you can use to uniquely identify it. (Besides the use as metadata when logging the invocation ID is also passed via the env var $INVOCATION_ID to the services btw; and systemctl status also shows it these days.)
One could say that what the Linux boot ID does for the system…