Commit 66246fff authored by Simon McVittie's avatar Simon McVittie

bus: Clear INVOCATION_ID when carrying out traditional activation

We weren't sure whether this one should be inherited or not, so I
asked on systemd-devel, and Lennart thought it shouldn't.
Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104641Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
parent b6b33485
......@@ -862,7 +862,6 @@ populate_environment (BusActivation *activation)
* - TERM, WATCHDOG_*: Should not be set for dbus-daemon, so not applicable
* - MAINPID, SERVICE_RESULT, EXIT_CODE, EXIT_STATUS: Not set for ExecStart,
* so not applicable
* - INVOCATION_ID: TODO: Do we want to clear this or not? It isn't clear.
*/
/* We give activated services their own Journal stream to avoid their
......@@ -878,6 +877,13 @@ populate_environment (BusActivation *activation)
* (and NotifyAccess wouldn't let it write here anyway) */
_dbus_hash_table_remove_string (activation->environment, "NOTIFY_SOCKET");
/* This identifies the dbus-daemon invocation. Whether it should be
* inherited by "smaller" services isn't entirely clear-cut, but not
* inheriting it makes traditional D-Bus activation under systemd a
* little more consistent with systemd activation.
* https://lists.freedesktop.org/archives/systemd-devel/2018-March/040467.html */
_dbus_hash_table_remove_string (activation->environment, "INVOCATION_ID");
return retval;
}
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment