From: Lennart Poettering Date: Tue, 27 Sep 2022 10:18:43 +0000 (+0200) Subject: man: document the Dump() calls of the PID 1 D-Bus interface, and what they are X-Git-Tag: v252-rc1~58^2~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=0df8512124b05ed2d3be1537a4023e89ec33f0f7;p=thirdparty%2Fsystemd.git man: document the Dump() calls of the PID 1 D-Bus interface, and what they are --- diff --git a/man/org.freedesktop.systemd1.xml b/man/org.freedesktop.systemd1.xml index 741a72d2649..6127541f8bf 100644 --- a/man/org.freedesktop.systemd1.xml +++ b/man/org.freedesktop.systemd1.xml @@ -562,10 +562,6 @@ node /org/freedesktop/systemd1 { - - - - @@ -1336,6 +1332,20 @@ node /org/freedesktop/systemd1 { all clients which previously asked for Subscribe() either closed their connection to the bus or invoked Unsubscribe(). + Dump() returns a text dump of the internal service manager state. This is a + privileged, low-level debugging interface only. The returned string is supposed to be readable + exclusively by developers, and not programmatically. There's no interface stability on the returned + string guaranteed, and new fields may be added any time, and old fields removed. The general structure + may be rearranged drastically between releases. This is exposed by + systemd-analyze1's + dump command. The DumpByFileDescriptor() method is identical to + Dump() but returns the data serialized into a file descriptor (the client should + read the text data from it until hitting EOF). Given the size limits on D-Bus messages and the possibly + large size of the returned string, DumpByFileDescriptor() is usually the + preferable interface, since it ensures the data can be passed reliably from the service manager to the + client. (Note though that DumpByFileDescriptor() cannot work when communicating + with the service manager remotely, as file descriptors are strictly local to a system.) + Reload() may be invoked to reload all unit files. Reexecute() may be invoked to reexecute the main manager process. It will