From b750101eb236130cf056c675997decbac904cc49 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 17:35:18 +0200 Subject: Adding upstream version 252.22. Signed-off-by: Daniel Baumann --- man/.dir-locals.el | 15 + man/50-xdg-data-dirs.sh | 13 + man/90-rearrange-path.py | 41 + man/binfmt.d.xml | 74 + man/bootctl.xml | 537 ++ man/bootup.xml | 358 + man/busctl.xml | 526 ++ man/check-os-release-simple.py | 12 + man/check-os-release.py | 37 + man/check-os-release.sh | 11 + man/common-variables.xml | 202 + man/coredump.conf.xml | 146 + man/coredumpctl.xml | 438 + man/crypttab.xml | 867 ++ man/custom-entities.ent.in | 19 + man/custom-html.xsl | 318 + man/custom-man.xsl | 49 + man/daemon.xml | 731 ++ man/directives-template.xml | 206 + man/dnssec-trust-anchors.d.xml | 172 + man/environment.d.xml | 133 + man/event-quick-child.c | 42 + man/fido2-crypttab.sh | 12 + man/file-hierarchy.xml | 830 ++ man/glib-event-glue.c | 48 + man/halt.xml | 160 + man/homectl.xml | 1063 +++ man/homed.conf.xml | 84 + man/hostname.xml | 116 + man/hostnamectl.xml | 211 + man/html.in | 29 + man/hwdb-usb-device.c | 30 + man/hwdb.xml | 154 + man/id128-app-specific.c | 13 + man/inotify-watch-tmp.c | 58 + man/integritytab.xml | 161 + man/journal-enumerate-fields.c | 22 + man/journal-iterate-foreach.c | 31 + man/journal-iterate-poll.c | 27 + man/journal-iterate-unique.c | 29 + man/journal-iterate-wait.c | 45 + man/journal-remote.conf.xml | 100 + man/journal-stream-fd.c | 29 + man/journal-upload.conf.xml | 101 + man/journalctl.xml | 956 ++ man/journald.conf.xml | 511 ++ man/kernel-command-line.xml | 602 ++ man/kernel-install.xml | 392 + man/libsystemd-pkgconfig.xml | 13 + man/libudev.xml | 98 + man/loader.conf.xml | 359 + man/locale.conf.xml | 128 + man/localectl.xml | 211 + man/localtime.xml | 72 + man/logcontrol-example.c | 232 + man/loginctl.xml | 430 + man/logind.conf.xml | 371 + man/machine-id.xml | 203 + man/machine-info.xml | 171 + man/machinectl.xml | 993 +++ man/man.in | 30 + man/meson.build | 240 + man/modules-load.d.xml | 76 + man/networkctl.xml | 434 + man/networkd.conf.xml | 221 + man/nss-myhostname.xml | 138 + man/nss-mymachines.xml | 137 + man/nss-resolve.xml | 166 + man/nss-systemd.xml | 183 + man/oomctl.xml | 86 + man/oomd.conf.xml | 100 + man/org.freedesktop.LogControl1.xml | 143 + man/org.freedesktop.home1.xml | 533 ++ man/org.freedesktop.hostname1.xml | 403 + man/org.freedesktop.import1.xml | 343 + man/org.freedesktop.locale1.xml | 188 + man/org.freedesktop.login1.xml | 1489 ++++ man/org.freedesktop.machine1.xml | 673 ++ man/org.freedesktop.network1.xml | 502 ++ man/org.freedesktop.oom1.xml | 98 + man/org.freedesktop.portable1.xml | 569 ++ man/org.freedesktop.resolve1.xml | 895 ++ man/org.freedesktop.systemd1.xml | 10819 +++++++++++++++++++++++ man/org.freedesktop.timedate1.xml | 200 + man/os-release.xml | 565 ++ man/pam_systemd.xml | 349 + man/pam_systemd_home.xml | 175 + man/path-documents.c | 19 + man/portablectl.xml | 474 + man/print-unit-path-call-method.c | 51 + man/print-unit-path.c | 60 + man/pstore.conf.xml | 89 + man/repart.d.xml | 770 ++ man/resolvectl.xml | 581 ++ man/resolved.conf.xml | 352 + man/rules/meson.build | 1201 +++ man/runlevel.xml | 162 + man/sd-bus-container-append.c | 19 + man/sd-bus-container-read.c | 27 + man/sd-bus-errors.xml | 275 + man/sd-bus.xml | 192 + man/sd-daemon.xml | 114 + man/sd-device.xml | 62 + man/sd-event.xml | 164 + man/sd-hwdb.xml | 57 + man/sd-id128.xml | 283 + man/sd-journal.xml | 118 + man/sd-login.xml | 247 + man/sd_booted.xml | 68 + man/sd_bus_add_match.xml | 173 + man/sd_bus_add_node_enumerator.xml | 138 + man/sd_bus_add_object.xml | 692 ++ man/sd_bus_add_object_manager.xml | 118 + man/sd_bus_attach_event.xml | 119 + man/sd_bus_call.xml | 200 + man/sd_bus_call_method.xml | 156 + man/sd_bus_can_send.xml | 93 + man/sd_bus_close.xml | 119 + man/sd_bus_creds_get_pid.xml | 526 ++ man/sd_bus_creds_new_from_pid.xml | 315 + man/sd_bus_default.xml | 349 + man/sd_bus_emit_signal.xml | 243 + man/sd_bus_enqueue_for_read.xml | 88 + man/sd_bus_error-example.c | 18 + man/sd_bus_error.xml | 408 + man/sd_bus_error_add_map.xml | 134 + man/sd_bus_get_current_handler.xml | 86 + man/sd_bus_get_fd.xml | 177 + man/sd_bus_get_n_queued_read.xml | 100 + man/sd_bus_get_name_creds.xml | 121 + man/sd_bus_get_name_machine_id.xml | 98 + man/sd_bus_interface_name_is_valid.xml | 98 + man/sd_bus_is_open.xml | 106 + man/sd_bus_list_names.xml | 110 + man/sd_bus_message_append.xml | 239 + man/sd_bus_message_append_array.xml | 179 + man/sd_bus_message_append_basic.xml | 261 + man/sd_bus_message_append_string_memfd.xml | 119 + man/sd_bus_message_append_strv.xml | 81 + man/sd_bus_message_at_end.xml | 86 + man/sd_bus_message_copy.xml | 111 + man/sd_bus_message_dump.xml | 108 + man/sd_bus_message_get_cookie.xml | 107 + man/sd_bus_message_get_monotonic_usec.xml | 141 + man/sd_bus_message_get_signature.xml | 111 + man/sd_bus_message_get_type.xml | 167 + man/sd_bus_message_new.xml | 188 + man/sd_bus_message_new_method_call.xml | 172 + man/sd_bus_message_new_method_error.xml | 187 + man/sd_bus_message_new_signal.xml | 121 + man/sd_bus_message_open_container.xml | 183 + man/sd_bus_message_read.xml | 275 + man/sd_bus_message_read_array.xml | 116 + man/sd_bus_message_read_basic.xml | 237 + man/sd_bus_message_read_strv.xml | 113 + man/sd_bus_message_rewind.xml | 88 + man/sd_bus_message_seal.xml | 106 + man/sd_bus_message_sensitive.xml | 85 + man/sd_bus_message_set_destination.xml | 151 + man/sd_bus_message_set_expect_reply.xml | 147 + man/sd_bus_message_skip.xml | 108 + man/sd_bus_message_verify_type.xml | 99 + man/sd_bus_negotiate_fds.xml | 163 + man/sd_bus_new.xml | 199 + man/sd_bus_path_encode.xml | 153 + man/sd_bus_process.xml | 133 + man/sd_bus_query_sender_creds.xml | 134 + man/sd_bus_reply_method_error.xml | 176 + man/sd_bus_reply_method_return.xml | 123 + man/sd_bus_request_name.xml | 210 + man/sd_bus_send.xml | 168 + man/sd_bus_set_address.xml | 188 + man/sd_bus_set_close_on_exit.xml | 108 + man/sd_bus_set_connected_signal.xml | 109 + man/sd_bus_set_description.xml | 249 + man/sd_bus_set_exit_on_disconnect.xml | 114 + man/sd_bus_set_fd.xml | 120 + man/sd_bus_set_method_call_timeout.xml | 103 + man/sd_bus_set_property.xml | 173 + man/sd_bus_set_sender.xml | 103 + man/sd_bus_set_server.xml | 193 + man/sd_bus_set_watch_bind.xml | 118 + man/sd_bus_slot_get_bus.xml | 90 + man/sd_bus_slot_ref.xml | 94 + man/sd_bus_slot_set_description.xml | 105 + man/sd_bus_slot_set_destroy_callback.xml | 130 + man/sd_bus_slot_set_floating.xml | 117 + man/sd_bus_slot_set_userdata.xml | 88 + man/sd_bus_start.xml | 124 + man/sd_bus_track_add_name.xml | 228 + man/sd_bus_track_new.xml | 231 + man/sd_bus_wait.xml | 113 + man/sd_device_get_syspath.xml | 200 + man/sd_device_ref.xml | 85 + man/sd_event_add_child.xml | 352 + man/sd_event_add_defer.xml | 202 + man/sd_event_add_inotify.xml | 234 + man/sd_event_add_io.xml | 311 + man/sd_event_add_signal.xml | 207 + man/sd_event_add_time.xml | 326 + man/sd_event_exit.xml | 150 + man/sd_event_get_fd.xml | 111 + man/sd_event_new.xml | 218 + man/sd_event_now.xml | 114 + man/sd_event_run.xml | 164 + man/sd_event_set_signal_exit.xml | 101 + man/sd_event_set_watchdog.xml | 145 + man/sd_event_source_get_event.xml | 74 + man/sd_event_source_get_pending.xml | 137 + man/sd_event_source_set_description.xml | 140 + man/sd_event_source_set_destroy_callback.xml | 112 + man/sd_event_source_set_enabled.xml | 156 + man/sd_event_source_set_exit_on_failure.xml | 108 + man/sd_event_source_set_floating.xml | 118 + man/sd_event_source_set_prepare.xml | 142 + man/sd_event_source_set_priority.xml | 166 + man/sd_event_source_set_ratelimit.xml | 160 + man/sd_event_source_set_userdata.xml | 93 + man/sd_event_source_unref.xml | 132 + man/sd_event_wait.xml | 324 + man/sd_get_seats.xml | 118 + man/sd_hwdb_get.xml | 157 + man/sd_hwdb_new.xml | 131 + man/sd_id128_get_machine.xml | 212 + man/sd_id128_randomize.xml | 80 + man/sd_id128_to_string.xml | 122 + man/sd_is_fifo.xml | 201 + man/sd_journal_add_match.xml | 177 + man/sd_journal_enumerate_fields.xml | 114 + man/sd_journal_get_catalog.xml | 113 + man/sd_journal_get_cursor.xml | 114 + man/sd_journal_get_cutoff_realtime_usec.xml | 114 + man/sd_journal_get_data.xml | 276 + man/sd_journal_get_fd.xml | 259 + man/sd_journal_get_realtime_usec.xml | 112 + man/sd_journal_get_usage.xml | 71 + man/sd_journal_has_runtime_files.xml | 79 + man/sd_journal_next.xml | 148 + man/sd_journal_open.xml | 225 + man/sd_journal_print.xml | 276 + man/sd_journal_query_unique.xml | 175 + man/sd_journal_seek_head.xml | 131 + man/sd_journal_stream_fd.xml | 120 + man/sd_listen_fds.xml | 238 + man/sd_login_monitor_new.xml | 249 + man/sd_machine_get_class.xml | 116 + man/sd_notify.xml | 471 + man/sd_path_lookup.xml | 215 + man/sd_pid_get_owner_uid.xml | 312 + man/sd_seat_get_active.xml | 162 + man/sd_session_is_active.xml | 315 + man/sd_uid_get_state.xml | 191 + man/sd_watchdog_enabled.xml | 142 + man/send-unit-files-changed.c | 18 + man/shutdown.xml | 156 + man/standard-conf.xml | 71 + man/standard-options.xml | 89 + man/standard-specifiers.xml | 90 + man/supported-controllers.xml | 14 + man/sysctl.d.xml | 193 + man/system-only.xml | 16 + man/system-or-user-ns.xml | 16 + man/systemctl.xml | 2530 ++++++ man/systemd-analyze.xml | 1354 +++ man/systemd-ask-password-console.service.xml | 67 + man/systemd-ask-password.xml | 252 + man/systemd-backlight@.service.xml | 70 + man/systemd-binfmt.service.xml | 68 + man/systemd-bless-boot-generator.xml | 48 + man/systemd-bless-boot.service.xml | 113 + man/systemd-boot-check-no-failures.service.xml | 52 + man/systemd-boot-system-token.service.xml | 76 + man/systemd-boot.xml | 541 ++ man/systemd-cat.xml | 171 + man/systemd-cgls.xml | 147 + man/systemd-cgtop.xml | 349 + man/systemd-coredump.xml | 457 + man/systemd-creds.xml | 454 + man/systemd-cryptenroll.xml | 489 + man/systemd-cryptsetup-generator.xml | 224 + man/systemd-cryptsetup@.service.xml | 94 + man/systemd-debug-generator.xml | 85 + man/systemd-delta.xml | 178 + man/systemd-detect-virt.xml | 302 + man/systemd-dissect.xml | 308 + man/systemd-environment-d-generator.xml | 53 + man/systemd-escape.xml | 182 + man/systemd-firstboot.xml | 389 + man/systemd-fsck@.service.xml | 121 + man/systemd-fstab-generator.xml | 255 + man/systemd-getty-generator.xml | 97 + man/systemd-gpt-auto-generator.xml | 283 + man/systemd-halt.service.xml | 93 + man/systemd-hibernate-resume-generator.xml | 83 + man/systemd-hibernate-resume@.service.xml | 56 + man/systemd-homed.service.xml | 110 + man/systemd-hostnamed.service.xml | 82 + man/systemd-hwdb.xml | 84 + man/systemd-id128.xml | 138 + man/systemd-importd.service.xml | 56 + man/systemd-inhibit.xml | 154 + man/systemd-initctl.service.xml | 49 + man/systemd-integritysetup-generator.xml | 48 + man/systemd-integritysetup@.service.xml | 98 + man/systemd-journal-gatewayd.service.xml | 324 + man/systemd-journal-remote.service.xml | 348 + man/systemd-journal-upload.service.xml | 292 + man/systemd-journald.service.xml | 357 + man/systemd-localed.service.xml | 61 + man/systemd-logind.service.xml | 111 + man/systemd-machine-id-commit.service.xml | 74 + man/systemd-machine-id-setup.xml | 154 + man/systemd-machined.service.xml | 139 + man/systemd-makefs@.service.xml | 103 + man/systemd-measure.xml | 284 + man/systemd-modules-load.service.xml | 70 + man/systemd-mount.xml | 338 + man/systemd-network-generator.service.xml | 113 + man/systemd-networkd-wait-online.service.xml | 178 + man/systemd-networkd.service.xml | 97 + man/systemd-notify.xml | 196 + man/systemd-nspawn.xml | 1767 ++++ man/systemd-oomd.service.xml | 114 + man/systemd-path.xml | 81 + man/systemd-pcrphase.service.xml | 157 + man/systemd-portabled.service.xml | 51 + man/systemd-pstore.service.xml | 114 + man/systemd-quotacheck.service.xml | 69 + man/systemd-random-seed.service.xml | 93 + man/systemd-rc-local-generator.xml | 72 + man/systemd-remount-fs.service.xml | 70 + man/systemd-repart.xml | 390 + man/systemd-resolved.service.xml | 424 + man/systemd-rfkill.service.xml | 65 + man/systemd-run-generator.xml | 81 + man/systemd-run.xml | 559 ++ man/systemd-sleep.conf.xml | 235 + man/systemd-socket-activate.xml | 182 + man/systemd-socket-proxyd.xml | 184 + man/systemd-stdio-bridge.xml | 91 + man/systemd-stub.xml | 440 + man/systemd-suspend.service.xml | 127 + man/systemd-sysctl.service.xml | 161 + man/systemd-sysext.xml | 253 + man/systemd-system-update-generator.xml | 50 + man/systemd-system.conf.xml | 619 ++ man/systemd-sysupdate.xml | 287 + man/systemd-sysusers.xml | 217 + man/systemd-sysv-generator.xml | 76 + man/systemd-time-wait-sync.service.xml | 70 + man/systemd-timedated.service.xml | 105 + man/systemd-timesyncd.service.xml | 127 + man/systemd-tmpfiles.xml | 315 + man/systemd-tty-ask-password-agent.xml | 126 + man/systemd-udev-settle.service.xml | 51 + man/systemd-udevd.service.xml | 279 + man/systemd-update-done.service.xml | 76 + man/systemd-update-utmp.service.xml | 51 + man/systemd-user-sessions.service.xml | 50 + man/systemd-userdbd.service.xml | 73 + man/systemd-vconsole-setup.service.xml | 63 + man/systemd-veritysetup-generator.xml | 116 + man/systemd-veritysetup@.service.xml | 97 + man/systemd-volatile-root.service.xml | 55 + man/systemd-xdg-autostart-generator.xml | 106 + man/systemd.automount.xml | 190 + man/systemd.device.xml | 171 + man/systemd.dnssd.xml | 227 + man/systemd.environment-generator.xml | 134 + man/systemd.exec.xml | 4259 +++++++++ man/systemd.generator.xml | 359 + man/systemd.journal-fields.xml | 608 ++ man/systemd.kill.xml | 195 + man/systemd.link.xml | 1250 +++ man/systemd.mount.xml | 599 ++ man/systemd.net-naming-scheme.xml | 555 ++ man/systemd.netdev.xml | 2480 ++++++ man/systemd.network.xml | 4940 +++++++++++ man/systemd.nspawn.xml | 598 ++ man/systemd.offline-updates.xml | 163 + man/systemd.path.xml | 225 + man/systemd.preset.xml | 222 + man/systemd.resource-control.xml | 1286 +++ man/systemd.scope.xml | 143 + man/systemd.service.xml | 1567 ++++ man/systemd.slice.xml | 122 + man/systemd.socket.xml | 875 ++ man/systemd.special.xml | 1391 +++ man/systemd.swap.xml | 261 + man/systemd.syntax.xml | 229 + man/systemd.system-credentials.xml | 191 + man/systemd.target.xml | 143 + man/systemd.time.xml | 311 + man/systemd.timer.xml | 398 + man/systemd.unit.xml | 2432 +++++ man/systemd.xml | 1289 +++ man/sysupdate.d.xml | 885 ++ man/sysusers.d.xml | 299 + man/tc.xml | 48 + man/telinit.xml | 151 + man/threads-aware.xml | 15 + man/timedatectl.xml | 326 + man/timesyncd.conf.xml | 130 + man/tmpfiles.d.xml | 872 ++ man/tpm2-crypttab.sh | 12 + man/udev.conf.xml | 127 + man/udev.xml | 860 ++ man/udev_device_get_syspath.xml | 180 + man/udev_device_has_tag.xml | 170 + man/udev_device_new_from_syspath.xml | 187 + man/udev_enumerate_add_match_subsystem.xml | 136 + man/udev_enumerate_new.xml | 84 + man/udev_enumerate_scan_devices.xml | 106 + man/udev_list_entry.xml | 96 + man/udev_monitor_filter_update.xml | 95 + man/udev_monitor_new_from_netlink.xml | 86 + man/udev_monitor_receive_device.xml | 110 + man/udev_new.xml | 83 + man/udevadm.xml | 931 ++ man/user-system-options.xml | 58 + man/user@.service.xml | 194 + man/userdbctl.xml | 346 + man/vconsole.conf.xml | 144 + man/veritytab.xml | 198 + man/vtable-example.c | 112 + man/vtable-example.xml | 55 + man/yubikey-crypttab.sh | 28 + 427 files changed, 121616 insertions(+) create mode 100644 man/.dir-locals.el create mode 100755 man/50-xdg-data-dirs.sh create mode 100755 man/90-rearrange-path.py create mode 100644 man/binfmt.d.xml create mode 100644 man/bootctl.xml create mode 100644 man/bootup.xml create mode 100644 man/busctl.xml create mode 100644 man/check-os-release-simple.py create mode 100644 man/check-os-release.py create mode 100644 man/check-os-release.sh create mode 100644 man/common-variables.xml create mode 100644 man/coredump.conf.xml create mode 100644 man/coredumpctl.xml create mode 100644 man/crypttab.xml create mode 100644 man/custom-entities.ent.in create mode 100644 man/custom-html.xsl create mode 100644 man/custom-man.xsl create mode 100644 man/daemon.xml create mode 100644 man/directives-template.xml create mode 100644 man/dnssec-trust-anchors.d.xml create mode 100644 man/environment.d.xml create mode 100644 man/event-quick-child.c create mode 100644 man/fido2-crypttab.sh create mode 100644 man/file-hierarchy.xml create mode 100644 man/glib-event-glue.c create mode 100644 man/halt.xml create mode 100644 man/homectl.xml create mode 100644 man/homed.conf.xml create mode 100644 man/hostname.xml create mode 100644 man/hostnamectl.xml create mode 100755 man/html.in create mode 100644 man/hwdb-usb-device.c create mode 100644 man/hwdb.xml create mode 100644 man/id128-app-specific.c create mode 100644 man/inotify-watch-tmp.c create mode 100644 man/integritytab.xml create mode 100644 man/journal-enumerate-fields.c create mode 100644 man/journal-iterate-foreach.c create mode 100644 man/journal-iterate-poll.c create mode 100644 man/journal-iterate-unique.c create mode 100644 man/journal-iterate-wait.c create mode 100644 man/journal-remote.conf.xml create mode 100644 man/journal-stream-fd.c create mode 100644 man/journal-upload.conf.xml create mode 100644 man/journalctl.xml create mode 100644 man/journald.conf.xml create mode 100644 man/kernel-command-line.xml create mode 100644 man/kernel-install.xml create mode 100644 man/libsystemd-pkgconfig.xml create mode 100644 man/libudev.xml create mode 100644 man/loader.conf.xml create mode 100644 man/locale.conf.xml create mode 100644 man/localectl.xml create mode 100644 man/localtime.xml create mode 100644 man/logcontrol-example.c create mode 100644 man/loginctl.xml create mode 100644 man/logind.conf.xml create mode 100644 man/machine-id.xml create mode 100644 man/machine-info.xml create mode 100644 man/machinectl.xml create mode 100755 man/man.in create mode 100644 man/meson.build create mode 100644 man/modules-load.d.xml create mode 100644 man/networkctl.xml create mode 100644 man/networkd.conf.xml create mode 100644 man/nss-myhostname.xml create mode 100644 man/nss-mymachines.xml create mode 100644 man/nss-resolve.xml create mode 100644 man/nss-systemd.xml create mode 100644 man/oomctl.xml create mode 100644 man/oomd.conf.xml create mode 100644 man/org.freedesktop.LogControl1.xml create mode 100644 man/org.freedesktop.home1.xml create mode 100644 man/org.freedesktop.hostname1.xml create mode 100644 man/org.freedesktop.import1.xml create mode 100644 man/org.freedesktop.locale1.xml create mode 100644 man/org.freedesktop.login1.xml create mode 100644 man/org.freedesktop.machine1.xml create mode 100644 man/org.freedesktop.network1.xml create mode 100644 man/org.freedesktop.oom1.xml create mode 100644 man/org.freedesktop.portable1.xml create mode 100644 man/org.freedesktop.resolve1.xml create mode 100644 man/org.freedesktop.systemd1.xml create mode 100644 man/org.freedesktop.timedate1.xml create mode 100644 man/os-release.xml create mode 100644 man/pam_systemd.xml create mode 100644 man/pam_systemd_home.xml create mode 100644 man/path-documents.c create mode 100644 man/portablectl.xml create mode 100644 man/print-unit-path-call-method.c create mode 100644 man/print-unit-path.c create mode 100644 man/pstore.conf.xml create mode 100644 man/repart.d.xml create mode 100644 man/resolvectl.xml create mode 100644 man/resolved.conf.xml create mode 100644 man/rules/meson.build create mode 100644 man/runlevel.xml create mode 100644 man/sd-bus-container-append.c create mode 100644 man/sd-bus-container-read.c create mode 100644 man/sd-bus-errors.xml create mode 100644 man/sd-bus.xml create mode 100644 man/sd-daemon.xml create mode 100644 man/sd-device.xml create mode 100644 man/sd-event.xml create mode 100644 man/sd-hwdb.xml create mode 100644 man/sd-id128.xml create mode 100644 man/sd-journal.xml create mode 100644 man/sd-login.xml create mode 100644 man/sd_booted.xml create mode 100644 man/sd_bus_add_match.xml create mode 100644 man/sd_bus_add_node_enumerator.xml create mode 100644 man/sd_bus_add_object.xml create mode 100644 man/sd_bus_add_object_manager.xml create mode 100644 man/sd_bus_attach_event.xml create mode 100644 man/sd_bus_call.xml create mode 100644 man/sd_bus_call_method.xml create mode 100644 man/sd_bus_can_send.xml create mode 100644 man/sd_bus_close.xml create mode 100644 man/sd_bus_creds_get_pid.xml create mode 100644 man/sd_bus_creds_new_from_pid.xml create mode 100644 man/sd_bus_default.xml create mode 100644 man/sd_bus_emit_signal.xml create mode 100644 man/sd_bus_enqueue_for_read.xml create mode 100644 man/sd_bus_error-example.c create mode 100644 man/sd_bus_error.xml create mode 100644 man/sd_bus_error_add_map.xml create mode 100644 man/sd_bus_get_current_handler.xml create mode 100644 man/sd_bus_get_fd.xml create mode 100644 man/sd_bus_get_n_queued_read.xml create mode 100644 man/sd_bus_get_name_creds.xml create mode 100644 man/sd_bus_get_name_machine_id.xml create mode 100644 man/sd_bus_interface_name_is_valid.xml create mode 100644 man/sd_bus_is_open.xml create mode 100644 man/sd_bus_list_names.xml create mode 100644 man/sd_bus_message_append.xml create mode 100644 man/sd_bus_message_append_array.xml create mode 100644 man/sd_bus_message_append_basic.xml create mode 100644 man/sd_bus_message_append_string_memfd.xml create mode 100644 man/sd_bus_message_append_strv.xml create mode 100644 man/sd_bus_message_at_end.xml create mode 100644 man/sd_bus_message_copy.xml create mode 100644 man/sd_bus_message_dump.xml create mode 100644 man/sd_bus_message_get_cookie.xml create mode 100644 man/sd_bus_message_get_monotonic_usec.xml create mode 100644 man/sd_bus_message_get_signature.xml create mode 100644 man/sd_bus_message_get_type.xml create mode 100644 man/sd_bus_message_new.xml create mode 100644 man/sd_bus_message_new_method_call.xml create mode 100644 man/sd_bus_message_new_method_error.xml create mode 100644 man/sd_bus_message_new_signal.xml create mode 100644 man/sd_bus_message_open_container.xml create mode 100644 man/sd_bus_message_read.xml create mode 100644 man/sd_bus_message_read_array.xml create mode 100644 man/sd_bus_message_read_basic.xml create mode 100644 man/sd_bus_message_read_strv.xml create mode 100644 man/sd_bus_message_rewind.xml create mode 100644 man/sd_bus_message_seal.xml create mode 100644 man/sd_bus_message_sensitive.xml create mode 100644 man/sd_bus_message_set_destination.xml create mode 100644 man/sd_bus_message_set_expect_reply.xml create mode 100644 man/sd_bus_message_skip.xml create mode 100644 man/sd_bus_message_verify_type.xml create mode 100644 man/sd_bus_negotiate_fds.xml create mode 100644 man/sd_bus_new.xml create mode 100644 man/sd_bus_path_encode.xml create mode 100644 man/sd_bus_process.xml create mode 100644 man/sd_bus_query_sender_creds.xml create mode 100644 man/sd_bus_reply_method_error.xml create mode 100644 man/sd_bus_reply_method_return.xml create mode 100644 man/sd_bus_request_name.xml create mode 100644 man/sd_bus_send.xml create mode 100644 man/sd_bus_set_address.xml create mode 100644 man/sd_bus_set_close_on_exit.xml create mode 100644 man/sd_bus_set_connected_signal.xml create mode 100644 man/sd_bus_set_description.xml create mode 100644 man/sd_bus_set_exit_on_disconnect.xml create mode 100644 man/sd_bus_set_fd.xml create mode 100644 man/sd_bus_set_method_call_timeout.xml create mode 100644 man/sd_bus_set_property.xml create mode 100644 man/sd_bus_set_sender.xml create mode 100644 man/sd_bus_set_server.xml create mode 100644 man/sd_bus_set_watch_bind.xml create mode 100644 man/sd_bus_slot_get_bus.xml create mode 100644 man/sd_bus_slot_ref.xml create mode 100644 man/sd_bus_slot_set_description.xml create mode 100644 man/sd_bus_slot_set_destroy_callback.xml create mode 100644 man/sd_bus_slot_set_floating.xml create mode 100644 man/sd_bus_slot_set_userdata.xml create mode 100644 man/sd_bus_start.xml create mode 100644 man/sd_bus_track_add_name.xml create mode 100644 man/sd_bus_track_new.xml create mode 100644 man/sd_bus_wait.xml create mode 100644 man/sd_device_get_syspath.xml create mode 100644 man/sd_device_ref.xml create mode 100644 man/sd_event_add_child.xml create mode 100644 man/sd_event_add_defer.xml create mode 100644 man/sd_event_add_inotify.xml create mode 100644 man/sd_event_add_io.xml create mode 100644 man/sd_event_add_signal.xml create mode 100644 man/sd_event_add_time.xml create mode 100644 man/sd_event_exit.xml create mode 100644 man/sd_event_get_fd.xml create mode 100644 man/sd_event_new.xml create mode 100644 man/sd_event_now.xml create mode 100644 man/sd_event_run.xml create mode 100644 man/sd_event_set_signal_exit.xml create mode 100644 man/sd_event_set_watchdog.xml create mode 100644 man/sd_event_source_get_event.xml create mode 100644 man/sd_event_source_get_pending.xml create mode 100644 man/sd_event_source_set_description.xml create mode 100644 man/sd_event_source_set_destroy_callback.xml create mode 100644 man/sd_event_source_set_enabled.xml create mode 100644 man/sd_event_source_set_exit_on_failure.xml create mode 100644 man/sd_event_source_set_floating.xml create mode 100644 man/sd_event_source_set_prepare.xml create mode 100644 man/sd_event_source_set_priority.xml create mode 100644 man/sd_event_source_set_ratelimit.xml create mode 100644 man/sd_event_source_set_userdata.xml create mode 100644 man/sd_event_source_unref.xml create mode 100644 man/sd_event_wait.xml create mode 100644 man/sd_get_seats.xml create mode 100644 man/sd_hwdb_get.xml create mode 100644 man/sd_hwdb_new.xml create mode 100644 man/sd_id128_get_machine.xml create mode 100644 man/sd_id128_randomize.xml create mode 100644 man/sd_id128_to_string.xml create mode 100644 man/sd_is_fifo.xml create mode 100644 man/sd_journal_add_match.xml create mode 100644 man/sd_journal_enumerate_fields.xml create mode 100644 man/sd_journal_get_catalog.xml create mode 100644 man/sd_journal_get_cursor.xml create mode 100644 man/sd_journal_get_cutoff_realtime_usec.xml create mode 100644 man/sd_journal_get_data.xml create mode 100644 man/sd_journal_get_fd.xml create mode 100644 man/sd_journal_get_realtime_usec.xml create mode 100644 man/sd_journal_get_usage.xml create mode 100644 man/sd_journal_has_runtime_files.xml create mode 100644 man/sd_journal_next.xml create mode 100644 man/sd_journal_open.xml create mode 100644 man/sd_journal_print.xml create mode 100644 man/sd_journal_query_unique.xml create mode 100644 man/sd_journal_seek_head.xml create mode 100644 man/sd_journal_stream_fd.xml create mode 100644 man/sd_listen_fds.xml create mode 100644 man/sd_login_monitor_new.xml create mode 100644 man/sd_machine_get_class.xml create mode 100644 man/sd_notify.xml create mode 100644 man/sd_path_lookup.xml create mode 100644 man/sd_pid_get_owner_uid.xml create mode 100644 man/sd_seat_get_active.xml create mode 100644 man/sd_session_is_active.xml create mode 100644 man/sd_uid_get_state.xml create mode 100644 man/sd_watchdog_enabled.xml create mode 100644 man/send-unit-files-changed.c create mode 100644 man/shutdown.xml create mode 100644 man/standard-conf.xml create mode 100644 man/standard-options.xml create mode 100644 man/standard-specifiers.xml create mode 100644 man/supported-controllers.xml create mode 100644 man/sysctl.d.xml create mode 100644 man/system-only.xml create mode 100644 man/system-or-user-ns.xml create mode 100644 man/systemctl.xml create mode 100644 man/systemd-analyze.xml create mode 100644 man/systemd-ask-password-console.service.xml create mode 100644 man/systemd-ask-password.xml create mode 100644 man/systemd-backlight@.service.xml create mode 100644 man/systemd-binfmt.service.xml create mode 100644 man/systemd-bless-boot-generator.xml create mode 100644 man/systemd-bless-boot.service.xml create mode 100644 man/systemd-boot-check-no-failures.service.xml create mode 100644 man/systemd-boot-system-token.service.xml create mode 100644 man/systemd-boot.xml create mode 100644 man/systemd-cat.xml create mode 100644 man/systemd-cgls.xml create mode 100644 man/systemd-cgtop.xml create mode 100644 man/systemd-coredump.xml create mode 100644 man/systemd-creds.xml create mode 100644 man/systemd-cryptenroll.xml create mode 100644 man/systemd-cryptsetup-generator.xml create mode 100644 man/systemd-cryptsetup@.service.xml create mode 100644 man/systemd-debug-generator.xml create mode 100644 man/systemd-delta.xml create mode 100644 man/systemd-detect-virt.xml create mode 100644 man/systemd-dissect.xml create mode 100644 man/systemd-environment-d-generator.xml create mode 100644 man/systemd-escape.xml create mode 100644 man/systemd-firstboot.xml create mode 100644 man/systemd-fsck@.service.xml create mode 100644 man/systemd-fstab-generator.xml create mode 100644 man/systemd-getty-generator.xml create mode 100644 man/systemd-gpt-auto-generator.xml create mode 100644 man/systemd-halt.service.xml create mode 100644 man/systemd-hibernate-resume-generator.xml create mode 100644 man/systemd-hibernate-resume@.service.xml create mode 100644 man/systemd-homed.service.xml create mode 100644 man/systemd-hostnamed.service.xml create mode 100644 man/systemd-hwdb.xml create mode 100644 man/systemd-id128.xml create mode 100644 man/systemd-importd.service.xml create mode 100644 man/systemd-inhibit.xml create mode 100644 man/systemd-initctl.service.xml create mode 100644 man/systemd-integritysetup-generator.xml create mode 100644 man/systemd-integritysetup@.service.xml create mode 100644 man/systemd-journal-gatewayd.service.xml create mode 100644 man/systemd-journal-remote.service.xml create mode 100644 man/systemd-journal-upload.service.xml create mode 100644 man/systemd-journald.service.xml create mode 100644 man/systemd-localed.service.xml create mode 100644 man/systemd-logind.service.xml create mode 100644 man/systemd-machine-id-commit.service.xml create mode 100644 man/systemd-machine-id-setup.xml create mode 100644 man/systemd-machined.service.xml create mode 100644 man/systemd-makefs@.service.xml create mode 100644 man/systemd-measure.xml create mode 100644 man/systemd-modules-load.service.xml create mode 100644 man/systemd-mount.xml create mode 100644 man/systemd-network-generator.service.xml create mode 100644 man/systemd-networkd-wait-online.service.xml create mode 100644 man/systemd-networkd.service.xml create mode 100644 man/systemd-notify.xml create mode 100644 man/systemd-nspawn.xml create mode 100644 man/systemd-oomd.service.xml create mode 100644 man/systemd-path.xml create mode 100644 man/systemd-pcrphase.service.xml create mode 100644 man/systemd-portabled.service.xml create mode 100644 man/systemd-pstore.service.xml create mode 100644 man/systemd-quotacheck.service.xml create mode 100644 man/systemd-random-seed.service.xml create mode 100644 man/systemd-rc-local-generator.xml create mode 100644 man/systemd-remount-fs.service.xml create mode 100644 man/systemd-repart.xml create mode 100644 man/systemd-resolved.service.xml create mode 100644 man/systemd-rfkill.service.xml create mode 100644 man/systemd-run-generator.xml create mode 100644 man/systemd-run.xml create mode 100644 man/systemd-sleep.conf.xml create mode 100644 man/systemd-socket-activate.xml create mode 100644 man/systemd-socket-proxyd.xml create mode 100644 man/systemd-stdio-bridge.xml create mode 100644 man/systemd-stub.xml create mode 100644 man/systemd-suspend.service.xml create mode 100644 man/systemd-sysctl.service.xml create mode 100644 man/systemd-sysext.xml create mode 100644 man/systemd-system-update-generator.xml create mode 100644 man/systemd-system.conf.xml create mode 100644 man/systemd-sysupdate.xml create mode 100644 man/systemd-sysusers.xml create mode 100644 man/systemd-sysv-generator.xml create mode 100644 man/systemd-time-wait-sync.service.xml create mode 100644 man/systemd-timedated.service.xml create mode 100644 man/systemd-timesyncd.service.xml create mode 100644 man/systemd-tmpfiles.xml create mode 100644 man/systemd-tty-ask-password-agent.xml create mode 100644 man/systemd-udev-settle.service.xml create mode 100644 man/systemd-udevd.service.xml create mode 100644 man/systemd-update-done.service.xml create mode 100644 man/systemd-update-utmp.service.xml create mode 100644 man/systemd-user-sessions.service.xml create mode 100644 man/systemd-userdbd.service.xml create mode 100644 man/systemd-vconsole-setup.service.xml create mode 100644 man/systemd-veritysetup-generator.xml create mode 100644 man/systemd-veritysetup@.service.xml create mode 100644 man/systemd-volatile-root.service.xml create mode 100644 man/systemd-xdg-autostart-generator.xml create mode 100644 man/systemd.automount.xml create mode 100644 man/systemd.device.xml create mode 100644 man/systemd.dnssd.xml create mode 100644 man/systemd.environment-generator.xml create mode 100644 man/systemd.exec.xml create mode 100644 man/systemd.generator.xml create mode 100644 man/systemd.journal-fields.xml create mode 100644 man/systemd.kill.xml create mode 100644 man/systemd.link.xml create mode 100644 man/systemd.mount.xml create mode 100644 man/systemd.net-naming-scheme.xml create mode 100644 man/systemd.netdev.xml create mode 100644 man/systemd.network.xml create mode 100644 man/systemd.nspawn.xml create mode 100644 man/systemd.offline-updates.xml create mode 100644 man/systemd.path.xml create mode 100644 man/systemd.preset.xml create mode 100644 man/systemd.resource-control.xml create mode 100644 man/systemd.scope.xml create mode 100644 man/systemd.service.xml create mode 100644 man/systemd.slice.xml create mode 100644 man/systemd.socket.xml create mode 100644 man/systemd.special.xml create mode 100644 man/systemd.swap.xml create mode 100644 man/systemd.syntax.xml create mode 100644 man/systemd.system-credentials.xml create mode 100644 man/systemd.target.xml create mode 100644 man/systemd.time.xml create mode 100644 man/systemd.timer.xml create mode 100644 man/systemd.unit.xml create mode 100644 man/systemd.xml create mode 100644 man/sysupdate.d.xml create mode 100644 man/sysusers.d.xml create mode 100644 man/tc.xml create mode 100644 man/telinit.xml create mode 100644 man/threads-aware.xml create mode 100644 man/timedatectl.xml create mode 100644 man/timesyncd.conf.xml create mode 100644 man/tmpfiles.d.xml create mode 100644 man/tpm2-crypttab.sh create mode 100644 man/udev.conf.xml create mode 100644 man/udev.xml create mode 100644 man/udev_device_get_syspath.xml create mode 100644 man/udev_device_has_tag.xml create mode 100644 man/udev_device_new_from_syspath.xml create mode 100644 man/udev_enumerate_add_match_subsystem.xml create mode 100644 man/udev_enumerate_new.xml create mode 100644 man/udev_enumerate_scan_devices.xml create mode 100644 man/udev_list_entry.xml create mode 100644 man/udev_monitor_filter_update.xml create mode 100644 man/udev_monitor_new_from_netlink.xml create mode 100644 man/udev_monitor_receive_device.xml create mode 100644 man/udev_new.xml create mode 100644 man/udevadm.xml create mode 100644 man/user-system-options.xml create mode 100644 man/user@.service.xml create mode 100644 man/userdbctl.xml create mode 100644 man/vconsole.conf.xml create mode 100644 man/veritytab.xml create mode 100644 man/vtable-example.c create mode 100644 man/vtable-example.xml create mode 100644 man/yubikey-crypttab.sh (limited to 'man') diff --git a/man/.dir-locals.el b/man/.dir-locals.el new file mode 100644 index 0000000..bd028d1 --- /dev/null +++ b/man/.dir-locals.el @@ -0,0 +1,15 @@ +; SPDX-License-Identifier: LGPL-2.1-or-later +; special .c mode with reduced indentation for man pages +((c-mode . ((fill-column . 80) + (c-basic-offset . 2) + (eval . (c-set-offset 'substatement-open 0)) + (eval . (c-set-offset 'statement-case-open 0)) + (eval . (c-set-offset 'case-label 0)) + (eval . (c-set-offset 'arglist-intro '++)) + (eval . (c-set-offset 'arglist-close 0)))) + (nxml-mode . ((nxml-child-indent . 2) + (fill-column . 109))) + (meson-mode . ((meson-indent-basic . 8))) + (nil . ((indent-tabs-mode . nil) + (tab-width . 8) + (fill-column . 79)))) diff --git a/man/50-xdg-data-dirs.sh b/man/50-xdg-data-dirs.sh new file mode 100755 index 0000000..0a180ff --- /dev/null +++ b/man/50-xdg-data-dirs.sh @@ -0,0 +1,13 @@ +#!/bin/sh +# SPDX-License-Identifier: MIT-0 + +# set the default value +XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share}" + +# add a directory if it exists +if [ -d /opt/foo/share ]; then + XDG_DATA_DIRS="/opt/foo/share:${XDG_DATA_DIRS}" +fi + +# write our output +echo "XDG_DATA_DIRS=${XDG_DATA_DIRS}" diff --git a/man/90-rearrange-path.py b/man/90-rearrange-path.py new file mode 100755 index 0000000..5c727e4 --- /dev/null +++ b/man/90-rearrange-path.py @@ -0,0 +1,41 @@ +#!/usr/bin/env python3 +# SPDX-License-Identifier: MIT-0 + +""" + +Proof-of-concept systemd environment generator that makes sure that bin dirs +are always after matching sbin dirs in the path. +(Changes /sbin:/bin:/foo/bar to /bin:/sbin:/foo/bar.) + +This generator shows how to override the configuration possibly created by +earlier generators. It would be easier to write in bash, but let's have it +in Python just to prove that we can, and to serve as a template for more +interesting generators. + +""" + +import os +import pathlib + +def rearrange_bin_sbin(path): + """Make sure any pair of …/bin, …/sbin directories is in this order + + >>> rearrange_bin_sbin('/bin:/sbin:/usr/sbin:/usr/bin') + '/bin:/sbin:/usr/bin:/usr/sbin' + """ + items = [pathlib.Path(p) for p in path.split(':')] + for i in range(len(items)): + if 'sbin' in items[i].parts: + ind = items[i].parts.index('sbin') + bin = pathlib.Path(*items[i].parts[:ind], 'bin', *items[i].parts[ind+1:]) + if bin in items[i+1:]: + j = i + 1 + items[i+1:].index(bin) + items[i], items[j] = items[j], items[i] + return ':'.join(p.as_posix() for p in items) + +if __name__ == '__main__': + path = os.environ['PATH'] # This should be always set. + # If it's not, we'll just crash, which is OK too. + new = rearrange_bin_sbin(path) + if new != path: + print('PATH={}'.format(new)) diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml new file mode 100644 index 0000000..ab56460 --- /dev/null +++ b/man/binfmt.d.xml @@ -0,0 +1,74 @@ + + + + + + + + binfmt.d + systemd + + + + binfmt.d + 5 + + + + binfmt.d + Configure additional binary formats for + executables at boot + + + + /etc/binfmt.d/*.conf + /run/binfmt.d/*.conf + /usr/lib/binfmt.d/*.conf + + + + Description + + At boot, + systemd-binfmt.service8 + reads configuration files from the above directories to register + in the kernel additional binary formats for executables. + + + + Configuration Format + + Each file contains a list of binfmt_misc kernel binary format rules. Consult the kernel's Kernel Support for + miscellaneous Binary Formats (binfmt_misc) documentation file for more information on + registration of additional binary formats and how to write rules. + + Empty lines and lines beginning with ; and # are ignored. + Note that this means you may not use those symbols as the delimiter in binary format rules. + + + + + + Example + + /etc/binfmt.d/wine.conf example: + + # Start WINE on Windows executables +:DOSWin:M::MZ::/usr/bin/wine: + + + + + See Also + + systemd1, + systemd-binfmt.service8, + systemd-delta1, + wine8 + + + + diff --git a/man/bootctl.xml b/man/bootctl.xml new file mode 100644 index 0000000..dfc56d6 --- /dev/null +++ b/man/bootctl.xml @@ -0,0 +1,537 @@ + + + + + + + bootctl + systemd + + + + bootctl + 1 + + + + bootctl + Control EFI firmware boot settings and manage boot loader + + + + + bootctl + OPTIONS + COMMAND + + + + + Description + + bootctl can check the EFI firmware and boot loader status, list and manage + available boot loaders and boot loader entries, and install, update, or remove the + systemd-boot7 boot + loader on the current system. + + + + Generic EFI Firmware/Boot Loader Commands + + These commands are available on any EFI system, regardless of the boot loader used. + + + + + + Shows brief information about the system firmware, the boot loader that was used to + boot the system, the boot loaders currently available in the ESP, the boot loaders listed in the + firmware's list of boot loaders and the current default boot loader entry. If no command is + specified, this is the implied default. + + See the example below for details of the output. + + + + + BOOL + + Query or set the "Reboot-Into-Firmware-Setup" flag of the EFI firmware. Takes a + boolean argument which controls whether to show the firmware setup on next system reboot. If the + argument is omitted shows the current status of the flag, or whether the flag is supported. This + controls the same flag as systemctl reboot --firmware-setup, but is more low-level + and allows setting the flag independently from actually requesting a reboot. + + Hint: use systemctl reboot --firmware-setup to reboot into firmware setup + once. See + systemctl1 + for details. + + + + STRING + + When called without the optional argument, prints the current value of the + SystemdOptions EFI variable. When called with an argument, sets the variable to + that value. See + systemd1 for the + meaning of that variable. + + + + + + Boot Loader Specification Commands + + These commands are available for all boot loaders that implement the Boot Loader Specification and/or the Boot Loader Interface, such as + systemd-boot. + + + + + + Shows all available boot loader entries implementing the Boot Loader Specification, as well as any + other entries discovered or automatically generated by a boot loader implementing the Boot Loader Interface. + JSON output may be requested with . + + See the example below for details of the output. + + + + + ID + ID + + Sets the default boot loader entry. Takes a single boot loader entry ID string or a glob + pattern as argument. The command will set the default entry only for the next boot, + the will set it persistently for all future boots. + + bootctl list can be used to list available boot loader entries and their + IDs. + + In addition, the boot loader entry ID may be specified as one of: , + or , which correspond to the current default boot loader + entry for all future boots, the current default boot loader entry for the next boot, and the currently booted + boot loader entry. These special IDs are resolved to the current values of the EFI variables + LoaderEntryDefault, LoaderEntryOneShot and LoaderEntrySelected, + see Boot Loader Specification for details. + These special IDs are primarily useful as a quick way to persistently make the currently booted boot loader + entry the default choice, or to upgrade the default boot loader entry for the next boot to the default boot + loader entry for all future boots, but may be used for other operations too. + + If set to the chosen entry will be saved as an EFI variable + on every boot and automatically selected the next time the boot loader starts. + + When an empty string ("") is specified as the ID, then the corresponding EFI variable will be + unset. + + Hint: use systemctl reboot --boot-loader-entry=ID + to reboot into a specific boot entry and + systemctl reboot --boot-loader-menu=timeout + to reboot into the boot loader menu once. See + systemctl1 + for details. + + + + TIMEOUT + TIMEOUT + + Sets the boot loader menu timeout in seconds. The + command will set the timeout only for the next boot. See + systemd.time7 + for details about the syntax of time spans. + + If this is set to or no menu is shown and + the default entry will be booted immediately, while setting this to + disables the timeout while always showing the menu. When an empty string ("") is specified the + bootloader will revert to its default menu timeout. + + + + + + <command>systemd-boot</command> Commands + + These commands manage the systemd-boot EFI boot loader, and do not work in + conjunction with other boot loaders. + + + + + + Installs systemd-boot into the EFI system partition. A copy of + systemd-boot will be stored as the EFI default/fallback loader at + ESP/EFI/BOOT/BOOT*.EFI. The boot loader is then added + to the top of the firmware's boot loader list. + + + + + + Updates all installed versions of + systemd-boot7, if the + available version is newer than the version installed in the EFI system partition. This also includes the EFI + default/fallback loader at ESP/EFI/BOOT/BOOT*.EFI. The boot + loader is then added to end of the firmware's boot loader list if missing. + + + + + + Removes all installed versions of systemd-boot from the EFI system partition + and the firmware's boot loader list. + + + + + + Checks whether systemd-boot is installed in the ESP. Note that a + single ESP might host multiple boot loaders; this hence checks whether + systemd-boot is one (of possibly many) installed boot loaders — and neither + whether it is the default nor whether it is registered in any EFI variables. + + + + + + Generates a random seed and stores it in the EFI System Partition, for use by the + systemd-boot boot loader. Also, generates a random 'system token' and stores it + persistently as an EFI variable, if one has not been set before. If the boot loader finds the random + seed in the ESP and the system token in the EFI variable it will derive a random seed to pass to the + OS and a new seed to store in the ESP from the combination of both. The random seed passed to the OS + is credited to the kernel's entropy pool by the system manager during early boot, and permits + userspace to boot up with an entropy pool fully initialized very early on. Also see + systemd-boot-system-token.service8. + + See Random Seeds for further + information. + + + + + + + Options + The following options are understood: + + + + + Path to the EFI System Partition (ESP). If not specified, /efi/, + /boot/, and /boot/efi/ are checked in turn. It is + recommended to mount the ESP to /efi/, if possible. + + + + + Path to the Extended Boot Loader partition, as defined in the Boot Loader Specification. If not + specified, /boot/ is checked. It is recommended to mount the Extended Boot + Loader partition to /boot/, if possible. + + + + + Takes a directory path as an argument. All + paths will be prefixed with the given alternate + root path, including config search + paths. + + + + + + Takes a path to a disk image file or block device node. If specified, all operations + are applied to file system in the indicated disk image. This option is similar to + , but operates on file systems stored in disk images or block devices. The + disk image should either contain just a file system or a set of file systems within a GPT partition + table, following the Discoverable Partitions + Specification. For further information on supported disk images, see + systemd-nspawn1's + switch of the same name. + + + + + When installing binaries with or + , selects where to source them from. Takes one of auto + (the default), image or host. With auto + binaries will be picked from the specified directory or image, and if not found they will be picked + from the host. With image or host no fallback search will be + performed if the binaries are not found in the selected source. + + + + + + This option modifies the behaviour of status. Only prints the path + to the EFI System Partition (ESP) to standard output and exits. + + + + + + This option modifies the behaviour of status. Only prints the path + to the Extended Boot Loader partition if it exists, and the path to the ESP otherwise to standard + output and exit. This command is useful to determine where to place boot loader entries, as they are + preferably placed in the Extended Boot Loader partition if it exists and in the ESP otherwise. + + Boot Loader Specification Type #1 entries should generally be placed in the directory + $(bootctl -x)/loader/entries/. Existence of that directory may also be used as + indication that boot loader entry support is available on the system. Similarly, Boot Loader + Specification Type #2 entries should be placed in the directory $(bootctl + -x)/EFI/Linux/. + + Note that this option (similarly to the option mentioned + above), is available independently from the boot loader used, i.e. also without + systemd-boot being installed. + + + + + Do not touch the firmware's boot loader list stored in EFI variables. + + + + + Ignore failure when the EFI System Partition cannot be found, when EFI variables + cannot be written, or a different or newer boot loader is already installed. Currently only applies + to is-installed, update, and random-seed + verbs. + + + + + + + Suppress printing of the results of various commands and also the hints about ESP + being unavailable. + + + + + Controls creation and deletion of the Boot Loader Specification Type #1 entry + directory on the file system containing resources such as kernel and initrd images during + and , respectively. The directory is named after the + entry token, as specified with parameter described below, and is + placed immediately below the $BOOT root directory (i.e. beneath the file system + returned by the option, see above). Defaults to + no. + + + + + + Controls how to name and identify boot loader entries for this OS + installation. Accepted during , and takes one of auto, + machine-id, os-id, os-image-id or an + arbitrary string prefixed by literal: as argument. + + If set to the entries are named after the machine ID of the running + system (e.g. b0e793a9baf14b5fa13ecbe84ff637ac). See + machine-id5 for + details about the machine ID concept and file. + + If set to the entries are named after the OS ID of the running system, + i.e. the ID= field of + os-release5 (e.g. + fedora). Similarly, if set to the entries are named + after the OS image ID of the running system, i.e. the IMAGE_ID= field of + os-release (e.g. vendorx-cashier-system). + + If set to (the default), the /etc/kernel/entry-token + file will be read if it exists, and the stored value used. Otherwise if the local machine ID is + initialized it is used. Otherwise IMAGE_ID= from os-release + will be used, if set. Otherwise, ID= from os-release will be + used, if set. + + Unless set to machine-id, or when + is used the selected token string is written to a file + /etc/kernel/entry-token, to ensure it will be used for future entries. This file + is also read by + kernel-install8, + in order to identify under which name to generate boot loader entries for newly installed kernels, or + to determine the entry names for removing old ones. + + Using the machine ID for naming the entries is generally preferable, however there are cases + where using the other identifiers is a good option. Specifically: if the identification data that the + machine ID entails shall not be stored on the (unencrypted) $BOOT partition, or if + the ID shall be generated on first boot and is not known when the entries are prepared. Note that + using the machine ID has the benefit that multiple parallel installations of the same OS can coexist + on the same medium, and they can update their boot loader entries independently. When using another + identifier (such as the OS ID or the OS image ID), parallel installations of the same OS would try to + use the same entry name. To support parallel installations, the installer must use a different entry + token when adding a second installation. + + + + + Install binaries for all supported EFI architectures (this implies ). + + + + + Description of the entry added to the firmware's boot option list. Defaults to Linux + Boot Manager. + + Using the default entry name Linux Boot Manager is generally preferable as only + one bootloader installed to a single ESP partition should be used to boot any number of OS installations + found on the various disks installed in the system. Specifically distributions should not use this flag + to install a branded entry in the boot option list. However in situations with multiple disks, each with + their own ESP partition, it can be beneficial to make it easier to identify the bootloader being used in + the firmware's boot option menu. + + + + + + + + + + + Signed .efi files + bootctl and will look for a + systemd-boot file ending with the .efi.signed suffix first, and copy + that instead of the normal .efi file. This allows distributions or end-users to provide + signed images for UEFI SecureBoot. + + + + Exit status + On success, 0 is returned, a non-zero failure code otherwise. + + + + Environment + If $SYSTEMD_RELAX_ESP_CHECKS=1 is set the validation checks for the ESP are + relaxed, and the path specified with may refer to any kind of file system on + any kind of partition. + + Similarly, $SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 turns off some validation checks for + the Extended Boot Loader partition. + + + + Examples + + + Output from <command>status</command> and <command>list</command> + + $ bootctl status +System: + Firmware: UEFI 2.40 (firmware-version) ← firmware vendor and version + Secure Boot: disabled (setup) ← secure boot status + TPM2 Support: yes + Boot into FW: supported ← does the firmware support booting into itself + +Current Boot Loader: ← details about sd-boot or another boot loader + Product: systemd-boot version implementing the Boot Loader Interface + Features: ✓ Boot counting + ✓ Menu timeout control + ✓ One-shot menu timeout control + ✓ Default entry control + ✓ One-shot entry control + ✓ Support for XBOOTLDR partition + ✓ Support for passing random seed to OS + ✓ Load drop-in drivers + ✓ Boot loader sets ESP information + ESP: /dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000 + File: └─/EFI/systemd/systemd-bootx64.efi + +Random Seed: ← random seed used for entropy in early boot + Passed to OS: yes + System Token: set + Exists: yes + +Available Boot Loaders on ESP: + ESP: /boot/efi (/dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000) + File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 251 + File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 251 + +Boot Loaders Listed in EFI Variables: + Title: Linux Boot Manager + ID: 0x0001 + Status: active, boot-order + Partition: /dev/disk/by-partuuid/… + File: └─/EFI/systemd/systemd-bootx64.efi + + Title: Fedora + ID: 0x0000 + Status: active, boot-order + Partition: /dev/disk/by-partuuid/… + File: └─/EFI/fedora/shimx64.efi + + Title: Linux-Firmware-Updater + ID: 0x0002 + Status: active, boot-order + Partition: /dev/disk/by-partuuid/… + File: └─/EFI/fedora/fwupdx64.efi + +Boot Loader Entries: + $BOOT: /boot/efi (/dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000) + +Default Boot Loader Entry: + type: Boot Loader Specification Type #1 (.conf) + title: Fedora Linux 36 (Workstation Edition) + id: … + source: /boot/efi/loader/entries/entry-token-kernel-version.conf + version: kernel-version + machine-id: … + linux: /entry-token/kernel-version/linux + initrd: /entry-token/kernel-version/initrd + options: root=… + + + $ bootctl list +Boot Loader Entries: + type: Boot Loader Specification Type #1 (.conf) + title: Fedora Linux 36 (Workstation Edition) (default) (selected) + id: … + source: /boot/efi/loader/entries/entry-token-kernel-version.conf + version: kernel-version + machine-id: … + linux: /entry-token/kernel-version/linux + initrd: /entry-token/kernel-version/initrd + options: root=… + + type: Boot Loader Specification Type #2 (.efi) + title: Fedora Linux 35 (Workstation Edition) + id: … + source: /boot/efi/EFI/Linux/fedora-kernel-version.efi + version: kernel-version + machine-id: … + linux: /EFI/Linux/fedora-kernel-version.efi + options: root=… + + type: Automatic + title: Reboot Into Firmware Interface + id: auto-reboot-to-firmware-setup + source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f + + + In the listing, (default) specifies the entry that will be + used by default, and (selected) specifies the entry that was + selected the last time (i.e. is currently running). + + + + + See Also + + systemd-boot7, + Boot Loader Specification, + Boot Loader Interface, + systemd-boot-system-token.service8 + + + diff --git a/man/bootup.xml b/man/bootup.xml new file mode 100644 index 0000000..31f7a31 --- /dev/null +++ b/man/bootup.xml @@ -0,0 +1,358 @@ + + + + + + + + bootup + systemd + + + + bootup + 7 + + + + bootup + System bootup process + + + + Description + + A number of different components are involved in the boot of a Linux system. Immediately after + power-up, the system firmware will do minimal hardware initialization, and hand control over to a boot + loader (e.g. + systemd-boot7 or + GRUB) stored on a persistent storage device. This + boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types + of firmware, this firmware may also load the kernel directly. + + The kernel (optionally) mounts an in-memory file system, often generated by dracut8, which + looks for the root file system. Nowadays this is implemented as an "initramfs" — a compressed CPIO + archive that the kernel extracts into a tmpfs. In the past normal file systems using an in-memory block + device (ramdisk) were used, and the name "initrd" is still used to describe both concepts. It's the boot + loader or the firmware that loads both the kernel and initrd/initramfs images into memory, but the kernel + which interprets it as a file system. + systemd1 may be used + to manage services in the initrd, similarly to the real system. + + After the root file system is found and mounted, the initrd hands over control to the host's system + manager (such as + systemd1) stored in + the root file system, which is then responsible for probing all remaining hardware, mounting all + necessary file systems and spawning all configured services. + + On shutdown, the system manager stops all services, unmounts + all file systems (detaching the storage technologies backing + them), and then (optionally) jumps back into the initrd code which + unmounts/detaches the root file system and the storage it resides + on. As a last step, the system is powered down. + + Additional information about the system boot process may be + found in + boot7. + + + + System Manager Bootup + + At boot, the system manager on the OS image is responsible + for initializing the required file systems, services and drivers + that are necessary for operation of the system. On + systemd1 + systems, this process is split up in various discrete steps which + are exposed as target units. (See + systemd.target5 + for detailed information about target units.) The boot-up process + is highly parallelized so that the order in which specific target + units are reached is not deterministic, but still adheres to a + limited amount of ordering structure. + + When systemd starts up the system, it will activate all + units that are dependencies of default.target + (as well as recursively all dependencies of these dependencies). + Usually, default.target is simply an alias of + graphical.target or + multi-user.target, depending on whether the + system is configured for a graphical UI or only for a text + console. To enforce minimal ordering between the units pulled in, + a number of well-known target units are available, as listed on + systemd.special7. + + The following chart is a structural overview of these + well-known units and their position in the boot-up logic. The + arrows describe which units are pulled in and ordered before which + other units. Units near the top are started before units nearer to + the bottom of the chart. + + + cryptsetup-pre.target veritysetup-pre.target + | +(various low-level v + API VFS mounts: (various cryptsetup/veritysetup devices...) + mqueue, configfs, | | + debugfs, ...) v | + | cryptsetup.target | + | (various swap | | remote-fs-pre.target + | devices...) | | | | + | | | | | v + | v local-fs-pre.target | | | (network file systems) + | swap.target | | v v | + | | v | remote-cryptsetup.target | + | | (various low-level (various mounts and | remote-veritysetup.target | + | | services: udevd, fsck services...) | | | + | | tmpfiles, random | | | remote-fs.target + | | seed, sysctl, ...) v | | | + | | | local-fs.target | | _____________/ + | | | | | |/ + \____|______|_______________ ______|___________/ | + \ / | + v | + sysinit.target | + | | + ______________________/|\_____________________ | + / | | | \ | + | | | | | | + v v | v | | + (various (various | (various | | + timers...) paths...) | sockets...) | | + | | | | | | + v v | v | | +timers.target paths.target | sockets.target | | + | | | | v | + v \_______ | _____/ rescue.service | + \|/ | | + v v | + basic.target rescue.target | + | | + ________v____________________ | + / | \ | + | | | | + v v v | + display- (various system (various system | + manager.service services services) | + | required for | | + | graphical UIs) v v + | | multi-user.target +emergency.service | | | + | \_____________ | _____________/ + v \|/ +emergency.target v + graphical.target + + Target units that are commonly used as boot targets are + emphasized. These units are good choices as + goal targets, for example by passing them to the + systemd.unit= kernel command line option (see + systemd1) + or by symlinking default.target to them. + + + timers.target is pulled-in by + basic.target asynchronously. This allows + timers units to depend on services which become only available + later in boot. + + + + User manager startup + + The system manager starts the user@uid.service unit + for each user, which launches a separate unprivileged instance of systemd for each + user — the user manager. Similarly to the system manager, the user manager starts units which are pulled + in by default.target. The following chart is a structural overview of the well-known + user units. For non-graphical sessions, default.target is used. Whenever the user + logs into a graphical session, the login manager will start the + graphical-session.target target that is used to pull in units required for the + graphical session. A number of targets (shown on the right side) are started when specific hardware is + available to the user. + + + (various (various (various + timers...) paths...) sockets...) (sound devices) + | | | | + v v v v + timers.target paths.target sockets.target sound.target + | | | + \______________ _|_________________/ (bluetooth devices) + \ / | + V v + basic.target bluetooth.target + | + __________/ \_______ (smartcard devices) + / \ | + | | v + | v smartcard.target + v graphical-session-pre.target +(various user services) | (printers) + | v | + | (services for the graphical session) v + | | printer.target + v v + default.target graphical-session.target + + + + + Bootup in the initrd + + Systemd can be used in the initrd as well. It detects the initrd environment by checking for the + /etc/initrd-release file. The default target in the initrd is + initrd.target. The bootup process is identical to the system manager bootup until + the target basic.target. After that, systemd executes the special target + initrd.target. + + Before any file systems are mounted, the manager will determine whether the system shall resume from + hibernation or proceed with normal boot. This is accomplished by + systemd-hibernate-resume@.service which must be finished before + local-fs-pre.target, so no filesystems can be mounted before the check is complete. + + When the root device becomes available, + initrd-root-device.target is reached. + If the root device can be mounted at + /sysroot, the + sysroot.mount unit becomes active and + initrd-root-fs.target is reached. The service + initrd-parse-etc.service scans + /sysroot/etc/fstab for a possible + /usr/ mount point and additional entries + marked with the x-initrd.mount option. All + entries found are mounted below /sysroot, and + initrd-fs.target is reached. The service + initrd-cleanup.service isolates to the + initrd-switch-root.target, where cleanup + services can run. As the very last step, the + initrd-switch-root.service is activated, + which will cause the system to switch its root to + /sysroot. + + + : (beginning identical to above) + : + v + basic.target + | emergency.service + ______________________/| | + / | v + | initrd-root-device.target emergency.target + | | + | v + | sysroot.mount + | | + | v + | initrd-root-fs.target + | | + | v + v initrd-parse-etc.service +(custom initrd | + services...) v + | (sysroot-usr.mount and + | various mounts marked + | with fstab option + | x-initrd.mount...) + | | + | v + | initrd-fs.target + \______________________ | + \| + v + initrd.target + | + v + initrd-cleanup.service + isolates to + initrd-switch-root.target + | + v + ______________________/| + / v + | initrd-udevadm-cleanup-db.service + v | +(custom initrd | + services...) | + \______________________ | + \| + v + initrd-switch-root.target + | + v + initrd-switch-root.service + | + v + Transition to Host OS + + + + System Manager Shutdown + + System shutdown with systemd also consists of various target + units with some minimal ordering structure applied: + + (conflicts with (conflicts with + all system all file system + services) mounts, swaps, + | cryptsetup/ + | veritysetup + | devices, ...) + | | + v v + shutdown.target umount.target + | | + \_______ ______/ + \ / + v + (various low-level + services) + | + v + final.target + | + ___________________________/ \_________________ + / | | \ + | | | | + v | | | +systemd-reboot.service | | | + | v | | + | systemd-poweroff.service | | + v | v | + reboot.target | systemd-halt.service | + v | v + poweroff.target | systemd-kexec.service + v | + halt.target | + v + kexec.target + + Commonly used system shutdown targets are emphasized. + + Note that + systemd-halt.service8, + systemd-reboot.service, systemd-poweroff.service and + systemd-kexec.service will transition the system and server manager (PID 1) into the second + phase of system shutdown (implemented in the systemd-shutdown binary), which will unmount any + remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and + robust fashion, without taking any service or unit concept into account anymore. At that point, regular + applications and resources are generally terminated and released already, the second phase hence operates only as + safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based + shutdown phase described above. + + + + See Also + + systemd1, + boot7, + systemd.special7, + systemd.target5, + systemd-halt.service8, + dracut8 + + + + diff --git a/man/busctl.xml b/man/busctl.xml new file mode 100644 index 0000000..294ef5d --- /dev/null +++ b/man/busctl.xml @@ -0,0 +1,526 @@ + + + + + + + + busctl + systemd + + + + busctl + 1 + + + + busctl + Introspect the bus + + + + + busctl + OPTIONS + COMMAND + NAME + + + + + Description + + busctl may be used to + introspect and monitor the D-Bus bus. + + + + Commands + + The following commands are understood: + + + + list + + Show all peers on the bus, by their service + names. By default, shows both unique and well-known names, but + this may be changed with the and + switches. This is the default + operation if no command is specified. + + + + status SERVICE + + Show process information and credentials of a + bus service (if one is specified by its unique or well-known + name), a process (if one is specified by its numeric PID), or + the owner of the bus (if no parameter is + specified). + + + + monitor SERVICE + + Dump messages being exchanged. If + SERVICE is specified, show messages + to or from this peer, identified by its well-known or unique + name. Otherwise, show all messages on the bus. Use + CtrlC + to terminate the dump. + + + + capture SERVICE + + Similar to monitor but + writes the output in pcapng format (for details, see + + PCAP Next Generation (pcapng) Capture File Format). + Make sure to redirect standard output to a file or pipe. Tools like + wireshark1 + may be used to dissect and view the resulting + files. + + + + tree SERVICE + + Shows an object tree of one or more + services. If SERVICE is specified, + show object tree of the specified services only. Otherwise, + show all object trees of all services on the bus that acquired + at least one well-known name. + + + + introspect SERVICE OBJECT INTERFACE + + Show interfaces, methods, properties and + signals of the specified object (identified by its path) on + the specified service. If the interface argument is passed, the + output is limited to members of the specified + interface. + + + + call SERVICE OBJECT INTERFACE METHOD SIGNATURE ARGUMENT + + Invoke a method and show the response. Takes a + service name, object path, interface name and method name. If + parameters shall be passed to the method call, a signature + string is required, followed by the arguments, individually + formatted as strings. For details on the formatting used, see + below. To suppress output of the returned data, use the + option. + + + + emit OBJECT INTERFACE SIGNAL SIGNATURE ARGUMENT + + Emit a signal. Takes an object path, interface name and method name. If parameters + shall be passed, a signature string is required, followed by the arguments, individually formatted as + strings. For details on the formatting used, see below. To specify the destination of the signal, + use the option. + + + + get-property SERVICE OBJECT INTERFACE PROPERTY + + Retrieve the current value of one or more + object properties. Takes a service name, object path, + interface name and property name. Multiple properties may be + specified at once, in which case their values will be shown one + after the other, separated by newlines. The output is, by + default, in terse format. Use for a + more elaborate output format. + + + + set-property SERVICE OBJECT INTERFACE PROPERTY SIGNATURE ARGUMENT + + Set the current value of an object + property. Takes a service name, object path, interface name, + property name, property signature, followed by a list of + parameters formatted as strings. + + + + help + + Show command syntax help. + + + + + + Options + + The following options are understood: + + + + + + Connect to the bus specified by + ADDRESS instead of using suitable + defaults for either the system or user bus (see + and + options). + + + + + + When showing the list of peers, show a + column containing the names of containers they belong to. + See + systemd-machined.service8. + + + + + + + When showing the list of peers, show only + "unique" names (of the form + :number.number). + + + + + + + The opposite of — + only "well-known" names will be shown. + + + + + + When showing the list of peers, show only + peers which have actually not been activated yet, but may be + started automatically if accessed. + + + + + + + When showing messages being exchanged, show only the + subset matching MATCH. + See + sd_bus_add_match3. + + + + + + + + When used with the capture command, + specifies the maximum bus message size to capture + ("snaplen"). Defaults to 4096 bytes. + + + + + + + + When used with the tree command, shows a + flat list of object paths instead of a tree. + + + + + + + + + When used with the call command, + suppresses display of the response message payload. Note that even + if this option is specified, errors returned will still be + printed and the tool will indicate success or failure with + the process exit code. + + + + + + + + When used with the call or + get-property command, shows output in a + more verbose format. + + + + + + + + When used with the introspect call, dump the XML description received from + the D-Bus org.freedesktop.DBus.Introspectable.Introspect call instead of the + normal output. + + + + + MODE + + + When used with the call or get-property command, shows output + formatted as JSON. Expects one of short (for the shortest possible output without any + redundant whitespace or line breaks) or pretty (for a pretty version of the same, with + indentation and line breaks). Note that transformation from D-Bus marshalling to JSON is done in a loss-less + way, which means type information is embedded into the JSON object tree. + + + + + + + + Equivalent to when invoked interactively from a terminal. Otherwise + equivalent to , in particular when the output is piped to some other + program. + + + + + BOOL + + + When used with the call command, + specifies whether busctl shall wait for + completion of the method call, output the returned method + response data, and return success or failure via the process + exit code. If this is set to no, the + method call will be issued but no response is expected, the + tool terminates immediately, and thus no response can be + shown, and no success or failure is returned via the exit + code. To only suppress output of the reply message payload, + use above. Defaults to + yes. + + + + + BOOL + + + When used with the call or emit command, specifies + whether the method call should implicitly activate the + called service, should it not be running yet but is + configured to be auto-started. Defaults to + yes. + + + + + BOOL + + + When used with the call command, + specifies whether the services may enforce interactive + authorization while executing the operation, if the security + policy is configured for this. Defaults to + yes. + + + + + SECS + + + When used with the call command, + specifies the maximum time to wait for method call + completion. If no time unit is specified, assumes + seconds. The usual other units are understood, too (ms, us, + s, min, h, d, w, month, y). Note that this timeout does not + apply if is used, as the + tool does not wait for any reply message then. When not + specified or when set to 0, the default of + 25s is assumed. + + + + + BOOL + + + Controls whether credential data reported by + list or status shall + be augmented with data from + /proc/. When this is turned on, the data + shown is possibly inconsistent, as the data read from + /proc/ might be more recent than the rest of + the credential information. Defaults to yes. + + + + + BOOL + + + Controls whether to wait for the specified AF_UNIX bus socket to appear in the + file system before connecting to it. Defaults to off. When enabled, the tool will watch the file system until + the socket is created and then connect to it. + + + + + SERVICE + + + Takes a service name. When used with the emit command, a signal is + emitted to the specified service. + + + + + + + + + + + + + + Do not ellipsize the output in list command. + + + + + + + + + + + + Parameter Formatting + + The call and + set-property commands take a signature string + followed by a list of parameters formatted as string (for details + on D-Bus signature strings, see the Type + system chapter of the D-Bus specification). For simple + types, each parameter following the signature should simply be the + parameter's value formatted as string. Positive boolean values may + be formatted as true, yes, + on, or 1; negative boolean + values may be specified as false, + no, off, or + 0. For arrays, a numeric argument for the + number of entries followed by the entries shall be specified. For + variants, the signature of the contents shall be specified, + followed by the contents. For dictionaries and structs, the + contents of them shall be directly specified. + + For example, + s jawoll is the formatting + of a single string jawoll. + + + as 3 hello world foobar + is the formatting of a string array with three entries, + hello, world and + foobar. + + + a{sv} 3 One s Eins Two u 2 Yes b true + is the formatting of a dictionary + array that maps strings to variants, consisting of three + entries. The string One is assigned the + string Eins. The string + Two is assigned the 32-bit unsigned + integer 2. The string Yes is assigned a + positive boolean. + + Note that the call, + get-property, introspect + commands will also generate output in this format for the returned + data. Since this format is sometimes too terse to be easily + understood, the call and + get-property commands may generate a more + verbose, multi-line output when passed the + option. + + + + Examples + + + Write and Read a Property + + The following two commands first write a property and then + read it back. The property is found on the + /org/freedesktop/systemd1 object of the + org.freedesktop.systemd1 service. The name of + the property is LogLevel on the + org.freedesktop.systemd1.Manager + interface. The property contains a single string: + + # busctl set-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager LogLevel s debug +# busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager LogLevel +s "debug" + + + + + Terse and Verbose Output + + The following two commands read a property that contains + an array of strings, and first show it in terse format, followed + by verbose format: + + $ busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager Environment +as 2 "LANG=en_US.UTF-8" "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" +$ busctl get-property --verbose org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager Environment +ARRAY "s" { + STRING "LANG=en_US.UTF-8"; + STRING "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"; +}; + + + + Invoking a Method + + The following command invokes the + StartUnit method on the + org.freedesktop.systemd1.Manager + interface of the + /org/freedesktop/systemd1 object + of the org.freedesktop.systemd1 + service, and passes it two strings + cups.service and + replace. As a result of the method + call, a single object path parameter is received and + shown: + + # busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit ss "cups.service" "replace" +o "/org/freedesktop/systemd1/job/42684" + + + + + See Also + + + dbus-daemon1, + D-Bus, + sd-bus3, + systemd1, + machinectl1, + wireshark1 + + + diff --git a/man/check-os-release-simple.py b/man/check-os-release-simple.py new file mode 100644 index 0000000..ce73c77 --- /dev/null +++ b/man/check-os-release-simple.py @@ -0,0 +1,12 @@ +#!/usr/bin/python +# SPDX-License-Identifier: MIT-0 + +import platform +os_release = platform.freedesktop_os_release() + +pretty_name = os_release.get('PRETTY_NAME', 'Linux') +print(f'Running on {pretty_name!r}') + +if 'fedora' in [os_release.get('ID', 'linux'), + *os_release.get('ID_LIKE', '').split()]: + print('Looks like Fedora!') diff --git a/man/check-os-release.py b/man/check-os-release.py new file mode 100644 index 0000000..19b193e --- /dev/null +++ b/man/check-os-release.py @@ -0,0 +1,37 @@ +#!/usr/bin/python +# SPDX-License-Identifier: MIT-0 + +import ast +import re +import sys + +def read_os_release(): + try: + filename = '/etc/os-release' + f = open(filename) + except FileNotFoundError: + filename = '/usr/lib/os-release' + f = open(filename) + + for line_number, line in enumerate(f, start=1): + line = line.rstrip() + if not line or line.startswith('#'): + continue + m = re.match(r'([A-Z][A-Z_0-9]+)=(.*)', line) + if m: + name, val = m.groups() + if val and val[0] in '"\'': + val = ast.literal_eval(val) + yield name, val + else: + print(f'{filename}:{line_number}: bad line {line!r}', + file=sys.stderr) + +os_release = dict(read_os_release()) + +pretty_name = os_release.get('PRETTY_NAME', 'Linux') +print(f'Running on {pretty_name!r}') + +if 'debian' in [os_release.get('ID', 'linux'), + *os_release.get('ID_LIKE', '').split()]: + print('Looks like Debian!') diff --git a/man/check-os-release.sh b/man/check-os-release.sh new file mode 100644 index 0000000..12f7ee1 --- /dev/null +++ b/man/check-os-release.sh @@ -0,0 +1,11 @@ +#!/bin/sh -eu +# SPDX-License-Identifier: MIT-0 + +test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release' +. "${os_release}" + +echo "Running on ${PRETTY_NAME:-Linux}" + +if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then + echo "Looks like Debian!" +fi diff --git a/man/common-variables.xml b/man/common-variables.xml new file mode 100644 index 0000000..0e220b3 --- /dev/null +++ b/man/common-variables.xml @@ -0,0 +1,202 @@ + + + + + + Environment + + + + $SYSTEMD_LOG_LEVEL + + The maximum log level of emitted messages (messages with a higher + log level, i.e. less important ones, will be suppressed). Either one of (in order of decreasing + importance) emerg, alert, crit, + err, warning, notice, + info, debug, or an integer in the range 0…7. See + syslog3 + for more information. + + + + + $SYSTEMD_LOG_COLOR + + A boolean. If true, messages written to the tty will be colored + according to priority. + + This setting is only useful when messages are written directly to the terminal, because + journalctl1 and + other tools that display logs will color messages based on the log level on their own. + + + + + $SYSTEMD_LOG_TIME + + A boolean. If true, console log messages will be prefixed with a + timestamp. + + This setting is only useful when messages are written directly to the terminal or a file, because + journalctl1 and + other tools that display logs will attach timestamps based on the entry metadata on their own. + + + + + $SYSTEMD_LOG_LOCATION + + A boolean. If true, messages will be prefixed with a filename + and line number in the source code where the message originates. + + Note that the log location is often attached as metadata to journal entries anyway. Including it + directly in the message text can nevertheless be convenient when debugging programs. + + + + + $SYSTEMD_LOG_TID + + A boolean. If true, messages will be prefixed with the current + numerical thread ID (TID). + + Note that the this information is attached as metadata to journal entries anyway. Including it + directly in the message text can nevertheless be convenient when debugging programs. + + + + + $SYSTEMD_LOG_TARGET + + The destination for log messages. One of + console (log to the attached tty), console-prefixed (log to + the attached tty but with prefixes encoding the log level and "facility", see syslog3, + kmsg (log to the kernel circular log buffer), journal (log to + the journal), journal-or-kmsg (log to the journal if available, and to kmsg + otherwise), auto (determine the appropriate log target automatically, the default), + null (disable log output). + + + + + + $SYSTEMD_PAGER + + Pager to use when is not given; overrides + $PAGER. If neither $SYSTEMD_PAGER nor $PAGER are set, a + set of well-known pager implementations are tried in turn, including + less1 and + more1, until one is found. If + no pager implementation is discovered no pager is invoked. Setting this environment variable to an empty string + or the value cat is equivalent to passing . + + Note: if $SYSTEMD_PAGERSECURE is not set, $SYSTEMD_PAGER + (as well as $PAGER) will be silently ignored. + + + + $SYSTEMD_LESS + + Override the options passed to less (by default + FRSXMK). + + Users might want to change two options in particular: + + + + + + This option instructs the pager to exit immediately when + CtrlC is pressed. To allow + less to handle CtrlC + itself to switch back to the pager command prompt, unset this option. + + If the value of $SYSTEMD_LESS does not include K, + and the pager that is invoked is less, + CtrlC will be ignored by the + executable, and needs to be handled by the pager. + + + + + + This option instructs the pager to not send termcap initialization and deinitialization + strings to the terminal. It is set by default to allow command output to remain visible in the + terminal even after the pager exits. Nevertheless, this prevents some pager functionality from + working, in particular paged output cannot be scrolled with the mouse. + + + + See + less1 + for more discussion. + + + + $SYSTEMD_LESSCHARSET + + Override the charset passed to less (by default utf-8, if + the invoking terminal is determined to be UTF-8 compatible). + + + + $SYSTEMD_PAGERSECURE + + Takes a boolean argument. When true, the "secure" mode of the pager is enabled; if + false, disabled. If $SYSTEMD_PAGERSECURE is not set at all, secure mode is enabled + if the effective UID is not the same as the owner of the login session, see + geteuid2 + and sd_pid_get_owner_uid3. + In secure mode, will be set when invoking the pager, and the pager shall + disable commands that open or create new files or start new subprocesses. When + $SYSTEMD_PAGERSECURE is not set at all, pagers which are not known to implement + secure mode will not be used. (Currently only + less1 + implements secure mode.) + + Note: when commands are invoked with elevated privileges, for example under sudo8 or + pkexec1, care + must be taken to ensure that unintended interactive features are not enabled. "Secure" mode for the + pager may be enabled automatically as describe above. Setting SYSTEMD_PAGERSECURE=0 + or not removing it from the inherited environment allows the user to invoke arbitrary commands. Note + that if the $SYSTEMD_PAGER or $PAGER variables are to be + honoured, $SYSTEMD_PAGERSECURE must be set too. It might be reasonable to completely + disable the pager using instead. + + + + $SYSTEMD_COLORS + + Takes a boolean argument. When true, systemd and related utilities + will use colors in their output, otherwise the output will be monochrome. Additionally, the variable can + take one of the following special values: 16, 256 to restrict the use + of colors to the base 16 or 256 ANSI colors, respectively. This can be specified to override the automatic + decision based on $TERM and what the console is connected to. + + + + + + $SYSTEMD_URLIFY + + The value must be a boolean. Controls whether clickable links should be generated in + the output for terminal emulators supporting this. This can be specified to override the decision that + systemd makes based on $TERM and other conditions. + + + + + diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml new file mode 100644 index 0000000..b1680f2 --- /dev/null +++ b/man/coredump.conf.xml @@ -0,0 +1,146 @@ + + + + + + + coredump.conf + systemd + + + + coredump.conf + 5 + + + + coredump.conf + coredump.conf.d + Core dump storage configuration files + + + + /etc/systemd/coredump.conf + /etc/systemd/coredump.conf.d/*.conf + /run/systemd/coredump.conf.d/*.conf + /usr/lib/systemd/coredump.conf.d/*.conf + + + + Description + + These files configure the behavior of + systemd-coredump8, + a handler for core dumps invoked by the kernel. Whether systemd-coredump is used + is determined by the kernel's + kernel.core_pattern sysctl8 + setting. See + systemd-coredump8 + and + core5 + pages for the details. + + + + + + Options + + All options are configured in the + [Coredump] section: + + + + + Storage= + + Controls where to store cores. One of none, + external, and journal. When none, the core + dumps may be logged (including the backtrace if possible), but not stored permanently. When + external (the default), cores will be stored in + /var/lib/systemd/coredump/. When journal, cores will be + stored in the journal and rotated following normal journal rotation patterns. + + When cores are stored in the journal, they might be compressed following journal compression + settings, see + journald.conf5. + When cores are stored externally, they will be compressed by default, see below. + + Note that in order to process a coredump (i.e. extract a stack trace) the core must be written + to disk first. Thus, unless ProcessSizeMax= is set to 0 (see below), the core will + be written to /var/lib/systemd/coredump/ either way (under a temporary filename, + or even in an unlinked file), Storage= thus only controls whether to leave it + there even after it was processed. + + + + Compress= + + Controls compression for external + storage. Takes a boolean argument, which defaults to + yes. + + + + + ProcessSizeMax= + + The maximum size in bytes of a core which will be processed. Core dumps exceeding + this size may be stored, but the stack trace will not be generated. Like other sizes in this same + config file, the usual suffixes to the base of 1024 are allowed (B, K, M, G, T, P, and E). Defaults + to 1G on 32bit systems, 32G on 64bit systems. + + Setting Storage=none and ProcessSizeMax=0 + disables all coredump handling except for a log entry. + + + + + ExternalSizeMax= + JournalSizeMax= + + The maximum (compressed or uncompressed) size in bytes of a core to be saved in + separate files on disk (default: 1G on 32bit, 32G on 64bit systems) or in the journal (default: + 10M). Unit suffixes are allowed just as in . + + ExternalSizeMax=infinity sets the core size to unlimited. + + + + MaxUse= + KeepFree= + + Enforce limits on the disk space, specified + in bytes, taken up by externally stored core dumps. + Unit suffixes are allowed just as in . + makes + sure that old core dumps are removed as soon as the total disk + space taken up by core dumps grows beyond this limit (defaults + to 10% of the total disk size). + controls how much disk space to keep free at least (defaults + to 15% of the total disk size). Note that the disk space used + by core dumps might temporarily exceed these limits while + core dumps are processed. Note that old core dumps are also + removed based on time via + systemd-tmpfiles8. + Set either value to 0 to turn off size-based cleanup. + + + + The defaults for all values are listed as comments in the + template /etc/systemd/coredump.conf file that + is installed by default. + + + + See Also + + systemd-journald.service8, + coredumpctl1, + systemd-tmpfiles8 + + + + diff --git a/man/coredumpctl.xml b/man/coredumpctl.xml new file mode 100644 index 0000000..8002549 --- /dev/null +++ b/man/coredumpctl.xml @@ -0,0 +1,438 @@ + + + + + + + + coredumpctl + systemd + + + + coredumpctl + 1 + + + + coredumpctl + Retrieve and process saved core dumps and metadata + + + + + coredumpctl + OPTIONS + COMMAND + PID|COMM|EXE|MATCH + + + + + Description + + coredumpctl is a tool that can be used to retrieve and process core + dumps and metadata which were saved by + systemd-coredump8. + + + + + Commands + + The following commands are understood: + + + + list + + List core dumps captured in the journal + matching specified characteristics. If no command is + specified, this is the implied default. + + The output is designed to be human readable and contains a table with the following + columns: + + + TIME + The timestamp of the crash, as reported by the kernel. + + + + + PID + The identifier of the process that crashed. + + + + + UID + GID + The user and group identifiers of the process that crashed. + + + + + SIGNAL + The signal that caused the process to crash, when applicable. + + + + + COREFILE + Information whether the coredump was stored, and whether + it is still accessible: none means the core was + not stored, - means that it was not available (for + example because the process was not terminated by a signal), + present means that the core file is accessible by the + current user, journal means that the core was stored + in the journal, truncated is the + same as one of the previous two, but the core was too large and was not + stored in its entirety, error means that the core file + cannot be accessed, most likely because of insufficient permissions, and + missing means that the core was stored in a file, but + this file has since been removed. + + + + EXE + The full path to the executable. For backtraces of scripts + this is the name of the interpreter. + + + + It's worth noting that different restrictions apply to + data saved in the journal and core dump files saved in + /var/lib/systemd/coredump, see overview in + systemd-coredump8. + Thus it may very well happen that a particular core dump is still listed + in the journal while its corresponding core dump file has already been + removed. + + + + info + + Show detailed information about the last core dump + or core dumps matching specified characteristics + captured in the journal. + + + + dump + + Extract the last core dump matching specified + characteristics. The core dump will be written on standard + output, unless an output file is specified with + . + + + + debug + + Invoke a debugger on the last core dump + matching specified characteristics. By default, + gdb1 + will be used. This may be changed using the + option or the $SYSTEMD_DEBUGGER environment + variable. Use the option to pass extra + command line arguments to the debugger. + + + + + + + + Options + + The following options are understood: + + + + + + + + + + + + + Show information of the most recent core dump only, instead of listing all known core + dumps. Equivalent to . + + + + INT + + Show at most the specified number of entries. The specified parameter must be an + integer greater or equal to 1. + + + + + + + Only print entries which are since the specified date. + + + + + + + Only print entries which are until the specified date. + + + + + + + Reverse output so that the newest entries are displayed first. + + + + + FIELD + FIELD + + Print all possible data values the specified + field takes in matching core dump entries of the + journal. + + + + FILE + FILE + + Write the core to . + + + + + DEBUGGER + + Use the given debugger for the debug + command. If not given and $SYSTEMD_DEBUGGER is unset, then + gdb1 + will be used. + + + + ARGS + ARGS + + Pass the given ARGS as extra command line arguments + to the debugger. Quote as appropriate when ARGS contain whitespace. + (See Examples.) + + + + + + Takes a file glob as an argument. If + specified, coredumpctl will operate on the specified journal + files matching GLOB instead of the + default runtime and system journal paths. May be specified + multiple times, in which case files will be suitably + interleaved. + + + + DIR + DIR + + Use the journal files in the specified . + + + + + + + Use root directory when searching for coredumps. + + + + + + + Takes a path to a disk image file or block device node. If specified, all operations + are applied to file system in the indicated disk image. This option is similar to + , but operates on file systems stored in disk images or block devices. The + disk image should either contain just a file system or a set of file systems within a GPT partition + table, following the Discoverable Partitions + Specification. For further information on supported disk images, see + systemd-nspawn1's + switch of the same name. + + + + + + + Suppresses informational messages about lack + of access to journal files and possible in-flight coredumps. + + + + + + + Look at all available journal files in /var/log/journal/ + (excluding journal namespaces) instead of only local ones. + + + + + + Matching + + A match can be: + + + + PID + + Process ID of the + process that dumped + core. An integer. + + + + COMM + + Name of the executable (matches + ). Must not contain slashes. + + + + + EXE + + Path to the executable (matches + ). Must contain at least one + slash. + + + + MATCH + + General journalctl match filter, must contain an equals + sign (=). See + journalctl1. + + + + + + + Exit status + On success, 0 is returned; otherwise, a non-zero failure + code is returned. Not finding any matching core dumps is treated as + failure. + + + + + Environment + + + + $SYSTEMD_DEBUGGER + Use the given debugger for the debug + command. See the option. + + + + + + Examples + + + List all the core dumps of a program + + $ coredumpctl list /usr/lib64/firefox/firefox +TIME PID UID GID SIG COREFILE EXE SIZE +Tue … 8018 1000 1000 SIGSEGV missing /usr/lib64/firefox/firefox - +Wed … 251609 1000 1000 SIGTRAP missing /usr/lib64/firefox/firefox - +Fri … 552351 1000 1000 SIGSEGV present /usr/lib64/firefox/firefox 28.7M + + + The journal has three entries pertaining to /usr/lib64/firefox/firefox, and + only the last entry still has an available core file (in external storage on disk). + + Note that coredumpctl needs access to the journal files to retrieve the + relevant entries from the journal. Thus, an unprivileged user will normally only see information about + crashing programs of this user. + + + + Invoke <command>gdb</command> on the last core dump + + $ coredumpctl debug + + + + Use <command>gdb</command> to display full register info from the last core dump + + $ coredumpctl debug --debugger-arguments="-batch -ex 'info all-registers'" + + + + Show information about a core dump matched by PID + + $ coredumpctl info 6654 + PID: 6654 (bash) + UID: 1000 (user) + GID: 1000 (user) + Signal: 11 (SEGV) + Timestamp: Mon 2021-01-01 00:00:01 CET (20s ago) + Command Line: bash -c $'kill -SEGV $$' + Executable: /usr/bin/bash + Control Group: /user.slice/user-1000.slice/… + Unit: user@1000.service + User Unit: vte-spawn-….scope + Slice: user-1000.slice + Owner UID: 1000 (user) + Boot ID: … + Machine ID: … + Hostname: … + Storage: /var/lib/systemd/coredump/core.bash.1000.….zst (present) + Size on Disk: 51.7K + Message: Process 130414 (bash) of user 1000 dumped core. + + Stack trace of thread 130414: + #0 0x00007f398142358b kill (libc.so.6 + 0x3d58b) + #1 0x0000558c2c7fda09 kill_builtin (bash + 0xb1a09) + #2 0x0000558c2c79dc59 execute_builtin.lto_priv.0 (bash + 0x51c59) + #3 0x0000558c2c79709c execute_simple_command (bash + 0x4b09c) + #4 0x0000558c2c798408 execute_command_internal (bash + 0x4c408) + #5 0x0000558c2c7f6bdc parse_and_execute (bash + 0xaabdc) + #6 0x0000558c2c85415c run_one_command.isra.0 (bash + 0x10815c) + #7 0x0000558c2c77d040 main (bash + 0x31040) + #8 0x00007f398140db75 __libc_start_main (libc.so.6 + 0x27b75) + #9 0x0000558c2c77dd1e _start (bash + 0x31d1e) + + + + + Extract the last core dump of /usr/bin/bar to a file named + <filename index="false">bar.coredump</filename> + + $ coredumpctl -o bar.coredump dump /usr/bin/bar + + + + + See Also + + systemd-coredump8, + coredump.conf5, + systemd-journald.service8, + gdb1 + + + + diff --git a/man/crypttab.xml b/man/crypttab.xml new file mode 100644 index 0000000..ef6cd2b --- /dev/null +++ b/man/crypttab.xml @@ -0,0 +1,867 @@ + + + + + + + + crypttab + systemd + + + + crypttab + 5 + + + + crypttab + Configuration for encrypted block devices + + + + /etc/crypttab + + + + Description + + The /etc/crypttab file describes + encrypted block devices that are set up during system boot. + + Empty lines and lines starting with the # + character are ignored. Each of the remaining lines describes one + encrypted block device. Fields are delimited by white space. + + Each line is in the formvolume-name encrypted-device key-file options + The first two fields are mandatory, the remaining two are + optional. + + Setting up encrypted block devices using this file supports four encryption modes: LUKS, TrueCrypt, + BitLocker and plain. See cryptsetup8 for + more information about each mode. When no mode is specified in the options field and the block device + contains a LUKS signature, it is opened as a LUKS device; otherwise, it is assumed to be in raw dm-crypt + (plain mode) format. + + The four fields of /etc/crypttab are defined as follows: + + + + The first field contains the name of the resulting volume with decrypted data; its + block device is set up below /dev/mapper/. + + The second field contains a path to the underlying block + device or file, or a specification of a block device via + UUID= followed by the UUID. + + The third field specifies an absolute path to a file with the encryption + key. Optionally, the path may be followed by : and an + /etc/fstab style device specification (e.g. starting with + LABEL= or similar); in which case the path is taken relative to the specified + device's file system root. If the field is not present or is none or + -, a key file named after the volume to unlock (i.e. the first column of the line), + suffixed with .key is automatically loaded from the + /etc/cryptsetup-keys.d/ and /run/cryptsetup-keys.d/ + directories, if present. Otherwise, the password has to be manually entered during system boot. For + swap encryption, /dev/urandom may be used as key file, resulting in a randomized + key. + + If the specified key file path refers to an AF_UNIX stream socket in the + file system, the key is acquired by connecting to the socket and reading it from the connection. This + allows the implementation of a service to provide key information dynamically, at the moment when it is + needed. For details see below. + + The fourth field, if present, is a comma-delimited list of options. The supported + options are listed below. + + + + + Key Acquisition + + Six different mechanisms for acquiring the decryption key or passphrase unlocking the encrypted + volume are supported. Specifically: + + + + Most prominently, the user may be queried interactively during volume activation + (i.e. typically at boot), asking them to type in the necessary passphrases. + + The (unencrypted) key may be read from a file on disk, possibly on removable media. The third field + of each line encodes the location, for details see above. + + The (unencrypted) key may be requested from another service, by specifying an + AF_UNIX file system socket in place of a key file in the third field. For details + see above and below. + + The key may be acquired via a PKCS#11 compatible hardware security token or + smartcard. In this case an encrypted key is stored on disk/removable media, acquired via + AF_UNIX, or stored in the LUKS2 JSON token metadata header. The encrypted key is + then decrypted by the PKCS#11 token with an RSA key stored on it, and then used to unlock the encrypted + volume. Use the option described below to use this mechanism. + + Similarly, the key may be acquired via a FIDO2 compatible hardware security token + (which must implement the "hmac-secret" extension). In this case a key generated randomly during + enrollment is stored on disk/removable media, acquired via AF_UNIX, or stored in + the LUKS2 JSON token metadata header. The random key is hashed via a keyed hash function (HMAC) on the + FIDO2 token, using a secret key stored on the token that never leaves it. The resulting hash value is + then used as key to unlock the encrypted volume. Use the option + described below to use this mechanism. + + Similarly, the key may be acquired via a TPM2 security chip. In this case a (during + enrollment) randomly generated key — encrypted by an asymmetric key derived from the TPM2 chip's seed + key — is stored on disk/removable media, acquired via AF_UNIX, or stored in the + LUKS2 JSON token metadata header. Use the option described below to use + this mechanism. + + + For the latter five mechanisms the source for the key material used for unlocking the volume is + primarily configured in the third field of each /etc/crypttab line, but may also + configured in /etc/cryptsetup-keys.d/ and + /run/cryptsetup-keys.d/ (see above) or in the LUKS2 JSON token header (in case of + the latter three). Use the + systemd-cryptenroll1 + tool to enroll PKCS#11, FIDO2 and TPM2 devices in LUKS2 volumes. + + + + Supported Options + + The following options may be used in the fourth field of each line: + + + + + + + Specifies the cipher to use. See cryptsetup8 + for possible values and the default value of this option. A cipher with unpredictable IV values, such + as aes-cbc-essiv:sha256, is recommended. Embedded commas in the cipher + specification need to be escaped by preceding them with a backslash, see example below. + + + + + + + Allow discard requests to be passed through the encrypted block + device. This improves performance on SSD storage but has security implications. + + + + + + + Specifies the hash to use for password + hashing. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Use a detached (separated) metadata device or + file where the LUKS header is stored. This option is only + relevant for LUKS devices. See + cryptsetup8 + for possible values and the default value of this + option. + + Optionally, the path may be followed by : and an + /etc/fstab device specification (e.g. starting with UUID= or + similar); in which case, the path is relative to the device file system root. The device gets mounted + automatically for LUKS device activation duration only. + + + + + + Specifies the number of bytes to skip at the + start of the key file. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Specifies the maximum number of bytes to read + from the key file. See + cryptsetup8 + for possible values and the default value of this option. This + option is ignored in plain encryption mode, as the key file + size is then given by the key size. + + + + + + If enabled, the specified key file is erased after the volume is activated or when + activation fails. This is in particular useful when the key file is only acquired transiently before + activation (e.g. via a file in /run/, generated by a service running before + activation), and shall be removed after use. Defaults to off. + + + + + + Specifies the key slot to compare the + passphrase or key against. If the key slot does not match the + given passphrase or key, but another would, the setup of the + device will fail regardless. This option implies + . See + cryptsetup8 + for possible values. The default is to try all key slots in + sequential order. + + + + + + Specifies the timeout for the device on + which the key file resides or the device used as the key file, + and falls back to a password if it could not be accessed. See + systemd-cryptsetup-generator8 + for key files on external devices. + + + + + + + Force LUKS mode. When this mode is used, the + following options are ignored since they are provided by the + LUKS header on the device: , + , + . + + + + + + Decrypt BitLocker drive. Encryption parameters + are deduced by cryptsetup from BitLocker header. + + + + + + Marks this cryptsetup device as requiring network. It will be + started after the network is available, similarly to + systemd.mount5 + units marked with . The service unit to set up this device + will be ordered between remote-fs-pre.target and + remote-cryptsetup.target, instead of + cryptsetup-pre.target and + cryptsetup.target. + + Hint: if this device is used for a mount point that is specified in + fstab5, + the option should also be used for the mount + point. Otherwise, a dependency loop might be created where the mount point + will be pulled in by local-fs.target, while the + service to configure the network is usually only started after + the local file system has been mounted. + + + + + + + This device will not be added to cryptsetup.target. + This means that it will not be automatically unlocked on boot, unless something else pulls + it in. In particular, if the device is used for a mount point, it'll be unlocked + automatically during boot, unless the mount point itself is also disabled with + . + + + + + + This device will not be a hard dependency of + cryptsetup.target. It'll still be pulled in and started, but the system + will not wait for the device to show up and be unlocked, and boot will not fail if this is + unsuccessful. Note that other units that depend on the unlocked device may still fail. In + particular, if the device is used for a mount point, the mount point itself also needs to + have the option, or the boot will fail if the device is not unlocked + successfully. + + + + + + Start offset in the backend device, in 512-byte sectors. This + option is only relevant for plain devices. + + + + + + Force plain encryption mode. + + + + + + Set up the encrypted block device in read-only + mode. + + + + + + Perform encryption using the same CPU that IO was submitted on. The default is to use + an unbound workqueue so that encryption work is automatically balanced between available CPUs. + + This requires kernel 4.0 or newer. + + + + + + + Disable offloading writes to a separate thread after encryption. There are some + situations where offloading write requests from the encryption threads to a dedicated thread degrades + performance significantly. The default is to offload write requests to a dedicated thread because it + benefits the CFQ scheduler to have writes submitted using the same context. + + This requires kernel 4.0 or newer. + + + + + + + Bypass dm-crypt internal workqueue and process read requests synchronously. The + default is to queue these requests and process them asynchronously. + + This requires kernel 5.9 or newer. + + + + + + Bypass dm-crypt internal workqueue and process write requests synchronously. The + default is to queue these requests and process them asynchronously. + + This requires kernel 5.9 or newer. + + + + + + + How many 512-byte sectors of the encrypted data to skip at the + beginning. This is different from the option with respect + to the sector numbers used in initialization vector (IV) calculation. Using + will shift the IV calculation by the same negative + amount. Hence, if is given, + sector n will get a sector number of 0 for the IV + calculation. Using causes sector + n to also be the first sector of the mapped device, but + with its number for IV generation being n. + + This option is only relevant for plain devices. + + + + + + + Specifies the key size in bits. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + Specifies the sector size in bytes. See + cryptsetup8 + for possible values and the default value of this + option. + + + + + + The encrypted block device will be used as a + swap device, and will be formatted accordingly after setting + up the encrypted block device, with + mkswap8. + This option implies . + + WARNING: Using the option will + destroy the contents of the named partition during every boot, + so make sure the underlying block device is specified + correctly. + + + + + + Use TrueCrypt encryption mode. When this mode + is used, the following options are ignored since they are + provided by the TrueCrypt header on the device or do not + apply: + , + , + , + , + . + + When this mode is used, the passphrase is read from the + key file given in the third field. Only the first line of this + file is read, excluding the new line character. + + Note that the TrueCrypt format uses both passphrase and + key files to derive a password for the volume. Therefore, the + passphrase and all key files need to be provided. Use + to provide the absolute path + to all key files. When using an empty passphrase in + combination with one or more key files, use + /dev/null as the password file in the third + field. + + + + + + Use the hidden TrueCrypt volume. This option + implies . + + This will map the hidden volume that is inside of the + volume provided in the second field. Please note that there is + no protection for the hidden volume if the outer volume is + mounted instead. See + cryptsetup8 + for more information on this limitation. + + + + + + Specifies the absolute path to a key file to + use for a TrueCrypt volume. This implies + and can be used more than once to + provide several key files. + + See the entry for on the + behavior of the passphrase and key files when using TrueCrypt + encryption mode. + + + + + + Use TrueCrypt in system encryption mode. This + option implies . + + + + + + Check for a VeraCrypt volume. VeraCrypt is a fork of + TrueCrypt that is mostly compatible, but uses different, stronger key + derivation algorithms that cannot be detected without this flag. + Enabling this option could substantially slow down unlocking, because + VeraCrypt's key derivation takes much longer than TrueCrypt's. This + option implies . + + + + + + Specifies the timeout for querying for a + password. If no unit is specified, seconds is used. Supported + units are s, ms, us, min, h, d. A timeout of 0 waits + indefinitely (which is the default). + + + + + + The encrypted block device will be prepared for using it as + /tmp/; it will be formatted using mkfs8. Takes + a file system type as argument, such as ext4, xfs or + btrfs. If no argument is specified defaults to ext4. This + option implies . + + WARNING: Using the option will destroy the contents of the named partition + during every boot, so make sure the underlying block device is specified correctly. + + + + + + Specifies the maximum number of times the user + is queried for a password. The default is 3. If set to 0, the + user is queried for a password indefinitely. + + + + + + Takes a boolean argument, defaults to false. If true, never query interactively + for the password/PIN. Useful for headless systems. + + + + + + If the encryption password is read from console, it has to be entered twice to + prevent typos. + + + + + + Controls whether to echo passwords or security token PINs + that are read from console. Takes a boolean or the special string masked. + The default is . + + If enabled, the typed characters are echoed literally. If disabled, + the typed characters are not echoed in any form, the user will not get + feedback on their input. If set to masked, an asterisk + (*) is echoed for each character typed. Regardless of + which mode is chosen, if the user hits the tabulator key (↹) + at any time, or the backspace key (⌫) before any other + data has been entered, then echo is turned off. + + + + + + Takes either the special value auto or an RFC7512 PKCS#11 URI pointing to a private RSA key + which is used to decrypt the encrypted key specified in the third column of the line. This is useful + for unlocking encrypted volumes through PKCS#11 compatible security tokens or smartcards. See below + for an example how to set up this mechanism for unlocking a LUKS2 volume with a YubiKey security + token. + + If specified as auto the volume must be of type LUKS2 and must carry PKCS#11 + security token metadata in its LUKS2 JSON token section. In this mode the URI and the encrypted key + are automatically read from the LUKS2 JSON token header. Use + systemd-cryptenroll1 + as simple tool for enrolling PKCS#11 security tokens or smartcards in a way compatible with + auto. In this mode the third column of the line should remain empty (that is, + specified as -). + + The specified URI can refer directly to a private RSA key stored on a token or alternatively + just to a slot or token, in which case a search for a suitable private RSA key will be performed. In + this case if multiple suitable objects are found the token is refused. The encrypted key configured + in the third column of the line is passed as is (i.e. in binary form, unprocessed) to RSA + decryption. The resulting decrypted key is then Base64 encoded before it is used to unlock the LUKS + volume. + + Use systemd-cryptenroll --pkcs11-token-uri=list to list all suitable PKCS#11 + security tokens currently plugged in, along with their URIs. + + Note that many newer security tokens that may be used as PKCS#11 security token typically also + implement the newer and simpler FIDO2 standard. Consider using + (described below) to enroll it via FIDO2 instead. Note that a security token enrolled via PKCS#11 + cannot be used to unlock the volume via FIDO2, unless also enrolled via FIDO2, and vice + versa. + + + + + + Takes either the special value auto or the path to a + hidraw device node (e.g. /dev/hidraw1) referring to a FIDO2 + security token that implements the hmac-secret extension (most current hardware + security tokens do). See below for an example how to set up this mechanism for unlocking an encrypted + volume with a FIDO2 security token. + + If specified as auto the FIDO2 token device is automatically discovered, as + it is plugged in. + + FIDO2 volume unlocking requires a client ID hash (CID) to be configured via + (see below) and a key to pass to the security token's HMAC functionality + (configured in the line's third column) to operate. If not configured and the volume is of type + LUKS2, the CID and the key are read from LUKS2 JSON token metadata instead. Use + systemd-cryptenroll1 + as simple tool for enrolling FIDO2 security tokens, compatible with this automatic mode, which is + only available for LUKS2 volumes. + + Use systemd-cryptenroll --fido2-device=list to list all suitable FIDO2 + security tokens currently plugged in, along with their device nodes. + + This option implements the following mechanism: the configured key is hashed via they HMAC + keyed hash function the FIDO2 device implements, keyed by a secret key embedded on the device. The + resulting hash value is Base64 encoded and used to unlock the LUKS2 volume. As it should not be + possible to extract the secret from the hardware token, it should not be possible to retrieve the + hashed key given the configured key — without possessing the hardware token. + + Note that many security tokens that implement FIDO2 also implement PKCS#11, suitable for + unlocking volumes via the option described above. Typically the newer, + simpler FIDO2 standard is preferable. + + + + + + Takes a Base64 encoded FIDO2 client ID to use for the FIDO2 unlock operation. If + specified, but is not, is + implied. If is used but is not, the volume + must be of LUKS2 type, and the CID is read from the LUKS2 JSON token header. Use + systemd-cryptenroll1 + for enrolling a FIDO2 token in the LUKS2 header compatible with this automatic + mode. + + + + + + Takes a string, configuring the FIDO2 Relying Party (rp) for the FIDO2 unlock + operation. If not specified io.systemd.cryptsetup is used, except if the LUKS2 + JSON token header contains a different value. It should normally not be necessary to override + this. + + + + + + Takes either the special value auto or the path to a device node + (e.g. /dev/tpmrm0) referring to a TPM2 security chip. See below for an example + how to set up this mechanism for unlocking an encrypted volume with a TPM2 chip. + + Use (see below) to configure the set of TPM2 PCRs to bind the + volume unlocking to. Use + systemd-cryptenroll1 + as simple tool for enrolling TPM2 security chips in LUKS2 volumes. + + If specified as auto the TPM2 device is automatically discovered. Use + systemd-cryptenroll --tpm2-device=list to list all suitable TPM2 devices currently + available, along with their device nodes. + + This option implements the following mechanism: when enrolling a TPM2 device via + systemd-cryptenroll on a LUKS2 volume, a randomized key unlocking the volume is + generated on the host and loaded into the TPM2 chip where it is encrypted with an asymmetric + "primary" key pair derived from the TPM2's internal "seed" key. Neither the seed key nor the primary + key are permitted to ever leave the TPM2 chip — however, the now encrypted randomized key may. It is + saved in the LUKS2 volume JSON token header. When unlocking the encrypted volume, the primary key + pair is generated on the TPM2 chip again (which works as long as the chip's seed key is correctly + maintained by the TPM2 chip), which is then used to decrypt (on the TPM2 chip) the encrypted key from + the LUKS2 volume JSON token header saved there during enrollment. The resulting decrypted key is then + used to unlock the volume. When the randomized key is encrypted the current values of the selected + PCRs (see below) are included in the operation, so that different PCR state results in different + encrypted keys and the decrypted key can only be recovered if the same PCR state is + reproduced. + + + + + + Takes a + separated list of numeric TPM2 PCR (i.e. "Platform + Configuration Register") indexes to bind the TPM2 volume unlocking to. This option is only useful + when TPM2 enrollment metadata is not available in the LUKS2 JSON token header already, the way + systemd-cryptenroll writes it there. If not used (and no metadata in the LUKS2 + JSON token header defines it), defaults to a list of a single entry: PCR 7. Assign an empty string to + encode a policy that binds the key to no PCRs, making the key accessible to local programs regardless + of the current PCR state. + + + + + + Takes a boolean argument, defaults to false. Controls whether + TPM2 volume unlocking is bound to a PIN in addition to PCRs. Similarly, this option is only useful + when TPM2 enrollment metadata is not available. + + + + + + Takes an absolute path to a TPM2 PCR JSON signature file, as produced by the + systemd-measure1 + tool. This permits locking LUKS2 volumes to any PCR values for which a valid signature matching a + public key specified at key enrollment time can be provided. See + systemd-cryptenroll1 + for details on enrolling TPM2 PCR public keys. If this option is not specified but it is attempted to + unlock a LUKS2 volume with a signed TPM2 PCR enrollment a suitable signature file + tpm2-pcr-signature.json is searched for in /etc/systemd/, + /run/systemd/, /usr/lib/systemd/ (in this + order). + + + + + + Specifies how long to wait at most for configured security devices (i.e. FIDO2, + PKCS#11, TPM2) to show up. Takes a time value in seconds (but other time units may be specified too, + see systemd.time7 + for supported formats). Defaults to 30s. Once the specified timeout elapsed authentication via + password is attempted. Note that this timeout applies to waiting for the security device to show up — + it does not apply to the PIN prompt for the device (should one be needed) or similar. Pass 0 to turn + off the time-out and wait forever. + + + + + + Takes a boolean argument. If enabled, right before asking the user for a password it + is first attempted to unlock the volume with an empty password. This is useful for systems that are + initialized with an encrypted volume with only an empty password set, which shall be replaced with a + suitable password during first boot, but after activation. + + + + + + Specifies how long systemd should wait for a block device to show up before + giving up on the entry. The argument is a time in seconds or explicitly specified units of + s, min, h, ms. + + + + + + + Setup this encrypted block device in the initrd, similarly to + systemd.mount5 + units marked with . + + Although it's not necessary to mark the mount entry for the root file system with + , is still recommended with + the encrypted block device containing the root file system as otherwise systemd will + attempt to detach the device during the regular system shutdown while it's still in + use. With this option the device will still be detached but later after the root file + system is unmounted. + + All other encrypted block devices that contain file systems mounted in the initrd should use + this option. + + + + + + At early boot and when the system manager configuration is + reloaded, this file is translated into native systemd units by + systemd-cryptsetup-generator8. + + + + <constant>AF_UNIX</constant> Key Files + + If the key file path (as specified in the third column of /etc/crypttab + entries, see above) refers to an AF_UNIX stream socket in the file system, the key + is acquired by connecting to the socket and reading the key from the connection. The connection is made + from an AF_UNIX socket name in the abstract namespace, see unix7 for + details. The source socket name is chosen according the following format: + + NUL RANDOM /cryptsetup/ VOLUME + + In other words: a NUL byte (as required for abstract namespace sockets), + followed by a random string (consisting of alphanumeric characters only), followed by the literal + string /cryptsetup/, followed by the name of the volume to acquire they key + for. For example, for the volume myvol: + + \0d7067f78d9827418/cryptsetup/myvol + + Services listening on the AF_UNIX stream socket may query the source socket + name with getpeername2, + and use this to determine which key to send, allowing a single listening socket to serve keys for + multiple volumes. If the PKCS#11 logic is used (see above), the socket source name is picked in similar + fashion, except that the literal string /cryptsetup-pkcs11/ is used. And similarly for + FIDO2 (/cryptsetup-fido2/) and TPM2 (/cryptsetup-tpm2/). A diffent + path component is used so that services providing key material know that the secret key was not requested + directly, but instead an encrypted key that will be decrypted via the PKCS#11/FIDO2/TPM2 logic to acquire + the final secret key. + + + + Examples + + /etc/crypttab example + Set up four encrypted block devices. One using LUKS for normal storage, another one for usage as + a swap device and two TrueCrypt volumes. For the fourth device, the option string is interpreted as two + options cipher=xchacha12,aes-adiantum-plain64, + keyfile-timeout=10s. + + luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b +swap /dev/sda7 /dev/urandom swap +truecrypt /dev/sda2 /etc/container_password tcrypt +hidden /mnt/tc_hidden /dev/null tcrypt-hidden,tcrypt-keyfile=/etc/keyfile +external /dev/sda3 keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64 + + + + + Yubikey-based PKCS#11 Volume Unlocking Example + + The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA + decryption keys for unlocking an encrypted volume. Here's an example how to set up a Yubikey security + token for this purpose on a LUKS2 volume, using ykmap1 from the + yubikey-manager project to initialize the token and + systemd-cryptenroll1 + to add it in the LUKS2 volume: + + + + A few notes on the above: + + + We use RSA2048, which is the longest key size current Yubikeys support + We use Yubikey key slot 9d, since that's apparently the keyslot to use for decryption purposes, + see + documentation. + + + + + FIDO2 Volume Unlocking Example + + The FIDO2 logic allows using any compatible FIDO2 security token that implements the + hmac-secret extension for unlocking an encrypted volume. Here's an example how to + set up a FIDO2 security token for this purpose for a LUKS2 volume, using + systemd-cryptenroll1: + + + + + + TPM2 Volume Unlocking Example + + The TPM2 logic allows using any TPM2 chip supported by the Linux kernel for unlocking an + encrypted volume. Here's an example how to set up a TPM2 chip for this purpose for a LUKS2 volume, + using + systemd-cryptenroll1: + + + + + + + See Also + + systemd1, + systemd-cryptsetup@.service8, + systemd-cryptsetup-generator8, + systemd-cryptenroll1, + fstab5, + cryptsetup8, + mkswap8, + mke2fs8 + + + + diff --git a/man/custom-entities.ent.in b/man/custom-entities.ent.in new file mode 100644 index 0000000..d25340d --- /dev/null +++ b/man/custom-entities.ent.in @@ -0,0 +1,19 @@ + + + + + + + + + + + + + + + + + + + diff --git a/man/custom-html.xsl b/man/custom-html.xsl new file mode 100644 index 0000000..8b21e15 --- /dev/null +++ b/man/custom-html.xsl @@ -0,0 +1,318 @@ + + + + + + + + + + + + + + + .html# + + + + + + + + + + https://man7.org/linux/man-pages/man + + / + + . + + .html + + + + + + + + + http://linux.die.net/man/ + + / + + + + + + + + + + https://git.zx2c4.com/WireGuard/about/src/tools/ + + . + + + + + + + + + + https://www.mankier.com/ + + / + + + + + + + + + + https://www.archlinux.org/ + + / + + . + + .html + + + + + + + + + https://manpages.debian.org/unstable/ + + / + + . + + .en.html + + + + + + + + + https://www.freebsd.org/cgi/man.cgi? + + ( + + ) + + + + + + + + + https://dbus.freedesktop.org/doc/ + + . + + .html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + + + index.html + + Index + · + + + systemd.directives.html + + Directives + + + + systemd + + +
+ + + + " + + " + + + + + + diff --git a/man/custom-man.xsl b/man/custom-man.xsl new file mode 100644 index 0000000..2ed361f --- /dev/null +++ b/man/custom-man.xsl @@ -0,0 +1,49 @@ + + + + + + + + + + + + + + + + + + + .TH " + + + + + + " " + + " "" "systemd + + " " + + " + + + + + + + + " + + " + + + diff --git a/man/daemon.xml b/man/daemon.xml new file mode 100644 index 0000000..f2b3f6f --- /dev/null +++ b/man/daemon.xml @@ -0,0 +1,731 @@ + + + + + + + + daemon + systemd + + + + daemon + 7 + + + + daemon + Writing and packaging system daemons + + + + Description + + A daemon is a service process that runs in the background + and supervises the system or provides functionality to other + processes. Traditionally, daemons are implemented following a + scheme originating in SysV Unix. Modern daemons should follow a + simpler yet more powerful scheme (here called "new-style" + daemons), as implemented by + systemd1. + This manual page covers both schemes, and in particular includes + recommendations for daemons that shall be included in the systemd + init system. + + + SysV Daemons + + When a traditional SysV daemon starts, it should execute + the following steps as part of the initialization. Note that + these steps are unnecessary for new-style daemons (see below), + and should only be implemented if compatibility with SysV is + essential. + + + Close all open file descriptors except + standard input, output, and error (i.e. the first three file + descriptors 0, 1, 2). This ensures that no accidentally passed + file descriptor stays around in the daemon process. On Linux, + this is best implemented by iterating through + /proc/self/fd, with a fallback of + iterating from file descriptor 3 to the value returned by + getrlimit() for + RLIMIT_NOFILE. + + Reset all signal handlers to their default. + This is best done by iterating through the available signals + up to the limit of _NSIG and resetting + them to SIG_DFL. + + Reset the signal mask + using + sigprocmask(). + + Sanitize the environment block, removing or + resetting environment variables that might negatively impact + daemon runtime. + + Call fork(), to create a + background process. + + In the child, call + setsid() to detach from any terminal and + create an independent session. + + In the child, call fork() again, to ensure that the daemon can + never re-acquire a terminal again. (This relevant if the program — and all its dependencies — does + not carefully specify `O_NOCTTY` on each and every single `open()` call that might potentially open a + TTY device node.) + + Call exit() in the first + child, so that only the second child (the actual daemon + process) stays around. This ensures that the daemon process is + re-parented to init/PID 1, as all daemons should + be. + + In the daemon process, connect + /dev/null to standard input, output, and + error. + + In the daemon process, reset the umask to 0, + so that the file modes passed to open(), + mkdir() and suchlike directly control the + access mode of the created files and + directories. + + In the daemon process, change the current + directory to the root directory (/), in order to avoid that + the daemon involuntarily blocks mount points from being + unmounted. + + In the daemon process, write the daemon PID + (as returned by getpid()) to a PID file, + for example /run/foobar.pid (for a + hypothetical daemon "foobar") to ensure that the daemon cannot + be started more than once. This must be implemented in + race-free fashion so that the PID file is only updated when it + is verified at the same time that the PID previously stored in + the PID file no longer exists or belongs to a foreign + process. + + In the daemon process, drop privileges, if + possible and applicable. + + From the daemon process, notify the original + process started that initialization is complete. This can be + implemented via an unnamed pipe or similar communication + channel that is created before the first + fork() and hence available in both the + original and the daemon process. + + Call exit() in the + original process. The process that invoked the daemon must be + able to rely on that this exit() happens + after initialization is complete and all external + communication channels are established and + accessible. + + + The BSD daemon() function should not + be used, as it implements only a subset of these steps. + + A daemon that needs to provide compatibility with SysV + systems should implement the scheme pointed out above. However, + it is recommended to make this behavior optional and + configurable via a command line argument to ease debugging as + well as to simplify integration into systems using + systemd. + + + + New-Style Daemons + + Modern services for Linux should be implemented as + new-style daemons. This makes it easier to supervise and control + them at runtime and simplifies their implementation. + + For developing a new-style daemon, none of the + initialization steps recommended for SysV daemons need to be + implemented. New-style init systems such as systemd make all of + them redundant. Moreover, since some of these steps interfere + with process monitoring, file descriptor passing and other + functionality of the init system, it is recommended not to + execute them when run as new-style service. + + Note that new-style init systems guarantee execution of daemon processes in a clean process context: it is + guaranteed that the environment block is sanitized, that the signal handlers and mask is reset and that no + left-over file descriptors are passed. Daemons will be executed in their own session, with standard input + connected to /dev/null and standard output/error connected to the + systemd-journald.service8 + logging service, unless otherwise configured. The umask is reset. + + + It is recommended for new-style daemons to implement the + following: + + + If SIGTERM is received, + shut down the daemon and exit cleanly. + + If SIGHUP is received, + reload the configuration files, if this + applies. + + Provide a correct exit code from the main + daemon process, as this is used by the init system to detect + service errors and problems. It is recommended to follow the + exit code scheme as defined in the LSB + recommendations for SysV init + scripts. + + If possible and applicable, expose the + daemon's control interface via the D-Bus IPC system and grab a + bus name as last step of initialization. + + For integration in systemd, provide a + .service unit file that carries + information about starting, stopping and otherwise maintaining + the daemon. See + systemd.service5 + for details. + + As much as possible, rely on the init system's + functionality to limit the access of the daemon to files, + services and other resources, i.e. in the case of systemd, + rely on systemd's resource limit control instead of + implementing your own, rely on systemd's privilege dropping + code instead of implementing it in the daemon, and similar. + See + systemd.exec5 + for the available controls. + + If D-Bus is used, make your daemon + bus-activatable by supplying a D-Bus service activation + configuration file. This has multiple advantages: your daemon + may be started lazily on-demand; it may be started in parallel + to other daemons requiring it — which maximizes + parallelization and boot-up speed; your daemon can be + restarted on failure without losing any bus requests, as the + bus queues requests for activatable services. See below for + details. + + If your daemon provides services to other + local processes or remote clients via a socket, it should be + made socket-activatable following the scheme pointed out + below. Like D-Bus activation, this enables on-demand starting + of services as well as it allows improved parallelization of + service start-up. Also, for state-less protocols (such as + syslog, DNS), a daemon implementing socket-based activation + can be restarted without losing a single request. See below + for details. + + If applicable, a daemon should notify the init + system about startup completion or status updates via the + sd_notify3 + interface. + + Instead of using the + syslog() call to log directly to the + system syslog service, a new-style daemon may choose to simply + log to standard error via fprintf(), + which is then forwarded to syslog by the init system. If log + levels are necessary, these can be encoded by prefixing + individual log lines with strings like + <4> (for log level 4 "WARNING" in the + syslog priority scheme), following a similar style as the + Linux kernel's printk() level system. For + details, see + sd-daemon3 + and + systemd.exec5. + + As new-style daemons are invoked without a controlling TTY (but as their own session + leaders) care should be taken to always specify `O_NOCTTY` on `open()` calls that possibly reference + a TTY device node, so that no controlling TTY is accidentally acquired. + + + + These recommendations are similar but not identical to the + Apple + MacOS X Daemon Requirements. + + + + + Activation + + New-style init systems provide multiple additional + mechanisms to activate services, as detailed below. It is common + that services are configured to be activated via more than one + mechanism at the same time. An example for systemd: + bluetoothd.service might get activated either + when Bluetooth hardware is plugged in, or when an application + accesses its programming interfaces via D-Bus. Or, a print server + daemon might get activated when traffic arrives at an IPP port, or + when a printer is plugged in, or when a file is queued in the + printer spool directory. Even for services that are intended to be + started on system bootup unconditionally, it is a good idea to + implement some of the various activation schemes outlined below, + in order to maximize parallelization. If a daemon implements a + D-Bus service or listening socket, implementing the full bus and + socket activation scheme allows starting of the daemon with its + clients in parallel (which speeds up boot-up), since all its + communication channels are established already, and no request is + lost because client requests will be queued by the bus system (in + case of D-Bus) or the kernel (in case of sockets) until the + activation is completed. + + + Activation on Boot + + Old-style daemons are usually activated exclusively on + boot (and manually by the administrator) via SysV init scripts, + as detailed in the LSB + Linux Standard Base Core Specification. This method of + activation is supported ubiquitously on Linux init systems, both + old-style and new-style systems. Among other issues, SysV init + scripts have the disadvantage of involving shell scripts in the + boot process. New-style init systems generally employ updated + versions of activation, both during boot-up and during runtime + and using more minimal service description files. + + In systemd, if the developer or administrator wants to + make sure that a service or other unit is activated + automatically on boot, it is recommended to place a symlink to + the unit file in the .wants/ directory of + either multi-user.target or + graphical.target, which are normally used + as boot targets at system startup. See + systemd.unit5 + for details about the .wants/ directories, + and + systemd.special7 + for details about the two boot targets. + + + + + Socket-Based Activation + + In order to maximize the possible parallelization and + robustness and simplify configuration and development, it is + recommended for all new-style daemons that communicate via + listening sockets to employ socket-based activation. In a + socket-based activation scheme, the creation and binding of the + listening socket as primary communication channel of daemons to + local (and sometimes remote) clients is moved out of the daemon + code and into the init system. Based on per-daemon + configuration, the init system installs the sockets and then + hands them off to the spawned process as soon as the respective + daemon is to be started. Optionally, activation of the service + can be delayed until the first inbound traffic arrives at the + socket to implement on-demand activation of daemons. However, + the primary advantage of this scheme is that all providers and + all consumers of the sockets can be started in parallel as soon + as all sockets are established. In addition to that, daemons can + be restarted with losing only a minimal number of client + transactions, or even any client request at all (the latter is + particularly true for state-less protocols, such as DNS or + syslog), because the socket stays bound and accessible during + the restart, and all requests are queued while the daemon cannot + process them. + + New-style daemons which support socket activation must be + able to receive their sockets from the init system instead of + creating and binding them themselves. For details about the + programming interfaces for this scheme provided by systemd, see + sd_listen_fds3 + and + sd-daemon3. + For details about porting existing daemons to socket-based + activation, see below. With minimal effort, it is possible to + implement socket-based activation in addition to traditional + internal socket creation in the same codebase in order to + support both new-style and old-style init systems from the same + daemon binary. + + systemd implements socket-based activation via + .socket units, which are described in + systemd.socket5. + When configuring socket units for socket-based activation, it is + essential that all listening sockets are pulled in by the + special target unit sockets.target. It is + recommended to place a + WantedBy=sockets.target directive in the + [Install] section to automatically add such a + dependency on installation of a socket unit. Unless + DefaultDependencies=no is set, the necessary + ordering dependencies are implicitly created for all socket + units. For more information about + sockets.target, see + systemd.special7. + It is not necessary or recommended to place any additional + dependencies on socket units (for example from + multi-user.target or suchlike) when one is + installed in sockets.target. + + + + Bus-Based Activation + + When the D-Bus IPC system is used for communication with + clients, new-style daemons should employ bus activation so that + they are automatically activated when a client application + accesses their IPC interfaces. This is configured in D-Bus + service files (not to be confused with systemd service unit + files!). To ensure that D-Bus uses systemd to start-up and + maintain the daemon, use the SystemdService= + directive in these service files to configure the matching + systemd service for a D-Bus service. e.g.: For a D-Bus service + whose D-Bus activation file is named + org.freedesktop.RealtimeKit.service, make + sure to set + SystemdService=rtkit-daemon.service in that + file to bind it to the systemd service + rtkit-daemon.service. This is needed to + make sure that the daemon is started in a race-free fashion when + activated via multiple mechanisms simultaneously. + + + + Device-Based Activation + + Often, daemons that manage a particular type of hardware + should be activated only when the hardware of the respective + kind is plugged in or otherwise becomes available. In a + new-style init system, it is possible to bind activation to + hardware plug/unplug events. In systemd, kernel devices + appearing in the sysfs/udev device tree can be exposed as units + if they are tagged with the string systemd. + Like any other kind of unit, they may then pull in other units + when activated (i.e. plugged in) and thus implement device-based + activation. systemd dependencies may be encoded in the udev + database via the SYSTEMD_WANTS= property. See + systemd.device5 + for details. Often, it is nicer to pull in services from devices + only indirectly via dedicated targets. Example: Instead of + pulling in bluetoothd.service from all the + various bluetooth dongles and other hardware available, pull in + bluetooth.target from them and + bluetoothd.service from that target. This + provides for nicer abstraction and gives administrators the + option to enable bluetoothd.service via + controlling a bluetooth.target.wants/ + symlink uniformly with a command like enable + of + systemctl1 + instead of manipulating the udev ruleset. + + + + Path-Based Activation + + Often, runtime of daemons processing spool files or + directories (such as a printing system) can be delayed until + these file system objects change state, or become non-empty. + New-style init systems provide a way to bind service activation + to file system changes. systemd implements this scheme via + path-based activation configured in .path + units, as outlined in + systemd.path5. + + + + Timer-Based Activation + + Some daemons that implement clean-up jobs that are + intended to be executed in regular intervals benefit from + timer-based activation. In systemd, this is implemented via + .timer units, as described in + systemd.timer5. + + + + Other Forms of Activation + + Other forms of activation have been suggested and implemented in some systems. However, there are + often simpler or better alternatives, or they can be put together of combinations of the schemes + above. Example: Sometimes, it appears useful to start daemons or .socket units + when a specific IP address is configured on a network interface, because network sockets shall be bound + to the address. However, an alternative to implement this is by utilizing the Linux + IP_FREEBIND/IPV6_FREEBIND socket option, as accessible via + FreeBind=yes in systemd socket files (see + systemd.socket5 for + details). This option, when enabled, allows sockets to be bound to a non-local, not configured IP + address, and hence allows bindings to a particular IP address before it actually becomes available, + making such an explicit dependency to the configured address redundant. Another often suggested trigger + for service activation is low system load. However, here too, a more convincing approach might be to + make proper use of features of the operating system, in particular, the CPU or I/O scheduler of + Linux. Instead of scheduling jobs from userspace based on monitoring the OS scheduler, it is advisable + to leave the scheduling of processes to the OS scheduler itself. systemd provides fine-grained access + to the CPU and I/O schedulers. If a process executed by the init system shall not negatively impact the + amount of CPU or I/O bandwidth available to other processes, it should be configured with + CPUSchedulingPolicy=idle and/or + IOSchedulingClass=idle. Optionally, this may be combined with timer-based activation + to schedule background jobs during runtime and with minimal impact on the system, and remove it from + the boot phase itself. + + + + + Integration with systemd + + + Writing systemd Unit Files + + When writing systemd unit files, it is recommended to + consider the following suggestions: + + + If possible, do not use the + Type=forking setting in service files. But + if you do, make sure to set the PID file path using + PIDFile=. See + systemd.service5 + for details. + + If your daemon registers a D-Bus name on the + bus, make sure to use Type=dbus in the + service file if possible. + + Make sure to set a good human-readable + description string with + Description=. + + Do not disable + DefaultDependencies=, unless you really + know what you do and your unit is involved in early boot or + late system shutdown. + + Normally, little if any dependencies should + need to be defined explicitly. However, if you do configure + explicit dependencies, only refer to unit names listed on + systemd.special7 + or names introduced by your own package to keep the unit file + operating system-independent. + + Make sure to include an + [Install] section including installation + information for the unit file. See + systemd.unit5 + for details. To activate your service on boot, make sure to + add a WantedBy=multi-user.target or + WantedBy=graphical.target directive. To + activate your socket on boot, make sure to add + WantedBy=sockets.target. Usually, you also + want to make sure that when your service is installed, your + socket is installed too, hence add + Also=foo.socket in your service file + foo.service, for a hypothetical program + foo. + + + + + + Installing systemd Service Files + + At the build installation time (e.g. make + install during package build), packages are + recommended to install their systemd unit files in the directory + returned by pkg-config systemd + --variable=systemdsystemunitdir (for system services) + or pkg-config systemd + --variable=systemduserunitdir (for user services). + This will make the services available in the system on explicit + request but not activate them automatically during boot. + Optionally, during package installation (e.g. rpm + -i by the administrator), symlinks should be created + in the systemd configuration directories via the + enable command of the + systemctl1 + tool to activate them automatically on boot. + + Packages using + autoconf1 + are recommended to use a configure script + excerpt like the following to determine the + unit installation path during source + configuration: + + PKG_PROG_PKG_CONFIG() +AC_ARG_WITH([systemdsystemunitdir], + [AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],, + [with_systemdsystemunitdir=auto]) +AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [ + def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd) + + AS_IF([test "x$def_systemdsystemunitdir" = "x"], + [AS_IF([test "x$with_systemdsystemunitdir" = "xyes"], + [AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])]) + with_systemdsystemunitdir=no], + [with_systemdsystemunitdir="$def_systemdsystemunitdir"])]) +AS_IF([test "x$with_systemdsystemunitdir" != "xno"], + [AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])]) +AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"]) + + This snippet allows automatic + installation of the unit files on systemd + machines, and optionally allows their + installation even on machines lacking + systemd. (Modification of this snippet for the + user unit directory is left as an exercise for the + reader.) + + Additionally, to ensure that + make distcheck continues to + work, it is recommended to add the following + to the top-level Makefile.am + file in + automake1-based + projects: + + AM_DISTCHECK_CONFIGURE_FLAGS = \ + --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir) + + Finally, unit files should be installed in the system with an automake excerpt like the following: + + if HAVE_SYSTEMD +systemdsystemunit_DATA = \ + foobar.socket \ + foobar.service +endif + + In the + rpm8 + .spec file, use snippets like the following + to enable/disable the service during + installation/deinstallation. This makes use of the RPM macros + shipped along systemd. Consult the packaging guidelines of your + distribution for details and the equivalent for other package + managers. + + At the top of the file: + + BuildRequires: systemd +%{?systemd_requires} + + And as scriptlets, further down: + + %post +%systemd_post foobar.service foobar.socket + +%preun +%systemd_preun foobar.service foobar.socket + +%postun +%systemd_postun + + If the service shall be restarted during upgrades, replace + the %postun scriptlet above with the + following: + + %postun +%systemd_postun_with_restart foobar.service + + Note that %systemd_post and + %systemd_preun expect the names of all units + that are installed/removed as arguments, separated by spaces. + %systemd_postun expects no arguments. + %systemd_postun_with_restart expects the + units to restart as arguments. + + To facilitate upgrades from a package version that shipped + only SysV init scripts to a package version that ships both a + SysV init script and a native systemd service file, use a + fragment like the following: + + %triggerun -- foobar < 0.47.11-1 +if /sbin/chkconfig --level 5 foobar ; then + /bin/systemctl --no-reload enable foobar.service foobar.socket >/dev/null 2>&1 || : +fi + + Where 0.47.11-1 is the first package version that includes + the native unit file. This fragment will ensure that the first + time the unit file is installed, it will be enabled if and only + if the SysV init script is enabled, thus making sure that the + enable status is not changed. Note that + chkconfig is a command specific to Fedora + which can be used to check whether a SysV init script is + enabled. Other operating systems will have to use different + commands here. + + + + + Porting Existing Daemons + + Since new-style init systems such as systemd are compatible + with traditional SysV init systems, it is not strictly necessary + to port existing daemons to the new style. However, doing so + offers additional functionality to the daemons as well as + simplifying integration into new-style init systems. + + To port an existing SysV compatible daemon, the following + steps are recommended: + + + If not already implemented, add an optional + command line switch to the daemon to disable daemonization. This + is useful not only for using the daemon in new-style init + systems, but also to ease debugging. + + If the daemon offers interfaces to other + software running on the local system via local + AF_UNIX sockets, consider implementing + socket-based activation (see above). Usually, a minimal patch is + sufficient to implement this: Extend the socket creation in the + daemon code so that + sd_listen_fds3 + is checked for already passed sockets first. If sockets are + passed (i.e. when sd_listen_fds() returns a + positive value), skip the socket creation step and use the + passed sockets. Secondly, ensure that the file system socket + nodes for local AF_UNIX sockets used in the + socket-based activation are not removed when the daemon shuts + down, if sockets have been passed. Third, if the daemon normally + closes all remaining open file descriptors as part of its + initialization, the sockets passed from the init system must be + spared. Since new-style init systems guarantee that no left-over + file descriptors are passed to executed processes, it might be a + good choice to simply skip the closing of all remaining open + file descriptors if sockets are passed. + + Write and install a systemd unit file for the + service (and the sockets if socket-based activation is used, as + well as a path unit file, if the daemon processes a spool + directory), see above for details. + + If the daemon exposes interfaces via D-Bus, + write and install a D-Bus activation file for the service, see + above for details. + + + + + Placing Daemon Data + + It is recommended to follow the general guidelines for + placing package files, as discussed in + file-hierarchy7. + + + + See Also + + systemd1, + sd-daemon3, + sd_listen_fds3, + sd_notify3, + daemon3, + systemd.service5, + file-hierarchy7 + + + + diff --git a/man/directives-template.xml b/man/directives-template.xml new file mode 100644 index 0000000..f28bd98 --- /dev/null +++ b/man/directives-template.xml @@ -0,0 +1,206 @@ + + + + + systemd.directives + systemd + + + + systemd.directives + 7 + + + + systemd.directives + Index of configuration directives + + + + Unit directives + + Directives for configuring units, used in unit files. + + + + + + Options on the kernel command line + + Kernel boot options for configuring the behaviour of the systemd process. + + + + + + Environment variables + + Environment variables understood by the systemd manager and other programs and environment + variable-compatible settings. + + + + + + EFI variables + + EFI variables understood by + systemd-boot7 + and other programs. + + + + + + Home Area/User Account directives + + Directives for configuring home areas and user accounts via + systemd-homed.service8. + + + + + + UDEV directives + + Directives for configuring systemd units through the udev database. + + + + + + Network directives + + Directives for configuring network links through the net-setup-link udev builtin and networks + through systemd-networkd. + + + + + + Journal fields + + Fields in the journal events with a well known meaning. + + + + + + PAM configuration directives + + Directives for configuring PAM behaviour. + + + + + + <filename>/etc/crypttab</filename>, + <filename>/etc/veritytab</filename> and + <filename>/etc/fstab</filename> options + + Options which influence mounted filesystems and encrypted volumes. + + + + + + <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry> + directives + + Directives for configuring systemd-nspawn containers. + + + + + + Program configuration options + + Directives for configuring the behaviour of the systemd process and other tools through + configuration files. + + + + + + Command line options + + Command-line options accepted by programs in the systemd suite. + + + + + + Constants + + Various constants used and/or defined by systemd. + + + + + + DNS resource record types + + + + + + Miscellaneous options and directives + + Other configuration elements which don't fit in any of the above groups. + + + + + + Specifiers + + Short strings which are substituted in configuration directives. + + + + + + Files and directories + + Paths and file names referred to in the documentation. + + + + + + D-Bus interfaces + + Interfaces exposed over D-Bus. + + + + + + D-Bus methods + + Methods exposed in the D-Bus interface. + + + + + + D-Bus properties + + Properties exposed in the D-Bus interface. + + + + + + D-Bus signals + + Signals emitted in the D-Bus interface. + + + + + + Colophon + + + diff --git a/man/dnssec-trust-anchors.d.xml b/man/dnssec-trust-anchors.d.xml new file mode 100644 index 0000000..39b9515 --- /dev/null +++ b/man/dnssec-trust-anchors.d.xml @@ -0,0 +1,172 @@ + + + + + + + dnssec-trust-anchors.d + systemd + + + + dnssec-trust-anchors.d + 5 + + + + dnssec-trust-anchors.d + systemd.positive + systemd.negative + DNSSEC trust anchor configuration files + + + + /etc/dnssec-trust-anchors.d/*.positive + /run/dnssec-trust-anchors.d/*.positive + /usr/lib/dnssec-trust-anchors.d/*.positive + /etc/dnssec-trust-anchors.d/*.negative + /run/dnssec-trust-anchors.d/*.negative + /usr/lib/dnssec-trust-anchors.d/*.negative + + + + Description + + The DNSSEC trust anchor configuration files define positive + and negative trust anchors + systemd-resolved.service8 + bases DNSSEC integrity proofs on. + + + + Positive Trust Anchors + + Positive trust anchor configuration files contain DNSKEY and + DS resource record definitions to use as base for DNSSEC integrity + proofs. See RFC 4035, Section 4.4 + for more information about DNSSEC trust anchors. + + Positive trust anchors are read from files with the suffix + .positive located in + /etc/dnssec-trust-anchors.d/, + /run/dnssec-trust-anchors.d/ and + /usr/lib/dnssec-trust-anchors.d/. These + directories are searched in the specified order, and a trust + anchor file of the same name in an earlier path overrides a trust + anchor files in a later path. To disable a trust anchor file + shipped in /usr/lib/dnssec-trust-anchors.d/ + it is sufficient to provide an identically-named file in + /etc/dnssec-trust-anchors.d/ or + /run/dnssec-trust-anchors.d/ that is either + empty or a symlink to /dev/null ("masked"). + + Positive trust anchor files are simple text files resembling DNS zone files, as documented in + RFC 1035, Section 5. One DS or DNSKEY resource record may be listed per + line. Empty lines and lines starting with # or ; are ignored, which + may be used for commenting. A DS resource record is specified like in the + following example: + + . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 + + The first word specifies the domain, use + . for the root domain. The domain may be + specified with or without trailing dot, which is considered + equivalent. The second word must be IN the + third word DS. The following words specify the + key tag, signature algorithm, digest algorithm, followed by the + hex-encoded key fingerprint. See RFC 4034, + Section 5 for details about the precise syntax and meaning + of these fields. + + Alternatively, DNSKEY resource records may be used to define trust + anchors, like in the following example: + + . IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= + + The first word specifies the domain again, the second word must be IN, followed + by DNSKEY. The subsequent words encode the DNSKEY + flags, protocol and algorithm fields, followed by the key data encoded in Base64. See RFC 4034, Section 2 for details about the + precise syntax and meaning of these fields. + + If multiple DS or DNSKEY records + are defined for the same domain (possibly even in different trust anchor files), all keys are used and + are considered equivalent as base for DNSSEC proofs. + + Note that systemd-resolved will + automatically use a built-in trust anchor key for the Internet + root domain if no positive trust anchors are defined for the root + domain. In most cases it is hence unnecessary to define an + explicit key with trust anchor files. The built-in key is disabled + as soon as at least one trust anchor key for the root domain is + defined in trust anchor files. + + It is generally recommended to encode trust anchors in DS resource + records, rather than DNSKEY resource records. + + If a trust anchor specified via a DS record is found revoked it is + automatically removed from the trust anchor database for the runtime. See RFC 5011 for details about revoked trust anchors. Note + that systemd-resolved will not update its trust anchor database from DNS servers + automatically. Instead, it is recommended to update the resolver software or update the new trust anchor + via adding in new trust anchor files. + + The current DNSSEC trust anchor for the Internet's root + domain is available at the IANA + Trust Anchor and Keys page. + + + + Negative Trust Anchors + + Negative trust anchors define domains where DNSSEC validation shall be turned + off. Negative trust anchor files are found at the same location as positive trust anchor files, + and follow the same overriding rules. They are text files with the + .negative suffix. Empty lines and lines whose first character is + ; are ignored. Each line specifies one domain name which is the root of a DNS + subtree where validation shall be disabled. For example: + + # Reverse IPv4 mappings +10.in-addr.arpa +16.172.in-addr.arpa +168.192.in-addr.arpa +... +# Some custom domains +prod +stag + + + Negative trust anchors are useful to support private DNS + subtrees that are not referenced from the Internet DNS hierarchy, + and not signed. + + RFC + 7646 for details on negative trust anchors. + + If no negative trust anchor files are configured a built-in + set of well-known private DNS zone domains is used as negative + trust anchors. + + It is also possibly to define per-interface negative trust + anchors using the DNSSECNegativeTrustAnchors= + setting in + systemd.network5 + files. + + + + See Also + + systemd1, + systemd-resolved.service8, + resolved.conf5, + systemd.network5 + + + + diff --git a/man/environment.d.xml b/man/environment.d.xml new file mode 100644 index 0000000..fc03405 --- /dev/null +++ b/man/environment.d.xml @@ -0,0 +1,133 @@ + + + + + + + + environment.d + systemd + + + + environment.d + 5 + + + + environment.d + Definition of user service environment + + + + ~/.config/environment.d/*.conf + /etc/environment.d/*.conf + /run/environment.d/*.conf + /usr/lib/environment.d/*.conf + /etc/environment + + + + Description + + Configuration files in the environment.d/ directories contain lists of + environment variable assignments passed to services started by the systemd user instance. + systemd-environment-d-generator8 + parses them and updates the environment exported by the systemd user instance. See below for an + discussion of which processes inherit those variables. + + It is recommended to use numerical prefixes for file names to simplify ordering. + + For backwards compatibility, a symlink to /etc/environment is + installed, so this file is also parsed. + + + + + + Configuration Format + + The configuration files contain a list of + KEY=VALUE environment + variable assignments, separated by newlines. The right hand side of these assignments may + reference previously defined environment variables, using the ${OTHER_KEY} + and $OTHER_KEY format. It is also possible to use + ${FOO:-DEFAULT_VALUE} + to expand in the same way as ${FOO} unless the + expansion would be empty, in which case it expands to DEFAULT_VALUE, + and use + ${FOO:+ALTERNATE_VALUE} + to expand to ALTERNATE_VALUE as long as + ${FOO} would have expanded to a non-empty value. + No other elements of shell syntax are supported. + + Each KEY must be a valid variable name. Empty lines + and lines beginning with the comment character # are ignored. + + + Example + + Setup environment to allow access to a program installed in + <filename index="false">/opt/foo</filename> + + /etc/environment.d/60-foo.conf: + + + FOO_DEBUG=force-software-gl,log-verbose + PATH=/opt/foo/bin:$PATH + LD_LIBRARY_PATH=/opt/foo/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} + XDG_DATA_DIRS=/opt/foo/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/} + + + + + + + Applicability + + Environment variables exported by the user service manager (systemd --user + instance started in the user@uid.service system service) + are passed to any services started by that service manager. In particular, this may include services + which run user shells. For example in the GNOME environment, the graphical terminal emulator runs as the + gnome-terminal-server.service user unit, which in turn runs the user shell, so that + shell will inherit environment variables exported by the user manager. For other instances of the shell, + not launched by the user service manager, the environment they inherit is defined by the program that + starts them. Hint: in general, + systemd.service5 units + contain programs launched by systemd, and + systemd.scope5 units + contain programs launched by something else. + + Note that these files do not affect the environment block of the service manager itself, but + exclusively the environment blocks passed to the services it manages. Environment variables set that way + thus cannot be used to influence behaviour of the service manager. In order to make changes to the + service manager's environment block the environment must be modified before the user's service manager is + invoked, for example from the system service manager or via a PAM module. + + Specifically, for ssh logins, the + sshd8 + service builds an environment that is a combination of variables forwarded from the remote system and + defined by sshd, see the discussion in + ssh1. + A graphical display session will have an analogous mechanism to define the environment. Note that some + managers query the systemd user instance for the exported environment and inject this configuration into + programs they start, using systemctl show-environment or the underlying D-Bus call. + + + + + See Also + + systemd1, + systemd-environment-d-generator8, + systemd.environment-generator7 + + + + diff --git a/man/event-quick-child.c b/man/event-quick-child.c new file mode 100644 index 0000000..8195efb --- /dev/null +++ b/man/event-quick-child.c @@ -0,0 +1,42 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include +#include + +int main(int argc, char **argv) { + pid_t pid = fork(); + assert(pid >= 0); + + /* SIGCHLD signal must be blocked for sd_event_add_child to work */ + sigset_t ss; + sigemptyset(&ss); + sigaddset(&ss, SIGCHLD); + sigprocmask(SIG_BLOCK, &ss, NULL); + + if (pid == 0) /* child */ + sleep(1); + + else { /* parent */ + sd_event *e = NULL; + int r; + + /* Create the default event loop */ + sd_event_default(&e); + assert(e); + + /* We create a floating child event source (attached to 'e'). + * The default handler will be called with 666 as userdata, which + * will become the exit value of the loop. */ + r = sd_event_add_child(e, NULL, pid, WEXITED, NULL, (void*) 666); + assert(r >= 0); + + r = sd_event_loop(e); + assert(r == 666); + + sd_event_unref(e); + } + + return 0; +} diff --git a/man/fido2-crypttab.sh b/man/fido2-crypttab.sh new file mode 100644 index 0000000..acb2e17 --- /dev/null +++ b/man/fido2-crypttab.sh @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: MIT-0 + +# Enroll the security token in the LUKS2 volume. Replace /dev/sdXn by the +# partition to use (e.g. /dev/sda1). +sudo systemd-cryptenroll --fido2-device=auto /dev/sdXn + +# Test: Let's run systemd-cryptsetup to test if this worked. +sudo /usr/lib/systemd/systemd-cryptsetup attach mytest /dev/sdXn - fido2-device=auto + +# If that worked, let's now add the same line persistently to /etc/crypttab, +# for the future. +sudo bash -c 'echo "mytest /dev/sdXn - fido2-device=auto" >> /etc/crypttab' diff --git a/man/file-hierarchy.xml b/man/file-hierarchy.xml new file mode 100644 index 0000000..1af2c67 --- /dev/null +++ b/man/file-hierarchy.xml @@ -0,0 +1,830 @@ + + + + + + + + file-hierarchy + systemd + + + + file-hierarchy + 7 + + + + file-hierarchy + File system hierarchy overview + + + + Description + + Operating systems using the + systemd1 system and service + manager are organized based on a file system hierarchy inspired by UNIX, more specifically the hierarchy described + in the File System Hierarchy + specification and hier7, with various + extensions, partially documented in the XDG Base Directory + Specification and XDG User + Directories. This manual page describes a more generalized, though minimal and modernized subset of these + specifications that defines more strictly the suggestions and restrictions systemd makes on the file system + hierarchy. + + Many of the paths described here can be queried + with the + systemd-path1 + tool. + + + + General Structure + + + + / + The file system root. Usually writable, but + this is not required. Possibly a temporary file system + (tmpfs). Not shared with other hosts + (unless read-only). + + + + /boot/ + The boot partition used for bringing up the + system. On EFI systems, this is possibly the EFI System + Partition (ESP), also see + systemd-gpt-auto-generator8. + This directory is usually strictly local to the host, and + should be considered read-only, except when a new kernel or + boot loader is installed. This directory only exists on + systems that run on physical or emulated hardware that + requires boot loaders. + + + + /efi/ + If the boot partition /boot/ is maintained separately from the EFI System + Partition (ESP), the latter is mounted here. Tools that need to operate on the EFI system partition should look + for it at this mount point first, and fall back to /boot/ — if the former doesn't qualify + (for example if it is not a mount point or does not have the correct file system type + MSDOS_SUPER_MAGIC). + + + + /etc/ + System-specific configuration. This directory + may or may not be read-only. Frequently, this directory is + pre-populated with vendor-supplied configuration files, but + applications should not make assumptions about this directory + being fully populated or populated at all, and should fall + back to defaults if configuration is + missing. + + + + /home/ + The location for normal user's home + directories. Possibly shared with other systems, and never + read-only. This directory should only be used for normal + users, never for system users. This directory and possibly the + directories contained within it might only become available or + writable in late boot or even only after user authentication. + This directory might be placed on limited-functionality + network file systems, hence applications should not assume the + full set of file API is available on this directory. + Applications should generally not reference this directory + directly, but via the per-user $HOME + environment variable, or via the home directory field of the + user database. + + + + /root/ + The home directory of the root user. The root + user's home directory is located outside of + /home/ in order to make sure the root user + may log in even without /home/ being + available and mounted. + + + + /srv/ + The place to store general server payload, + managed by the administrator. No restrictions are made how + this directory is organized internally. Generally writable, + and possibly shared among systems. This directory might become + available or writable only very late during + boot. + + + + /tmp/ + The place for small temporary files. This directory is usually mounted as a + tmpfs instance, and should hence not be used for larger files. (Use + /var/tmp/ for larger files.) This directory is usually flushed at boot-up. Also, + files that are not accessed within a certain time may be automatically deleted. + + If applications find the environment variable $TMPDIR set, they should use + the directory specified in it instead of /tmp/ (see environ7 and + IEEE + Std 1003.1 for details). + + Since /tmp/ is accessible to other users of the system, it is essential + that files and subdirectories under this directory are only created with mkstemp3, + mkdtemp3, + and similar calls. For more details, see Using + /tmp/ and /var/tmp/ Safely. + + + + + + + + Runtime Data + + + + /run/ + A tmpfs file system for system packages to place runtime data, + socket files, and similar. This directory is flushed on boot, and generally writable for privileged + programs only. Always writable. + + + + /run/log/ + Runtime system logs. System components may + place private logs in this directory. Always writable, even + when /var/log/ might not be accessible + yet. + + + + /run/user/ + Contains per-user runtime directories, each + usually individually mounted tmpfs + instances. Always writable, flushed at each reboot and when + the user logs out. User code should not reference this + directory directly, but via the + $XDG_RUNTIME_DIR environment variable, as + documented in the XDG + Base Directory Specification. + + + + + + Vendor-supplied Operating System Resources + + + + + /usr/ + Vendor-supplied operating system resources. + Usually read-only, but this is not required. Possibly shared + between multiple hosts. This directory should not be modified + by the administrator, except when installing or removing + vendor-supplied packages. + + + + /usr/bin/ + Binaries and executables for user commands + that shall appear in the $PATH search path. + It is recommended not to place binaries in this directory that + are not useful for invocation from a shell (such as daemon + binaries); these should be placed in a subdirectory of + /usr/lib/ instead. + + + + /usr/include/ + C and C++ API header files of system + libraries. + + + + /usr/lib/ + Static, private vendor data that is compatible + with all architectures (though not necessarily + architecture-independent). Note that this includes internal + executables or other binaries that are not regularly invoked + from a shell. Such binaries may be for any architecture + supported by the system. Do not place public libraries in this + directory, use $libdir (see below), + instead. + + + + /usr/lib/arch-id/ + Location for placing dynamic libraries into, also + called $libdir. The architecture identifier + to use is defined on Multiarch + Architecture Specifiers (Tuples) list. Legacy + locations of $libdir are + /usr/lib/, + /usr/lib64/. This directory should not be + used for package-specific data, unless this data is + architecture-dependent, too. To query + $libdir for the primary architecture of the + system, invoke: + # systemd-path system-library-arch + + + + + /usr/share/ + Resources shared between multiple packages, + such as documentation, man pages, time zone information, fonts + and other resources. Usually, the precise location and format + of files stored below this directory is subject to + specifications that ensure interoperability. + + + + /usr/share/doc/ + Documentation for the operating system or + system packages. + + + + /usr/share/factory/etc/ + Repository for vendor-supplied default + configuration files. This directory should be populated with + pristine vendor versions of all configuration files that may + be placed in /etc/. This is useful to + compare the local configuration of a system with vendor + defaults and to populate the local configuration with + defaults. + + + + /usr/share/factory/var/ + + Similar to + /usr/share/factory/etc/, but for vendor + versions of files in the variable, persistent data directory + /var/. + + + + + + + Persistent Variable System Data + + + + /var/ + Persistent, variable system data. Writable during normal system operation. This + directory might be pre-populated with vendor-supplied data, but applications should be able to + reconstruct necessary files and directories in this subhierarchy should they be missing, as the + system might start up without this directory being populated. Persistency is recommended, but + optional, to support ephemeral systems. This directory might become available or writable only very + late during boot. Components that are required to operate during early boot hence shall not + unconditionally rely on this directory. + + + + /var/cache/ + Persistent system cache data. System + components may place non-essential data in this directory. + Flushing this directory should have no effect on operation of + programs, except for increased runtimes necessary to rebuild + these caches. + + + + /var/lib/ + Persistent system data. System components may + place private data in this directory. + + + + /var/log/ + Persistent system logs. System components may + place private logs in this directory, though it is recommended + to do most logging via the + syslog3 + and + sd_journal_print3 + calls. + + + + /var/spool/ + Persistent system spool data, such as printer + or mail queues. + + + + /var/tmp/ + The place for larger and persistent temporary files. In contrast to + /tmp/, this directory is usually mounted from a persistent physical file system + and can thus accept larger files. (Use /tmp/ for small ephemeral files.) This + directory is generally not flushed at boot-up, but time-based cleanup of files that have not been + accessed for a certain time is applied. + + If applications find the environment variable $TMPDIR set, they should use + the directory specified in it instead of /var/tmp/ (see environ7 for + details). + + The same security restrictions as with /tmp/ apply: mkstemp3, + mkdtemp3, + and similar calls should be used. For further details about this directory, see Using /tmp/ and /var/tmp/ Safely. + + + + + + + + Virtual Kernel and API File Systems + + + + /dev/ + The root directory for device nodes. Usually, + this directory is mounted as a devtmpfs + instance, but might be of a different type in + sandboxed/containerized setups. This directory is managed + jointly by the kernel and + systemd-udevd8, + and should not be written to by other components. A number of + special purpose virtual file systems might be mounted below + this directory. + + + + /dev/shm/ + Place for POSIX shared memory segments, as + created via + shm_open3. + This directory is flushed on boot, and is a + tmpfs file system. Since all users have + write access to this directory, special care should be taken + to avoid name clashes and vulnerabilities. For normal users, + shared memory segments in this directory are usually deleted + when the user logs out. Usually, it is a better idea to use + memory mapped files in /run/ (for system + programs) or $XDG_RUNTIME_DIR (for user + programs) instead of POSIX shared memory segments, since these + directories are not world-writable and hence not vulnerable to + security-sensitive name clashes. + + + + /proc/ + A virtual kernel file system exposing the + process list and other functionality. This file system is + mostly an API to interface with the kernel and not a place + where normal files may be stored. For details, see + proc5. + A number of special purpose virtual file systems might be + mounted below this directory. + + + + /proc/sys/ + A hierarchy below /proc/ + that exposes a number of kernel tunables. The primary way to + configure the settings in this API file tree is via + sysctl.d5 + files. In sandboxed/containerized setups, this directory is + generally mounted read-only. + + + + /sys/ + A virtual kernel file system exposing + discovered devices and other functionality. This file system + is mostly an API to interface with the kernel and not a place + where normal files may be stored. In sandboxed/containerized + setups, this directory is generally mounted read-only. A number + of special purpose virtual file systems might be mounted below + this directory. + + + + /sys/fs/cgroup/ + A virtual kernel file system exposing process + control groups (cgroups). This file system is an API to interface + with the kernel and not a place where normal files may be stored. On + current systems running in the default "unified" mode, + this directory serves as the mount point for the + cgroup2 filesystem, which provides a unified + cgroup hierarchy for all resource controllers. On systems with + non-default configurations, this directory may instead be a tmpfs + filesystem containing mount points for various + cgroup (v1) resource controllers; in such + configurations, if cgroup2 is mounted it will be + mounted on /sys/fs/cgroup/unified/, but + cgroup2 will not have resource controllers attached. In + sandboxed/containerized setups, this directory may either not exist or + may include a subset of functionality. + + + + + + + Compatibility Symlinks + + + + /bin/ + /sbin/ + /usr/sbin/ + + These compatibility symlinks point to + /usr/bin/, ensuring that scripts and + binaries referencing these legacy paths correctly find their + binaries. + + + + /lib/ + + This compatibility symlink points to + /usr/lib/, ensuring that programs + referencing this legacy path correctly find their + resources. + + + + /lib64/ + + On some architecture ABIs, this compatibility + symlink points to $libdir, ensuring that + binaries referencing this legacy path correctly find their + dynamic loader. This symlink only exists on architectures + whose ABI places the dynamic loader in this + path. + + + + /var/run/ + + This compatibility symlink points to + /run/, ensuring that programs referencing + this legacy path correctly find their runtime + data. + + + + + + + Home Directory + + User applications may want to place files and directories in + the user's home directory. They should follow the following basic + structure. Note that some of these directories are also + standardized (though more weakly) by the XDG + Base Directory Specification. Additional locations for + high-level user resources are defined by xdg-user-dirs. + + + + ~/.cache/ + + Persistent user cache data. User programs may place non-essential data in this + directory. Flushing this directory should have no effect on operation of programs, except for + increased runtimes necessary to rebuild these caches. If an application finds + $XDG_CACHE_HOME set, it should use the directory specified in it instead of this + directory. + + + + ~/.config/ + + Application configuration and state. When a + new user is created, this directory will be empty or not exist + at all. Applications should fall back to defaults should their + configuration or state in this directory be missing. If an + application finds $XDG_CONFIG_HOME set, it + should use the directory specified in it instead of this + directory. + + + + ~/.local/bin/ + + Executables that shall appear in the user's $PATH search path. It + is recommended not to place executables in this directory that are not useful for invocation from a + shell; these should be placed in a subdirectory of ~/.local/lib/ instead. Care + should be taken when placing architecture-dependent binaries in this place, which might be + problematic if the home directory is shared between multiple hosts with different + architectures. + + + + ~/.local/lib/ + + Static, private vendor data that is compatible with all + architectures. + + + + ~/.local/lib/arch-id/ + + Location for placing public dynamic libraries. The architecture identifier to use is + defined on Multiarch Architecture Specifiers + (Tuples) list. + + + + ~/.local/share/ + + Resources shared between multiple packages, such as fonts or artwork. Usually, the + precise location and format of files stored below this directory is subject to specifications that + ensure interoperability. If an application finds $XDG_DATA_HOME set, it should use + the directory specified in it instead of this directory. + + + + + + + Write Access + + + Unprivileged Write Access + + Unprivileged processes generally lack write access to most of the hierarchy. + + The exceptions for normal users are + /tmp/, + /var/tmp/, + /dev/shm/, as well as the home directory + $HOME (usually found below + /home/) and the runtime directory + $XDG_RUNTIME_DIR (found below + /run/user/) of the user, which are all + writable. + + For unprivileged system processes, only + /tmp/, + /var/tmp/ and + /dev/shm/ are writable. If an + unprivileged system process needs a private writable directory in + /var/ or /run/, it is + recommended to either create it before dropping privileges in the + daemon code, to create it via + tmpfiles.d5 + fragments during boot, or via the + StateDirectory= and RuntimeDirectory= + directives of service units (see + systemd.unit5 + for details). + + /tmp/, /var/tmp/ and /dev/shm/ + should be mounted and , which means that set-user-id mode + and character or block special devices are not interpreted on those file systems. In general it is not + possible to mount them , because various programs use those directories for + dynamically generated or optimized code, and with that flag those use cases would break. Using this + flag is OK on special-purpose installations or systems where all software that may be installed is + known and doesn't require such functionality. See the discussion of + // in mount8 and + PROT_EXEC in mmap2. + + + + + Lack of Write Access on Read-Only Systems and during System Recovery + + As noted above, some systems operate with the /usr and + /etc hierarchies mounted read-only, possibly only allowing write access during + package upgrades. Other part of the hierarchy are generally mounted read-write (in particular + /var and /var/tmp), but may be read-only when the kernel + remounts the file system read-only in response to errors, or when the system is booted read-only for + recovery purposes. To the extent reasonable, applications should be prepared to execute without write + access, so that for example, failure to save non-essential data to /var/cache/ or + failure to create a custom log file under /var/log does not prevent the + application from running. + + The /run/ directory is available since the earliest boot and is always + writable. It should be used for any runtime data and sockets, so that write access to e.g. + /etc or /var is not needed. + + + + + Node Types + + Unix file systems support different types of file nodes, + including regular files, directories, symlinks, character and + block device nodes, sockets and FIFOs. + + It is strongly recommended that /dev/ is + the only location below which device nodes shall be placed. + Similarly, /run/ shall be the only location to + place sockets and FIFOs. Regular files, directories and symlinks + may be used in all directories. + + + + System Packages + + Developers of system packages should follow strict rules when placing their files in the file + system. The following table lists recommended locations for specific types of files supplied by the + vendor. + + + System package vendor files locations + + + + + + Directory + Purpose + + + + + /usr/bin/ + Package executables that shall appear in the $PATH executable search path, compiled for any of the supported architectures compatible with the operating system. It is not recommended to place internal binaries or binaries that are not commonly invoked from the shell in this directory, such as daemon binaries. As this directory is shared with most other packages of the system, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files. + + + /usr/lib/arch-id/ + Public shared libraries of the package. As above, be careful with using too generic names, and pick unique names for your libraries to place here to avoid name clashes. + + + /usr/lib/package/ + Private static vendor resources of the package, including private binaries and libraries, or any other kind of read-only vendor data. + + + /usr/lib/arch-id/package/ + Private other vendor resources of the package that are architecture-specific and cannot be shared between architectures. Note that this generally does not include private executables since binaries of a specific architecture may be freely invoked from any other supported system architecture. + + + /usr/include/package/ + Public C/C++ APIs of public shared libraries of the package. + + + +
+ + Additional static vendor files may be installed in the + /usr/share/ hierarchy to the locations + defined by the various relevant specifications. + + The following directories shall be used by the package for local configuration and files created + during runtime: + + + System package variable files locations + + + + + + Directory + Purpose + + + + + /etc/package/ + System-specific configuration for the package. It is recommended to default to safe fallbacks if this configuration is missing, if this is possible. Alternatively, a tmpfiles.d5 fragment may be used to copy or symlink the necessary files and directories from /usr/share/factory/ during boot, via the L or C directives. + + + /run/package/ + Runtime data for the package. Packages must be able to create the necessary subdirectories in this tree on their own, since the directory is flushed automatically on boot. Alternatively, a tmpfiles.d5 fragment may be used to create the necessary directories during boot, or the RuntimeDirectory= directive of service units may be used to create them at service startup (see systemd.unit5 for details). + + + /run/log/package/ + Runtime log data for the package. As above, the package needs to make sure to create this directory if necessary, as it will be flushed on every boot. + + + /var/cache/package/ + Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary. To create an empty directory, a tmpfiles.d5 fragment or the CacheDirectory= directive of service units (see systemd.unit5) may be used. + + + /var/lib/package/ + Persistent private data of the package. This is the primary place to put persistent data that does not fall into the other categories listed. Packages should be able to create the necessary subdirectories in this tree on their own, since the directory might be missing on boot. To create an empty directory, a tmpfiles.d5 fragment or the StateDirectory= directive of service units (see systemd.unit5) may be used. + + + /var/log/package/ + Persistent log data of the package. As above, the package should make sure to create this directory if necessary, possibly using tmpfiles.d5 or LogsDirectory= (see systemd.exec5), as it might be missing. + + + /var/spool/package/ + Persistent spool/queue data of the package. As above, the package should make sure to create this directory if necessary, as it might be missing. + + + +
+ + + + User Packages + + Programs running in user context should follow strict rules when placing their own files in the + user's home directory. The following table lists recommended locations in the home directory for specific + types of files supplied by the vendor if the application is installed in the home directory. (User + applications installed system-wide are covered by the rules outlined above for vendor files.) + + + Vendor package file locations under the home directory of the user + + + + + + Directory + Purpose + + + + + ~/.local/bin/ + Package executables that shall appear in the $PATH executable search path. It is not recommended to place internal executables or executables that are not commonly invoked from the shell in this directory, such as daemon executables. As this directory is shared with most other packages of the user, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files. + + + ~/.local/lib/arch-id/ + Public shared libraries of the package. As above, be careful with using overly generic names, and pick unique names for your libraries to place here to avoid name clashes. + + + ~/.local/lib/package/ + Private, static vendor resources of the package, compatible with any architecture, or any other kind of read-only vendor data. + + + ~/.local/lib/arch-id/package/ + Private other vendor resources of the package that are architecture-specific and cannot be shared between architectures. + + + +
+ + Additional static vendor files may be installed in the ~/.local/share/ + hierarchy, mirroring the subdirectories specified in the section "Vendor-supplied operating system + resources" above. + + The following directories shall be used by the package for per-user local configuration and files + created during runtime: + + + User package variable file locations + + + + + + Directory + Purpose + + + + + ~/.config/package/ + User-specific configuration and state for the package. It is required to default to safe fallbacks if this configuration is missing. + + + $XDG_RUNTIME_DIR/package/ + User runtime data for the package. + + + ~/.cache/package/ + Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary. + + + +
+ + + + See Also + + systemd1, + hier7, + systemd-path1, + systemd-gpt-auto-generator8, + sysctl.d5, + tmpfiles.d5, + pkg-config1, + systemd.unit5 + + + + diff --git a/man/glib-event-glue.c b/man/glib-event-glue.c new file mode 100644 index 0000000..61e8bf6 --- /dev/null +++ b/man/glib-event-glue.c @@ -0,0 +1,48 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +typedef struct SDEventSource { + GSource source; + GPollFD pollfd; + sd_event *event; +} SDEventSource; + +static gboolean event_prepare(GSource *source, gint *timeout_) { + return sd_event_prepare(((SDEventSource *)source)->event) > 0; +} + +static gboolean event_check(GSource *source) { + return sd_event_wait(((SDEventSource *)source)->event, 0) > 0; +} + +static gboolean event_dispatch(GSource *source, GSourceFunc callback, gpointer user_data) { + return sd_event_dispatch(((SDEventSource *)source)->event) > 0; +} + +static void event_finalize(GSource *source) { + sd_event_unref(((SDEventSource *)source)->event); +} + +static GSourceFuncs event_funcs = { + .prepare = event_prepare, + .check = event_check, + .dispatch = event_dispatch, + .finalize = event_finalize, +}; + +GSource *g_sd_event_create_source(sd_event *event) { + SDEventSource *source; + + source = (SDEventSource *)g_source_new(&event_funcs, sizeof(SDEventSource)); + + source->event = sd_event_ref(event); + source->pollfd.fd = sd_event_get_fd(event); + source->pollfd.events = G_IO_IN | G_IO_HUP | G_IO_ERR; + + g_source_add_poll((GSource *)source, &source->pollfd); + + return (GSource *)source; +} diff --git a/man/halt.xml b/man/halt.xml new file mode 100644 index 0000000..c13ee5c --- /dev/null +++ b/man/halt.xml @@ -0,0 +1,160 @@ + + + + + + + + halt + systemd + + + + halt + 8 + + + + halt + poweroff + reboot + Halt, power-off or reboot the machine + + + + + halt + OPTIONS + + + poweroff + OPTIONS + + + reboot + OPTIONS + + + + + Description + + halt, poweroff, reboot may be used to + halt, power-off, or reboot the machine. All three commands take the same options. + + + + + Options + + The following options are understood: + + + + + + + + + + + + Halt the machine, regardless of which one of + the three commands is invoked. + + + + + + + Power-off the machine, when either halt + or poweroff is invoked. This option is ignored when + reboot is invoked. + + + + + + Reboot the machine, regardless of which one of + the three commands is invoked. + + + + + + + + Force immediate halt, power-off, reboot. If specified, the command does not contact the init + system. In most cases, filesystems are not properly unmounted before shutdown. For example, the + command reboot -f is mostly equivalent to systemctl reboot -ff, + instead of systemctl reboot -f. + + + + + + + + Only write wtmp shutdown entry, do not + actually halt, power-off, reboot. + + + + + + + Do not write wtmp shutdown + entry. + + + + + + + Don't sync hard disks/storage media before + halt, power-off, reboot. + + + + + + Do not send wall message before halt, + power-off, reboot. + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Notes + + These commands are implemented in a way that preserves basic compatibility with the original SysV + commands. systemctl1 + verbs halt, poweroff, reboot provide the same + functionality with some additional features. + + Note that on many SysV systems halt used to be synonymous to + poweroff, i.e. both commands would equally result in powering the machine off. systemd + is more accurate here, and halt results in halting the machine only (leaving power + on), and poweroff is required to actually power it off. + + + + See Also + + systemd1, + systemctl1, + shutdown8, + wall1 + + + + diff --git a/man/homectl.xml b/man/homectl.xml new file mode 100644 index 0000000..594e61e --- /dev/null +++ b/man/homectl.xml @@ -0,0 +1,1063 @@ + + + + + + + + homectl + systemd + + + + homectl + 1 + + + + homectl + Create, remove, change or inspect home directories + + + + + homectl + OPTIONS + COMMAND + NAME + + + + + Description + + homectl may be used to create, remove, change or inspect a user's home + directory. It's primarily a command interfacing with + systemd-homed.service8 + which manages home directories of users. + + Home directories managed by systemd-homed.service are self-contained, and thus + include the user's full metadata record in the home's data storage itself, making them easy to migrate + between machines. In particular, a home directory describes a matching user record, and every user record + managed by systemd-homed.service also implies existence and encapsulation of a home + directory. The user account and home directory become the same concept. + + The following backing storage mechanisms are supported: + + + An individual LUKS2 encrypted loopback file for a user, stored in + /home/*.home. At login the file system contained in this files is mounted, after + the LUKS2 encrypted volume has been attached. The user's password is identical to the encryption + passphrase of the LUKS2 volume. Access to data without preceding user authentication is thus not + possible, even for the system administrator. This storage mechanism provides the strongest data + security and is thus recommended. + + Similar, but the LUKS2 encrypted file system is located on regular block device, such + as an USB storage stick. In this mode home directories and all data they include are nicely migratable + between machines, simply by plugging the USB stick into different systems at different + times. + + An encrypted directory using fscrypt on file systems that support it + (at the moment this is primarily ext4), located in + /home/*.homedir. This mechanism also provides encryption, but substantially + weaker than LUKS2, as most file system metadata is unprotected. Moreover + it currently does not support changing user passwords once the home directory has been + created. + + A btrfs subvolume for each user, also located in + /home/*.homedir. This provides no encryption, but good quota + support. + + A regular directory for each user, also located in + /home/*.homedir. This provides no encryption, but is a suitable fallback + available on all machines, even where LUKS2, fscrypt or btrfs + support is not available. + + An individual Windows file share (CIFS) for each user. + + + Note that systemd-homed.service and homectl will not manage + "classic" UNIX user accounts as created with useradd8 or + similar tools. In particular, this functionality is not suitable for managing system users (i.e. users + with a UID below 1000) but is exclusive to regular ("human") users. + + Note that users/home directories managed via systemd-homed.service do not show + up in /etc/passwd and similar files, they are synthesized via glibc NSS during + runtime. They are thus resolvable and may be enumerated via the getent1 + tool. + + This tool interfaces directly with systemd-homed.service, and may execute + specific commands on the home directories it manages. Since every home directory managed that way also + defines a JSON user and group record these home directories may also be inspected and enumerated via + userdbctl1. + + Home directories managed by systemd-homed.service are usually in one of two + states, or in a transition state between them: when active they are unlocked and + mounted, and thus accessible to the system and its programs; when inactive they are + not mounted and thus not accessible. Activation happens automatically at login of the user and usually + can only complete after a password (or other authentication token) has been supplied. Deactivation + happens after the user fully logged out. A home directory remains active as long as the user is logged in + at least once, i.e. has at least one login session. When the user logs in a second time simultaneously + the home directory remains active. It is deactivated only after the last of the user's sessions + ends. + + + + Options + + The following general options are understood (further options that control the various properties + of user records managed by systemd-homed.service are documented further + down): + + + + + FILE + + Read the user's JSON record from the specified file. If passed as + - read the user record from standard input. The supplied JSON object must follow + the structure documented in JSON User Records. + This option may be used in conjunction with the create and + update commands (see below), where it allows configuring the user record in JSON + as-is, instead of setting the individual user record properties (see below). + + + + FORMAT + + + Controls whether to output the user record in JSON format, if the + inspect command (see below) is used. Takes one of pretty, + short or off. If pretty human-friendly + whitespace and newlines are inserted in the output to make the JSON data more readable. If + short all superfluous whitespace is suppressed. If off (the + default) the user information is not shown in JSON format but in a friendly human readable formatting + instead. The option picks pretty when run interactively and + short otherwise. + + + + FORMAT + + + + When used with the inspect verb in JSON mode (see above) may be + used to suppress certain aspects of the JSON user record on output. Specifically, if + stripped format is used the binding and runtime fields of the record are + removed. If minimal format is used the cryptographic signature is removed too. If + full format is used the full JSON record is shown (this is the default). This + option is useful for copying an existing user record to a different system in order to create a + similar user there with the same settings. Specifically: homectl inspect -EE | ssh + root@othersystem homectl create -i- may be used as simple command line for replicating a + user on another host. is equivalent to , + to . Note that when replicating user + accounts user records acquired in stripped mode will retain the original + cryptographic signatures and thus may only be modified when the private key to update them is available + on the destination machine. When replicating users in minimal mode, the signature + is removed during the replication and thus the record will be implicitly signed with the key of the destination + machine and may be updated there without any private key replication. + + + + + + + + + + + + + + + User Record Properties + + The following options control various properties of the user records/home directories that + systemd-homed.service manages. These switches may be used in conjunction with the + create and update commands for configuring various aspects of the + home directory and the user account: + + + + + NAME + NAME + + The real name for the user. This corresponds with the GECOS field on classic UNIX NSS + records. + + + + REALM + + The realm for the user. The realm associates a user with a specific organization or + installation, and allows distinguishing users of the same name defined in different contexts. The + realm can be any string that also qualifies as valid DNS domain name, and it is recommended to use + the organization's or installation's domain name for this purpose, but this is not enforced nor + required. On each system only a single user of the same name may exist, and if a user with the same + name and realm is seen it is assumed to refer to the same user while a user with the same name but + different realm is considered a different user. Note that this means that two users sharing the same + name but with distinct realms are not allowed on the same system. Assigning a realm to a user is + optional. + + + + EMAIL + + Takes an electronic mail address to associate with the user. On log-in the + $EMAIL environment variable is initialized from this value. + + + + TEXT + + Takes location specification for this user. This is free-form text, which might or + might not be usable by geo-location applications. Example: or + + + + ICON + + Takes an icon name to associate with the user, following the scheme defined by the Icon Naming + Specification. + + + + PATH + PATH + + Takes a path to use as home directory for the user. Note that this is the directory + the user's home directory is mounted to while the user is logged in. This is not where the user's + data is actually stored, see for that. If not specified defaults to + /home/$USER. + + + + UID + + Takes a preferred numeric UNIX UID to assign this user. If a user is to be created + with the specified UID and it is already taken by a different user on the local system then creation + of the home directory is refused. Note though, if after creating the home directory it is used on a + different system and the configured UID is taken by another user there, then + systemd-homed may assign the user a different UID on that system. The specified + UID must be outside of the system user range. It is recommended to use the 60001…60513 UID range for + this purpose. If not specified, the UID is automatically picked. If the home directory is found to be + owned by a different UID when logging in, the home directory and everything underneath it will have + its ownership changed automatically before login completes. + + Note that changing this option for existing home directories generally has no effect on home + directories that already have been registered locally (have a local binding), as + the UID used for an account on the local system is determined when the home directory is first + activated on it, and then remains in effect until the home directory is removed. + + Note that users managed by systemd-homed always have a matching group + associated with the same name as well as a GID matching the UID of the user. Thus, configuring the + GID separately is not permitted. + + + + GROUP + GROUP + + Takes a comma-separated list of auxiliary UNIX groups this user shall belong + to. Example: to provide the user with administrator + privileges. Note that systemd-homed does not manage any groups besides a group + matching the user in name and numeric UID/GID. Thus any groups listed here must be registered + independently, for example with groupadd8. + Any non-existent groups are ignored. This option may be used more than once, in which case all + specified group lists are combined. If the user is currently a member of a group which is not listed, + the user will be removed from the group. + + + + PATH + + Takes a file system path to a directory. Specifies the skeleton directory to + initialize the home directory with. All files and directories in the specified path are copied into + any newly create home directory. If not specified defaults to /etc/skel/. + + + + + SHELL + + Takes a file system path. Specifies the shell binary to execute on terminal + logins. If not specified defaults to /bin/bash. + + + + VARIABLE[=VALUE] + + Takes an environment variable assignment to set for all user processes. May be used + multiple times to set multiple environment variables. When = and + VALUE are omitted, the value of the variable with the same name in the + program environment will be used. + + Note that a number of other settings also result in environment variables to be set for the + user, including , and + . + + + + TIMEZONE + + Takes a time zone location name that sets the timezone for the specified user. When + the user logs in the $TZ environment variable is initialized from this + setting. Example: will result in the environment + variable TZ=:Europe/Amsterdam. (: is used intentionally as part + of the timezone specification, see + tzset3.) + + + + + LANG + + Takes a specifier indicating the preferred language of the user. The + $LANG environment variable is initialized from this value on login, and thus a + value suitable for this environment variable is accepted here, for example + . + + + + KEYS + Either takes a SSH authorized key line to associate with the user record or a + @ character followed by a path to a file to read one or more such lines from. SSH + keys configured this way are made available to SSH to permit access to this home directory and user + record. This option may be used more than once to configure multiple SSH keys. + + + + URI + Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV + smartcard) that shall be able to unlock the user account. The security token URI should reference a + security token with exactly one pair of X.509 certificate and private key. A random secret key is + then generated, encrypted with the public key of the X.509 certificate, and stored as part of the + user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the + account and associated resources. See below for an example how to set up authentication with a + security token. + + Instead of a valid PKCS#11 URI, the special strings list and + auto may be specified. If list is passed, a brief table of + suitable, currently plugged in PKCS#11 hardware tokens is shown, along with their URIs. If + auto is passed, a suitable PKCS#11 hardware token is automatically selected (this + operation will fail if there isn't exactly one suitable token discovered). The latter is a useful + shortcut for the most common case where a single PKCS#11 hardware token is plugged in. + + Note that many hardware security tokens implement both PKCS#11/PIV and FIDO2 with the + hmac-secret extension (for example: the YubiKey 5 series), as supported with the + option below. Both mechanisms are similarly powerful, though FIDO2 + is the more modern technology. PKCS#11/PIV tokens have the benefit of being recognizable before + authentication and hence can be used for implying the user identity to use for logging in, which + FIDO2 does not allow. PKCS#11/PIV devices generally require initialization (i.e. storing a + private/public key pair on them, see example below) before they can be used; FIDO2 security tokens + generally do not required that, and work out of the box. + + + + STRING + Specify COSE algorithm used in credential generation. The default value is + es256. Supported values are es256, rs256 + and eddsa. + + es256 denotes ECDSA over NIST P-256 with SHA-256. rs256 + denotes 2048-bit RSA with PKCS#1.5 padding and SHA-256. eddsa denotes + EDDSA over Curve25519 with SHA-512. + + Note that your authenticator may not support some algorithms. + + + + PATH + + Takes a path to a Linux hidraw device + (e.g. /dev/hidraw1), referring to a FIDO2 security token implementing the + hmac-secret extension that shall be able to unlock the user account. A random salt + value is generated on the host and passed to the FIDO2 device, which calculates a HMAC hash of the + salt using an internal secret key. The result is then used as the key to unlock the user account. The + random salt is included in the user record, so that whenever authentication is needed it can be + passed to the FIDO2 token again. + + Instead of a valid path to a FIDO2 hidraw device the special strings + list and auto may be specified. If list is + passed, a brief table of suitable discovered FIDO2 devices is shown. If auto is + passed, a suitable FIDO2 token is automatically selected, if exactly one is discovered. The latter is + a useful shortcut for the most common case where a single FIDO2 hardware token is plugged in. + + Note that FIDO2 devices suitable for this option must implement the + hmac-secret extension. Most current devices (such as the YubiKey 5 series) do. If + the extension is not implemented the device cannot be used for unlocking home directories. + + The FIDO2 device may be subsequently removed by setting the device path to an empty string + (e.g. homectl update $USER --fido2-device=""). + + Note that many hardware security tokens implement both FIDO2 and PKCS#11/PIV (and thus may be + used with either or ), for a + discussion see above. + + + + BOOL + + When enrolling a FIDO2 security token, controls whether to require the user to enter + a PIN when unlocking the account (the FIDO2 clientPin feature). Defaults to + yes. (Note: this setting is without effect if the security token does not support + the clientPin feature at all, or does not allow enabling or disabling + it.) + + + + BOOL + + When enrolling a FIDO2 security token, controls whether to require the user to + verify presence (tap the token, the FIDO2 up feature) when unlocking the account. + Defaults to yes. (Note: this setting is without effect if the security token does not support + the up feature at all, or does not allow enabling or disabling it.) + + + + + BOOL + + When enrolling a FIDO2 security token, controls whether to require user verification + when unlocking the account (the FIDO2 uv feature). Defaults to + no. (Note: this setting is without effect if the security token does not support + the uv feature at all, or does not allow enabling or disabling it.) + + + + BOOL + + Accepts a boolean argument. If enabled a recovery key is configured for the + account. A recovery key is a computer generated access key that may be used to regain access to an + account if the password has been forgotten or the authentication token lost. The key is generated and + shown on screen, and should be printed or otherwise transferred to a secure location. A recovery key + may be entered instead of a regular password to unlock the account. + + + + BOOLEAN + + Takes a boolean argument. Specifies whether this user account shall be locked. If + true logins into this account are prohibited, if false (the default) they are permitted (of course, + only if authorization otherwise succeeds). + + + + TIMESTAMP + TIMESTAMP + + These options take a timestamp string, in the format documented in + systemd.time7 and + configures points in time before and after logins into this account are not + permitted. + + + + SECS + NUMBER + + Configures a rate limit on authentication attempts for this user. If the user + attempts to authenticate more often than the specified number, on a specific system, within the + specified time interval authentication is refused until the time interval passes. Defaults to 10 + times per 1min. + + + + TEXT + + Takes a password hint to store alongside the user record. This string is stored + accessible only to privileged users and the user itself and may not be queried by other users. + Example: . + + + + BOOL + + + Takes a boolean argument. Configures whether to enforce the system's password policy + for this user, regarding quality and strength of selected passwords. Defaults to + on. is short for + . + + + + BOOL + + Takes a boolean argument. If true the user is asked to change their password on next + login. + + + + TIME + TIME + TIME + TIME + + Each of these options takes a time span specification as argument (in the syntax + documented in + systemd.time7) and + configures various aspects of the user's password expiration policy. Specifically, + configures how much time has to pass after changing the + password of the user until the password may be changed again. If the user tries to change their + password before this time passes the attempt is refused. + configures how soon after it has been changed the password expires and needs to be changed again. + After this time passes logging in may only proceed after the password is changed. + specifies how much earlier than then the time configured + with the user is warned at login to change their password as + it will expire soon. Finally configures the time which + has to pass after the password as expired until the user is not permitted to log in or change the + password anymore. Note that these options only apply to password authentication, and do not apply to + other forms of authentication, for example PKCS#11-based security token + authentication. + + + + BYTES + Either takes a size in bytes as argument (possibly using the usual K, M, G, … + suffixes for 1024 base values), a percentage value, or the special strings min or + max, and configures the disk space to assign to the user. If a percentage value is + specified (i.e. the argument suffixed with %) it is taken relative to the + available disk space of the backing file system. If specified as min assigns the + minimal disk space permitted by the constraints of the backing file system and other limits, when + specified as max assigns the maximum disk space available. If the LUKS2 backend is + used this configures the size of the loopback file and file system contained therein. For the other + storage backends configures disk quota using the filesystem's native quota logic, if available. If + not specified, defaults to 85% of the available disk space for the LUKS2 backend and to no quota for + the others. + + + + MODE + + Takes a UNIX file access mode written in octal. Configures the access mode of the + home directory itself. Note that this is only used when the directory is first created, and the user + may change this any time afterwards. Example: + + + + + MASK + + Takes the access mode mask (in octal syntax) to apply to newly created files and + directories of the user ("umask"). If set this controls the initial umask set for all login sessions of + the user, possibly overriding the system's defaults. + + + + NICE + + Takes the numeric scheduling priority ("nice level") to apply to the processes of the user at login + time. Takes a numeric value in the range -20 (highest priority) to 19 (lowest priority). + + + + LIMIT=VALUE:VALUE + + Allows configuration of resource limits for processes of this user, see getrlimit2 + for details. Takes a resource limit name (e.g. LIMIT_NOFILE) followed by an equal + sign, followed by a numeric limit. Optionally, separated by colon a second numeric limit may be + specified. If two are specified this refers to the soft and hard limits, respectively. If only one + limit is specified the setting sets both limits in one. + + + + TASKS + + Takes a non-zero unsigned integer as argument. Configures the maximum number of tasks + (i.e. threads, where each process is at least one thread) the user may have at any given time. This + limit applies to all tasks forked off the user's sessions, even if they change user identity via + su1 + or a similar tool. Use to place a limit on the tasks actually + running under the UID of the user, thus excluding any child processes that might have changed user + identity. This controls the TasksMax= setting of the per-user systemd slice unit + user-$UID.slice. See + systemd.resource-control5 + for further details. + + + + BYTES + BYTES + + Set a limit on the memory a user may take up on a system at any given time in bytes + (the usual K, M, G, … suffixes are supported, to the base of 1024). This includes all memory used by + the user itself and all processes they forked off that changed user credentials. This controls the + MemoryHigh= and MemoryMax= settings of the per-user systemd + slice unit user-$UID.slice. See + systemd.resource-control5 + for further details. + + + + WEIGHT + WEIGHT + + Set CPU and IO scheduling weights of the processes of the user, including those of + processes forked off by the user that changed user credentials. Takes a numeric value in the range + 1…10000. This controls the CPUWeight= and IOWeight= settings of + the per-user systemd slice unit user-$UID.slice. See + systemd.resource-control5 + for further details. + + + + STORAGE + + Selects the storage mechanism to use for this home directory. Takes one of + luks, fscrypt, directory, + subvolume, cifs. For details about these mechanisms, see + above. If a new home directory is created and the storage type is not specifically specified, + homed.conf5 + defines which default storage to use. + + + + PATH + + Takes a file system path. Configures where to place the user's home directory. When + LUKS2 storage is used refers to the path to the loopback file, otherwise to the path to the home + directory (which may be in /home/ or any other accessible filesystem). When + unspecified defaults to /home/$USER.home when LUKS storage is used and + /home/$USER.homedir for the other storage mechanisms. Not defined for the + cifs storage mechanism. To use LUKS2 storage on a regular block device (for + example a USB stick) pass the path to the block device here. Specifying the path to a directory here + when using LUKS2 storage is not allowed. Similar, specifying the path to a regular file or device + node is not allowed if any of the other storage backends are used. + + + + BOOL + + Automatically flush OS file system caches on logout. This is useful in combination + with the fscrypt storage backend to ensure the OS does not keep decrypted versions of the files and + directories in memory (and accessible) after logout. This option is also supported on other backends, + but should not bring any benefit there. Defaults to off, except if the selected storage backend is + fscrypt, where it defaults to on. Note that flushing OS caches will negatively influence performance + of the OS shortly after logout. + + + + TYPE + + When LUKS2 storage is used configures the file system type to use inside the home + directory LUKS2 container. One of btrfs, ext4, + xfs. If not specified + homed.conf5 + defines which default file system type to use. Note that xfs is not recommended as + its support for file system resizing is too limited. + + + + BOOL + + When LUKS2 storage is used configures whether to enable the + discard feature of the file system. If enabled the file system on top of the LUKS2 + volume will report empty block information to LUKS2 and the loopback file below, ensuring that empty + space in the home directory is returned to the backing file system below the LUKS2 volume, resulting + in a "sparse" loopback file. This option mostly defaults to off, since this permits over-committing + home directories which results in I/O errors if the underlying file system runs full while the upper + file system wants to allocate a block. Such I/O errors are generally not handled well by file systems + nor applications. When LUKS2 storage is used on top of regular block devices (instead of on top a + loopback file) the discard logic defaults to on. + + + + BOOL + + Similar to , controls the trimming of the file + system. However, while controls what happens when the home directory + is active, controls what happens when it becomes inactive, + i.e. whether to trim/allocate the storage when deactivating the home directory. This option defaults + to on, to ensure disk space is minimized while a user is not logged in. + + + + OPTIONS + + Takes a string containing additional mount options to use when mounting the LUKS + volume. If specified, this string will be appended to the default, built-in mount + options. + + + + CIPHER + MODE + BYTES + TYPE + ALGORITHM + SECONDS + BYTES + THREADS + BYTES + + Configures various cryptographic parameters for the LUKS2 storage mechanism. See + cryptsetup8 + for details on the specific attributes. + + Note that homectl uses bytes for key size, like + /proc/crypto, but cryptsetup8 + uses bits. + + + + + + Configures whether to automatically grow and/or shrink the backing file system on + login and logout. Takes one of the strings off, grow, + shrink-and-grow. Only applies to the LUKS2 backend currently, and if the btrfs + file system is used inside it (since only then online growing/shrinking of the file system is + supported). Defaults to shrink-and-grow, if LUKS2/btrfs is used, otherwise is + off. If set to off no automatic shrinking/growing during login or logout is + done. If set to grow the home area is grown to the size configured via + should it currently be smaller. If it already matches the configured + size or is larger no operation is executed. If set to shrink-and-grow the home + area is also resized during logout to the minimal size the used disk space and file system + constraints permit. This mode thus ensures that while a home area is activated it is sized to the + configured size, but while deactivated it is compacted taking up only the minimal space possible. + Note that if the system is powered off abnormally or if the user otherwise not logged out cleanly the + shrinking operation will not take place, and the user has to re-login/logout again before it is + executed again. + + + + + + Configures the weight parameter for the free disk space rebalancing logic. Only + applies to the LUKS2 backend (since for the LUKS2 backend disk space is allocated from a per-user + loopback file system instead of immediately from a common pool like the other backends do it). In + regular intervals free disk space in the active home areas and their backing storage is redistributed + among them, taking the weight value configured here into account. Expects an integer in the range + 1…10000, or the special string off. If not specified defaults to 100. The weight + is used to scale free space made available to the home areas: a home area with a weight of 200 will + get twice the free space as one with a weight of 100; a home area with a weight of 50 will get half + of that. The backing file system will be assigned space for a weight of 20. If set to + off no automatic free space distribution is done for this home area. Note that + resizing the home area explicitly (with homectl resize see below) will implicitly + turn off the automatic rebalancing. To reenable the automatic rebalancing use + with an empty parameter. + + + + BOOL + BOOL + BOOL + + Configures the nosuid, nodev and + noexec mount options for the home directories. By default nodev + and nosuid are on, while noexec is off. For details about these + mount options see mount8. + + + + DOMAIN + USER + SERVICE + OPTIONS + + Configures the Windows File Sharing (CIFS) domain and user to associate with the home + directory/user account, as well as the file share ("service") to mount as directory. The latter is + used when cifs storage is selected. The file share should be specified in format + //host/share/directory/…. The + directory part is optional — if not specified the home directory will be placed in the top-level + directory of the share. The setting allows specifying + additional mount options when mounting the share, see mount.cifs8 + for details. + + + + SECS + + Configures the time the per-user service manager shall continue to run after the all + sessions of the user ended. The default is configured in + logind.conf5 (for + home directories of LUKS2 storage located on removable media this defaults to 0 though). A longer + time makes sure quick, repetitive logins are more efficient as the user's service manager doesn't + have to be started every time. + + + + BOOL + + Configures whether to kill all processes of the user on logout. The default is + configured in + logind.conf5. + + + + BOOL + + Takes a boolean argument. Configures whether the graphical UI of the system should + automatically log this user in if possible. Defaults to off. If less or more than one user is marked + this way automatic login is disabled. + + + + + + Commands + + The following commands are understood: + + + + + list + + List all home directories (along with brief details) currently managed by + systemd-homed.service. This command is also executed if none is specified on the + command line. (Note that the list of users shown by this command does not include users managed by + other subsystems, such as system users or any traditional users listed in + /etc/passwd.) + + + + activate USER [USER…] + + Activate one or more home directories. The home directories of each listed user will + be activated and made available under their mount points (typically in + /home/$USER). Note that any home activated this way stays active indefinitely, + until it is explicitly deactivated again (with deactivate, see below), or the user + logs in and out again and it thus is deactivated due to the automatic deactivation-on-logout + logic. + + Activation of a home directory involves various operations that depend on the selected storage + mechanism. If the LUKS2 mechanism is used, this generally involves: inquiring the user for a + password, setting up a loopback device, validating and activating the LUKS2 volume, checking the file + system, mounting the file system, and potentially changing the ownership of all included files to the + correct UID/GID. + + + + deactivate USER [USER…] + + Deactivate one or more home directories. This undoes the effect of + activate. + + + + inspect USER [USER…] + + Show various details about the specified home directories. This shows various + information about the home directory and its user account, including runtime data such as current + state, disk use and similar. Combine with to show the detailed JSON user + record instead, possibly combined with to suppress certain aspects + of the output. + + + + authenticate USER [USER…] + + Validate authentication credentials of a home directory. This queries the caller for + a password (or similar) and checks that it correctly unlocks the home directory. This leaves the home + directory in the state it is in, i.e. it leaves the home directory in inactive state if it was + inactive before, and in active state if it was active before. + + + + create USER + create PATH USER + + Create a new home directory/user account of the specified name. Use the various + user record property options (as documented above) to control various aspects of the home directory + and its user accounts. + + The specified user name should follow the strict syntax described on User/Group Name Syntax. + + + + remove USER + + Remove a home directory/user account. This will remove both the home directory's user + record and the home directory itself, and thus delete all files and directories owned by the + user. + + + + update USER + update PATH USER + + Update a home directory/user account. Use the various user record property options + (as documented above) to make changes to the account, or alternatively provide a full, updated JSON + user record via the option. + + Note that changes to user records not signed by a cryptographic private key available locally + are not permitted, unless is used with a user record that is already + correctly signed by a recognized private key. + + + + passwd USER + + Change the password of the specified home directory/user account. + + + + resize USER BYTES + + Change the disk space assigned to the specified home directory. If the LUKS2 storage + mechanism is used this will automatically resize the loopback file and the file system contained + within. Note that if ext4 is used inside of the LUKS2 volume, it is necessary to + deactivate the home directory before shrinking it (i.e the user has to log out). Growing can be done + while the home directory is active. If xfs is used inside of the LUKS2 volume the + home directory may not be shrunk whatsoever. On all three of ext4, + xfs and btrfs the home directory may be grown while the user is + logged in, and on the latter also shrunk while the user is logged in. If the + subvolume, directory, fscrypt storage + mechanisms are used, resizing will change file system quota. The size parameter may make use of the + usual suffixes B, K, M, G, T (to the base of 1024). The special strings min and + max may be specified in place of a numeric size value, for minimizing or + maximizing disk space assigned to the home area, taking constraints of the file system, disk usage inside + the home area and on the backing storage into account. + + + + lock USER + + Temporarily suspend access to the user's home directory and remove any associated + cryptographic keys from memory. Any attempts to access the user's home directory will stall until the + home directory is unlocked again (i.e. re-authenticated). This functionality is primarily intended to + be used during system suspend to make sure the user's data cannot be accessed until the user + re-authenticates on resume. This operation is only defined for home directories that use the LUKS2 + storage mechanism. + + + + unlock USER + + Resume access to the user's home directory again, undoing the effect of + lock above. This requires authentication of the user, as the cryptographic keys + required for access to the home directory need to be reacquired. + + + + lock-all + + Execute the lock command on all suitable home directories at + once. This operation is generally executed on system suspend (i.e. by systemctl + suspend and related commands), to ensure all active user's cryptographic keys for accessing + their home directories are removed from memory. + + + + deactivate-all + + Execute the deactivate command on all active home directories at + once. This operation is generally executed on system shut down (i.e. by systemctl + poweroff and related commands), to ensure all active user's home directories are fully + deactivated before /home/ and related file systems are unmounted. + + + + with USER COMMAND… + + Activate the specified user's home directory, run the specified command (under the + caller's identity, not the specified user's) and deactivate the home directory afterwards again + (unless the user is logged in otherwise). This command is useful for running privileged backup + scripts and such, but requires authentication with the user's credentials in order to be able to + unlock the user's home directory. + + + + rebalance + + Rebalance free disk space between active home areas and the backing storage. See + above. This executes no operation unless there's at least one + active LUKS2 home area that has disk space rebalancing enabled. This operation is synchronous: it + will only complete once disk space is rebalanced according to the rebalancing weights. Note that + rebalancing also takes place automatically in the background in regular intervals. Use this command + to synchronously ensure disk space is properly redistributed before initiating an operation requiring + large amounts of disk space. + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + When a command is invoked with with, the exit status of the child is + propagated. Effectively, homectl will exit without error if the command is + successfully invoked and finishes successfully. + + + + + + Examples + + + Create a user <literal>waldo</literal> in the administrator group <literal>wheel</literal>, and + assign 500 MiB disk space to them. + + homectl create waldo --real-name="Waldo McWaldo" -G wheel --disk-size=500M + + + + Create a user <literal>wally</literal> on a USB stick, and assign a maximum of 500 concurrent + tasks to them. + + homectl create wally --real-name="Wally McWally" --image-path=/dev/disk/by-id/usb-SanDisk_Ultra_Fit_476fff954b2b5c44-0:0 --tasks-max=500 + + + + Change nice level of user <literal>odlaw</literal> to +5 and make sure the environment variable + <varname>$SOME</varname> is set to the string <literal>THING</literal> for them on login. + + homectl update odlaw --nice=5 --setenv=SOME=THING + + + + Set up authentication with a YubiKey security token using PKCS#11/PIV: + + # Clear the Yubikey from any old keys (careful!) +ykman piv reset + +# Generate a new private/public key pair on the device, store the public key in 'pubkey.pem'. +ykman piv generate-key -a RSA2048 9d pubkey.pem + +# Create a self-signed certificate from this public key, and store it on the device. +ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem + +# We don't need the public key on disk anymore +rm pubkey.pem + +# Allow the security token to unlock the account of user 'lafcadio'. +homectl update lafcadio --pkcs11-token-uri=auto + + + + Set up authentication with a FIDO2 security token: + + # Allow a FIDO2 security token to unlock the account of user 'nihilbaxter'. +homectl update nihilbaxter --fido2-device=auto + + + + + See Also + + systemd1, + systemd-homed.service8, + homed.conf5, + userdbctl1, + useradd8, + cryptsetup8 + + + + diff --git a/man/homed.conf.xml b/man/homed.conf.xml new file mode 100644 index 0000000..7e99aa6 --- /dev/null +++ b/man/homed.conf.xml @@ -0,0 +1,84 @@ + + + + + + + homed.conf + systemd + + + + homed.conf + 5 + + + + homed.conf + homed.conf.d + Home area/user account manager configuration files + + + + /etc/systemd/homed.conf + /etc/systemd/homed.conf.d/*.conf + /run/systemd/homed.conf.d/*.conf + /usr/lib/systemd/homed.conf.d/*.conf + + + + Description + + These configuration files control default parameters for home areas/user accounts created and + managed by + systemd-homed.service8. + + + + + + + Options + + The following options are available in the [Home] section: + + + + + DefaultStorage= + The default storage to use for home areas. Takes one of luks, + fscrypt, directory, subvolume, + cifs. For details about these options, see + homectl1. If not + configured or assigned the empty string, the default storage is automatically determined: if not + running in a container environment and /home/ is not itself encrypted, defaults + to luks. Otherwise defaults to subvolume if + /home/ is on a btrfs file system, and directory + otherwise. Note that the storage selected on the homectl command line always takes + precedence. + + + + DefaultFileSystemType= + When using luks as storage (see above), selects the default file + system to use inside the user's LUKS volume. Takes one of btrfs, + ext4 or xfs. If not specified defaults to + btrfs. This setting has no effect if a different storage mechanism is used. The + file system type selected on the homectl command line always takes + precedence. + + + + + + + See Also + + systemd1, + systemd-homed.service8 + + + + diff --git a/man/hostname.xml b/man/hostname.xml new file mode 100644 index 0000000..d050703 --- /dev/null +++ b/man/hostname.xml @@ -0,0 +1,116 @@ + + +%entities; +]> + + + + + hostname + systemd + + + + hostname + 5 + + + + hostname + Local hostname configuration file + + + + /etc/hostname + + + + Description + + The /etc/hostname file configures the name of the local system. Unless + overridden as described in the next section, + systemd1 will set this + hostname during boot using the + sethostname2 system + call. + + The file should contain a single newline-terminated hostname string. Comments (lines starting with + a #) are ignored. The hostname should be composed of up to 64 7-bit ASCII lower-case + alphanumeric characters or hyphens forming a valid DNS domain name. It is recommended that this name + contains only a single label, i.e. without any dots. Invalid characters will be filtered out in an + attempt to make the name valid, but obviously it is recommended to use a valid name and not rely on this + filtering. + + You may use + hostnamectl1 to change + the value of this file during runtime from the command line. Use + systemd-firstboot1 to + initialize it on mounted (but not booted) system images. + + + + Hostname semantics + + systemd1 and the + associated tools will obtain the hostname in the following ways: + + If the kernel commandline parameter systemd.hostname= specifies a + valid hostname, + systemd1 will use it + to set the hostname during early boot, see + kernel-command-line7, + + + Otherwise, the "static" hostname specified by /etc/hostname as + described above will be used. + + Otherwise, a transient hostname may be set during runtime, for example based on + information in a DHCP lease, see + systemd-hostnamed.service8. + Both NetworkManager and + systemd-networkd.service8 + allow this. Note that + systemd-hostnamed.service8 + gives higher priority to the static hostname, so the transient hostname will only be used if the static + hostname is not configured. + + Otherwise, a fallback hostname configured at compilation time will be used + (&FALLBACK_HOSTNAME;). + + + + + Effectively, the static hostname has higher priority than a transient hostname, which has higher + priority than the fallback hostname. Transient hostnames are equivalent, so setting a new transient + hostname causes the previous transient hostname to be forgotten. The hostname specified on the kernel + command line is like a transient hostname, with the exception that it has higher priority when the + machine boots. Also note that those are the semantics implemented by systemd tools, but other programs + may also set the hostname. + + + + History + + The simple configuration file format of + /etc/hostname originates from Debian + GNU/Linux. + + + + See Also + + systemd1, + sethostname2, + hostname1, + hostname7, + machine-id5, + machine-info5, + hostnamectl1, + systemd-hostnamed.service8, + systemd-firstboot1 + + + + diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml new file mode 100644 index 0000000..6933c68 --- /dev/null +++ b/man/hostnamectl.xml @@ -0,0 +1,211 @@ + + +%entities; +]> + + + + + + hostnamectl + systemd + + + + hostnamectl + 1 + + + + hostnamectl + Control the system hostname + + + + + hostnamectl + OPTIONS + COMMAND + + + + + Description + + hostnamectl may be used to query and change the system hostname and related + settings. + + systemd-hostnamed.service8 + and this tool distinguish three different hostnames: the high-level "pretty" hostname which might include + all kinds of special characters (e.g. "Lennart's Laptop"), the "static" hostname which is the + user-configured hostname (e.g. "lennarts-laptop"), and the transient hostname which is a fallback value + received from network configuration (e.g. "node12345678"). If a static hostname is set to a valid value, + then the transient hostname is not used. + + Note that the pretty hostname has little restrictions on the characters and length used, while the static and + transient hostnames are limited to the usually accepted characters of Internet domain names, and 64 characters at + maximum (the latter being a Linux limitation). + + Use + systemd-firstboot1 to + initialize the system hostname for mounted (but not booted) system images. + + + + Commands + + The following commands are understood: + + + + status + + Show system hostname and related information. If no command is specified, + this is the implied default. + + + + hostname [NAME] + + If no argument is given, print the system hostname. If an + optional argument NAME is provided then the command changes the + system hostname to NAME. By default, this will alter the + pretty, the static, and the transient hostname alike; however, if one or more of , + , are used, only the selected hostnames are changed. If + the pretty hostname is being set, and static or transient are being set as well, the specified hostname will be + simplified in regards to the character set used before the latter are updated. This is done by removing special + characters and spaces. This ensures that the pretty and the static hostname are always closely related while + still following the validity rules of the specific name. This simplification of the hostname string is not done + if only the transient and/or static hostnames are set, and the pretty hostname is left untouched. + + The static and transient hostnames must each be either a single DNS label (a string composed of + 7-bit ASCII lower-case characters and no spaces or dots, limited to the format allowed for DNS domain + name labels), or a sequence of such labels separated by single dots that forms a valid DNS FQDN. The + hostname must be at most 64 characters, which is a Linux limitation (DNS allows longer names). + + + + icon-name [NAME] + + If no argument is given, print the icon name of the system. If an + optional argument NAME is provided then the command changes the + icon name to NAME. The icon name is used by some + graphical applications to visualize this host. The icon name + should follow the Icon + Naming Specification. + + + + chassis [TYPE] + + If no argument is given, print the chassis type. If an + optional argument TYPE is provided then the command changes the + chassis type to TYPE. The chassis type is used by + some graphical applications to visualize the host or alter user interaction. + Currently, the following chassis types are defined: + desktop, + laptop, + convertible, + server, + tablet, + handset, + watch, + embedded, + as well as the special chassis types + vm and + container for virtualized systems that lack + an immediate physical chassis. + + + + + deployment [ENVIRONMENT] + + If no argument is given, print the deployment environment. If an + optional argument ENVIRONMENT is provided then the command changes the + deployment environment to ENVIRONMENT. + Argument ENVIRONMENT + must be a single word without any control characters. One of the following is suggested: + development, + integration, + staging, + production. + + + + + + location [LOCATION] + + If no argument is given, print the location string for the system. If an + optional argument LOCATION is provided then the command changes the + location string for the system to LOCATION. + Argument LOCATION should be a + human-friendly, free-form string describing the physical + location of the system, if it is known and applicable. This + may be as generic as Berlin, Germany or as + specific as Left Rack, 2nd Shelf. + + + + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + + + If status is invoked (or no explicit command is given) and one of these + switches is specified, hostnamectl will print out just this selected hostname. + + If used with set-hostname, only the selected hostnames will be updated. When more + than one of these switches are specified, all the specified hostnames will be updated. + + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + hostname1, + hostname5, + machine-info5, + systemctl1, + systemd-hostnamed.service8, + systemd-firstboot1 + + + + diff --git a/man/html.in b/man/html.in new file mode 100755 index 0000000..aaff9d1 --- /dev/null +++ b/man/html.in @@ -0,0 +1,29 @@ +#!/bin/sh +# SPDX-License-Identifier: LGPL-2.1-or-later +set -e + +if [ -z "$1" ]; then + echo "Use: $0 page-name (with no section suffix)" + exit 1 +fi + +# make sure the rules have been regenerated (in case update-man-rules was just run) +ninja -C "@BUILD_ROOT@" version.h + +target="man/$1.html" +ninja -C "@BUILD_ROOT@" "$target" + +fullname="@BUILD_ROOT@/$target" +if [ -f "$fullname" ]; then + redirect="$(readlink "$fullname" || :)" +else + redirect="" +fi +if [ -n "$redirect" ]; then + ninja -C "@BUILD_ROOT@" "man/$redirect" + + fullname="@BUILD_ROOT@/man/$redirect" +fi + +set -x +exec xdg-open "$fullname" diff --git a/man/hwdb-usb-device.c b/man/hwdb-usb-device.c new file mode 100644 index 0000000..19a5db8 --- /dev/null +++ b/man/hwdb-usb-device.c @@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +int print_usb_properties(uint16_t vid, uint16_t pid) { + char match[STRLEN("usb:vp") + DECIMAL_STR_MAX(uint16_t) * 2]; + sd_hwdb *hwdb; + const char *key, *value; + int r; + + /* Match this USB vendor and product ID combination */ + xsprintf(match, "usb:v%04Xp%04X", vid, pid); + + r = sd_hwdb_new(&hwdb); + if (r < 0) + return r; + + SD_HWDB_FOREACH_PROPERTY(hwdb, match, key, value) + printf("%s: \"%s\" → \"%s\"\n", match, key, value); + + sd_hwdb_unref(hwdb); + return 0; +} + +int main(int argc, char **argv) { + print_usb_properties(0x046D, 0xC534); + return 0; +} diff --git a/man/hwdb.xml b/man/hwdb.xml new file mode 100644 index 0000000..2c1e502 --- /dev/null +++ b/man/hwdb.xml @@ -0,0 +1,154 @@ + + + + + + + hwdb + systemd + + + + hwdb + 7 + + + + hwdb + Hardware Database + + + Description + The hardware database is a key-value store for associating modalias-like keys to + udev-property-like values. It is used primarily by udev to add the relevant properties + to matching devices, but it can also be queried directly. + + + Hardware Database Files + The hwdb files are read from the files located in the + system hwdb directory /usr/lib/udev/hwdb.d and + the local administration directory /etc/udev/hwdb.d. + All hwdb files are collectively sorted and processed in lexical order, + regardless of the directories in which they live. However, files with + identical filenames replace each other. Files in /etc/ + have the highest priority and take precedence over files with the same + name in /usr/lib/. This can be used to override a + system-supplied hwdb file with a local file if needed; + a symlink in /etc/ with the same name as a hwdb file in + /usr/lib/, pointing to /dev/null, + disables that hwdb file entirely. hwdb files must have the extension + .hwdb; other extensions are ignored. + + Each hwdb file contains data records consisting of matches and associated + key-value pairs. Every record in the hwdb starts with one or more match strings, + specifying a shell glob to compare the lookup string against. Multiple match lines + are specified in consecutive lines. Every match line is compared individually, and + they are combined by OR. Every match line must start at the first character of the + line. + + Match patterns consist of literal characters, and shell-style wildcards: + + Asterisk * matches any number of characters + + Question mark ? matches a single character + + Character list [chars] matches one of + the characters chars listed between [ and + ]. A range may be specified as with a dash as + [first-last]. The match may + be inverted with a caret [^…]. + + + The match lines are followed by one or more key-value pair lines, which are + recognized by a leading space character. The key name and value are separated by + =. An empty line signifies the end of a record. Lines beginning + with # are ignored. + + In case multiple records match a given lookup string, the key-value pairs + from all records are combined. If a key is specified multiple times, the value + from the record with the highest priority is used (each key can have only a single + value). The priority is higher when the record is in a file that sorts later + lexicographically, and in case of records in the same file, later records have + higher priority. + + The content of all hwdb files is read by + systemd-hwdb8 + and compiled to a binary database located at /etc/udev/hwdb.bin, + or alternatively /usr/lib/udev/hwdb.bin if you want ship the + compiled database in an immutable image. During runtime, only the binary database + is used. + + + + Examples + + + General syntax of hwdb files + + # /usr/lib/udev/hwdb.d/example.hwdb +# Comments can be placed before any records. This is a good spot +# to describe what that file is used for, what kind of properties +# it defines, and the ordering convention. + +# A record with three matches and one property +mouse:*:name:*Trackball*:* +mouse:*:name:*trackball*:* +mouse:*:name:*TrackBall*:* + ID_INPUT_TRACKBALL=1 + +# The rule above could be also be written in a form that +# matches Tb, tb, TB, tB: +mouse:*:name:*[tT]rack[bB]all*:* + ID_INPUT_TRACKBALL=1 + +# A record with a single match and five properties +mouse:usb:v046dp4041:name:Logitech MX Master:* + MOUSE_DPI=1000@166 + MOUSE_WHEEL_CLICK_ANGLE=15 + MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26 + MOUSE_WHEEL_CLICK_COUNT=24 + MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14 + + + + + Overriding of properties + + # /usr/lib/udev/hwdb.d/60-keyboard.hwdb +evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*:* + KEYBOARD_KEY_a1=help + KEYBOARD_KEY_a2=setup + KEYBOARD_KEY_a3=battery + +# Match vendor name "Acer" and any product name starting with "X123" +evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer:pnX123*:* + KEYBOARD_KEY_a2=wlan + +# /etc/udev/hwdb.d/70-keyboard.hwdb +# disable wlan key on all at keyboards +evdev:atkbd:* + KEYBOARD_KEY_a2=reserved + PROPERTY_WITH_SPACES=some string + + If the hwdb consists of those two files, a keyboard with the lookup string + evdev:atkbd:dmi:bvnAcer:bdXXXXX:bd08/05/2010:svnAcer:pnX123 + will match all three records, and end up with the following properties: + + KEYBOARD_KEY_a1=help +KEYBOARD_KEY_a2=reserved +KEYBOARD_KEY_a3=battery +PROPERTY_WITH_SPACES=some string + + + + + + See Also + + + systemd-hwdb8 + + + + diff --git a/man/id128-app-specific.c b/man/id128-app-specific.c new file mode 100644 index 0000000..b8982c7 --- /dev/null +++ b/man/id128-app-specific.c @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include + +#define OUR_APPLICATION_ID SD_ID128_MAKE(c2,73,27,73,23,db,45,4e,a6,3b,b9,6e,79,b5,3e,97) + +int main(int argc, char *argv[]) { + sd_id128_t id; + sd_id128_get_machine_app_specific(OUR_APPLICATION_ID, &id); + printf("Our application ID: " SD_ID128_FORMAT_STR "\n", SD_ID128_FORMAT_VAL(id)); + return 0; +} diff --git a/man/inotify-watch-tmp.c b/man/inotify-watch-tmp.c new file mode 100644 index 0000000..07ee8f6 --- /dev/null +++ b/man/inotify-watch-tmp.c @@ -0,0 +1,58 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +#include + +#define _cleanup_(f) __attribute__((cleanup(f))) + +static int inotify_handler(sd_event_source *source, + const struct inotify_event *event, + void *userdata) { + + const char *desc = NULL; + + sd_event_source_get_description(source, &desc); + + if (event->mask & IN_Q_OVERFLOW) + printf("inotify-handler <%s>: overflow\n", desc); + else if (event->mask & IN_CREATE) + printf("inotify-handler <%s>: create on %s\n", desc, event->name); + else if (event->mask & IN_DELETE) + printf("inotify-handler <%s>: delete on %s\n", desc, event->name); + else if (event->mask & IN_MOVED_TO) + printf("inotify-handler <%s>: moved-to on %s\n", desc, event->name); + + /* Terminate the program if an "exit" file appears */ + if ((event->mask & (IN_CREATE|IN_MOVED_TO)) && + strcmp(event->name, "exit") == 0) + sd_event_exit(sd_event_source_get_event(source), 0); + + return 1; +} + +int main(int argc, char **argv) { + _cleanup_(sd_event_unrefp) sd_event *event = NULL; + _cleanup_(sd_event_source_unrefp) sd_event_source *source1 = NULL, *source2 = NULL; + + const char *path1 = argc > 1 ? argv[1] : "/tmp"; + const char *path2 = argc > 2 ? argv[2] : NULL; + + /* Note: failure handling is omitted for brevity */ + + sd_event_default(&event); + + sd_event_add_inotify(event, &source1, path1, + IN_CREATE | IN_DELETE | IN_MODIFY | IN_MOVED_TO, + inotify_handler, NULL); + if (path2) + sd_event_add_inotify(event, &source2, path2, + IN_CREATE | IN_DELETE | IN_MODIFY | IN_MOVED_TO, + inotify_handler, NULL); + + sd_event_loop(event); + + return 0; +} diff --git a/man/integritytab.xml b/man/integritytab.xml new file mode 100644 index 0000000..44f0a55 --- /dev/null +++ b/man/integritytab.xml @@ -0,0 +1,161 @@ + + + + + + + + integritytab + systemd + + + + integritytab + 5 + + + + integritytab + Configuration for integrity block devices + + + + /etc/integritytab + + + + Description + + The /etc/integritytab file describes + integrity protected block devices that are set up during + system boot. + + Empty lines and lines starting with the # + character are ignored. Each of the remaining lines describes one + verity integrity protected block device. Fields are delimited by + white space. + + Each line is in the formvolume-name block-device + [keyfile|-] [options|-] + The first two fields are mandatory, the remaining two are optional and only required if user specified non-default options during integrity format. + + The first field contains the name of the resulting integrity volume; its block device is set up + below /dev/mapper/. + + The second field contains a path to the underlying block device, or a specification of a block device via + UUID= followed by the UUID, + PARTUUID= followed by the partition UUID, + LABEL= followed by the label, + PARTLABEL= followed by the partition label. + + + The third field if present contains an absolute filename path to a key file or a - + to specify none. When the filename is present, the "integrity-algorithm" defaults to hmac-sha256 + with the key length derived from the number of bytes in the key file. At this time the only supported integrity algorithm + when using key file is hmac-sha256. The maximum size of the key file is 4096 bytes. + + + The fourth field, if present, is a comma-delimited list of options or a - to specify none. The following options are + recognized: + + + + + + + Allow the use of discard (TRIM) requests for the device. + This option is available since the Linux kernel version 5.7. + + + + + + + + Journal watermark in percent. When the journal percentage exceeds this watermark, the journal flush will be started. Setting a value of + "0%" uses default value. + + + + + + + + Commit time in milliseconds. When this time passes (and no explicit flush operation was issued), the journal is written. Setting a value of + zero uses default value. + + + + + + + + Specify a separate block device that contains existing data. The second field specified in the + integritytab for block device then will contain calculated integrity tags and journal for data-device, + but not the end user data. + + + + + + + + The algorithm used for integrity checking. The default is crc32c. Must match option used during format. + + + + + At early boot and when the system manager configuration is + reloaded, this file is translated into native systemd units by + systemd-integritysetup-generator8. + + + + Examples + + /etc/integritytab + Set up two integrity protected block devices. + + home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 - journal-commit-time=10,allow-discards,journal-watermark=55% +data PARTUUID=5d4b1808-be76-774d-88af-03c4c3a41761 - allow-discards + + + + + /etc/integritytab + Set up 1 integrity protected block device using defaults + + home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 + + + + /etc/integritytab + Set up 1 integrity device using existing data block device which contains user data + + home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 - data-device=/dev/disk/by-uuid/9276d9c0-d4e3-4297-b4ff-3307cd0d092f + + + + /etc/integritytab + Set up 1 integrity device using a HMAC key file using defaults + + home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 /etc/hmac.key + + + + + + See Also + + systemd1, + systemd-integritysetup@.service8, + systemd-integritysetup-generator8, + integritysetup8, + + + + diff --git a/man/journal-enumerate-fields.c b/man/journal-enumerate-fields.c new file mode 100644 index 0000000..bb09319 --- /dev/null +++ b/man/journal-enumerate-fields.c @@ -0,0 +1,22 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +int main(int argc, char *argv[]) { + sd_journal *j; + const char *field; + int r; + + r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to open journal: %m\n"); + return 1; + } + SD_JOURNAL_FOREACH_FIELD(j, field) + printf("%s\n", field); + sd_journal_close(j); + return 0; +} diff --git a/man/journal-iterate-foreach.c b/man/journal-iterate-foreach.c new file mode 100644 index 0000000..381b50f --- /dev/null +++ b/man/journal-iterate-foreach.c @@ -0,0 +1,31 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +int main(int argc, char *argv[]) { + int r; + sd_journal *j; + r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to open journal: %m\n"); + return 1; + } + SD_JOURNAL_FOREACH(j) { + const char *d; + size_t l; + + r = sd_journal_get_data(j, "MESSAGE", (const void **)&d, &l); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to read message field: %m\n"); + continue; + } + + printf("%.*s\n", (int) l, d); + } + sd_journal_close(j); + return 0; +} diff --git a/man/journal-iterate-poll.c b/man/journal-iterate-poll.c new file mode 100644 index 0000000..d377324 --- /dev/null +++ b/man/journal-iterate-poll.c @@ -0,0 +1,27 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +int wait_for_changes(sd_journal *j) { + uint64_t t; + int msec; + struct pollfd pollfd; + + sd_journal_get_timeout(j, &t); + if (t == (uint64_t) -1) + msec = -1; + else { + struct timespec ts; + uint64_t n; + clock_gettime(CLOCK_MONOTONIC, &ts); + n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000; + msec = t > n ? (int) ((t - n + 999) / 1000) : 0; + } + + pollfd.fd = sd_journal_get_fd(j); + pollfd.events = sd_journal_get_events(j); + poll(&pollfd, 1, msec); + return sd_journal_process(j); +} diff --git a/man/journal-iterate-unique.c b/man/journal-iterate-unique.c new file mode 100644 index 0000000..5fe98b3 --- /dev/null +++ b/man/journal-iterate-unique.c @@ -0,0 +1,29 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +int main(int argc, char *argv[]) { + sd_journal *j; + const void *d; + size_t l; + int r; + + r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to open journal: %m\n"); + return 1; + } + r = sd_journal_query_unique(j, "_SYSTEMD_UNIT"); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to query journal: %m\n"); + return 1; + } + SD_JOURNAL_FOREACH_UNIQUE(j, d, l) + printf("%.*s\n", (int) l, (const char*) d); + sd_journal_close(j); + return 0; +} diff --git a/man/journal-iterate-wait.c b/man/journal-iterate-wait.c new file mode 100644 index 0000000..ac4b60b --- /dev/null +++ b/man/journal-iterate-wait.c @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +int main(int argc, char *argv[]) { + int r; + sd_journal *j; + r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to open journal: %m\n"); + return 1; + } + for (;;) { + const void *d; + size_t l; + r = sd_journal_next(j); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to iterate to next entry: %m\n"); + break; + } + if (r == 0) { + /* Reached the end, let's wait for changes, and try again */ + r = sd_journal_wait(j, (uint64_t) -1); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to wait for changes: %m\n"); + break; + } + continue; + } + r = sd_journal_get_data(j, "MESSAGE", &d, &l); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to read message field: %m\n"); + continue; + } + printf("%.*s\n", (int) l, (const char*) d); + } + sd_journal_close(j); + return 0; +} diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml new file mode 100644 index 0000000..3f69f30 --- /dev/null +++ b/man/journal-remote.conf.xml @@ -0,0 +1,100 @@ + + + + + + + + journal-remote.conf + systemd + + + + journal-remote.conf + 5 + + + + journal-remote.conf + journal-remote.conf.d + Configuration files for the service accepting remote journal uploads + + + + /etc/systemd/journal-remote.conf + /etc/systemd/journal-remote.conf.d/*.conf + /run/systemd/journal-remote.conf.d/*.conf + /usr/lib/systemd/journal-remote.conf.d/*.conf + + + + Description + + These files configure various parameters of + systemd-journal-remote.service8. + See + systemd.syntax7 + for a general description of the syntax. + + + + + + Options + + All options are configured in the + [Remote] section: + + + + Seal= + + Periodically sign the data in the journal using Forward Secure Sealing. + + + + + SplitMode= + + One of host or none. + + + + + ServerKeyFile= + + SSL key in PEM format. + + + + ServerCertificateFile= + + SSL certificate in PEM format. + + + + TrustedCertificateFile= + + SSL CA certificate. + + + + + + + + See Also + + systemd-journal-remote.service8, + systemd1, + systemd-journald.service8 + + + + diff --git a/man/journal-stream-fd.c b/man/journal-stream-fd.c new file mode 100644 index 0000000..8aad5ff --- /dev/null +++ b/man/journal-stream-fd.c @@ -0,0 +1,29 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include +#include +#include +#include + +int main(int argc, char *argv[]) { + int fd; + FILE *log; + fd = sd_journal_stream_fd("test", LOG_INFO, 1); + if (fd < 0) { + errno = -fd; + fprintf(stderr, "Failed to create stream fd: %m\n"); + return 1; + } + log = fdopen(fd, "w"); + if (!log) { + fprintf(stderr, "Failed to create file object: %m\n"); + close(fd); + return 1; + } + fprintf(log, "Hello World!\n"); + fprintf(log, SD_WARNING "This is a warning!\n"); + fclose(log); + return 0; +} diff --git a/man/journal-upload.conf.xml b/man/journal-upload.conf.xml new file mode 100644 index 0000000..a1caae1 --- /dev/null +++ b/man/journal-upload.conf.xml @@ -0,0 +1,101 @@ + + + + + + + journal-upload.conf + systemd + + + + journal-upload.conf + 5 + + + + journal-upload.conf + journal-upload.conf.d + Configuration files for the journal upload service + + + + /etc/systemd/journal-upload.conf + /etc/systemd/journal-upload.conf.d/*.conf + /run/systemd/journal-upload.conf.d/*.conf + /usr/lib/systemd/journal-upload.conf.d/*.conf + + + + Description + + These files configure various parameters of + systemd-journal-upload.service8. + See + systemd.syntax7 + for a general description of the syntax. + + + + + + Options + + All options are configured in the [Upload] section: + + + + URL= + + The URL to upload the journal entries to. See the description + of option in + systemd-journal-upload8 + for the description of possible values. There is no default value, so either this + option or the command-line option must be always present to make an upload. + + + + ServerKeyFile= + + SSL key in PEM format. + + + + ServerCertificateFile= + + SSL CA certificate in PEM format. + + + + TrustedCertificateFile= + + SSL CA certificate. + + + + NetworkTimeoutSec= + + When network connectivity to the server is lost, this option + configures the time to wait for the connectivity to get restored. If the server is + not reachable over the network for the configured time, systemd-journal-upload + exits. Takes a value in seconds (or in other time units if suffixed with "ms", "min", "h", etc). + For details, see systemd.time5. + + + + + + + + + See Also + + systemd-journal-upload.service8, + systemd1, + systemd-journald.service8 + + + + diff --git a/man/journalctl.xml b/man/journalctl.xml new file mode 100644 index 0000000..229a2fd --- /dev/null +++ b/man/journalctl.xml @@ -0,0 +1,956 @@ + + + + + + + + journalctl + systemd + + + + journalctl + 1 + + + + journalctl + Query the systemd journal + + + + + journalctl + OPTIONS + MATCHES + + + + + Description + + journalctl may be used to query the contents of the + systemd1 journal as + written by + systemd-journald.service8. + + If called without parameters, it will show the full contents of the journal, starting with the + oldest entry collected. + + If one or more match arguments are passed, the output is filtered accordingly. A match is in the + format FIELD=VALUE, e.g. _SYSTEMD_UNIT=httpd.service, referring to + the components of a structured journal entry. See + systemd.journal-fields7 + for a list of well-known fields. If multiple matches are specified matching different fields, the log + entries are filtered by both, i.e. the resulting output will show only entries matching all the specified + matches of this kind. If two matches apply to the same field, then they are automatically matched as + alternatives, i.e. the resulting output will show entries matching any of the specified matches for the + same field. Finally, the character + may appear as a separate word between other terms + on the command line. This causes all matches before and after to be combined in a disjunction + (i.e. logical OR). + + It is also possible to filter the entries by specifying an absolute file path as an argument. The + file path may be a file or a symbolic link and the file must exist at the time of the query. If a file + path refers to an executable binary, an _EXE= match for the canonicalized binary path + is added to the query. If a file path refers to an executable script, a _COMM= match + for the script name is added to the query. If a file path refers to a device node, + _KERNEL_DEVICE= matches for the kernel name of the device and for each of its ancestor + devices is added to the query. Symbolic links are dereferenced, kernel names are synthesized, and parent + devices are identified from the environment at the time of the query. In general, a device node is the + best proxy for an actual device, as log entries do not usually contain fields that identify an actual + device. For the resulting log entries to be correct for the actual device, the relevant parts of the + environment at the time the entry was logged, in particular the actual device corresponding to the device + node, must have been the same as those at the time of the query. Because device nodes generally change + their corresponding devices across reboots, specifying a device node path causes the resulting entries to + be restricted to those from the current boot. + + Additional constraints may be added using options , + , etc., to further limit what entries will be shown (logical AND). + + Output is interleaved from all accessible journal files, whether they are rotated or currently + being written, and regardless of whether they belong to the system itself or are accessible user + journals. The option can be used to identify which files + are being shown. + + The set of journal files which will be used can be modified using the , + , , and options, see + below. + + All users are granted access to their private per-user journals. However, by default, only root and + users who are members of a few special groups are granted access to the system journal and the journals + of other users. Members of the groups systemd-journal, adm, and + wheel can read all journal files. Note that the two latter groups traditionally have + additional privileges specified by the distribution. Members of the wheel group can + often perform administrative tasks. + + The output is paged through less by default, and long lines are "truncated" to + screen width. The hidden part can be viewed by using the left-arrow and right-arrow keys. Paging can be + disabled; see the option and the "Environment" section below. + + When outputting to a tty, lines are colored according to priority: lines of level ERROR and higher + are colored red; lines of level NOTICE and higher are highlighted; lines of level DEBUG are colored + lighter grey; other lines are displayed normally. + + + + Source Options + + The following options control where to read journal records from: + + + + + + + Show messages from system services and the kernel (with + ). Show messages from service of current user (with + ). If neither is specified, show all messages that the user can see. + + + The option affects how arguments are + treated. See . + + + + + + + Show messages from a running, local container. Specify a container name to connect + to. + + + + + + + Show entries interleaved from all available journals, including remote + ones. + + + + + + + Takes a directory path as argument. If specified, journalctl will operate on the + specified journal directory DIR instead of the default runtime and system + journal paths. + + + + + + Takes a file glob as an argument. If specified, journalctl will operate on the + specified journal files matching GLOB instead of the default runtime and + system journal paths. May be specified multiple times, in which case files will be suitably + interleaved. + + + + + + Takes a directory path as an argument. If specified, journalctl + will operate on journal directories and catalog file hierarchy underneath the specified directory + instead of the root directory (e.g. will create + ROOT/var/lib/systemd/catalog/database, and journal + files under ROOT/run/journal/ or + ROOT/var/log/journal/ will be displayed). + + + + + + + Takes a path to a disk image file or block device node. If specified, + journalctl will operate on the file system in the indicated disk image. This + option is similar to , but operates on file systems stored in disk images or + block devices, thus providing an easy way to extract log data from disk images. The disk image should + either contain just a file system or a set of file systems within a GPT partition table, following + the Discoverable Partitions + Specification. For further information on supported disk images, see + systemd-nspawn1's + switch of the same name. + + + + + + Takes a journal namespace identifier string as argument. If not specified the data + collected by the default namespace is shown. If specified shows the log data of the specified + namespace instead. If the namespace is specified as * data from all namespaces is + shown, interleaved. If the namespace identifier is prefixed with + data from the + specified namespace and the default namespace is shown, interleaved, but no other. For details about + journal namespaces see + systemd-journald.service8. + + + + + + Filtering Options + + The following options control how to filter journal records: + + + + + + + + + Start showing entries on or newer than the specified date, or on or older than the + specified date, respectively. Date specifications should be of the format 2012-10-30 + 18:17:16. If the time part is omitted, 00:00:00 is assumed. If only + the seconds component is omitted, :00 is assumed. If the date component is + omitted, the current day is assumed. Alternatively the strings yesterday, + today, tomorrow are understood, which refer to 00:00:00 of the + day before the current day, the current day, or the day after the current day, + respectively. now refers to the current time. Finally, relative times may be + specified, prefixed with - or +, referring to times before or + after the current time, respectively. For complete time and date specification, see + systemd.time7. Note + that prints timestamps that follow precisely this format. + + + + + + + + Start showing entries from the location in the journal specified by the passed + cursor. + + + + + + Start showing entries from the location in the journal after + the location specified by the passed cursor. The cursor is shown when the + option is used. + + + + + + If FILE exists and contains a cursor, start showing + entries after this location. Otherwise show entries according to the other + given options. At the end, write the cursor of the last entry to + FILE. Use this option to continually read the journal by sequentially + calling journalctl. + + + + + + + Show messages from a specific boot. This will add a match for + _BOOT_ID=. + + The argument may be empty, in which case logs for the current boot will be shown. + + If the boot ID is omitted, a positive offset will look up the boots + starting from the beginning of the journal, and an equal-or-less-than zero + offset will look up boots starting from the end of the journal. Thus, + 1 means the first boot found in the journal in chronological order, + 2 the second and so on; while -0 is the last boot, + -1 the boot before last, and so on. An empty offset + is equivalent to specifying -0, except when the current boot is not the last + boot (e.g. because was specified to look at logs from a different + machine). + + If the 32-character ID is specified, it may optionally be followed + by offset which identifies the boot relative to the one given by boot + ID. Negative values mean earlier boots and positive values mean later + boots. If offset is not specified, a value of zero is assumed, and the + logs for the boot given by ID are shown. + + The special argument all can be used to negate the effect of an earlier + use of . + + + + + + + Show messages for the specified systemd unit UNIT (such as + a service unit), or for any of the units matched by PATTERN. If a pattern + is specified, a list of unit names found in the journal is compared with the specified pattern and + all that match are used. For each unit name, a match is added for messages from the unit + (_SYSTEMD_UNIT=UNIT), along with additional matches for + messages from systemd and messages about coredumps for the specified unit. A match is also added for + _SYSTEMD_SLICE=UNIT, such that if the provided + UNIT is a + systemd.slice5 + unit, all logs of children of the slice will be shown. + + With , all arguments will be converted to match + user messages as if specified with . + + This parameter can be specified multiple times. + + + + + + Show messages for the specified user session unit. This will add a match for messages + from the unit (_SYSTEMD_USER_UNIT= and _UID=) and additional + matches for messages from session systemd and messages about coredumps for the specified unit. A + match is also added for _SYSTEMD_USER_SLICE=UNIT, such + that if the provided UNIT is a + systemd.slice5 + unit, all logs of children of the unit will be shown. + + This parameter can be specified multiple times. + + + + + + + Show messages for the specified syslog identifier + SYSLOG_IDENTIFIER. + + This parameter can be specified multiple times. + + + + + + + Filter output by message priorities or priority ranges. Takes either a single numeric + or textual log level (i.e. between 0/emerg and 7/debug), or a + range of numeric/text log levels in the form FROM..TO. The log levels are the usual syslog log levels + as documented in syslog3, + i.e. emerg (0), alert (1), crit (2), + err (3), warning (4), notice (5), + info (6), debug (7). If a single log level is specified, all + messages with this log level or a lower (hence more important) log level are shown. If a range is + specified, all messages within the range are shown, including both the start and the end value of the + range. This will add PRIORITY= matches for the specified + priorities. + + + + + + Filter output by syslog facility. Takes a comma-separated list of numbers or + facility names. The names are the usual syslog facilities as documented in syslog3. + may be used to display a list of known facility names and exit. + + + + + + + + Filter output to entries where the MESSAGE= field matches the + specified regular expression. PERL-compatible regular expressions are used, see pcre2pattern3 + for a detailed description of the syntax. + + If the pattern is all lowercase, matching is case insensitive. Otherwise, matching is case + sensitive. This can be overridden with the option, see + below. + + When used with , is implied. + + + + + + Make pattern matching case sensitive or case insensitive. + + + + + + + Show only kernel messages. This implies and adds the match + _TRANSPORT=kernel. + + + + + + Output Options + + The following options control how journal records are printed: + + + + + + + Controls the formatting of the journal entries that are shown. Takes one of the + following options: + + + + + is the default and generates an output that is mostly identical to the + formatting of classic syslog files, showing one line per journal entry. + + + + + is very similar, but shows timestamps in the format the + and options accept. Unlike the timestamp + information shown in output mode this mode includes weekday, year and + timezone information in the output, and is locale-independent. + + + + + is very similar, but shows ISO 8601 wallclock timestamps. + + + + + as for but includes full microsecond + precision. + + + + + is very similar, but shows classic syslog timestamps with full microsecond + precision. + + + + + is very similar, but shows monotonic timestamps instead of wallclock + timestamps. + + + + + as for but includes the time difference + to the previous entry. + Maybe unreliable time differences are marked by a *. + + + + + is very similar, but shows seconds passed since January 1st 1970 UTC instead of + wallclock timestamps ("UNIX time"). The time is shown with microsecond accuracy. + + + + + shows the full-structured entry items with all fields. + + + + + serializes the journal into a binary (but mostly text-based) stream suitable + for backups and network transfer (see Journal Export + Format for more information). To import the binary stream back into native journald + format use + systemd-journal-remote8. + + + + + formats entries as JSON objects, separated by newline characters (see Journal JSON Format + for more information). Field values are generally encoded as JSON strings, with three exceptions: + + Fields larger than 4096 bytes are encoded as null + values. (This may be turned off by passing , but be aware that this may + allocate overly long JSON objects.) + + Journal entries permit non-unique fields within the same log entry. JSON does + not allow non-unique fields within objects. Due to this, if a non-unique field is encountered a + JSON array is used as field value, listing all field values as elements. + + Fields containing non-printable or non-UTF8 bytes are encoded as arrays + containing the raw bytes individually formatted as unsigned numbers. + + + Note that this encoding is reversible (with the exception of the size limit). + + + + + formats entries as JSON data structures, but formats them in multiple lines in + order to make them more readable by humans. + + + + + formats entries as JSON data structures, but wraps them in a format suitable for + Server-Sent + Events. + + + + + formats entries as JSON data structures, but prefixes them with an ASCII Record + Separator character (0x1E) and suffixes them with an ASCII Line Feed character (0x0A), in + accordance with JavaScript Object Notation + (JSON) Text Sequences (application/json-seq). + + + + + generates a very terse output, only showing the actual message of each journal + entry with no metadata, not even a timestamp. If combined with the + option will output the listed fields for each log record, + instead of the message. + + + + + similar to , but prefixes the unit and user unit names + instead of the traditional syslog identifier. Useful when using templated instances, as it will + include the arguments in the unit names. + + + + + + + + A comma separated list of the fields which should be included in the output. This + has an effect only for the output modes which would normally show all fields + (, , , + , and ), as well as + on . For the former, the __CURSOR, + __REALTIME_TIMESTAMP, __MONOTONIC_TIMESTAMP, and + _BOOT_ID fields are always printed. + + + + + + + Show the most recent journal events and limit the number of events shown. If + is used, this option is implied. The argument is a positive integer or + all to disable line limiting. The default value is 10 if no argument is + given. + + When used with , is implied. + + + + + + + Reverse output so that the newest entries are displayed first. + + + + + + The cursor is shown after the last entry after two dashes: + -- cursor: s=0639… + The format of the cursor is private and subject to change. + + + + + + Express time in Coordinated Universal Time (UTC). + + + + + + + Augment log lines with explanation texts from the message catalog. This will add + explanatory help texts to log messages in the output where this is available. These short help texts + will explain the context of an error or log event, possible solutions, as well as pointers to support + forums, developer documentation, and any other relevant manuals. Note that help texts are not + available for all messages, but only for selected ones. For more information on the message catalog, + please refer to the Message + Catalog Developer Documentation. + + Note: when attaching journalctl output to bug reports, please do + not use . + + + + + + Don't show the hostname field of log messages originating from the local host. This + switch has an effect only on the family of output modes (see above). + + Note: this option does not remove occurrences of the hostname from log entries themselves, so + it does not prevent the hostname from being visible in the logs. + + + + + + + + Ellipsize fields when they do not fit in available columns. The default is to show + full fields, allowing them to wrap or be truncated by the pager, if one is used. + + The old options / are not useful anymore, except to + undo . + + + + + + + Show all fields in full, even if they include unprintable characters or are very + long. By default, fields with unprintable characters are abbreviated as "blob data". (Note that the + pager may escape unprintable characters again.) + + + + + + + Show only the most recent journal entries, and continuously print new entries as + they are appended to the journal. + + + + + + Show all stored output lines, even in follow mode. Undoes the effect of + . + + + + + + + Suppresses all informational messages (i.e. "-- Journal begins at …", "-- Reboot + --"), any warning messages regarding inaccessible system journals when run as a normal + user. + + + + + + Pager Control Options + + The following options control page support: + + + + + + + + + + Immediately jump to the end of the journal inside the implied pager tool. This + implies to guarantee that the pager will not buffer logs of unbounded + size. This may be overridden with an explicit with some other numeric value, + while will disable this cap. Note that this option is only supported for + the less1 + pager. + + + + + + Forward Secure Sealing (FSS) Options + + The following options make be used together with the command, see below. + + + + + + Specifies the change interval for the sealing key when generating an FSS key pair + with . Shorter intervals increase CPU consumption but shorten the time + range of undetectable journal alterations. Defaults to 15min. + + + + + + Specifies the FSS verification key to use for the + operation. + + + + + + When is passed and Forward Secure Sealing (FSS) has + already been configured, recreate FSS keys. + + + + + + Commands + + The following commands are understood. If none is specified the default is to display journal records. + + + + + + + Print all field names currently used in all entries of the journal. + + + + + + + Print all possible data values the specified field can take in all entries of the + journal. + + + + + + Show a tabular list of boot numbers (relative to the current boot), their IDs, and + the timestamps of the first and last message pertaining to the boot. + + + + + + Shows the current disk usage of all journal files. This shows the sum of the disk + usage of all archived and active journal files. + + + + + + + + removes the oldest archived journal files until the + disk space they use falls below the specified size. Accepts the usual K, + M, G and T suffixes (to the base of + 1024). + + removes archived journal files older than the specified + timespan. Accepts the usual s (default), m, + h, days, months, weeks + and years suffixes, see + systemd.time7 for + details. + + leaves only the specified number of separate journal + files. + + Note that running has only an indirect effect on the output + shown by , as the latter includes active journal files, while the + vacuuming operation only operates on archived journal files. Similarly, + might not actually reduce the number of journal files to below the + specified number, as it will not remove active journal files. + + , and + may be combined in a single invocation to enforce any combination of + a size, a time and a number of files limit on the archived journal files. Specifying any of these + three parameters as zero is equivalent to not enforcing the specific limit, and is thus + redundant. + + These three switches may also be combined with into one command. If + so, all active files are rotated first, and the requested vacuuming operation is executed right + after. The rotation has the effect that all currently active files are archived (and potentially new, + empty journal files opened as replacement), and hence the vacuuming operation has the greatest effect + as it can take all log data written so far into account. + + + + + + Check the journal file for internal consistency. If the file has been generated + with FSS enabled and the FSS verification key has been specified with + , authenticity of the journal file is verified. + + + + + + Asks the journal daemon to write all yet unwritten journal data to the backing file + system and synchronize all journals. This call does not return until the synchronization operation + is complete. This command guarantees that any log messages written before its invocation are safely + stored on disk at the time it returns. + + + + + + Asks the journal daemon for the reverse operation to : if + requested the daemon will write further log data to /run/log/journal/ and + stops writing to /var/log/journal/. A subsequent call to + causes the log output to switch back to + /var/log/journal/, see above. + + + + + + Similar to , but executes no operation if the root + file system and /var/log/journal/ reside on the same mount point. This operation + is used during system shutdown in order to make the journal daemon stop writing data to + /var/log/journal/ in case that directory is located on a mount point that needs + to be unmounted. + + + + + + Asks the journal daemon to flush any log data stored in + /run/log/journal/ into /var/log/journal/, if persistent + storage is enabled. This call does not return until the operation is complete. Note that this call is + idempotent: the data is only flushed from /run/log/journal/ into + /var/log/journal/ once during system runtime (but see + below), and this command exits cleanly without executing any + operation if this has already happened. This command effectively guarantees that all data is flushed + to /var/log/journal/ at the time it returns. + + + + + + Asks the journal daemon to rotate journal files. This call does not return until + the rotation operation is complete. Journal file rotation has the effect that all currently active + journal files are marked as archived and renamed, so that they are never written to in future. New + (empty) journal files are then created in their place. This operation may be combined with + , and + into a single command, see above. + + + + + + Instead of showing journal contents, show internal header information of the + journal fields accessed. + + This option is particularly useful when trying to identify out-of-order journal entries, as + happens for example when the machine is booted with the wrong system time. + + + + + + List the contents of the message catalog as a table of message IDs, plus their + short description strings. + + If any 128-bit-IDs are specified, only those entries are + shown. + + + + + + Show the contents of the message catalog, with entries separated by a line + consisting of two dashes and the ID (the format is the same as .catalog + files). + + If any 128-bit-IDs are specified, only those entries are + shown. + + + + + + Update the message catalog index. This command needs to be executed each time new + catalog files are installed, removed, or updated to rebuild the binary catalog + index. + + + + + + Instead of showing journal contents, generate a new key pair for Forward Secure + Sealing (FSS). This will generate a sealing key and a verification key. The sealing key is stored in + the journal data directory and shall remain on the host. The verification key should be stored + externally. Refer to the option in + journald.conf5 for + information on Forward Secure Sealing and for a link to a refereed scholarly paper detailing the + cryptographic theory it is based on. + + + + + + + + + Exit status + + On success, 0 is returned; otherwise, a non-zero failure code is returned. + + + + + + Examples + + Without arguments, all collected logs are shown unfiltered: + + journalctl + + With one match specified, all entries with a field matching the expression are shown: + + journalctl _SYSTEMD_UNIT=avahi-daemon.service +journalctl _SYSTEMD_CGROUP=/user.slice/user-42.slice/session-c1.scope + + If two different fields are matched, only entries matching both expressions at the same time are + shown: + + journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + + If two matches refer to the same field, all entries matching either expression are shown: + + journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service + + If the separator + is used, two expressions may be combined in a logical OR. The + following will show all messages from the Avahi service process with the PID 28097 plus all messages from + the D-Bus service (from any of its processes): + + journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + _SYSTEMD_UNIT=dbus.service + + To show all fields emitted by a unit and about the unit, + option / should be used. journalctl -u + name expands to a complex filter similar to + + _SYSTEMD_UNIT=name.service + + UNIT=name.service _PID=1 + + OBJECT_SYSTEMD_UNIT=name.service _UID=0 + + COREDUMP_UNIT=name.service _UID=0 MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 + + (see + systemd.journal-fields7 + for an explanation of those patterns). + + Show all logs generated by the D-Bus executable: + + journalctl /usr/bin/dbus-daemon + + Show all kernel logs from previous boot: + + journalctl -k -b -1 + + Show a live log display from a system service apache.service: + + journalctl -f -u apache + + + + See Also + + systemd1, + systemd-journald.service8, + systemctl1, + coredumpctl1, + systemd.journal-fields7, + journald.conf5, + systemd.time7, + systemd-journal-remote.service8, + systemd-journal-upload.service8 + + + diff --git a/man/journald.conf.xml b/man/journald.conf.xml new file mode 100644 index 0000000..2db6a0f --- /dev/null +++ b/man/journald.conf.xml @@ -0,0 +1,511 @@ + + + + + + + journald.conf + systemd + + + + journald.conf + 5 + + + + journald.conf + journald.conf.d + journald@.conf + Journal service configuration files + + + + /etc/systemd/journald.conf + /etc/systemd/journald.conf.d/*.conf + /run/systemd/journald.conf.d/*.conf + /usr/lib/systemd/journald.conf.d/*.conf + /etc/systemd/journald@NAMESPACE.conf + /etc/systemd/journald@NAMESPACE.conf.d/*.conf + /run/systemd/journald@NAMESPACE.conf.d/*.conf + /usr/lib/systemd/journald@NAMESPACE.conf.d/*.conf + + + + Description + + These files configure various parameters of the systemd journal service, + systemd-journald.service8. + See + systemd.syntax7 + for a general description of the syntax. + + The systemd-journald instance managing the default namespace is configured by + /etc/systemd/journald.conf and associated drop-ins. Instances managing other + namespaces read /etc/systemd/journald@NAMESPACE.conf + and associated drop-ins with the namespace identifier filled in. This allows each namespace to carry + a distinct configuration. See + systemd-journald.service8 + for details about journal namespaces. + + + + + + Options + + All options are configured in the + [Journal] section: + + + + + Storage= + + Controls where to store journal data. One of volatile, + persistent, auto and none. If + volatile, journal log data will be stored only in memory, i.e. below the + /run/log/journal hierarchy (which is created if needed). If + persistent, data will be stored preferably on disk, i.e. below the + /var/log/journal hierarchy (which is created if needed), with a fallback to + /run/log/journal (which is created if needed), during early boot and if the disk + is not writable. auto behaves like persistent if the + /var/log/journal directory exists, and volatile otherwise + (the existence of the directory controls the storage mode). none turns off all + storage, all log data received will be dropped (but forwarding to other targets, such as the console, + the kernel log buffer, or a syslog socket will still work). Defaults to auto in + the default journal namespace, and persistent in all others. + + Note that journald will initially use volatile storage, until a call to + journalctl --flush (or sending SIGUSR1 to journald) will cause + it to switch to persistent logging (under the conditions mentioned above). This is done automatically + on boot via systemd-journal-flush.service. + + Note that when this option is changed to volatile, existing persistent data + is not removed. In the other direction, + journalctl1 with + the option may be used to move volatile data to persistent storage. + + When journal namespacing (see LogNamespace= in + systemd.exec5) is + used, setting Storage= to volatile or auto + will not have an effect on the creation of the per-namespace logs directory in + /var/log/journal/, as the systemd-journald@.service service + file by default carries LogsDirectory=. To turn that off, add a unit file drop-in + file that sets LogsDirectory= to an empty string. + + + + + Compress= + + Can take a boolean value. If enabled (the + default), data objects that shall be stored in the journal + and are larger than the default threshold of 512 bytes are + compressed before they are written to the file system. It + can also be set to a number of bytes to specify the + compression threshold directly. Suffixes like K, M, and G + can be used to specify larger units. + + + + Seal= + + Takes a boolean value. If enabled (the + default), and a sealing key is available (as created by + journalctl1's + command), Forward Secure Sealing + (FSS) for all persistent journal files is enabled. FSS is + based on Seekable Sequential Key + Generators by G. A. Marson and B. Poettering + (doi:10.1007/978-3-642-40203-6_7) and may be used to protect + journal files from unnoticed alteration. + + + + SplitMode= + + Controls whether to split up journal files per user, either uid or + none. Split journal files are primarily useful for access control: on UNIX/Linux access + control is managed per file, and the journal daemon will assign users read access to their journal files. If + uid, all regular users (with UID outside the range of system users, dynamic service users, + and the nobody user) will each get their own journal files, and system users will log to the system journal. + See Users, Groups, UIDs and GIDs on systemd systems + for more details about UID ranges. + If none, journal files are not split up by user and all messages are + instead stored in the single system journal. In this mode unprivileged users generally do not have access to + their own log data. Note that splitting up journal files by user is only available for journals stored + persistently. If journals are stored on volatile storage (see Storage= above), only a single + journal file is used. Defaults to uid. + + + + RateLimitIntervalSec= + RateLimitBurst= + + Configures the rate limiting that is applied + to all messages generated on the system. If, in the time + interval defined by RateLimitIntervalSec=, + more messages than specified in + RateLimitBurst= are logged by a service, + all further messages within the interval are dropped until the + interval is over. A message about the number of dropped + messages is generated. This rate limiting is applied + per-service, so that two services which log do not interfere + with each other's limits. Defaults to 10000 messages in 30s. + The time specification for + RateLimitIntervalSec= may be specified in the + following units: s, min, + h, ms, + us. To turn off any kind of rate limiting, + set either value to 0. + + Note that the effective rate limit is multiplied by a + factor derived from the available free disk space for the journal. + Currently, this factor is calculated using the base 2 logarithm. + + + Example <varname>RateLimitBurst=</varname> rate + modifications by the available disk space + + + + + + Available Disk Space + Burst Multiplier + + + + + <= 1MB + 1 + + + <= 16MB + 2 + + + <= 256MB + 3 + + + <= 4GB + 4 + + + <= 64GB + 5 + + + <= 1TB + 6 + + + +
+ + If a service provides rate limits for itself through + LogRateLimitIntervalSec= and/or LogRateLimitBurst= + in systemd.exec5, + those values will override the settings specified here. + + + + + SystemMaxUse= + SystemKeepFree= + SystemMaxFileSize= + SystemMaxFiles= + RuntimeMaxUse= + RuntimeKeepFree= + RuntimeMaxFileSize= + RuntimeMaxFiles= + + Enforce size limits on the journal files + stored. The options prefixed with System + apply to the journal files when stored on a persistent file + system, more specifically + /var/log/journal. The options prefixed + with Runtime apply to the journal files + when stored on a volatile in-memory file system, more + specifically /run/log/journal. The former + is used only when /var/ is mounted, + writable, and the directory + /var/log/journal exists. Otherwise, only + the latter applies. Note that this means that during early + boot and if the administrator disabled persistent logging, + only the latter options apply, while the former apply if + persistent logging is enabled and the system is fully booted + up. journalctl and + systemd-journald ignore all files with + names not ending with .journal or + .journal~, so only such files, located in + the appropriate directories, are taken into account when + calculating current disk usage. + + SystemMaxUse= and + RuntimeMaxUse= control how much disk space + the journal may use up at most. + SystemKeepFree= and + RuntimeKeepFree= control how much disk + space systemd-journald shall leave free for other uses. + systemd-journald will respect both limits + and use the smaller of the two values. + + The first pair defaults to 10% and the second to 15% of + the size of the respective file system, but each value is + capped to 4G. If the file system is nearly full and either + SystemKeepFree= or + RuntimeKeepFree= are violated when + systemd-journald is started, the limit will be raised to the + percentage that is actually free. This means that if there was + enough free space before and journal files were created, and + subsequently something else causes the file system to fill up, + journald will stop using more space, but it will not be + removing existing files to reduce the footprint again, + either. Also note that only archived files are deleted to reduce the + space occupied by journal files. This means that, in effect, there might + still be more space used than SystemMaxUse= or + RuntimeMaxUse= limit after a vacuuming operation is + complete. + + SystemMaxFileSize= and RuntimeMaxFileSize= control how + large individual journal files may grow at most. This influences the granularity in which disk space + is made available through rotation, i.e. deletion of historic data. Defaults to one eighth of the + values configured with SystemMaxUse= and RuntimeMaxUse= capped + to 128M, so that usually seven rotated journal files are kept as history. If the journal compact + mode is enabled (enabled by default), the maximum file size is capped to 4G. + + Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to + 1024, 1024², … bytes). Note that size limits are enforced synchronously when journal files are + extended, and no explicit rotation step triggered by time is needed. + + SystemMaxFiles= and + RuntimeMaxFiles= control how many + individual journal files to keep at most. Note that only + archived files are deleted to reduce the number of files until + this limit is reached; active files will stay around. This + means that, in effect, there might still be more journal files + around in total than this limit after a vacuuming operation is + complete. This setting defaults to 100. + + + + MaxFileSec= + + The maximum time to store entries in a single + journal file before rotating to the next one. Normally, + time-based rotation should not be required as size-based + rotation with options such as + SystemMaxFileSize= should be sufficient to + ensure that journal files do not grow without bounds. However, + to ensure that not too much data is lost at once when old + journal files are deleted, it might make sense to change this + value from the default of one month. Set to 0 to turn off this + feature. This setting takes time values which may be suffixed + with the units year, + month, week, + day, h or + m to override the default time unit of + seconds. + + + + MaxRetentionSec= + + The maximum time to store journal entries. + This controls whether journal files containing entries older + than the specified time span are deleted. Normally, time-based + deletion of old journal files should not be required as + size-based deletion with options such as + SystemMaxUse= should be sufficient to + ensure that journal files do not grow without bounds. However, + to enforce data retention policies, it might make sense to + change this value from the default of 0 (which turns off this + feature). This setting also takes time values which may be + suffixed with the units year, + month, week, + day, h or + m to override the default time unit of + seconds. + + + + SyncIntervalSec= + + The timeout before synchronizing journal files + to disk. After syncing, journal files are placed in the + OFFLINE state. Note that syncing is unconditionally done + immediately after a log message of priority CRIT, ALERT or + EMERG has been logged. This setting hence applies only to + messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The + default timeout is 5 minutes. + + + + ForwardToSyslog= + ForwardToKMsg= + ForwardToConsole= + ForwardToWall= + + Control whether log messages received by the journal daemon shall be forwarded to a + traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall + messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is + enabled but nothing reads messages from the socket, forwarding to syslog has no effect. By default, + only forwarding to wall is enabled. These settings may be overridden at boot time with the kernel + command line options systemd.journald.forward_to_syslog, + systemd.journald.forward_to_kmsg, + systemd.journald.forward_to_console, and + systemd.journald.forward_to_wall. If the option name is specified without + = and the following argument, true is assumed. Otherwise, the argument is parsed + as a boolean. + + When forwarding to the console, the TTY to log to can be changed with + TTYPath=, described below. + + When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for + the log buffer, for example by adding log_buf_len=8M to the kernel command line. + systemd will automatically disable kernel's rate-limiting applied to userspace + processes (equivalent to setting printk.devkmsg=on). + + Note: Forwarding is performed synchronously within journald, and may significantly affect its + performance. This is particularly relevant when using ForwardToConsole=yes in cloud environments, + where the console is often a slow, virtual serial port. Since journald is implemented as a + conventional single-process daemon, forwarding to a completely hung console will block journald. + This can have a cascading effect resulting in any services synchronously logging to the blocked + journal also becoming blocked. Unless actively debugging/developing something, it's generally + preferable to setup a journalctl --follow style service redirected to the + console, instead of ForwardToConsole=yes, for production use. + + + + MaxLevelStore= + MaxLevelSyslog= + MaxLevelKMsg= + MaxLevelConsole= + MaxLevelWall= + + Controls the maximum log level of messages + that are stored in the journal, forwarded to syslog, kmsg, the + console or wall (if that is enabled, see above). As argument, + takes one of + emerg, + alert, + crit, + err, + warning, + notice, + info, + debug, + or integer values in the range of 0–7 (corresponding to the + same levels). Messages equal or below the log level specified + are stored/forwarded, messages above are dropped. Defaults to + debug for MaxLevelStore= + and MaxLevelSyslog=, to ensure that the all + messages are stored in the journal and forwarded to syslog. + Defaults to + notice for MaxLevelKMsg=, + info for MaxLevelConsole=, + and emerg for + MaxLevelWall=. These settings may be + overridden at boot time with the kernel command line options + systemd.journald.max_level_store=, + systemd.journald.max_level_syslog=, + systemd.journald.max_level_kmsg=, + systemd.journald.max_level_console=, + systemd.journald.max_level_wall=. + + + + + ReadKMsg= + + Takes a boolean value. If enabled systemd-journal processes + /dev/kmsg messages generated by the kernel. In the default journal namespace + this option is enabled by default, it is disabled in all others. + + + + Audit= + + Takes a boolean value. If enabled systemd-journal will turn on + kernel auditing on start-up. If disabled it will turn it off. If unset it will neither enable nor + disable it, leaving the previous state unchanged. Note that this option does not control whether + systemd-journald collects generated audit records, it just controls whether it + tells the kernel to generate them. This means if another tool turns on auditing even if + systemd-journald left it off, it will still collect the generated + messages. Defaults to on. + + + + TTYPath= + + Change the console TTY to use if + ForwardToConsole=yes is used. Defaults to + /dev/console. + + + + LineMax= + + The maximum line length to permit when converting stream logs into record logs. When a systemd + unit's standard output/error are connected to the journal via a stream socket, the data read is split into + individual log records at newline (\n, ASCII 10) and NUL characters. If no such delimiter is + read for the specified number of bytes a hard log record boundary is artificially inserted, breaking up overly + long lines into multiple log records. Selecting overly large values increases the possible memory usage of the + Journal daemon for each stream client, as in the worst case the journal daemon needs to buffer the specified + number of bytes in memory before it can flush a new log record to disk. Also note that permitting overly large + line maximum line lengths affects compatibility with traditional log protocols as log records might not fit + anymore into a single AF_UNIX or AF_INET datagram. Takes a size in + bytes. If the value is suffixed with K, M, G or T, the specified size is parsed as Kilobytes, Megabytes, + Gigabytes, or Terabytes (with the base 1024), respectively. Defaults to 48K, which is relatively large but + still small enough so that log records likely fit into network datagrams along with extra room for + metadata. Note that values below 79 are not accepted and will be bumped to 79. + + + + + + + + Forwarding to traditional syslog daemons + + + Journal events can be transferred to a different logging daemon + in two different ways. With the first method, messages are + immediately forwarded to a socket + (/run/systemd/journal/syslog), where the + traditional syslog daemon can read them. This method is + controlled by the ForwardToSyslog= option. With a + second method, a syslog daemon behaves like a normal journal + client, and reads messages from the journal files, similarly to + journalctl1. + With this, messages do not have to be read immediately, + which allows a logging daemon which is only started late in boot + to access all messages since the start of the system. In + addition, full structured meta-data is available to it. This + method of course is available only if the messages are stored in + a journal file at all. So it will not work if + Storage=none is set. It should be noted that + usually the second method is used by syslog + daemons, so the Storage= option, and not the + ForwardToSyslog= option, is relevant for them. + + + + + See Also + + systemd1, + systemd-journald.service8, + journalctl1, + systemd.journal-fields7, + systemd-system.conf5 + + + + diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml new file mode 100644 index 0000000..2e60beb --- /dev/null +++ b/man/kernel-command-line.xml @@ -0,0 +1,602 @@ + + + + + + + + kernel-command-line + systemd + + + + kernel-command-line + 7 + + + + kernel-command-line + Kernel command line parameters + + + + /proc/cmdline + + + + Description + + The kernel, the programs running in the initrd and in the host system may be configured at boot via + kernel command line arguments. In addition, various systemd tools look at the EFI variable + SystemdOptions (if available). Both sources are combined, but the kernel command line + has higher priority. Please note that the EFI variable is only used by systemd tools, and is + ignored by the kernel and other user space tools, so it is not a replacement for the kernel + command line. + + For command line parameters understood by the kernel, please + see + kernel-parameters.html + and + bootparam7. + + For command line parameters understood by the initrd, see + dracut.cmdline7, + or the documentation of the specific initrd implementation of your + installation. + + + + Core OS Command Line Arguments + + + + systemd.unit= + rd.systemd.unit= + systemd.dump_core + systemd.crash_chvt + systemd.crash_shell + systemd.crash_reboot + systemd.confirm_spawn + systemd.service_watchdogs + systemd.show_status + systemd.status_unit_format= + systemd.log_target= + systemd.log_level= + systemd.log_location= + systemd.log_color + systemd.default_standard_output= + systemd.default_standard_error= + systemd.setenv= + systemd.machine_id= + systemd.set_credential= + systemd.import_credentials= + + Parameters understood by the system and service + manager to control system behavior. For details, see + systemd1. + + + + + systemd.mask= + systemd.wants= + systemd.debug_shell + + Additional parameters understood by + systemd-debug-generator8, + to mask or start specific units at boot, or invoke a debug + shell on tty9. + + + + + systemd.run= + systemd.run_success_action= + systemd.run_failure_action= + + Additional parameters understood by + systemd-run-generator8, to + run a command line specified on the kernel command line as system service after booting up. + + + + + systemd.early_core_pattern= + + During early boot, the generation of core dump files is disabled until a core dump handler (if any) + takes over. This parameter allows specifying an absolute path where core dump files should be stored until + a handler is installed. The path should be absolute and may contain specifiers, see + core5 for details. + + + + + systemd.restore_state= + + This parameter is understood by several system tools + to control whether or not they should restore system state + from the previous boot. For details, see + systemd-backlight@.service8 + and + systemd-rfkill.service8. + + + + + + systemd.volatile= + + This parameter controls whether the system shall boot up in volatile mode. Takes a boolean argument, or + the special value state. If false (the default), normal boot mode is selected, the root + directory and /var/ are mounted as specified on the kernel command line or + /etc/fstab, or otherwise configured. If true, full state-less boot mode is selected. In + this case the root directory is mounted as volatile memory file system (tmpfs), and only + /usr/ is mounted from the file system configured as root device, in read-only mode. This + enables fully state-less boots were the vendor-supplied OS is used as shipped, with only default + configuration and no stored state in effect, as /etc/ and /var/ (as + well as all other resources shipped in the root file system) are reset at boot and lost on shutdown. If this + setting is set to state the root file system is mounted read-only, however + /var/ is mounted as a volatile memory file system (tmpfs), so that the + system boots up with the normal configuration applied, but all state reset at boot and lost at shutdown. If + this setting is set to overlay the root file system is set up as + overlayfs mount combining the read-only root directory with a writable + tmpfs, so that no modifications are made to disk, but the file system may be modified + nonetheless with all changes being lost at reboot. For details, see + systemd-volatile-root.service8 + and + systemd-fstab-generator8. + + + + + quiet + + Parameter understood by both the kernel and the system + and service manager to control console log verbosity. For + details, see + systemd1. + + + + + debug + + Parameter understood by both the kernel and the system + and service manager to control console log verbosity. For + details, see + systemd1. + + + + + -b + rd.emergency + emergency + rd.rescue + rescue + single + s + S + 1 + 2 + 3 + 4 + 5 + + Parameters understood by the system and service + manager, as compatibility and convenience options. For details, see + systemd1. + + + + + locale.LANG= + locale.LANGUAGE= + locale.LC_CTYPE= + locale.LC_NUMERIC= + locale.LC_TIME= + locale.LC_COLLATE= + locale.LC_MONETARY= + locale.LC_MESSAGES= + locale.LC_PAPER= + locale.LC_NAME= + locale.LC_ADDRESS= + locale.LC_TELEPHONE= + locale.LC_MEASUREMENT= + locale.LC_IDENTIFICATION= + + Parameters understood by the system and service + manager to control locale and language settings. For + details, see + systemd1. + + + + + fsck.mode= + fsck.repair= + + + Parameters understood by the file system checker + services. For details, see + systemd-fsck@.service8. + + + + + quotacheck.mode= + + + Parameter understood by the file quota checker + service. For details, see + systemd-quotacheck.service8. + + + + + systemd.journald.forward_to_syslog= + systemd.journald.forward_to_kmsg= + systemd.journald.forward_to_console= + systemd.journald.forward_to_wall= + + + Parameters understood by the journal service. For + details, see + systemd-journald.service8. + + + + + vconsole.keymap= + vconsole.keymap_toggle= + vconsole.font= + vconsole.font_map= + vconsole.font_unimap= + + + Parameters understood by the virtual console setup logic. For details, see + vconsole.conf5. + + + + + udev.log_level= + rd.udev.log_level= + udev.children_max= + rd.udev.children_max= + udev.exec_delay= + rd.udev.exec_delay= + udev.event_timeout= + rd.udev.event_timeout= + udev.timeout_signal= + rd.udev.timeout_signal= + udev.blockdev_read_only + rd.udev.blockdev_read_only + net.ifnames= + net.naming-scheme= + + + Parameters understood by the device event managing + daemon. For details, see + systemd-udevd.service8. + + + + + plymouth.enable= + + + May be used to disable the Plymouth boot splash. For + details, see + plymouth8. + + + + + luks= + rd.luks= + luks.crypttab= + rd.luks.crypttab= + luks.name= + rd.luks.name= + luks.uuid= + rd.luks.uuid= + luks.options= + rd.luks.options= + luks.key= + rd.luks.key= + + + Configures the LUKS full-disk encryption logic at + boot. For details, see + systemd-cryptsetup-generator8. + + + + + fstab= + rd.fstab= + + + Configures the /etc/fstab logic + at boot. For details, see + systemd-fstab-generator8. + + + + + root= + rootfstype= + rootflags= + ro + rw + + + Configures the root file system and its file system + type and mount options, as well as whether it shall be + mounted read-only or read-write initially. For details, + see + systemd-fstab-generator8. + + + + + mount.usr= + mount.usrfstype= + mount.usrflags= + + + Configures the /usr file system (if required) and + its file system type and mount options. For details, see + systemd-fstab-generator8. + + + + + veritytab= + rd.veritytab= + roothash= + systemd.verity= + rd.systemd.verity= + systemd.verity_root_data= + systemd.verity_root_hash= + systemd.verity.root_options= + usrhash= + systemd.verity_usr_data= + systemd.verity_usr_hash= + systemd.verity_usr_options= + + Configures the integrity protection root hash for the root and /usr file systems, and other related + parameters. For details, see + systemd-veritysetup-generator8. + + + + + systemd.getty_auto= + + + Configures whether the serial-getty@.service will run. + For details, see + systemd-getty-generator8. + + + + + systemd.gpt_auto= + rd.systemd.gpt_auto= + + + Configures whether GPT based partition auto-discovery + shall be attempted. For details, see + systemd-gpt-auto-generator8. + + + + + systemd.default_timeout_start_sec= + + + Overrides the default start job timeout DefaultTimeoutStartSec= at + boot. For details, see + systemd-system.conf5. + + + + + systemd.watchdog_device= + + + Overrides the watchdog device path WatchdogDevice=. For details, see + systemd-system.conf5. + + + + + systemd.watchdog_sec= + + + Overrides the watchdog timeout settings otherwise configured with + RuntimeWatchdog=, RebootWatchdog= and + KExecWatchdogSec=. Takes a time value (if no unit is specified, seconds is the + implicitly assumed time unit) or the special strings off or + default. For details, see + systemd-system.conf5. + + + + + systemd.watchdog_pre_sec= + + + Overrides the watchdog pre-timeout settings otherwise configured with + RuntimeWatchdogPreSec=. Takes a time value (if no unit is specified, seconds is the + implicitly assumed time unit) or the special strings off or + default. For details, see + systemd-system.conf5. + + + + + systemd.watchdog_pretimeout_governor= + + + Overrides the watchdog pre-timeout settings otherwise configured with + RuntimeWatchdogPreGovernor=. Takes a string value. For details, see + systemd-system.conf5. + + + + + systemd.cpu_affinity= + + + Overrides the CPU affinity mask for the service manager and the default for all child + processes it forks. This takes precedence over CPUAffinity=, see + systemd-system.conf5 + for details. + + + + + modules_load= + rd.modules_load= + + + Load a specific kernel module early at boot. For + details, see + systemd-modules-load.service8. + + + + + resume= + resumeflags= + + + Enables resume from hibernation using the specified + device and mount options. All + fstab5-like + paths are supported. For details, see + systemd-hibernate-resume-generator8. + + + + + systemd.firstboot= + + Takes a boolean argument, defaults to on. If off, + systemd-firstboot.service8 + will not query the user for basic system settings, even if the system boots up for the first time and + the relevant settings are not initialized yet. Not to be confused with + systemd.condition-first-boot= (see below), which overrides the result of the + ConditionFirstBoot= unit file condition, and thus controls more than just + systemd-firstboot.service behaviour. + + + + systemd.condition-needs-update= + + Takes a boolean argument. If specified, overrides the result of + ConditionNeedsUpdate= unit condition checks. See + systemd.unit5 for + details. + + + + systemd.condition-first-boot= + + Takes a boolean argument. If specified, overrides the result of + ConditionFirstBoot= unit condition checks. See + systemd.unit5 for + details. Not to be confused with systemd.firstboot= which only controls behaviour + of the systemd-firstboot.service system service but has no effect on the + condition check (see above). + + + + systemd.clock-usec= + + Takes a decimal, numeric timestamp in µs since January 1st 1970, 00:00am, to set the + system clock to. The system time is set to the specified timestamp early during boot. It is not + propagated to the hardware clock (RTC). + + + + systemd.random-seed= + + Takes a base64 encoded random seed value to credit with full entropy to the kernel's + random pool during early service manager initialization. This option is useful in testing + environments where delays due to random pool initialization in entropy starved virtual machines shall + be avoided. + + Note that if this option is used the seed is accessible to unprivileged programs from + /proc/cmdline. This option is hence a security risk when used outside of test + systems, since the (possibly) only seed used for initialization of the kernel's entropy pool might be + easily acquired by unprivileged programs. + + It is recommended to pass 512 bytes of randomized data (as that matches the Linux kernel pool + size), which may be generated with a command like the following: + + dd if=/dev/urandom bs=512 count=1 status=none | base64 -w 0 + + Again: do not use this option outside of testing environments, it's a security risk elsewhere, + as secret key material derived from the entropy pool can possibly be reconstructed by unprivileged + programs. + + + + + systemd.hostname= + + Accepts a hostname to set during early boot. If specified takes precedence over what + is set in /etc/hostname. Note that this does not bar later runtime changes to + the hostname, it simply controls the initial hostname set during early boot. + + + + + + History + + + + systemd 252 + Kernel command-line arguments systemd.unified_cgroup_hierarchy + and systemd.legacy_systemd_cgroup_controller were deprecated. Please switch to + the unified cgroup hierarchy. + + + + + + See Also + + systemd1, + systemd-system.conf5, + bootparam7, + dracut.cmdline7, + systemd-debug-generator8, + systemd-fsck@.service8, + systemd-quotacheck.service8, + systemd-journald.service8, + systemd-vconsole-setup.service8, + systemd-udevd.service8, + plymouth8, + systemd-cryptsetup-generator8, + systemd-veritysetup-generator8, + systemd-fstab-generator8, + systemd-getty-generator8, + systemd-gpt-auto-generator8, + systemd-volatile-root.service8, + systemd-modules-load.service8, + systemd-backlight@.service8, + systemd-rfkill.service8, + systemd-hibernate-resume-generator8, + systemd-firstboot.service8, + bootctl1 + + + + diff --git a/man/kernel-install.xml b/man/kernel-install.xml new file mode 100644 index 0000000..b8ea2b1 --- /dev/null +++ b/man/kernel-install.xml @@ -0,0 +1,392 @@ + + + + + + + + kernel-install + systemd + + + + kernel-install + 8 + + + + kernel-install + Add and remove kernel and initrd images to and from /boot + + + + + kernel-install + OPTIONS + COMMAND + KERNEL-VERSION + KERNEL-IMAGE + INITRD-FILE + + + + + Description + kernel-install is used to install and remove kernel and initrd images + + Nowadays actually CPIO archives used as an "initramfs", rather than "initrd". See + bootup7 for an + explanation. + + to and from the boot loader partition, referred to as $BOOT here. It will usually be + one of /boot/, /efi/, or /boot/efi/, see + below. + + kernel-install will run the executable files ("plugins") located in the + directory /usr/lib/kernel/install.d/ and the local administration directory + /etc/kernel/install.d/. All files are collectively sorted and executed in lexical + order, regardless of the directory in which they live. However, files with identical filenames replace + each other. Files in /etc/kernel/install.d/ take precedence over files with the + same name in /usr/lib/kernel/install.d/. This can be used to override a + system-supplied executables with a local file if needed; a symbolic link in + /etc/kernel/install.d/ with the same name as an executable in + /usr/lib/kernel/install.d/, pointing to /dev/null, disables the + executable entirely. Executables must have the extension .install; other extensions + are ignored. + + An executable placed in these directories should return 0 on success. It may + also return 77 to cause the whole operation to terminate (executables later in + lexical order will be skipped). + + + + Commands + The following commands are understood: + + + add KERNEL-VERSION KERNEL-IMAGE [INITRD-FILE ...] + + This command expects a kernel version string and a path to a kernel image file as arguments. + Optionally, one or more initrd images may be specified as well (note that plugins might generate + additional ones). kernel-install calls the executable files from + /usr/lib/kernel/install.d/*.install and + /etc/kernel/install.d/*.install (i.e. the plugins) with the following + arguments: + + add KERNEL-VERSION $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ KERNEL-IMAGE [INITRD-FILE ...] + + The third argument directly refers to the path where to place kernel images, initrd + images and other resources for Boot + Loader Specification Type #1 entries (the "entry directory"). If other boot loader schemes + are used the parameter may be ignored. The ENTRY-TOKEN string is + typically the machine ID and is supposed to identify the local installation on the system. For + details see below. + + Two default plugins execute the following operations in this case: + + + kernel-install creates + $BOOT/ENTRY-TOKEN/KERNEL-VERSION, + if enabled (see $KERNEL_INSTALL_LAYOUT). + + 50-depmod.install runs + depmod8 for the + KERNEL-VERSION. + + 90-loaderentry.install copies + KERNEL-IMAGE to + $BOOT/ENTRY-TOKEN/KERNEL-VERSION/linux. + If INITRD-FILEs are provided, it also copies them to + $BOOT/ENTRY-TOKEN/KERNEL_VERSION/INITRD-FILE. + It also creates a boot loader entry according to the Boot Loader Specification (Type #1) in + $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION.conf. + The title of the entry is the PRETTY_NAME parameter specified in + /etc/os-release or /usr/lib/os-release (if the former + is missing), or "Linux KERNEL-VERSION", if unset. + + If $KERNEL_INSTALL_LAYOUT is not "bls", this plugin does nothing. + + + + + remove KERNEL-VERSION + + This command expects a kernel version string as single argument. This calls executables from + /usr/lib/kernel/install.d/*.install and + /etc/kernel/install.d/*.install with the following arguments: + + + remove KERNEL-VERSION $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ + + Afterwards, kernel-install removes the entry directory + $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ + and its contents, if it exists. + + Two default plugins execute the following operations in this case: + + + 50-depmod.install removes the files generated by depmod for this kernel again. + + 90-loaderentry.install removes the file + $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION.conf. + + + + + inspect + + Shows the various paths and parameters configured or auto-detected. In particular shows the + values of the various $KERNEL_INSTALL_* environment variables listed + below. + + + + + + + + The <varname>$BOOT</varname> partition + + The partition where the kernels and Boot + Loader Specification snippets are located is called $BOOT. + kernel-install determines the location of this partition by checking + /efi/, /boot/, and /boot/efi/ in turn. The + first location where $BOOT/loader/entries/ or + $BOOT/ENTRY-TOKEN/ exists is used. + + + + Options + The following options are understood: + + + + + + + Output additional information about operations being performed. + + + + + + + + + + Environment variables + + + Environment variables exported for plugins + + If is used, $KERNEL_INSTALL_VERBOSE=1 will be + exported for plugins. They may output additional logs in this case. + + $KERNEL_INSTALL_MACHINE_ID is set for the plugins to the desired machine-id to + use. It's always a 128-bit ID. Normally it's read from /etc/machine-id, but it can + also be overridden via $MACHINE_ID (see below). If not specified via these methods a + fallback value will generated by kernel-install, and used only for a single + invocation. + + $KERNEL_INSTALL_ENTRY_TOKEN is set for the plugins to the desired entry + "token" to use. It's an identifier that shall be used to identify the local installation, and is often + the machine ID, i.e. same as $KERNEL_INSTALL_MACHINE_ID, but might also be a + different type of identifier, for example a fixed string or the ID=, + IMAGE_ID= values from /etc/os-release. The string passed here + will be used to name Boot Loader Specification entries, or the directories the kernel image and initial + RAM disk images are placed into. + + Note that while $KERNEL_INSTALL_ENTRY_TOKEN and + $KERNEL_INSTALL_MACHINE_ID are often set to the same value, the latter is guaranteed + to be a valid 32 character ID in lowercase hexadecimals while the former can be any short string. The + entry token to use is read from /etc/kernel/entry-token, if it exists. Otherwise a + few possible candidates below $BOOT are checked for Boot Loader Specification Type 1 + entry directories, and if found the entry token is derived from that. If that is not successful, + $KERNEL_INSTALL_MACHINE_ID is used as fallback. + + $KERNEL_INSTALL_BOOT_ROOT is set for the plugins to the absolute path of the + root directory (mount point, usually) of the hierarchy where boot loader entries, kernel images, and + associated resources should be placed. This usually is the path where the XBOOTLDR partition or the ESP + (EFI System Partition) are mounted, and also conceptually referred to as $BOOT. Can + be overridden by setting $BOOT_ROOT (see below). + + $KERNEL_INSTALL_LAYOUT=bls|other|... is set for the plugins to specify the + installation layout. Defaults to if + $BOOT/ENTRY-TOKEN exists, or + otherwise. Additional layout names may be defined by convention. If a plugin uses a special layout, + it's encouraged to declare its own layout name and configure layout= in + install.conf upon initial installation. The following values are currently + understood: + + + + bls + + Standard Boot Loader + Specification Type #1 layout, compatible with + systemd-boot7: + entries in + $BOOT/loader/entries/ENTRY-TOKEN-KERNEL-VERSION[+TRIES].conf, + kernel and initrds under + $BOOT/ENTRY-TOKEN/KERNEL-VERSION/ + Implemented by 90-loaderentry.install. + + + + other + + Some other layout not understood natively by kernel-install. + + + + + $KERNEL_INSTALL_INITRD_GENERATOR is set for plugins to select the initrd + generator. This may be configured as initrd_generator= in + install.conf, see below. + + $KERNEL_INSTALL_STAGING_AREA is set for plugins to a path to a directory. + Plugins may drop files in that directory, and they will be installed as part of the loader entry, based + on the file name and extension. + + + + Environment variables understood by <command>kernel-install</command> + + $KERNEL_INSTALL_CONF_ROOT can be set to override the location of the + configuration files read by kernel-install. When set, + install.conf, entry-token, and other files will be + read from this directory. + + $KERNEL_INSTALL_PLUGINS can be set to override the list of plugins executed by + kernel-install. The argument is a whitespace-separated list of paths. + KERNEL_INSTALL_PLUGINS=: may be used to prevent any plugins from running. + + + $MACHINE_ID can be set for kernel-install to override + $KERNEL_INSTALL_MACHINE_ID, the machine ID. + + $BOOT_ROOT can be set for kernel-install to override + $KERNEL_INSTALL_BOOT_ROOT, the installation location for boot entries. + + The last two variables may also be set in install.conf. Variables set in the + environment take precedence over the values specified in the config file. + + + + + Exit status + If every executable returns 0 or 77, 0 is returned, and a non-zero failure code otherwise. + + + + Files + + + + /usr/lib/kernel/install.d/*.install + /etc/kernel/install.d/*.install + + + Drop-in files which are executed by kernel-install. + + + + + /usr/lib/kernel/cmdline + /etc/kernel/cmdline + /proc/cmdline + + + Read by 90-loaderentry.install. The content of the file + /etc/kernel/cmdline specifies the kernel command line to use. If that file + does not exist, /usr/lib/kernel/cmdline is used. If that also does not + exist, /proc/cmdline is used. $KERNEL_INSTALL_CONF_ROOT + may be used to override the path. + + + + + /etc/kernel/tries + + + Read by 90-loaderentry.install. If this file exists a numeric value is read from + it and the naming of the generated entry file is slightly altered to include it as + $BOOT/loader/entries/MACHINE-ID-KERNEL-VERSION+TRIES.conf. This + is useful for boot loaders such as + systemd-boot7 which + implement boot attempt counting with a counter embedded in the entry file name. + $KERNEL_INSTALL_CONF_ROOT may be used to override the path. + + + + + /etc/kernel/entry-token + + + If this file exists it is read and used as "entry token" for this system, i.e. is used for + naming Boot Loader Specification entries, see $KERNEL_INSTALL_ENTRY_TOKEN + above for details. $KERNEL_INSTALL_CONF_ROOT may be used to override the + path. + + + + + /etc/machine-id + + + The content of this file specifies the machine identification + MACHINE-ID. + + + + + /etc/os-release + /usr/lib/os-release + + + Read by 90-loaderentry.install. + If available, PRETTY_NAME= is read from these files and used as the title of the boot menu entry. + Otherwise, Linux KERNEL-VERSION will be used. + + + + + /usr/lib/kernel/install.conf + /etc/kernel/install.conf + + + Configuration options for kernel-install, as a series of + KEY=VALUE assignments, compatible with shell + syntax, following the same rules as described in + os-release5. + /etc/kernel/install.conf will be read if present, and + /usr/lib/kernel/install.conf otherwise. This file is optional. + $KERNEL_INSTALL_CONF_ROOT may be used to override the path. + + + Currently, the following keys are supported: + MACHINE_ID=, + BOOT_ROOT=, + layout=, + initrd_generator=. + See the Environment variables section above for details. + + + + + + + See Also + + machine-id5, + os-release5, + depmod8, + systemd-boot7, + Boot Loader Specification + + + + diff --git a/man/libsystemd-pkgconfig.xml b/man/libsystemd-pkgconfig.xml new file mode 100644 index 0000000..e3b0634 --- /dev/null +++ b/man/libsystemd-pkgconfig.xml @@ -0,0 +1,13 @@ + + + + + + Notes + + These APIs are implemented as a shared + library, which can be compiled and linked to with the + libsystemd pkg-config1 + file. + diff --git a/man/libudev.xml b/man/libudev.xml new file mode 100644 index 0000000..8632ea9 --- /dev/null +++ b/man/libudev.xml @@ -0,0 +1,98 @@ + + +%entities; +]> + + + + + + libudev + systemd + + + + libudev + 3 + + + + libudev + API for enumerating and introspecting local devices + + + + + #include <libudev.h> + + + + pkg-config --cflags --libs libudev + + + + + Description + + libudev.h provides an API to introspect and enumerate devices on the local + system. This library is supported, but should not be used in new projects. Please see + sd-device3 for an + equivalent replacement with a more modern API. + + All functions require a libudev context to operate. This + context can be create via + udev_new3. + It is used to track library state and link objects together. No + global state is used by libudev, everything is always linked to + a udev context. + + + + To introspect a local device on a system, a udev device + object can be created via + udev_device_new_from_syspath3 + and friends. The device object allows one to query current state, + read and write attributes and lookup properties of the device in + question. + + To enumerate local devices on the system, an enumeration + object can be created via + udev_enumerate_new3. + + To monitor the local system for hotplugged or unplugged + devices, a monitor can be created via + udev_monitor_new_from_netlink3. + + Whenever libudev returns a list of objects, the + udev_list_entry3 + API should be used to iterate, access and modify those lists. + + Furthermore, libudev also exports legacy APIs that should + not be used by new software (and as such are not documented as + part of this manual). This includes the hardware database known + as udev_hwdb (please use the new + sd-hwdb3 + API instead) and the udev_queue object to + query the udev daemon (which should not be used by new software + at all). + + + + See Also + + udev_new3, + udev_device_new_from_syspath3, + udev_enumerate_new3, + udev_monitor_new_from_netlink3, + udev_list_entry3, + systemd1, + sd-device3, + sd-hwdb3, + pkg-config1 + + + + diff --git a/man/loader.conf.xml b/man/loader.conf.xml new file mode 100644 index 0000000..6dfb6c0 --- /dev/null +++ b/man/loader.conf.xml @@ -0,0 +1,359 @@ + + + + + + + loader.conf + systemd + + + + loader.conf + 5 + + + + loader.conf + Configuration file for systemd-boot + + + + ESP/loader/loader.conf, + ESP/loader/entries/*.conf + XBOOTLDR/loader/entries/*.conf + + + + + Description + + + systemd-boot7 will + read ESP/loader/loader.conf, and any files with the + .conf extension under + ESP/loader/entries/ on the EFI system partition (ESP), + and XBOOTLDR/loader/entries/ on the extended boot loader + partition (XBOOTLDR) as defined by Boot Loader + Specification. + + + Each of these configuration files must consist of series of newline (i.e. ASCII code 10) separated + lines, each consisting of an option name, followed by whitespace, and the option + value. # may be used to start a comment line. Empty and comment lines are ignored. The + files use UTF-8 encoding. + + Boolean arguments may be written as + yes/y/true/t/on/1 or + no/n/false/f/off/0. + + + + + Options + + The configuration options supported by + ESP/loader/entries/*.conf and + XBOOTLDR/loader/entries/*.conf files are defined as part + of the Boot Loader + Specification. + + The following configuration are supported by the loader.conf configuration + file: + + + + default + + A glob pattern to select the default entry. The default entry + may be changed in the boot menu itself, in which case the name of the + selected entry will be stored as an EFI variable, overriding this option. + + + If set to @saved the chosen entry will be saved as an EFI variable + on every boot and automatically selected the next time the boot loader starts. + + + Automatically detected entries will use the following names: + + + + + + + Name + Description + + + + + auto-efi-default + EFI Default Loader + + + auto-efi-shell + EFI Shell + + + auto-osx + macOS + + + auto-reboot-to-firmware-setup + Reboot Into Firmware Interface + + + auto-windows + Windows Boot Manager + + + +
+ + Supported glob wildcard patterns are ?, *, and + […] (including ranges). Note that these patterns use the same syntax as + glob7, + but do not support all features. In particular, set negation and named character classes are not + supported. The matching is done case-insensitively on the entry ID (as shown by bootctl + list). + + + + timeout + + How long the boot menu should be shown before the default + entry is booted, in seconds. This may be changed in the boot menu itself and + will be stored as an EFI variable in that case, overriding this option. + + + If set to menu-hidden or 0 (the default) no menu + is shown and the default entry will be booted immediately. The menu can be shown + by pressing and holding a key before systemd-boot is launched. Setting this to + menu-force disables the timeout while always showing the menu. + + + + + console-mode + + This option configures the resolution of the console. Takes a + number or one of the special values listed below. The following values may be + used: + + + + 0 + + Standard UEFI 80x25 mode + + + + + 1 + + 80x50 mode, not supported by all devices + + + + + 2 + + the first non-standard mode provided by the device + firmware, if any + + + + + auto + + Pick a suitable mode automatically using heuristics + + + + + max + + Pick the highest-numbered available mode + + + + + keep + + Keep the mode selected by firmware (the default) + + + + + + + + + editor + + Takes a boolean argument. Enable (the default) or disable the + editor. The editor should be disabled if the machine can be accessed by + unauthorized persons. + + + + auto-entries + + Takes a boolean argument. Enable (the default) or disable + entries for other boot entries found on the boot partition. In particular, + this may be useful when loader entries are created to show replacement + descriptions for those entries. + + + + auto-firmware + + A boolean controlling the presence of the "Reboot into firmware" entry + (enabled by default). If this is disabled, the firmware interface may still be reached + by using the f key. + + + + beep + + Takes a boolean argument. If timeout enabled beep every second, otherwise beep n times when n-th entry in boot menu is selected (default disabled). + Currently, only x86 is supported, where it uses the PC speaker. + + + + secure-boot-enroll + + Danger: this feature might soft-brick your device if used improperly. + + Takes one of off, manual or force. + Controls the enrollment of secure boot keys. If set to off, no action whatsoever + is taken. If set to manual (the default) and the UEFI firmware is in setup-mode + then entries to manually enroll Secure Boot variables are created in the boot menu. If set to + force, in addition, if a directory named /loader/keys/auto/ + exists on the ESP then the keys in that directory are enrolled automatically. + + The different sets of variables can be set up under /loader/keys/NAME + where NAME is the name that is going to be used as the name of the entry. + This allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime. + + Supported secure boot variables are one database for authorized images, one key exchange key (KEK) + and one platform key (PK). For more information, refer to the UEFI specification, + under Secure Boot and Driver Signing. Another resource that describe the interplay of the different variables is the + + EDK2 documentation. + + A complete set of UEFI variable includes db.auth, KEK.auth + and PK.auth. Note that these files need to be authenticated UEFI variables. See + below for an example of how to generate them from regular X.509 keys. + + uuid=$(systemd-id128 new --uuid) +for key in PK KEK db; do + openssl req -new -x509 -subj "/CN=${key}/" -keyout "${key}.key" -out "${key}.crt" + openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer" + cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.esl" +done + +for key in MicWinProPCA2011_2011-10-19.crt MicCorUEFCA2011_2011-06-27.crt MicCorKEKCA2011_2011-06-24.crt; do + curl "https://www.microsoft.com/pkiops/certs/${key}" --output "${key}" + sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output "${key%crt}esl" "${key}" +done + +# Optionally add Microsoft Windows Production CA 2011 (needed to boot into Windows). +cat MicWinProPCA2011_2011-10-19.esl >> db.esl + +# Optionally add Microsoft Corporation UEFI CA 2011 (for firmware drivers / option ROMs +# and third-party boot loaders (including shim). This is highly recommended on real +# hardware as not including this may soft-brick your device (see next paragraph). +cat MicCorUEFCA2011_2011-06-27.esl >> db.esl + +# Optionally add Microsoft Corporation KEK CA 2011. Recommended if either of the +# Microsoft keys is used as the official UEFI revocation database is signed with this +# key. The revocation database can be updated with fwupdmgr1. +cat MicCorKEKCA2011_2011-06-24.esl >> KEK.esl + +sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth +sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth +sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth + + + This feature is considered dangerous because even if all the required files are signed with the + keys being loaded, some files necessary for the system to function properly still won't be. This + is especially the case with Option ROMs (e.g. for storage controllers or graphics cards). See + Secure Boot and Option ROMs + for more details. + + + + reboot-for-bitlocker + + Caveat: This feature is experimental, and is likely to be changed (or removed in its + current form) in a future version of systemd. + + Work around BitLocker requiring a recovery key when the boot loader was + updated (disabled by default). + + Try to detect BitLocker encrypted drives along with an active TPM. If both are found + and Windows Boot Manager is selected in the boot menu, set the BootNext + EFI variable and restart the system. The firmware will then start Windows Boot Manager + directly, leaving the TPM PCRs in expected states so that Windows can unseal the encryption + key. This allows systemd-boot to be updated without having to provide the recovery key for + BitLocker drive unlocking. + + Note that the PCRs that Windows uses can be configured with the + Configure TPM platform validation profile for native UEFI firmware configurations + group policy under Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption. + When secure boot is enabled, changing this to PCRs 0,2,7,11 should be safe. + The TPM key protector needs to be removed and then added back for the PCRs on an already + encrypted drive to change. If PCR 4 is not measured, this setting can be disabled to speed + up booting into Windows. + + + + random-seed-mode + + Takes one of off, with-system-token and + always. If off no random seed data is read off the ESP, nor + passed to the OS. If with-system-token (the default) + systemd-boot will read a random seed from the ESP (from the file + /loader/random-seed) only if the LoaderSystemToken EFI + variable is set, and then derive the random seed to pass to the OS from the combination. If + always the boot loader will do so even if LoaderSystemToken is + not set. This mode is useful in environments where protection against OS image reuse is not a + concern, and the random seed shall be used even with no further setup in place. Use bootctl + random-seed to initialize both the random seed file in the ESP and the system token EFI + variable. + + See Random Seeds for further + information. + + + + + + Example + + # /boot/efi/loader/loader.conf +timeout 0 +default 01234567890abcdef1234567890abdf0-* +editor no + + + The menu will not be shown by default (the menu can still be shown by + pressing and holding a key during boot). One of the entries with files with a + name starting with 01234567890abcdef1234567890abdf0- will be + selected by default. If more than one entry matches, the one with the highest + priority will be selected (generally the one with the highest version number). + The editor will be disabled, so it is not possible to alter the kernel command + line. + + + + See Also + + systemd-boot7, + bootctl1 + + + diff --git a/man/locale.conf.xml b/man/locale.conf.xml new file mode 100644 index 0000000..24be105 --- /dev/null +++ b/man/locale.conf.xml @@ -0,0 +1,128 @@ + + + + + + + locale.conf + systemd + + + + locale.conf + 5 + + + + locale.conf + Configuration file for locale settings + + + + /etc/locale.conf + + + + Description + + The /etc/locale.conf file configures + system-wide locale settings. It is read at early boot by + systemd1. + + The format of locale.conf is a newline-separated list of environment-like + shell-compatible variable assignments, ignoring comments and empty lines. It is possible to source the + configuration from shell scripts, however, beyond mere variable assignments, no shell features are + supported, allowing applications to read the file without implementing a shell compatible execution + engine. See + os-release5 for a + detailed description of the format. + + Note that the kernel command line options + locale.LANG=, + locale.LANGUAGE=, + locale.LC_CTYPE=, + locale.LC_NUMERIC=, + locale.LC_TIME=, + locale.LC_COLLATE=, + locale.LC_MONETARY=, + locale.LC_MESSAGES=, + locale.LC_PAPER=, + locale.LC_NAME=, + locale.LC_ADDRESS=, + locale.LC_TELEPHONE=, + locale.LC_MEASUREMENT=, + locale.LC_IDENTIFICATION= may be + used to override the locale settings at boot. + + The locale settings configured in + /etc/locale.conf are system-wide and are + inherited by every service or user, unless overridden or unset by + individual programs or users. + + Depending on the operating system, other configuration files + might be checked for locale configuration as well, however only as + fallback. + + /etc/locale.conf can be updated + using + systemd-localed.service8. + localectl1 + may be used to alter the settings in this file during runtime from + the command line. Use + systemd-firstboot1 + to customize them on mounted (but not booted) system images. + + + + Options + + The following locale settings may be set using + /etc/locale.conf: + LANG=, + LANGUAGE=, + LC_CTYPE=, + LC_NUMERIC=, + LC_TIME=, + LC_COLLATE=, + LC_MONETARY=, + LC_MESSAGES=, + LC_PAPER=, + LC_NAME=, + LC_ADDRESS=, + LC_TELEPHONE=, + LC_MEASUREMENT=, + LC_IDENTIFICATION=. + Note that LC_ALL may not be configured in this + file. For details about the meaning and semantics of these + settings, refer to + locale7. + + + + Example + + + German locale with English messages + + /etc/locale.conf: + + # Custom settings + +LANG=de_DE.UTF-8 +LC_MESSAGES=en_US.UTF-8 + + + + + + See Also + + systemd1, + locale7, + localectl1, + systemd-localed.service8, + systemd-firstboot1 + + + diff --git a/man/localectl.xml b/man/localectl.xml new file mode 100644 index 0000000..617922e --- /dev/null +++ b/man/localectl.xml @@ -0,0 +1,211 @@ + + + + + + + + localectl + systemd + + + + localectl + 1 + + + + localectl + Control the system locale and keyboard layout settings + + + + + localectl + OPTIONS + COMMAND + + + + + Description + + localectl may be used to query and change + the system locale and keyboard layout settings. It communicates with + systemd-localed8 + to modify files such as /etc/locale.conf and + /etc/vconsole.conf. + + The system locale controls the language settings of system + services and of the UI before the user logs in, such as the + display manager, as well as the default for users after + login. + + The keyboard settings control the keyboard layout used on + the text console and of the graphical UI before the user logs in, + such as the display manager, as well as the default for users + after login. + + Note that the changes performed using this tool might require the initrd to be rebuilt to take + effect during early system boot. The initrd is not rebuilt automatically by + localectl, this task has to be performed manually, usually using a tool like + dracut8. + + + Note that + systemd-firstboot1 + may be used to initialize the system locale for mounted (but not booted) + system images. + + + + Commands + + The following commands are understood: + + + + status + + Show current settings of the system locale and keyboard mapping. + If no command is specified, this is the implied default. + + + + set-locale LOCALE + set-locale VARIABLE=LOCALE… + + Set the system locale. This takes one locale such as en_US.UTF-8, or takes one or more + locale assignments such as LANG=de_DE.utf8, LC_MESSAGES=en_GB.utf8, and so on. If + one locale without variable name is provided, then LANG= locale variable will be set. See + locale7 + for details on the available settings and their meanings. Use + list-locales for a list of available + locales (see below). + + + + list-locales + + List available locales useful for + configuration with + set-locale. + + + + set-keymap MAP [TOGGLEMAP] + + Set the system keyboard mapping for the + console and X11. This takes a mapping name (such as "de" or + "us"), and possibly a second one to define a toggle keyboard + mapping. Unless is passed, the + selected setting is also applied as the default system + keyboard mapping of X11, after converting it to the closest + matching X11 keyboard mapping. Use + list-keymaps for a list of available + keyboard mappings (see below). + + + + list-keymaps + + List available keyboard mappings for the + console, useful for configuration with + set-keymap. + + + + set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]] + + Set the system default keyboard mapping for + X11 and the virtual console. This takes a keyboard mapping + name (such as de or us), + and possibly a model, variant, and options, see + kbd4 + for details. Unless is passed, + the selected setting is also applied as the system console + keyboard mapping, after converting it to the closest matching + console keyboard mapping. + + + + list-x11-keymap-models + list-x11-keymap-layouts + list-x11-keymap-variants [LAYOUT] + list-x11-keymap-options + + List available X11 keymap models, layouts, + variants and options, useful for configuration with + set-keymap. The command + list-x11-keymap-variants optionally takes a + layout parameter to limit the output to the variants suitable + for the specific layout. + + + + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + If set-keymap or + set-x11-keymap is invoked and this option + is passed, then the keymap will not be converted from the + console to X11, or X11 to console, + respectively. + + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + + + See Also + + systemd1, + locale7, + locale.conf5, + vconsole.conf5, + loadkeys1, + kbd4, + + The XKB Configuration Guide + , + systemctl1, + systemd-localed.service8, + systemd-firstboot1, + dracut8 + + + + diff --git a/man/localtime.xml b/man/localtime.xml new file mode 100644 index 0000000..e486474 --- /dev/null +++ b/man/localtime.xml @@ -0,0 +1,72 @@ + + + + + + + localtime + systemd + + + + localtime + 5 + + + + localtime + Local timezone configuration file + + + + /etc/localtime -> ../usr/share/zoneinfo/… + + + + Description + + The /etc/localtime file configures the + system-wide timezone of the local system that is used by + applications for presentation to the user. It should be an + absolute or relative symbolic link pointing to + /usr/share/zoneinfo/, followed by a timezone + identifier such as Europe/Berlin or + Etc/UTC. The resulting link should lead to the + corresponding binary + tzfile5 + timezone data for the configured timezone. + + Because the timezone identifier is extracted from the + symlink target name of /etc/localtime, this + file may not be a normal file or hardlink. + + If /etc/localtime is missing, the + default UTC timezone is used. + + The timezone may be overridden for individual programs by + using the $TZ environment variable. See + environ7. + + You may use + timedatectl1 + to change the settings of this file from the command line during + runtime. Use + systemd-firstboot1 + to initialize the time zone on mounted (but not booted) system + images. + + + + See Also + + systemd1, + tzset3, + localtime3, + timedatectl1, + systemd-timedated.service8, + systemd-firstboot1 + + + + diff --git a/man/logcontrol-example.c b/man/logcontrol-example.c new file mode 100644 index 0000000..734318d --- /dev/null +++ b/man/logcontrol-example.c @@ -0,0 +1,232 @@ +/* SPDX-License-Identifier: MIT-0 */ + +/* Implements the LogControl1 interface as per specification: + * https://www.freedesktop.org/software/systemd/man/org.freedesktop.LogControl1.html + * + * Compile with 'cc logcontrol-example.c $(pkg-config --libs --cflags libsystemd)' + * + * To get and set properties via busctl: + * + * $ busctl --user get-property org.freedesktop.Example \ + * /org/freedesktop/LogControl1 \ + * org.freedesktop.LogControl1 \ + * SyslogIdentifier + * s "example" + * $ busctl --user get-property org.freedesktop.Example \ + * /org/freedesktop/LogControl1 \ + * org.freedesktop.LogControl1 \ + * LogTarget + * s "journal" + * $ busctl --user get-property org.freedesktop.Example \ + * /org/freedesktop/LogControl1 \ + * org.freedesktop.LogControl1 \ + * LogLevel + * s "info" + * $ busctl --user set-property org.freedesktop.Example \ + * /org/freedesktop/LogControl1 \ + * org.freedesktop.LogControl1 \ + * LogLevel \ + * "s" debug + * $ busctl --user get-property org.freedesktop.Example \ + * /org/freedesktop/LogControl1 \ + * org.freedesktop.LogControl1 \ + * LogLevel + * s "debug" + */ + +#include +#include +#include +#include +#include +#include + +#define _cleanup_(f) __attribute__((cleanup(f))) + +#define check(log_level, x) ({ \ + int _r = (x); \ + errno = _r < 0 ? -_r : 0; \ + sd_journal_print((log_level), #x ": %m"); \ + if (_r < 0) \ + return EXIT_FAILURE; \ + }) + +typedef enum LogTarget { + LOG_TARGET_JOURNAL, + LOG_TARGET_KMSG, + LOG_TARGET_SYSLOG, + LOG_TARGET_CONSOLE, + _LOG_TARGET_MAX, +} LogTarget; + +static const char* const log_target_table[_LOG_TARGET_MAX] = { + [LOG_TARGET_JOURNAL] = "journal", + [LOG_TARGET_KMSG] = "kmsg", + [LOG_TARGET_SYSLOG] = "syslog", + [LOG_TARGET_CONSOLE] = "console", +}; + +static const char* const log_level_table[LOG_DEBUG + 1] = { + [LOG_EMERG] = "emerg", + [LOG_ALERT] = "alert", + [LOG_CRIT] = "crit", + [LOG_ERR] = "err", + [LOG_WARNING] = "warning", + [LOG_NOTICE] = "notice", + [LOG_INFO] = "info", + [LOG_DEBUG] = "debug", +}; + +typedef struct object { + const char *syslog_identifier; + LogTarget log_target; + int log_level; +} object; + +static int property_get( + sd_bus *bus, + const char *path, + const char *interface, + const char *property, + sd_bus_message *reply, + void *userdata, + sd_bus_error *error) { + + object *o = userdata; + + if (strcmp(property, "LogLevel") == 0) + return sd_bus_message_append(reply, "s", log_level_table[o->log_level]); + + if (strcmp(property, "LogTarget") == 0) + return sd_bus_message_append(reply, "s", log_target_table[o->log_target]); + + if (strcmp(property, "SyslogIdentifier") == 0) + return sd_bus_message_append(reply, "s", o->syslog_identifier); + + return sd_bus_error_setf(error, + SD_BUS_ERROR_UNKNOWN_PROPERTY, + "Unknown property '%s'", + property); +} + +static int property_set( + sd_bus *bus, + const char *path, + const char *interface, + const char *property, + sd_bus_message *message, + void *userdata, + sd_bus_error *error) { + + object *o = userdata; + const char *value; + int r; + + r = sd_bus_message_read(message, "s", &value); + if (r < 0) + return r; + + if (strcmp(property, "LogLevel") == 0) { + for (int i = 0; i < LOG_DEBUG + 1; i++) + if (strcmp(value, log_level_table[i]) == 0) { + o->log_level = i; + return 0; + } + + return sd_bus_error_setf(error, + SD_BUS_ERROR_INVALID_ARGS, + "Invalid value for LogLevel: '%s'", + value); + } + + if (strcmp(property, "LogTarget") == 0) { + for (LogTarget i = 0; i < _LOG_TARGET_MAX; i++) + if (strcmp(value, log_target_table[i]) == 0) { + o->log_target = i; + return 0; + } + + return sd_bus_error_setf(error, + SD_BUS_ERROR_INVALID_ARGS, + "Invalid value for LogTarget: '%s'", + value); + } + + return sd_bus_error_setf(error, + SD_BUS_ERROR_UNKNOWN_PROPERTY, + "Unknown property '%s'", + property); +} + +/* https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html + */ +static const sd_bus_vtable vtable[] = { + SD_BUS_VTABLE_START(0), + SD_BUS_WRITABLE_PROPERTY( + "LogLevel", "s", + property_get, property_set, + 0, + 0), + SD_BUS_WRITABLE_PROPERTY( + "LogTarget", "s", + property_get, property_set, + 0, + 0), + SD_BUS_PROPERTY( + "SyslogIdentifier", "s", + property_get, + 0, + SD_BUS_VTABLE_PROPERTY_CONST), + SD_BUS_VTABLE_END +}; + +int main(int argc, char **argv) { + /* The bus should be relinquished before the program terminates. The cleanup + * attribute allows us to do it nicely and cleanly whenever we exit the + * block. + */ + _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL; + + object o = { + .log_level = LOG_INFO, + .log_target = LOG_TARGET_JOURNAL, + .syslog_identifier = "example", + }; + + /* Acquire a connection to the bus, letting the library work out the details. + * https://www.freedesktop.org/software/systemd/man/sd_bus_default.html + */ + check(o.log_level, sd_bus_default(&bus)); + + /* Publish an interface on the bus, specifying our well-known object access + * path and public interface name. + * https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html + * https://dbus.freedesktop.org/doc/dbus-tutorial.html + */ + check(o.log_level, sd_bus_add_object_vtable(bus, NULL, + "/org/freedesktop/LogControl1", + "org.freedesktop.LogControl1", + vtable, + &o)); + + /* By default the service is assigned an ephemeral name. Also add a fixed + * one, so that clients know whom to call. + * https://www.freedesktop.org/software/systemd/man/sd_bus_request_name.html + */ + check(o.log_level, sd_bus_request_name(bus, "org.freedesktop.Example", 0)); + + for (;;) { + /* https://www.freedesktop.org/software/systemd/man/sd_bus_wait.html + */ + check(o.log_level, sd_bus_wait(bus, UINT64_MAX)); + /* https://www.freedesktop.org/software/systemd/man/sd_bus_process.html + */ + check(o.log_level, sd_bus_process(bus, NULL)); + } + + /* https://www.freedesktop.org/software/systemd/man/sd_bus_release_name.html + */ + check(o.log_level, sd_bus_release_name(bus, "org.freedesktop.Example")); + + return 0; +} diff --git a/man/loginctl.xml b/man/loginctl.xml new file mode 100644 index 0000000..7921663 --- /dev/null +++ b/man/loginctl.xml @@ -0,0 +1,430 @@ + + + + + + + + loginctl + systemd + + + + loginctl + 1 + + + + loginctl + Control the systemd login manager + + + + + loginctl + OPTIONS + COMMAND + NAME + + + + + Description + + loginctl may be used to introspect and + control the state of the + systemd1 + login manager + systemd-logind.service8. + + + + Commands + + The following commands are understood: + + Session Commands + + + list-sessions + + List current sessions. + + + + session-status ID… + + Show terse runtime status information about + one or more sessions, followed by the most recent log data + from the journal. Takes one or more session identifiers as + parameters. If no session identifiers are passed, the status of + the caller's session is shown. This function is intended to + generate human-readable output. If you are looking for + computer-parsable output, use show-session + instead. + + + + show-session ID… + + Show properties of one or more sessions or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a session ID is specified, + properties of the session are shown. By default, empty + properties are suppressed. Use to show + those too. To select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + session-status if you are looking for + formatted human-readable output. + + + + activate ID + + Activate a session. This brings a session into + the foreground if another session is currently in the + foreground on the respective seat. Takes a session identifier + as argument. If no argument is specified, the session of the + caller is put into foreground. + + + + lock-session ID… + unlock-session ID… + + Activates/deactivates the screen lock on one + or more sessions, if the session supports it. Takes one or + more session identifiers as arguments. If no argument is + specified, the session of the caller is locked/unlocked. + + + + + lock-sessions + unlock-sessions + + Activates/deactivates the screen lock on all + current sessions supporting it. + + + + terminate-session ID… + + Terminates a session. This kills all processes of the session and deallocates all + resources attached to the session. If the argument is specified as empty string the session invoking + the command is terminated. + + + + kill-session ID… + + Send a signal to one or more processes of the session. Use + to select which process to kill. Use to + select the signal to send. If the argument is specified as empty string the signal is sent to the + session invoking the command. + + + + User Commands + + list-users + + List currently logged in users. + + + + + user-status USER… + + Show terse runtime status information about + one or more logged in users, followed by the most recent log + data from the journal. Takes one or more user names or numeric + user IDs as parameters. If no parameters are passed, the status + is shown for the user of the session of the caller. This + function is intended to generate human-readable output. If you + are looking for computer-parsable output, use + show-user instead. + + + + show-user USER… + + Show properties of one or more users or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a user is specified, properties of + the user are shown. By default, empty properties are + suppressed. Use to show those too. To + select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + user-status if you are looking for + formatted human-readable output. + + + + enable-linger USER… + disable-linger USER… + + Enable/disable user lingering for one or more + users. If enabled for a specific user, a user manager is + spawned for the user at boot and kept around after logouts. + This allows users who are not logged in to run long-running + services. Takes one or more user names or numeric UIDs as + argument. If no argument is specified, enables/disables + lingering for the user of the session of the caller. + + See also KillUserProcesses= setting in + logind.conf5. + + + + + terminate-user USER… + + Terminates all sessions of a user. This kills all processes of all sessions of the + user and deallocates all runtime resources attached to the user. If the argument is specified as + empty string the sessions of the user invoking the command are terminated. + + + + kill-user USER… + + Send a signal to all processes of a user. Use to select + the signal to send. If the argument is specified as empty string the signal is sent to the sessions + of the user invoking the command. + + + + Seat Commands + + list-seats + + List currently available seats on the local + system. + + + + seat-status NAME… + + Show terse runtime status information about + one or more seats. Takes one or more seat names as parameters. + If no seat names are passed the status of the caller's + session's seat is shown. This function is intended to generate + human-readable output. If you are looking for + computer-parsable output, use show-seat + instead. + + + + show-seat NAME… + + Show properties of one or more seats or the + manager itself. If no argument is specified, properties of the + manager will be shown. If a seat is specified, properties of + the seat are shown. By default, empty properties are + suppressed. Use to show those too. To + select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + seat-status if you are looking for + formatted human-readable output. + + + + attach NAME DEVICE… + + Persistently attach one or more devices to a + seat. The devices should be specified via device paths in the + /sys/ file system. To create a new seat, + attach at least one graphics card to a previously unused seat + name. Seat names may consist only of a–z, A–Z, 0–9, + - and _ and must be + prefixed with seat. To drop assignment of a + device to a specific seat, just reassign it to a different + seat, or use flush-devices. + + + + + flush-devices + + Removes all device assignments previously + created with attach. After this call, only + automatically generated seats will remain, and all seat + hardware is assigned to them. + + + + terminate-seat NAME… + + Terminates all sessions on a seat. This kills + all processes of all sessions on the seat and deallocates all + runtime resources attached to them. + + + + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + + When showing session/user/seat properties, + limit display to certain properties as specified as argument. + If not specified, all set properties are shown. The argument + should be a property name, such as + Sessions. If specified more than once, all + properties with the specified names are + shown. + + + + + + When showing session/user/seat properties, + only print the value, and skip the property name and + =. + + + + + + + When showing session/user/seat properties, + show all properties regardless of whether they are set or + not. + + + + + + + Do not ellipsize process tree entries. + + + + + + + When used with + kill-session, choose which processes to + kill. Must be one of , or + to select whether to kill only the leader + process of the session or all processes of the session. If + omitted, defaults to . + + + + + + + When used with kill-session or kill-user, + choose which signal to send to selected processes. Must be one of the well known signal specifiers, + such as SIGTERM, SIGINT or SIGSTOP. + If omitted, defaults to SIGTERM. + + The special value help will list the known values and the program will exit + immediately, and the special value list will list known values along with the + numerical signal numbers and the program will exit immediately. + + + + + + + When used with user-status + and session-status, controls the number of + journal lines to show, counting from the most recent ones. + Takes a positive integer argument. Defaults to 10. + + + + + + + + When used with user-status + and session-status, controls the formatting + of the journal entries that are shown. For the available + choices, see + journalctl1. + Defaults to short. + + + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Examples + + + Querying user status + + $ loginctl user-status +fatima (1005) + Since: Sat 2016-04-09 14:23:31 EDT; 54min ago + State: active + Sessions: 5 *3 + Unit: user-1005.slice + ├─user@1005.service + … + ├─session-3.scope + … + └─session-5.scope + ├─3473 login -- fatima + └─3515 -zsh + +Apr 09 14:40:30 laptop login[2325]: pam_unix(login:session): + session opened for user fatima by LOGIN(uid=0) +Apr 09 14:40:30 laptop login[2325]: LOGIN ON tty3 BY fatima + + + There are two sessions, 3 and 5. Session 3 is a graphical session, + marked with a star. The tree of processing including the two corresponding + scope units and the user manager unit are shown. + + + + + + + See Also + + systemd1, + systemctl1, + systemd-logind.service8, + logind.conf5 + + + + diff --git a/man/logind.conf.xml b/man/logind.conf.xml new file mode 100644 index 0000000..9682add --- /dev/null +++ b/man/logind.conf.xml @@ -0,0 +1,371 @@ + + +%entities; +]> + + + + + logind.conf + systemd + + + + logind.conf + 5 + + + + logind.conf + logind.conf.d + Login manager configuration files + + + + /etc/systemd/logind.conf + /etc/systemd/logind.conf.d/*.conf + /run/systemd/logind.conf.d/*.conf + /usr/lib/systemd/logind.conf.d/*.conf + + + + Description + + These files configure various parameters of the systemd login manager, + systemd-logind.service8. See + systemd.syntax7 + for a general description of the syntax. + + + + + + Options + + All options are configured in the + [Login] section: + + + + + NAutoVTs= + + Takes a positive integer. Configures how many + virtual terminals (VTs) to allocate by default that, when + switched to and are previously unused, + autovt services are automatically spawned + on. These services are instantiated from the template unit + autovt@.service for the respective VT TTY + name, for example, autovt@tty4.service. + By default, autovt@.service is linked to + getty@.service. In other words, login + prompts are started dynamically as the user switches to unused + virtual terminals. Hence, this parameter controls how many + login gettys are available on the VTs. If a + VT is already used by some other subsystem (for example, a + graphical login), this kind of activation will not be + attempted. Note that the VT configured in + ReserveVT= is always subject to this kind + of activation, even if it is not one of the VTs configured + with the NAutoVTs= directive. Defaults to + 6. When set to 0, automatic spawning of + autovt services is + disabled. + + + + ReserveVT= + + Takes a positive integer. Identifies one + virtual terminal that shall unconditionally be reserved for + autovt@.service activation (see above). + The VT selected with this option will be marked busy + unconditionally, so that no other subsystem will allocate it. + This functionality is useful to ensure that, regardless of how + many VTs are allocated by other subsystems, one login + getty is always available. Defaults to 6 + (in other words, there will always be a + getty available on Alt-F6.). When set to 0, + VT reservation is disabled. + + + + KillUserProcesses= + + Takes a boolean argument. Configures whether the processes of a + user should be killed when the user logs out. If true, the scope unit + corresponding to the session and all processes inside that scope will be + terminated. If false, the scope is "abandoned", see + systemd.scope5, + and processes are not killed. Defaults to &KILL_USER_PROCESSES;, + but see the options KillOnlyUsers= and + KillExcludeUsers= below. + + In addition to session processes, user process may run under the user + manager unit user@.service. Depending on the linger + settings, this may allow users to run processes independent of their login + sessions. See the description of enable-linger in + loginctl1. + + + Note that setting KillUserProcesses=yes + will break tools like + screen1 + and + tmux1, + unless they are moved out of the session scope. See example in + systemd-run1. + + + + + KillOnlyUsers= + KillExcludeUsers= + + These settings take space-separated lists of usernames that override the + KillUserProcesses= setting. A user name may be added to + KillExcludeUsers= to exclude the processes in the session scopes of that user from + being killed even if KillUserProcesses=yes is set. If + KillExcludeUsers= is not set, the root user is excluded by + default. KillExcludeUsers= may be set to an empty value to override this + default. If a user is not excluded, KillOnlyUsers= is checked next. If this + setting is specified, only the processes in the session scopes of those users will be + killed. Otherwise, users are subject to the KillUserProcesses=yes setting. + + + + + IdleAction= + + Configures the action to take when the system + is idle. Takes one of + ignore, + poweroff, + reboot, + halt, + kexec, + suspend, + hibernate, + hybrid-sleep, + suspend-then-hibernate, and + lock. + Defaults to ignore. + + Note that this requires that user sessions correctly + report the idle status to the system. The system will execute + the action after all sessions report that they are idle, no + idle inhibitor lock is active, and subsequently, the time + configured with IdleActionSec= (see below) + has expired. + + + + + IdleActionSec= + + Configures the delay after which the action + configured in IdleAction= (see above) is + taken after the system is idle. + + + + InhibitDelayMaxSec= + + Specifies the maximum time a system shutdown + or sleep request is delayed due to an inhibitor lock of type + delay being active before the inhibitor is + ignored and the operation executes anyway. Defaults to + 5. + + + + UserStopDelaySec= + + Specifies how long to keep the user record and per-user service + user@.service around for a user after they logged out fully. If set to zero, the per-user + service is terminated immediately when the last session of the user has ended. If this option is configured to + non-zero rapid logout/login cycles are sped up, as the user's service manager is not constantly restarted. If + set to infinity the per-user service for a user is never terminated again after first login, + and continues to run until system shutdown. Defaults to 10s. + + + + HandlePowerKey= + HandlePowerKeyLongPress= + HandleRebootKey= + HandleRebootKeyLongPress= + HandleSuspendKey= + HandleSuspendKeyLongPress= + HandleHibernateKey= + HandleHibernateKeyLongPress= + HandleLidSwitch= + HandleLidSwitchExternalPower= + HandleLidSwitchDocked= + + Controls how logind shall handle the system power, reboot and sleep keys and the lid + switch to trigger actions such as system power-off, reboot or suspend. Can be one of + ignore, poweroff, reboot, + halt, kexec, suspend, + hibernate, hybrid-sleep, + suspend-then-hibernate, lock, and + factory-reset. If ignore, systemd-logind + will never handle these keys. If lock, all running sessions will be screen-locked; + otherwise, the specified action will be taken in the respective event. Only input devices with the + power-switch udev tag will be watched for key/lid switch + events. + + HandlePowerKey= defaults to poweroff, + HandleRebootKey= defaults to reboot, + HandleSuspendKey= defaults to suspend, + HandleHibernateKey= defaults to hibernate, + HandlePowerKeyLongPress= defaults to ignore, + HandleRebootKeyLongPress= defaults to poweroff, + HandleSuspendKeyLongPress= defaults to hibernate, + HandleHibernateKeyLongPress= defaults to ignore. + HandleLidSwitch= defaults to suspend. + HandleLidSwitchExternalPower= is completely ignored by default (for backwards + compatibility) — an explicit value must be set before it will be used to determine + behaviour. HandleLidSwitchDocked= defaults to ignore. If the + system is inserted in a docking station, or if more than one display is connected, the action + specified by HandleLidSwitchDocked= occurs; if the system is on external power the + action (if any) specified by HandleLidSwitchExternalPower= occurs; otherwise the + HandleLidSwitch= action occurs. + + A different application may disable logind's handling of system power and + sleep keys and the lid switch by taking a low-level inhibitor lock + (handle-power-key, handle-suspend-key, + handle-hibernate-key, handle-lid-switch, + handle-reboot-key). + This is most commonly used by graphical desktop environments + to take over suspend and hibernation handling, and to use their own configuration + mechanisms. If a low-level inhibitor lock is taken, logind will not take any + action when that key or switch is triggered and the Handle*= + settings are irrelevant. + + + + PowerKeyIgnoreInhibited= + SuspendKeyIgnoreInhibited= + HibernateKeyIgnoreInhibited= + LidSwitchIgnoreInhibited= + RebootKeyIgnoreInhibited= + + Controls whether actions that systemd-logind + takes when the power, reboot and sleep keys and the lid switch are triggered are subject + to high-level inhibitor locks ("shutdown", "reboot", "sleep", "idle"). Low level inhibitor + locks (handle-power-key, handle-suspend-key, + handle-hibernate-key, handle-lid-switch, + handle-reboot-key), + are always honored, irrespective of this setting. + + These settings take boolean arguments. If no, the + inhibitor locks taken by applications are respected. If yes, + "shutdown", "reboot" "sleep", and "idle" inhibitor locks are ignored. + PowerKeyIgnoreInhibited=, + SuspendKeyIgnoreInhibited=, + HibernateKeyIgnoreInhibited= and + RebootKeyIgnoreInhibited= default to no. + LidSwitchIgnoreInhibited= defaults to yes. + This means that when systemd-logind is handling events by + itself (no low level inhibitor locks are taken by another application), the lid + switch does not respect suspend blockers by default, but the power and sleep keys + do. + + + + HoldoffTimeoutSec= + + Specifies a period of time after system startup or + system resume in which systemd will hold off on reacting to + lid events. This is required for the system to properly + detect any hotplugged devices so systemd can ignore lid events + if external monitors, or docks, are connected. If set to 0, + systemd will always react immediately, possibly before the + kernel fully probed all hotplugged devices. This is safe, as + long as you do not care for systemd to account for devices + that have been plugged or unplugged while the system was off. + Defaults to 30s. + + + + RuntimeDirectorySize= + + Sets the size limit on the + $XDG_RUNTIME_DIR runtime directory for each + user who logs in. Takes a size in bytes, optionally suffixed + with the usual K, G, M, and T suffixes, to the base 1024 + (IEC). Alternatively, a numerical percentage suffixed by + % may be specified, which sets the size + limit relative to the amount of physical RAM. Defaults to 10%. + Note that this size is a safety limit only. As each runtime + directory is a tmpfs file system, it will only consume as much + memory as is needed. + + + + RuntimeDirectoryInodesMax= + + Sets the limit on number of inodes for the + $XDG_RUNTIME_DIR runtime directory for each + user who logs in. Takes a number, optionally suffixed with the + usual K, G, M, and T suffixes, to the base 1024 (IEC). + Defaults to RuntimeDirectorySize= divided + by 4096. Note that this size is a safety limit only. + As each runtime directory is a tmpfs file system, it will + only consume as much memory as is needed. + + + + InhibitorsMax= + + Controls the maximum number of concurrent inhibitors to permit. Defaults to 8192 + (8K). + + + + SessionsMax= + + Controls the maximum number of concurrent user sessions to manage. Defaults to 8192 + (8K). Depending on how the pam_systemd.so module is included in the PAM stack + configuration, further login sessions will either be refused, or permitted but not tracked by + systemd-logind. + + + + RemoveIPC= + + Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the + user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the + last of the user's sessions terminated. This covers System V semaphores, shared memory and message queues, as + well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users + are excluded from the effect of this setting. Defaults to yes. + + + + StopIdleSessionSec= + + Specifies a timeout in seconds, or a time span value after which + systemd-logind checks the idle state of all sessions. Every session that is idle for + longer then the timeout will be stopped. Defaults to infinity + (systemd-logind is not checking the idle state of sessions). For details about the syntax + of time spans, see + systemd.time7. + + + + + + + See Also + + systemd1, + systemd-logind.service8, + loginctl1, + systemd-system.conf5 + + + + diff --git a/man/machine-id.xml b/man/machine-id.xml new file mode 100644 index 0000000..ec1ab64 --- /dev/null +++ b/man/machine-id.xml @@ -0,0 +1,203 @@ + + + + + + + machine-id + systemd + + + + machine-id + 5 + + + + machine-id + Local machine ID configuration file + + + + /etc/machine-id + + + + Description + + The /etc/machine-id file contains the unique machine ID of + the local system that is set during installation or boot. The machine ID is a single + newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from + hexadecimal, this corresponds to a 16-byte/128-bit value. This ID may not be all + zeros. + + The machine ID is usually generated from a random source during system + installation or first boot and stays constant for all subsequent boots. Optionally, + for stateless systems, it is generated during runtime during early boot if necessary. + + + The machine ID may be set, for example when network booting, with the + systemd.machine_id= kernel command line parameter or by passing the + option to systemd. An ID specified in this manner + has higher priority and will be used instead of the ID stored in + /etc/machine-id. + + The machine ID does not change based on local or network configuration or when + hardware is replaced. Due to this and its greater length, it is a more useful + replacement for the + gethostid3 + call that POSIX specifies. + + This machine ID adheres to the same format and logic as the + D-Bus machine ID. + + This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in + untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is + needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID + should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the + ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve + the original machine ID from the application-specific one. The + sd_id128_get_machine_app_specific3 + API provides an implementation of such an algorithm. + + + + Initialization + + Each machine should have a non-empty ID in normal operation. The ID of each + machine should be unique. To achieve those objectives, + /etc/machine-id can be initialized in a few different ways. + + + For normal operating system installations, where a custom image is created for a + specific machine, /etc/machine-id should be populated during + installation. + + + systemd-machine-id-setup1 + may be used by installer tools to initialize the machine ID at install time, but + /etc/machine-id may also be written using any other means. + + + For operating system images which are created once and used on multiple machines, for example for + containers or in the cloud, /etc/machine-id should be either missing or an empty + file in the generic file system image (the difference between the two options is described under "First + Boot Semantics" below). An ID will be generated during boot and saved to this file if possible. Having an + empty file in place is useful because it allows a temporary file to be bind-mounted over the real file, + in case the image is used read-only. Also see Safely + Building Images. + + systemd-firstboot1 + may be used to initialize /etc/machine-id on mounted (but not + booted) system images. + + When a machine is booted with + systemd1 + the ID of the machine will be established. If systemd.machine_id= + or options (see first section) are specified, this + value will be used. Otherwise, the value in /etc/machine-id will + be used. If this file is empty or missing, systemd will attempt + to use the D-Bus machine ID from /var/lib/dbus/machine-id, the + value of the kernel command line option container_uuid, the KVM DMI + product_uuid or the devicetree vm,uuid + (on KVM systems), and finally a randomly generated UUID. + + After the machine ID is established, + systemd1 + will attempt to save it to /etc/machine-id. If this fails, it + will attempt to bind-mount a temporary file over /etc/machine-id. + It is an error if the file system is read-only and does not contain a (possibly empty) + /etc/machine-id file. + + systemd-machine-id-commit.service8 + will attempt to write the machine ID to the file system if + /etc/machine-id or /etc/ are read-only during + early boot but become writable later on. + + + + First Boot Semantics + + /etc/machine-id is used to decide whether a boot is the first one. The rules + are as follows: + + + The kernel command argument systemd.condition-first-boot= may be + used to override the autodetection logic, see + kernel-command-line7. + + + Otherwise, if /etc/machine-id does not exist, this is a first + boot. During early boot, systemd will write uninitialized\n to + this file and overmount a temporary file which contains the actual machine ID. Later (after + first-boot-complete.target has been reached), the real machine ID will be written + to disk. + + If /etc/machine-id contains the string uninitialized, + a boot is also considered the first boot. The same mechanism as above applies. + + If /etc/machine-id exists and is empty, a boot is + not considered the first boot. systemd will still bind-mount a file + containing the actual machine-id over it and later try to commit it to disk (if /etc/ is + writable). + + If /etc/machine-id already contains a valid machine-id, this is + not a first boot. + + + If according to the above rules a first boot is detected, units with + ConditionFirstBoot=yes will be run and systemd will perform + additional initialization steps, in particular presetting units. + + + + Relation to OSF UUIDs + + Note that the machine ID historically is not an OSF UUID as defined by RFC 4122, nor a Microsoft GUID; however, starting with + systemd v30, newly generated machine IDs do qualify as Variant 1 Version 4 UUIDs, as per RFC 4122. + + In order to maintain compatibility with existing installations, an application requiring a strictly + RFC 4122 compliant UUID should decode the machine ID, and then (non-reversibly) apply the following + operations to turn it into a valid RFC 4122 Variant 1 Version 4 UUID. With id being an + unsigned character array: + + /* Set UUID version to 4 --- truly random generation */ +id[6] = (id[6] & 0x0F) | 0x40; +/* Set the UUID variant to DCE */ +id[8] = (id[8] & 0x3F) | 0x80; + + (This code is inspired by + generate_random_uuid() of + drivers/char/random.c from the Linux kernel + sources.) + + + + + History + + The simple configuration file format of + /etc/machine-id originates in the + /var/lib/dbus/machine-id file introduced by + D-Bus. In fact, this latter file might be a symlink to + /etc/machine-id. + + + + See Also + + systemd1, + systemd-machine-id-setup1, + gethostid3, + hostname5, + machine-info5, + os-release5, + sd-id1283, + sd_id128_get_machine3, + systemd-firstboot1 + + + + diff --git a/man/machine-info.xml b/man/machine-info.xml new file mode 100644 index 0000000..781208b --- /dev/null +++ b/man/machine-info.xml @@ -0,0 +1,171 @@ + + + + + + + machine-info + systemd + + + + machine-info + 5 + + + + machine-info + Local machine information file + + + + /etc/machine-info + + + + Description + + The /etc/machine-info file contains + machine metadata. + + The format of machine-info is a newline-separated list of environment-like + shell-compatible variable assignments, ignoring comments and empty lines. It is possible to source the + configuration from shell scripts, however, beyond mere variable assignments no shell features are + supported, allowing applications to read the file without implementing a shell compatible execution + engine. See + os-release5 for a + detailed description of the format. + + /etc/machine-info contains metadata about the machine that is set by the user + or administrator. The settings configured here have the highest precedence. When not set, appropriate + values may be determined automatically, based on the information about the hardware or other + configuration files. It is thus completely fine for this file to not be present. + + You may use + hostnamectl1 + to change the settings of this file from the command line. + + + + Options + + The following machine metadata parameters may be set using + /etc/machine-info: + + + + + PRETTY_HOSTNAME= + + A pretty human-readable UTF-8 machine + identifier string. This should contain a name like + Lennart's Laptop which is useful to present + to the user and does not suffer by the syntax limitations of + internet domain names. If possible, the internet hostname as + configured in /etc/hostname should be + kept similar to this one. Example: if this value is + Lennart's Computer an Internet hostname of + lennarts-computer might be a good choice. + If this parameter is not set, an application should fall back + to the Internet hostname for presentation + purposes. + + + + ICON_NAME= + + An icon identifying this machine according to + the XDG + Icon Naming Specification. If this parameter is not + set, an application should fall back to + computer or a similar icon + name. + + + + CHASSIS= + + The chassis type. Currently, the following + chassis types are defined: + desktop, + laptop, + convertible, + server, + tablet, + handset, + watch, and + embedded, + as well as the special chassis types + vm and + container for + virtualized systems that lack an immediate physical chassis. + + Note that most systems allow detection of the chassis type automatically (based on firmware + information or suchlike). This setting should only be used to override a misdetection or to manually + configure the chassis type where automatic detection is not available. + + + + DEPLOYMENT= + + Describes the system deployment environment. + One of the following is suggested: + development, + integration, + staging, + production. + + + + + LOCATION= + + Describes the system location if applicable + and known. Takes a human-friendly, free-form string. This may + be as generic as Berlin, Germany or as + specific as Left Rack, 2nd Shelf. + + + + + HARDWARE_VENDOR= + + Specifies the hardware vendor. If unspecified, the hardware vendor set in DMI or + hwdb7 will be + used. + + + + HARDWARE_MODEL= + + Specifies the hardware model. If unspecified, the hardware model set in DMI or + hwdb7 will be + used. + + + + + + Example + + PRETTY_HOSTNAME="Lennart's Tablet" +ICON_NAME=computer-tablet +CHASSIS=tablet +DEPLOYMENT=production + + + + See Also + + systemd1, + os-release5, + hostname5, + machine-id5, + hostnamectl1, + systemd-hostnamed.service8 + + + + diff --git a/man/machinectl.xml b/man/machinectl.xml new file mode 100644 index 0000000..9f3e092 --- /dev/null +++ b/man/machinectl.xml @@ -0,0 +1,993 @@ + + +%entities; +]> + + + + + + machinectl + systemd + + + + machinectl + 1 + + + + machinectl + Control the systemd machine manager + + + + + machinectl + OPTIONS + COMMAND + NAME + + + + + Description + + machinectl may be used to introspect and + control the state of the + systemd1 + virtual machine and container registration manager + systemd-machined.service8. + + machinectl may be used to execute + operations on machines and images. Machines in this sense are + considered running instances of: + + + Virtual Machines (VMs) that virtualize hardware + to run full operating system (OS) instances (including their kernels) + in a virtualized environment on top of the host OS. + + Containers that share the hardware and + OS kernel with the host OS, in order to run + OS userspace instances on top the host OS. + + The host system itself. + + + Machines are identified by names that follow the same rules + as UNIX and DNS hostnames. For details, see below. + + Machines are instantiated from disk or file system images that + frequently — but not necessarily — carry the same name as machines running + from them. Images in this sense may be: + + + Directory trees containing an OS, including the + top-level directories /usr/, + /etc/, and so on. + + btrfs subvolumes containing OS trees, similar to regular directory trees. + + Binary "raw" disk image files containing MBR or GPT partition tables and Linux file + systems. + + Similarly, block devices containing MBR or GPT partition tables and file systems. + + The file system tree of the host OS itself. + + + + + + Commands + + The following commands are understood: + + Machine Commands + + + list + + List currently running (online) virtual + machines and containers. To enumerate machine images that can + be started, use list-images (see + below). Note that this command hides the special + .host machine by default. Use the + switch to show it. + + + + status NAME… + + Show runtime status information about + one or more virtual machines and containers, followed by the + most recent log data from the journal. This function is + intended to generate human-readable output. If you are looking + for computer-parsable output, use show + instead. Note that the log data shown is reported by the + virtual machine or container manager, and frequently contains + console output of the machine, but not necessarily journal + contents of the machine itself. + + + + show [NAME…] + + Show properties of one or more registered virtual machines or containers or the manager + itself. If no argument is specified, properties of the manager will be shown. If a NAME is specified, + properties of this virtual machine or container are shown. By default, empty properties are suppressed. Use + to show those too. To select specific properties to show, use + . This command is intended to be used whenever computer-parsable output is + required, and does not print the control group tree or journal entries. Use status if you + are looking for formatted human-readable output. + + + + start NAME… + + Start a container as a system service, using + systemd-nspawn1. + This starts systemd-nspawn@.service, + instantiated for the specified machine name, similar to the + effect of systemctl start on the service + name. systemd-nspawn looks for a container + image by the specified name in + /var/lib/machines/ (and other search + paths, see below) and runs it. Use + list-images (see below) for listing + available container images to start. + + Note that + systemd-machined.service8 + also interfaces with a variety of other container and VM + managers, systemd-nspawn is just one + implementation of it. Most of the commands available in + machinectl may be used on containers or VMs + controlled by other managers, not just + systemd-nspawn. Starting VMs and container + images on those managers requires manager-specific + tools. + + To interactively start a container on the command line + with full access to the container's console, please invoke + systemd-nspawn directly. To stop a running + container use machinectl poweroff. + + + + login [NAME] + + Open an interactive terminal login session in + a container or on the local host. If an argument is supplied, + it refers to the container machine to connect to. If none is + specified, or the container name is specified as the empty + string, or the special machine name .host + (see below) is specified, the connection is made to the local + host instead. This will create a TTY connection to a specific + container or the local host and asks for the execution of a + getty on it. Note that this is only supported for containers + running + systemd1 + as init system. + + This command will open a full login prompt on the + container or the local host, which then asks for username and + password. Use shell (see below) or + systemd-run1 + with the switch to directly invoke + a single command, either interactively or in the + background. + + + + shell [[NAME@]NAME [PATH [ARGUMENTS…]]] + + Open an interactive shell session in a + container or on the local host. The first argument refers to + the container machine to connect to. If none is specified, or + the machine name is specified as the empty string, or the + special machine name .host (see below) is + specified, the connection is made to the local host + instead. This works similarly to login, but + immediately invokes a user process. This command runs the + specified executable with the specified arguments, or the + default shell for the user if none is specified, or + /bin/sh if no default shell is found. By default, + , or by prefixing the machine name with + a username and an @ character, a different + user may be selected. Use to set + environment variables for the executed process. + + Note that machinectl shell does not propagate the exit code/status of the invoked + shell process. Use systemd-run instead if that information is required (see below). + + Using the shell command without arguments (thus invoking the executed shell + or command on the local host), is in many ways similar to a su1 session, + but, unlike su, completely isolates the new session from the originating session, + so that it shares no process or session properties and is in a clean well-defined state. It will be + tracked in a new utmp, login, audit, security, and keyring sessions, and will not inherit any + environment variables or resource limits, among other properties. + + Note that + systemd-run1 with + its switch may be used in place of the machinectl + shell command, and allows non-interactive operation, more detailed and low-level + configuration of the invoked unit, as well as access to runtime and exit code/status information of + the invoked shell process. In particular, use systemd-run's + switch to propagate exit status information of the invoked process. Use + systemd-run's switch to acquire an interactive shell, + similarly to machinectl shell. In general, systemd-run is + preferable for scripting purposes. However, note that systemd-run might require + higher privileges than machinectl shell. + + + + enable NAME… + disable NAME… + + Enable or disable a container as a system service to start at system boot, using + systemd-nspawn1. + This enables or disables systemd-nspawn@.service, instantiated for the specified + machine name, similarly to the effect of systemctl enable or systemctl + disable on the service name. + + + + poweroff NAME… + + Power off one or more containers. This will + trigger a reboot by sending SIGRTMIN+4 to the container's init + process, which causes systemd-compatible init systems to shut + down cleanly. Use stop as alias for poweroff. + This operation does not work on containers that do not run a + systemd1-compatible + init system, such as sysvinit. Use + terminate (see below) to immediately + terminate a container or VM, without cleanly shutting it + down. + + + + reboot NAME… + + Reboot one or more containers. This will + trigger a reboot by sending SIGINT to the container's init + process, which is roughly equivalent to pressing Ctrl+Alt+Del + on a non-containerized system, and is compatible with + containers running any system manager. + + + + terminate NAME… + + Immediately terminates a virtual machine or + container, without cleanly shutting it down. This kills all + processes of the virtual machine or container and deallocates + all resources attached to that instance. Use + poweroff to issue a clean shutdown + request. + + + + kill NAME… + + Send a signal to one or more processes of the + virtual machine or container. This means processes as seen by + the host, not the processes inside the virtual machine or + container. Use to select which + process to kill. Use to select the + signal to send. + + + + bind NAME PATH [PATH] + + Bind mounts a file or directory from the host into the specified container. The first path + argument is the source file or directory on the host, the second path argument is the destination file or + directory in the container. When the latter is omitted, the destination path in the container is the same as + the source path on the host. When combined with the switch, a ready-only bind + mount is created. When combined with the switch, the destination path is first created + before the mount is applied. Note that this option is currently only supported for + systemd-nspawn1 containers, + and only if user namespacing () is not used. This command supports bind + mounting directories, regular files, device nodes, AF_UNIX socket nodes, as well as + FIFOs. + + + + copy-to NAME PATH [PATH] + + Copies files or directories from the host + system into a running container. Takes a container name, + followed by the source path on the host and the destination + path in the container. If the destination path is omitted, the + same as the source path is used. + + If host and container share the same user and group namespace, file ownership by numeric user ID and + group ID is preserved for the copy, otherwise all files and directories in the copy will be owned by the root + user and group (UID/GID 0). + + + + copy-from NAME PATH [PATH] + + Copies files or directories from a container + into the host system. Takes a container name, followed by the + source path in the container and the destination path on the host. + If the destination path is omitted, the same as the source path + is used. + + If host and container share the same user and group namespace, file ownership by numeric user ID and + group ID is preserved for the copy, otherwise all files and directories in the copy will be owned by the root + user and group (UID/GID 0). + + + + Image Commands + + + list-images + + Show a list of locally installed container and + VM images. This enumerates all raw disk images and container + directories and subvolumes in + /var/lib/machines/ (and other search + paths, see below). Use start (see above) to + run a container off one of the listed images. Note that, by + default, containers whose name begins with a dot + (.) are not shown. To show these too, + specify . Note that a special image + .host always implicitly exists and refers + to the image the host itself is booted from. + + + + image-status [NAME…] + + Show terse status information about one or + more container or VM images. This function is intended to + generate human-readable output. Use + show-image (see below) to generate + computer-parsable output instead. + + + + show-image [NAME…] + + Show properties of one or more registered + virtual machine or container images, or the manager itself. If + no argument is specified, properties of the manager will be + shown. If a NAME is specified, properties of this virtual + machine or container image are shown. By default, empty + properties are suppressed. Use to show + those too. To select specific properties to show, use + . This command is intended to be + used whenever computer-parsable output is required. Use + image-status if you are looking for + formatted human-readable output. + + + + clone NAME NAME + + Clones a container or VM image. The arguments specify the name of the image to clone and the + name of the newly cloned image. Note that plain directory container images are cloned into btrfs subvolume + images with this command, if the underlying file system supports this. Note that cloning a container or VM + image is optimized for file systems that support copy-on-write, and might not be efficient on others, due to + file system limitations. + + Note that this command leaves hostname, machine ID and + all other settings that could identify the instance + unmodified. The original image and the cloned copy will hence + share these credentials, and it might be necessary to manually + change them in the copy. + + If combined with the switch a read-only cloned image is + created. + + + + rename NAME NAME + + Renames a container or VM image. The + arguments specify the name of the image to rename and the new + name of the image. + + + + read-only NAME [BOOL] + + Marks or (unmarks) a container or VM image + read-only. Takes a VM or container image name, followed by a + boolean as arguments. If the boolean is omitted, positive is + implied, i.e. the image is marked read-only. + + + + remove NAME… + + Removes one or more container or VM images. + The special image .host, which refers to + the host's own directory tree, may not be + removed. + + + + set-limit [NAME] BYTES + + Sets the maximum size in bytes that a specific + container or VM image, or all images, may grow up to on disk + (disk quota). Takes either one or two parameters. The first, + optional parameter refers to a container or VM image name. If + specified, the size limit of the specified image is changed. If + omitted, the overall size limit of the sum of all images stored + locally is changed. The final argument specifies the size + limit in bytes, possibly suffixed by the usual K, M, G, T + units. If the size limit shall be disabled, specify + - as size. + + Note that per-container size limits are only supported on btrfs file systems. + + + + clean + + Remove hidden VM or container images (or all). This command removes all hidden machine images + from /var/lib/machines/, i.e. those whose name begins with a dot. Use machinectl + list-images --all to see a list of all machine images, including the hidden ones. + + When combined with the switch removes all images, not just hidden ones. This + command effectively empties /var/lib/machines/. + + Note that commands such as machinectl pull-tar or machinectl + pull-raw usually create hidden, read-only, unmodified machine images from the downloaded image first, + before cloning a writable working copy of it, in order to avoid duplicate downloads in case of images that are + reused multiple times. Use machinectl clean to remove old, hidden images created this + way. + + + + + Image Transfer Commands + + + pull-tar URL [NAME] + + Downloads a .tar + container image from the specified URL, and makes it available + under the specified local machine name. The URL must be of + type http:// or + https://, and must refer to a + .tar, .tar.gz, + .tar.xz or .tar.bz2 + archive file. If the local machine name is omitted, it + is automatically derived from the last component of the URL, + with its suffix removed. + + The image is verified before it is made available, unless + is specified. + Verification is done either via an inline signed file with the name + of the image and the suffix .sha256 or via + separate SHA256SUMS and + SHA256SUMS.gpg files. + The signature files need to be made available on the same web + server, under the same URL as the .tar file. + With , only the SHA256 checksum + for the file is verified, based on the .sha256 + suffixed file or the SHA256SUMS file. + With , the sha checksum file is + first verified with the inline signature in the + .sha256 file or the detached GPG signature file + SHA256SUMS.gpg. + The public key for this verification step needs to be available in + /usr/lib/systemd/import-pubring.gpg or + /etc/systemd/import-pubring.gpg. + + The container image will be downloaded and stored in a + read-only subvolume in + /var/lib/machines/ that is named after + the specified URL and its HTTP etag. A writable snapshot is + then taken from this subvolume, and named after the specified + local name. This behavior ensures that creating multiple + container instances of the same URL is efficient, as multiple + downloads are not necessary. In order to create only the + read-only image, and avoid creating its writable snapshot, + specify - as local machine name. + + Note that the read-only subvolume is prefixed with + .tar-, and is thus not shown by + list-images, unless + is passed. + + Note that pressing C-c during execution of this command + will not abort the download. Use + cancel-transfer, described + below. + + + + pull-raw URL [NAME] + + Downloads a .raw + container or VM disk image from the specified URL, and makes + it available under the specified local machine name. The URL + must be of type http:// or + https://. The container image must either + be a .qcow2 or raw disk image, optionally + compressed as .gz, + .xz, or .bz2. If the + local machine name is omitted, it is automatically + derived from the last component of the URL, with its suffix + removed. + + Image verification is identical for raw and tar images + (see above). + + If the downloaded image is in + .qcow2 format it is converted into a raw + image file before it is made available. + + Downloaded images of this type will be placed as + read-only .raw file in + /var/lib/machines/. A local, writable + (reflinked) copy is then made under the specified local + machine name. To omit creation of the local, writable copy + pass - as local machine name. + + Similarly to the behavior of pull-tar, the read-only image is prefixed with + .raw-, and thus not shown by list-images, unless + is passed. + + Note that pressing C-c during execution of this command + will not abort the download. Use + cancel-transfer, described + below. + + + + import-tar FILE [NAME] + import-raw FILE [NAME] + Imports a TAR or RAW container or VM image, + and places it under the specified name in + /var/lib/machines/. When + import-tar is used, the file specified as + the first argument should be a tar archive, possibly compressed + with xz, gzip or bzip2. It will then be unpacked into its own + subvolume in /var/lib/machines/. When + import-raw is used, the file should be a + qcow2 or raw disk image, possibly compressed with xz, gzip or + bzip2. If the second argument (the resulting image name) is + not specified, it is automatically derived from the file + name. If the filename is passed as -, the + image is read from standard input, in which case the second + argument is mandatory. + + Optionally, the switch may be used to create a read-only container or VM + image. No cryptographic validation is done when importing the images. + + Much like image downloads, ongoing imports may be listed + with list-transfers and aborted with + cancel-transfer. + + + + import-fs DIRECTORY [NAME] + + Imports a container image stored in a local directory into + /var/lib/machines/, operates similarly to import-tar or + import-raw, but the first argument is the source directory. If supported, this + command will create a btrfs snapshot or subvolume for the new image. + + + + export-tar NAME [FILE] + export-raw NAME [FILE] + Exports a TAR or RAW container or VM image and + stores it in the specified file. The first parameter should be + a VM or container image name. The second parameter should be a + file path the TAR or RAW image is written to. If the path ends + in .gz, the file is compressed with gzip, if + it ends in .xz, with xz, and if it ends in + .bz2, with bzip2. If the path ends in + neither, the file is left uncompressed. If the second argument + is missing, the image is written to standard output. The + compression may also be explicitly selected with the + switch. This is in particular + useful if the second parameter is left unspecified. + + Much like image downloads and imports, ongoing exports + may be listed with list-transfers and + aborted with + cancel-transfer. + + Note that, currently, only directory and subvolume images + may be exported as TAR images, and only raw disk images as RAW + images. + + + + list-transfers + + Shows a list of container or VM image + downloads, imports and exports that are currently in + progress. + + + + cancel-transfer ID… + + Aborts a download, import or export of the + container or VM image with the specified ID. To list ongoing + transfers and their IDs, use + list-transfers. + + + + + + + + Options + + The following options are understood: + + + + + + + When showing machine or image properties, + limit the output to certain properties as specified by the + argument. If not specified, all set properties are shown. The + argument should be a property name, such as + Name. If specified more than once, all + properties with the specified names are + shown. + + + + + + + When showing machine or image properties, show + all properties regardless of whether they are set or + not. + + When listing VM or container images, do not suppress + images beginning in a dot character + (.). + + When cleaning VM or container images, remove all images, not just hidden ones. + + + + + + When printing properties with show, only print the value, + and skip the property name and =. + + + + + + + Do not ellipsize process tree entries or table. This implies + . + + + + + + + When used with kill, choose + which processes to kill. Must be one of + , or to select + whether to kill only the leader process of the machine or all + processes of the machine. If omitted, defaults to + . + + + + + + + + When used with the shell command, chooses the user ID to + open the interactive shell session as. If the argument to the shell + command also specifies a user name, this option is ignored. If the name is not specified + in either way, root will be used by default. Note that this switch is + not supported for the login command (see below). + + + + + + + When used with the shell command, sets an environment variable for + the executed shell. This option may be used more than once to set multiple variables. When + = and VALUE are omitted, the value of the variable with + the same name in the program environment will be used. + + Note that this option is not supported for the login command. + + + + + + + When used with bind, creates the destination file or directory before + applying the bind mount. Note that even though the name of this option suggests that it is suitable only for + directories, this option also creates the destination file node to mount over if the object to mount is not + a directory, but a regular file, device node, socket or FIFO. + + + + + + When used with bind, creates a read-only bind mount. + + When used with clone, import-raw or import-tar a + read-only container or VM image is created. + + + + + + + When used with status, + controls the number of journal lines to show, counting from + the most recent ones. Takes a positive integer argument. + Defaults to 10. + + + + + + + + When used with status, + controls the formatting of the journal entries that are shown. + For the available choices, see + journalctl1. + Defaults to short. + + + + + + When downloading a container or VM image, + specify whether the image shall be verified before it is made + available. Takes one of no, + checksum and signature. + If no, no verification is done. If + checksum is specified, the download is + checked for integrity after the transfer is complete, but no + signatures are verified. If signature is + specified, the checksum is verified and the image's signature + is checked against a local keyring of trustable vendors. It is + strongly recommended to set this option to + signature if the server and protocol + support this. Defaults to + signature. + + + + + + When downloading a container or VM image, and + a local copy by the specified local machine name already + exists, delete it first and replace it by the newly downloaded + image. + + + + + + When used with the + or commands, specifies the + compression format to use for the resulting file. Takes one of + uncompressed, xz, + gzip, bzip2. By default, + the format is determined automatically from the image file + name passed. + + + + + + When used with the command, limits the number of IP + addresses shown for every machine. Defaults to 1. All addresses can be requested with + all. If the limit is 0, the address column is not shown. Otherwise, if the machine + has more addresses than shown, … follows the last address. + + + + + + + Suppresses additional informational output while running. + + + + + + + + + Connect to + systemd-machined.service8 + running in a local container, to perform the specified operation within + the container. + + + + + + + + + + + + Machine and Image Names + + The machinectl tool operates on machines + and images whose names must be chosen following strict + rules. Machine names must be suitable for use as hostnames + following a conservative subset of DNS and UNIX/Linux + semantics. Specifically, they must consist of one or more + non-empty label strings, separated by dots. No leading or trailing + dots are allowed. No sequences of multiple dots are allowed. The + label strings may only consist of alphanumeric characters as well + as the dash and underscore. The maximum length of a machine name + is 64 characters. + + A special machine with the name .host + refers to the running host system itself. This is useful for execution + operations or inspecting the host system as well. Note that + machinectl list will not show this special + machine unless the switch is specified. + + Requirements on image names are less strict, however, they must be + valid UTF-8, must be suitable as file names (hence not be the + single or double dot, and not include a slash), and may not + contain control characters. Since many operations search for an + image by the name of a requested machine, it is recommended to name + images in the same strict fashion as machines. + + A special image with the name .host + refers to the image of the running host system. It hence + conceptually maps to the special .host machine + name described above. Note that machinectl + list-images will not show this special image either, unless + is specified. + + + + Files and Directories + + Machine images are preferably stored in + /var/lib/machines/, but are also searched for + in /usr/local/lib/machines/ and + /usr/lib/machines/. For compatibility reasons, + the directory /var/lib/container/ is + searched, too. Note that images stored below + /usr/ are always considered read-only. It is + possible to symlink machines images from other directories into + /var/lib/machines/ to make them available for + control with machinectl. + + Note that some image operations are only supported, efficient or atomic on btrfs file systems. + + Disk images are understood by + systemd-nspawn1 + and machinectl in three formats: + + + A simple directory tree, containing the files + and directories of the container to boot. + + Subvolumes (on btrfs file systems), which are + similar to the simple directories, described above. However, + they have additional benefits, such as efficient cloning and + quota reporting. + + "Raw" disk images, i.e. binary images of disks + with a GPT or MBR partition table. Images of this type are + regular files with the suffix + .raw. + + + See + systemd-nspawn1 + for more information on image formats, in particular its + and + options. + + + + Examples + + Download an Ubuntu image and open a shell in it + + # machinectl pull-tar https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz +# systemd-nspawn -M trusty-server-cloudimg-amd64-root + + This downloads and verifies the specified + .tar image, and then uses + systemd-nspawn1 + to open a shell in it. + + + + Download a Fedora image, set a root password in it, start + it as a service + + # machinectl pull-raw --verify=no \ + https://download.fedoraproject.org/pub/fedora/linux/releases/&fedora_latest_version;/Cloud/x86_64/images/Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw.xz \ + Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 +# systemd-nspawn -M Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 +# passwd +# exit +# machinectl start Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 +# machinectl login Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 + + This downloads the specified .raw + image with verification disabled. Then, a shell is opened in it + and a root password is set. Afterwards the shell is left, and + the machine started as system service. With the last command a + login prompt into the container is requested. + + + + Exports a container image as tar file + + # machinectl export-tar fedora myfedora.tar.xz + + Exports the container fedora as an + xz-compressed tar file myfedora.tar.xz into the + current directory. + + + + Create a new shell session + + # machinectl shell --uid=lennart + + This creates a new shell session on the local host for + the user ID lennart, in a su1-like + fashion. + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + + + See Also + + systemd1, + systemd-machined.service8, + systemd-nspawn1, + systemd.special7, + tar1, + xz1, + gzip1, + bzip21 + + + + diff --git a/man/man.in b/man/man.in new file mode 100755 index 0000000..201c32d --- /dev/null +++ b/man/man.in @@ -0,0 +1,30 @@ +#!/bin/sh +# SPDX-License-Identifier: LGPL-2.1-or-later + +set -e + +if [ -z "$1" ]; then + echo "Use: $0 page-name (with no section suffix)" + exit 1 +fi + +# make sure the rules have been regenerated (in case update-man-rules was just run) +ninja -C "@BUILD_ROOT@" version.h + +page="$(echo "$1" | sed 's/\./\\./')" +target=$(ninja -C "@BUILD_ROOT@" -t query man/man | grep -E -m1 "man/$page\.[0-9]$" | awk '{print $2}') +if [ -z "$target" ]; then + echo "Cannot find page $1" + exit 1 +fi +ninja -C "@BUILD_ROOT@" "$target" + +fullname="@BUILD_ROOT@/$target" +redirect="$(sed -n -r '1 s|^\.so man[0-9]/(.*)|\1|p' "$fullname")" +if [ -n "$redirect" ]; then + ninja -C "@BUILD_ROOT@" "man/$redirect" + + fullname="@BUILD_ROOT@/man/$redirect" +fi + +exec man "$fullname" diff --git a/man/meson.build b/man/meson.build new file mode 100644 index 0000000..b7725ce --- /dev/null +++ b/man/meson.build @@ -0,0 +1,240 @@ +# SPDX-License-Identifier: LGPL-2.1-or-later + +# This is lame, I know, but meson has no other include mechanism +subdir('rules') + +want_man = get_option('man') +want_html = get_option('html') +xsltproc = find_program('xsltproc', + required : want_man == 'true' or want_html == 'true') +want_man = want_man != 'false' and xsltproc.found() +want_html = want_html != 'false' and xsltproc.found() + +xsltproc_flags = [ + '--nonet', + '--xinclude', + '--maxdepth', '9000', + '--stringparam', 'man.output.quietly', '1', + '--stringparam', 'funcsynopsis.style', 'ansi', + '--stringparam', 'man.authors.section.enabled', '0', + '--stringparam', 'man.copyright.section.enabled', '0', + '--stringparam', 'systemd.version', '@0@'.format(meson.project_version()), + '--path', + '@0@:@1@'.format(meson.current_build_dir(), meson.current_source_dir())] + +custom_man_xsl = files('custom-man.xsl') +custom_html_xsl = files('custom-html.xsl') +xslt_cmd = [xsltproc, '-o', '@OUTPUT0@'] + xsltproc_flags + +custom_entities_ent = custom_target( + 'custom-entities.ent', + input : 'custom-entities.ent.in', + output : 'custom-entities.ent', + command : [jinja2_cmdline, '@INPUT@', '@OUTPUT@']) + +man_pages = [] +html_pages = [] +source_xml_files = [] +dbus_docs = [] +foreach tuple : manpages + stem = tuple[0] + section = tuple[1] + aliases = tuple[2] + condition = tuple[3] + + xml = stem + '.xml' + html = stem + '.html' + man = stem + '.' + section + + manaliases = [] + htmlaliases = [] + foreach alias : aliases + manaliases += alias + '.' + section + htmlaliases += alias + '.html' + endforeach + + mandirn = get_option('mandir') / ('man' + section) + + if condition == '' or conf.get(condition) == 1 + file = files(tuple[0] + '.xml') + source_xml_files += file + if tuple[0].startswith('org.freedesktop.') + dbus_docs += file + endif + + if xsltproc.found() + p1 = custom_target( + man, + input : xml, + output : [man] + manaliases, + command : xslt_cmd + [custom_man_xsl, '@INPUT@'], + depends : custom_entities_ent, + install : want_man, + install_dir : mandirn) + man_pages += p1 + + p2 = [] + foreach htmlalias : htmlaliases + link = custom_target( + htmlalias, + output : htmlalias, + command : [ln, '-fs', html, '@OUTPUT@']) + if want_html + dst = docdir / 'html' / htmlalias + cmd = 'ln -fs @0@ $DESTDIR@1@'.format(html, dst) + meson.add_install_script('sh', '-c', cmd) + p2 += link + endif + html_pages += link + endforeach + + p3 = custom_target( + html, + input : xml, + output : html, + command : xslt_cmd + [custom_html_xsl, '@INPUT@'], + depends : [custom_entities_ent, p2], + install : want_html, + install_dir : docdir / 'html') + html_pages += p3 + endif + else + message('Skipping @0@.@1@ because @2@ is false'.format(stem, section, condition)) + endif +endforeach + +############################################################ + +have_lxml = run_command(xml_helper_py, check: false).returncode() == 0 +if not have_lxml + message('python-lxml not available, not making man page indices') +endif + +systemd_directives_xml = custom_target( + 'systemd.directives.xml', + input : ['directives-template.xml', source_xml_files], + output : 'systemd.directives.xml', + depends : custom_entities_ent, + command : [make_directive_index_py, '@OUTPUT@', '@INPUT@']) + +nonindex_xml_files = source_xml_files + [systemd_directives_xml] +systemd_index_xml = custom_target( + 'systemd.index.xml', + input : nonindex_xml_files, + output : 'systemd.index.xml', + command : [make_man_index_py, '@OUTPUT@'] + nonindex_xml_files) + +foreach tuple : xsltproc.found() ? [['systemd.directives', '7', systemd_directives_xml], + ['systemd.index', '7', systemd_index_xml]] : [] + stem = tuple[0] + section = tuple[1] + xml = tuple[2] + + html = stem + '.html' + man = stem + '.' + section + + mandirn = get_option('mandir') / ('man' + section) + + p1 = custom_target( + man, + input : xml, + output : man, + command : xslt_cmd + [custom_man_xsl, '@INPUT@'], + install : want_man and have_lxml, + install_dir : mandirn) + man_pages += p1 + + p2 = [] + if html == 'systemd.index.html' + htmlalias = 'index.html' + link = custom_target( + htmlalias, + input : p2, + output : htmlalias, + command : [ln, '-fs', html, '@OUTPUT@']) + if want_html + dst = docdir / 'html' / htmlalias + cmd = 'ln -fs @0@ $DESTDIR@1@'.format(html, dst) + meson.add_install_script('sh', '-c', cmd) + p2 += link + endif + html_pages += link + endif + + p3 = custom_target( + html, + input : xml, + output : html, + command : xslt_cmd + [custom_html_xsl, '@INPUT@'], + depends : [custom_entities_ent, p2], + install : want_html and have_lxml, + install_dir : docdir / 'html') + html_pages += p3 +endforeach + +# Cannot use run_target because those targets are used in depends +# Also see https://github.com/mesonbuild/meson/issues/368. +man = custom_target( + 'man', + output : 'man', + depends : man_pages, + command : [echo]) + +html = custom_target( + 'html', + output : 'html', + depends : html_pages, + command : [echo]) + +if rsync.found() + run_target( + 'doc-sync', + depends : man_pages + html_pages, + command : [rsync, '-rlv', + '--delete-excluded', + '--include=man', + '--include=*.html', + '--exclude=*', + '--omit-dir-times', + meson.current_build_dir(), + get_option('www-target')]) +endif + +############################################################ + +buildroot_substs = configuration_data() +buildroot_substs.set_quoted('BUILD_ROOT', project_build_root) + +configure_file( + input : 'man.in', + output : 'man', + configuration : buildroot_substs) + +configure_file( + input : 'html.in', + output : 'html', + configuration : buildroot_substs) + +############################################################ + +update_dbus_docs = custom_target( + 'update-dbus-docs', + output : 'update-dbus-docs', + command : [update_dbus_docs_py, '--build-dir', project_build_root, '@INPUT@'], + input : dbus_docs) + +if conf.get('BUILD_MODE_DEVELOPER') == 1 + test('dbus-docs-fresh', + update_dbus_docs_py, + suite : 'dist-check', + args : ['--build-dir', project_build_root, '--test', dbus_docs], + depends : dbus_programs) +endif + +update_man_rules = custom_target( + 'update-man-rules', + output : 'update-man-rules', + command : [update_man_rules_py, + '@0@/man/*.xml'.format(project_source_root), + '@0@/rules/meson.build'.format(meson.current_source_dir())], + depends : custom_entities_ent) diff --git a/man/modules-load.d.xml b/man/modules-load.d.xml new file mode 100644 index 0000000..cd0c006 --- /dev/null +++ b/man/modules-load.d.xml @@ -0,0 +1,76 @@ + + + + + + + + modules-load.d + systemd + + + + modules-load.d + 5 + + + + modules-load.d + Configure kernel modules to load at boot + + + + /etc/modules-load.d/*.conf + /run/modules-load.d/*.conf + /usr/lib/modules-load.d/*.conf + + + + Description + + systemd-modules-load.service8 + reads files from the above directories which contain kernel + modules to load during boot in a static list. Each configuration + file is named in the style of + /etc/modules-load.d/program.conf. + Note that it is usually a better idea to rely on the automatic + module loading by PCI IDs, USB IDs, DMI IDs or similar triggers + encoded in the kernel modules themselves instead of static + configuration like this. In fact, most modern kernel modules are + prepared for automatic loading already. + + + + Configuration Format + + The configuration files should simply contain a list of + kernel module names to load, separated by newlines. Empty lines + and lines whose first non-whitespace character is # or ; are + ignored. + + + + + + Example + + /etc/modules-load.d/virtio-net.conf example: + + # Load virtio-net.ko at boot +virtio-net + + + + + See Also + + systemd1, + systemd-modules-load.service8, + systemd-delta1, + modprobe8 + + + + diff --git a/man/networkctl.xml b/man/networkctl.xml new file mode 100644 index 0000000..96c4c29 --- /dev/null +++ b/man/networkctl.xml @@ -0,0 +1,434 @@ + + + + + + + + networkctl + systemd + + + + networkctl + 1 + + + + networkctl + Query or modify the status of network links + + + + + networkctl + OPTIONS + COMMAND + LINK + + + + + Description + + networkctl may be used to query or modify the + state of the network links as seen by + systemd-networkd. Please refer to + systemd-networkd.service8 + for an introduction to the basic concepts, functionality, and + configuration syntax. + + + + Commands + + The following commands are understood: + + + + + list + PATTERN… + + + + Show a list of existing links and their status. If one or more + PATTERNs are specified, only links matching one of them are shown. + If no further arguments are specified shows all links, + otherwise just the specified links. Produces output similar to: + + IDX LINK TYPE OPERATIONAL SETUP + 1 lo loopback carrier unmanaged + 2 eth0 ether routable configured + 3 virbr0 ether no-carrier unmanaged + 4 virbr0-nic ether off unmanaged + +4 links listed. + + The operational status is one of the following: + + + missing + + the device is missing + + + + off + + the device is powered down + + + + no-carrier + + the device is powered up, but it does not yet have a carrier + + + + dormant + + the device has a carrier, but is not yet ready for normal traffic + + + + degraded-carrier + + one of the bonding or bridge slave network interfaces is in off, no-carrier, or dormant state, and the master interface has no address. + + + + carrier + + the link has a carrier, or for bond or bridge master, all bonding or bridge slave + network interfaces are enslaved to the master + + + + degraded + + the link has carrier and addresses valid on the local link configured. For bond or + bridge master this means that not all slave network interfaces have carrier but at least + one does. + + + + enslaved + + the link has carrier and is enslaved to bond or bridge master network interface + + + + routable + + the link has carrier and routable address configured. For bond or bridge master it is + not necessary for all slave network interfaces to have carrier, but at least one must. + + + + + + The setup status is one of the following: + + + pending + + udev is still processing the link, we don't yet know if we will manage it + + + + initialized + + udev has processed the link, but we don't yet know if we will manage it + + + + configuring + + in the process of retrieving configuration or configuring the link + + + + configured + + link configured successfully + + + + unmanaged + + networkd is not handling the link + + + + failed + + networkd failed to manage the link + + + + linger + + the link is gone, but has not yet been dropped by networkd + + + + + + + + + + status + PATTERN… + + + + Show information about the specified links: type, state, kernel module driver, hardware and + IP address, configured DNS servers, etc. If one or more PATTERNs are + specified, only links matching one of them are shown. + + When no links are specified, an overall network status is shown. Also see the option + . + + Produces output similar to: + +● State: routable + Online state: online + Address: 10.193.76.5 on eth0 + 192.168.122.1 on virbr0 + 169.254.190.105 on eth0 + fe80::5054:aa:bbbb:cccc on eth0 + Gateway: 10.193.11.1 (CISCO SYSTEMS, INC.) on eth0 + DNS: 8.8.8.8 + 8.8.4.4 + + In the overall network status, the online state depends on the individual online state of all + required links. Managed links are required for online by default. In this case, the online state is + one of the following: + + + unknown + + all links have unknown online status (i.e. there are no required links) + + + + offline + + all required links are offline + + + + partial + + some, but not all, required links are online + + + + online + + all required links are online + + + + + + + + + + + lldp + PATTERN… + + + + Show discovered LLDP (Link Layer Discovery Protocol) neighbors. If one or more + PATTERNs are specified only neighbors on those interfaces are shown. + Otherwise shows discovered neighbors on all interfaces. Note that for this feature to work, + LLDP= must be turned on for the specific interface, see + systemd.network5 for + details. + + Produces output similar to: + LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION +enp0s25 00:e0:4c:00:00:00 GS1900 ..b........ 2 Port #2 + +Capability Flags: +o - Other; p - Repeater; b - Bridge; w - WLAN Access Point; r - Router; +t - Telephone; d - DOCSIS cable device; a - Station; c - Customer VLAN; +s - Service VLAN, m - Two-port MAC Relay (TPMR) + +1 neighbors listed. + + + + + + label + + + Show numerical address labels that can be used for address selection. + This is the same information that + ip-addrlabel8 + shows. See RFC 3484 + for a discussion of address labels. + + Produces output similar to: + Prefix/Prefixlen Label + ::/0 1 + fc00::/7 5 + fec0::/10 11 + 2002::/16 2 + 3ffe::/16 12 + 2001:10::/28 7 + 2001::/32 6 +::ffff:0.0.0.0/96 4 + ::/96 3 + ::1/128 0 + + + + + + delete + DEVICE… + + Deletes virtual netdevs. Takes interface name or index number. + + + + + up + DEVICE… + + Bring devices up. Takes interface name or index number. + + + + + down + DEVICE… + + Bring devices down. Takes interface name or index number. + + + + + renew + DEVICE… + + Renew dynamic configurations e.g. addresses received from DHCP server. + Takes interface name or index number. + + + + + forcerenew + DEVICE… + + Send a FORCERENEW message to all connected clients, triggering DHCP reconfiguration. + Takes interface name or index number. + + + + + reconfigure + DEVICE… + + Reconfigure network interfaces. Takes interface name or index number. Note that + this does not reload .netdev or .network + corresponding to the specified interface. So, if you edit config files, it is necessary to call + networkctl reload first to apply new settings. + + + + + reload + + Reload .netdev and .network files. + If a new .netdev file is found, then the corresponding netdev is created. + Note that even if an existing .netdev is modified or removed, + systemd-networkd does not update or remove the netdev. + If a new, modified or removed .network file is found, then all interfaces + which match the file are reconfigured. + + + + + + + Options + + The following options are understood: + + + + + + + + + + Show all links with status. + + + + + + + + + + + Show link statistics with status. + + + + + + + + + Do not ellipsize the output. + + + + + + + + + When used with status, controls the number of journal lines to show, + counting from the most recent ones. Takes a positive integer argument. Defaults to 10. + + + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + See Also + + systemd-networkd.service8, + systemd.network5, + systemd.netdev5, + ip8 + + + diff --git a/man/networkd.conf.xml b/man/networkd.conf.xml new file mode 100644 index 0000000..85b21ee --- /dev/null +++ b/man/networkd.conf.xml @@ -0,0 +1,221 @@ + + + + + + + + networkd.conf + systemd + + + + networkd.conf + 5 + + + + networkd.conf + networkd.conf.d + Global Network configuration files + + + + /etc/systemd/networkd.conf + /etc/systemd/networkd.conf.d/*.conf + /usr/lib/systemd/networkd.conf.d/*.conf + + + + Description + + These configuration files control global network parameters. + Currently the DHCP Unique Identifier (DUID). + + + + + + + [Network] Section Options + + The following options are available in the [Network] section: + + + + SpeedMeter= + Takes a boolean. If set to yes, then systemd-networkd + measures the traffic of each interface, and + networkctl status INTERFACE shows the measured speed. + Defaults to no. + + + + SpeedMeterIntervalSec= + Specifies the time interval to calculate the traffic speed of each interface. + If SpeedMeter=no, the value is ignored. Defaults to 10sec. + + + + ManageForeignRoutingPolicyRules= + A boolean. When true, systemd-networkd will remove rules + that are not configured in .network files (except for rules with protocol + kernel). When false, it will not remove any foreign rules, keeping them even + if they are not configured in a .network file. Defaults to yes. + + + + + ManageForeignRoutes= + A boolean. When true, systemd-networkd will remove routes + that are not configured in .network files (except for routes with protocol + kernel, dhcp when KeepConfiguration= + is true or dhcp, and static when + KeepConfiguration= is true or static). When false, it will + not remove any foreign routes, keeping them even if they are not configured in a .network file. + Defaults to yes. + + + + RouteTable= + Defines the route table name. Takes a whitespace-separated list of the pairs of + route table name and number. The route table name and number in each pair are separated with a + colon, i.e., name:number. + The route table name must not be default, main, or + local, as these route table names are predefined with route table number 253, + 254, and 255, respectively. The route table number must be an integer in the range 1…4294967295. + This setting can be specified multiple times. If an empty string is specified, then the list + specified earlier are cleared. Defaults to unset. + + + + + + + [DHCPv4] Section Options + + This section configures the DHCP Unique Identifier (DUID) value used by DHCP protocol. DHCPv4 + client protocol sends IAID and DUID to the DHCP server when acquiring a dynamic IPv4 address if + . IAID and DUID allows a DHCP server to uniquely identify the + machine and the interface requesting a DHCP IP address. To configure IAID and ClientIdentifier, see + systemd.network5. + + + The following options are understood: + + + + DUIDType= + Specifies how the DUID should be generated. See + RFC 3315 + for a description of all the options. + + The following values are understood: + + + + If DUIDType=vendor, then the DUID value will be generated using + 43793 as the vendor identifier (systemd) and hashed contents of + machine-id5. + This is the default if DUIDType= is not specified. + + + + + + If DUIDType=uuid, and DUIDRawData= is not set, + then the product UUID is used as a DUID value. If a system does not have valid product UUID, then + an application-specific + machine-id5 + is used as a DUID value. About the application-specific machine ID, see + sd_id128_get_machine_app_specific3. + + + + + + + If link-layer-time or link-layer is specified, + then the MAC address of the interface is used as a DUID value. The value link-layer-time + can take additional time value after a colon, e.g. link-layer-time:2018-01-23 12:34:56 UTC. + The default time value is 2000-01-01 00:00:00 UTC. + + + + + + In all cases, DUIDRawData= can be used to override the + actual DUID value that is used. + + + + DUIDRawData= + Specifies the DHCP DUID value as a single newline-terminated, hexadecimal string, with each + byte separated by :. The DUID that is sent is composed of the DUID type specified by + DUIDType= and the value configured here. + + The DUID value specified here overrides the DUID that + systemd-networkd.service8 + generates from the machine ID. To configure DUID per-network, see + systemd.network5. + The configured DHCP DUID should conform to the specification in + RFC 3315, + RFC 6355. To configure IAID, see + systemd.network5 + . + + + A <option>DUIDType=vendor</option> with a custom value + + DUIDType=vendor +DUIDRawData=00:00:ab:11:f9:2a:c2:77:29:f9:5c:00 + + This specifies a 14 byte DUID, with the type DUID-EN (00:02), enterprise number + 43793 (00:00:ab:11), and identifier value f9:2a:c2:77:29:f9:5c:00. + + + + + + + + + [DHCPv6] Section Options + + This section configures the DHCP Unique Identifier (DUID) value used by DHCPv6 protocol. + DHCPv6 client protocol sends the DHCP Unique Identifier and the interface Identity Association + Identifier (IAID) to a DHCPv6 server when acquiring a dynamic IPv6 address. IAID and DUID allows a + DHCPv6 server to uniquely identify the machine and the interface requesting a DHCP IP address. To + configure IAID, see + systemd.network5. + + + The following options are understood: + + + + DUIDType= + DUIDRawData= + As in the [DHCPv4] section. + + + + + + See Also + + systemd1, + systemd.network5, + systemd-networkd.service8, + machine-id5, + sd_id128_get_machine_app_specific3 + + + + diff --git a/man/nss-myhostname.xml b/man/nss-myhostname.xml new file mode 100644 index 0000000..b6544cf --- /dev/null +++ b/man/nss-myhostname.xml @@ -0,0 +1,138 @@ + + + + + + + + nss-myhostname + systemd + + + + nss-myhostname + 8 + + + + nss-myhostname + libnss_myhostname.so.2 + Hostname resolution for the locally configured system hostname + + + + libnss_myhostname.so.2 + + + + Description + + nss-myhostname is a plug-in module for the GNU Name Service Switch (NSS) functionality of + the GNU C Library (glibc), primarily providing hostname resolution for the locally configured + system hostname as returned by + gethostname2. The precise + hostnames resolved by this module are: + + + The local, configured hostname is resolved to + all locally configured IP addresses ordered by their scope, or + — if none are configured — the IPv4 address 127.0.0.2 (which + is on the local loopback) and the IPv6 address ::1 (which is the + local host). + + The hostnames localhost and + localhost.localdomain (as well as any hostname + ending in .localhost or .localhost.localdomain) + are resolved to the IP addresses 127.0.0.1 and ::1. + + The hostname _gateway is + resolved to all current default routing gateway addresses, + ordered by their metric. This assigns a stable hostname to the + current gateway, useful for referencing it independently of the + current network configuration state. + + The hostname _outbound is resolved to the local IPv4 and IPv6 + addresses that are most likely used for communication with other hosts. This is determined by + requesting a routing decision to the configured default gateways from the kernel and then using the + local IP addresses selected by this decision. This hostname is only available if there is at least one + local default gateway configured. This assigns a stable hostname to the local outbound IP addresses, + useful for referencing them independently of the current network configuration state. + + + Various software relies on an always-resolvable local + hostname. When using dynamic hostnames, this is traditionally + achieved by patching /etc/hosts at the same + time as changing the hostname. This is problematic since it + requires a writable /etc/ file system and is + fragile because the file might be edited by the administrator at + the same time. With nss-myhostname enabled, + changing /etc/hosts is unnecessary, and on + many systems, the file becomes entirely optional. + + To activate the NSS modules, add myhostname to the line starting with + hosts: in /etc/nsswitch.conf. + + It is recommended to place myhostname after file and before dns. + This resolves well-known hostnames like localhost + and the machine hostnames locally. It is consistent with the behaviour + of nss-resolve, and still allows overriding via + /etc/hosts. + + Please keep in mind that nss-myhostname (and nss-resolve) also resolve + in the other direction — from locally attached IP addresses to + hostnames. If you rely on that lookup being provided by DNS, you might + want to order things differently. + + + + + Example + + Here is an example /etc/nsswitch.conf file that enables + nss-myhostname correctly: + + +passwd: compat systemd +group: compat [SUCCESS=merge] systemd +shadow: compat systemd +gshadow: files systemd + + +hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis + + To test, use glibc's getent tool: + + $ getent ahosts `hostname` +::1 STREAM omega +::1 DGRAM +::1 RAW +127.0.0.2 STREAM +127.0.0.2 DGRAM +127.0.0.2 RAW + + In this case, the local hostname is omega. + + + + + See Also + + systemd1, + nss-systemd8, + nss-resolve8, + nss-mymachines8, + nsswitch.conf5, + getent1 + + + + diff --git a/man/nss-mymachines.xml b/man/nss-mymachines.xml new file mode 100644 index 0000000..baec109 --- /dev/null +++ b/man/nss-mymachines.xml @@ -0,0 +1,137 @@ + + + + + + + + nss-mymachines + systemd + + + + nss-mymachines + 8 + + + + nss-mymachines + libnss_mymachines.so.2 + Hostname resolution for local container instances + + + + libnss_mymachines.so.2 + + + + Description + + nss-mymachines is a plug-in module for the GNU Name Service Switch (NSS) functionality of + the GNU C Library (glibc), providing hostname resolution for the names of containers running + locally that are registered with + systemd-machined.service8. The + container names are resolved to the IP addresses of the specific container, ordered by their scope. This + functionality only applies to containers using network namespacing (see the description of + in + systemd-nspawn1). + Note that the name that is resolved is the one registered with systemd-machined, which + may be different than the hostname configured inside of the container. + + Note that this NSS module only makes available names of the containers running immediately below + the current system context. It does not provide host name resolution for containers running side-by-side + with the invoking system context, or containers further up or down the container hierarchy. Or in other + words, on the host system it provides host name resolution for the containers running immediately below + the host environment. When used inside a container environment however, it will not be able to provide + name resolution for containers running on the host (as those are siblings and not children of the current + container environment), but instead only for nested containers running immediately below its own + container environment. + + To activate the NSS module, add mymachines to the line starting with + hosts: in /etc/nsswitch.conf. + + It is recommended to place mymachines before the resolve or + dns entry of the hosts: line of + /etc/nsswitch.conf in order to make sure that its mappings are preferred over other + resolvers such as DNS. + + + + Configuration in <filename>/etc/nsswitch.conf</filename> + + Here is an example /etc/nsswitch.conf file that enables + nss-mymachines correctly: + + + passwd: compat systemd +group: compat [SUCCESS=merge] systemd +shadow: compat systemd +gshadow: files systemd + +hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis + + + + + Example: Mappings provided by <filename>nss-mymachines</filename> + + The container rawhide is spawned using + systemd-nspawn1: + + + # systemd-nspawn -M rawhide --boot --network-veth --private-users=pick +Spawning container rawhide on /var/lib/machines/rawhide. +Selected user namespace base 20119552 and range 65536. +... + +$ machinectl --max-addresses=3 +MACHINE CLASS SERVICE OS VERSION ADDRESSES +rawhide container systemd-nspawn fedora 30 169.254.40.164 fe80::94aa:3aff:fe7b:d4b9 + +$ ping -c1 rawhide +PING rawhide(fe80::94aa:3aff:fe7b:d4b9%ve-rawhide (fe80::94aa:3aff:fe7b:d4b9%ve-rawhide)) 56 data bytes +64 bytes from fe80::94aa:3aff:fe7b:d4b9%ve-rawhide (fe80::94aa:3aff:fe7b:d4b9%ve-rawhide): icmp_seq=1 ttl=64 time=0.045 ms +... +$ ping -c1 -4 rawhide +PING rawhide (169.254.40.164) 56(84) bytes of data. +64 bytes from 169.254.40.164 (169.254.40.164): icmp_seq=1 ttl=64 time=0.064 ms +... + +# machinectl shell rawhide /sbin/ip a +Connected to machine rawhide. Press ^] three times within 1s to exit session. +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 + ... +2: host0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 + link/ether 96:aa:3a:7b:d4:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0 + inet 169.254.40.164/16 brd 169.254.255.255 scope link host0 + valid_lft forever preferred_lft forever + inet6 fe80::94aa:3aff:fe7b:d4b9/64 scope link + valid_lft forever preferred_lft forever +Connection to machine rawhide terminated. + + + + + See Also + + systemd1, + systemd-machined.service8, + machinectl1, + nss-systemd8, + nss-resolve8, + nss-myhostname8, + nsswitch.conf5, + getent1 + + + + diff --git a/man/nss-resolve.xml b/man/nss-resolve.xml new file mode 100644 index 0000000..b72b1ba --- /dev/null +++ b/man/nss-resolve.xml @@ -0,0 +1,166 @@ + + + + + + + + nss-resolve + systemd + + + + nss-resolve + 8 + + + + nss-resolve + libnss_resolve.so.2 + Hostname resolution via systemd-resolved.service + + + + libnss_resolve.so.2 + + + + Description + + nss-resolve is a plug-in module for the GNU Name Service Switch (NSS) functionality of the + GNU C Library (glibc) enabling it to resolve hostnames via the + systemd-resolved8 local network + name resolution service. It replaces the nss-dns plug-in module that traditionally resolves + hostnames via DNS. + + To activate the NSS module, add resolve [!UNAVAIL=return] to the line starting + with hosts: in /etc/nsswitch.conf. Specifically, it is + recommended to place resolve early in /etc/nsswitch.conf's + hosts: line. It should be before the files entry, since + systemd-resolved supports /etc/hosts internally, but with + caching. To the contrary, it should be after mymachines, to give hostnames given to + local VMs and containers precedence over names received over DNS. Finally, we recommend placing + dns somewhere after resolve, to fall back to + nss-dns if systemd-resolved.service is not available. + + Note that systemd-resolved will synthesize DNS resource records in a few cases, + for example for localhost and the current local hostname, see + systemd-resolved8 for + the full list. This duplicates the functionality of + nss-myhostname8, but + it is still recommended (see examples below) to keep nss-myhostname configured in + /etc/nsswitch.conf, to keep those names resolveable if + systemd-resolved is not running. + + Please keep in mind that nss-myhostname (and nss-resolve) also resolve + in the other direction — from locally attached IP addresses to + hostnames. If you rely on that lookup being provided by DNS, you might + want to order things differently. + + + Communication between nss-resolve and + systemd-resolved.service takes place via the + /run/systemd/resolve/io.systemd.Resolve AF_UNIX socket. + + + + Environment variables + + + + $SYSTEMD_NSS_RESOLVE_VALIDATE + + Takes a boolean argument. When false, cryptographic validation of resource records + via DNSSEC will be disabled. This may be useful for testing, or when system time is known to be + unreliable. + + + + + + $SYSTEMD_NSS_RESOLVE_SYNTHESIZE + + Takes a boolean argument. When false, synthetic records, e.g. for the local host + name, will not be returned. See section SYNTHETIC RECORDS in + systemd-resolved.service8 + for more information. This may be useful to query the "public" resource records, independent of the + configuration of the local machine. + + + + + + $SYSTEMD_NSS_RESOLVE_CACHE + + Takes a boolean argument. When false, the cache of previously queried records will + not be used by systemd-resolved. + + + + + + $SYSTEMD_NSS_RESOLVE_ZONE + + Takes a boolean argument. When false, answers using locally registered public + LLMNR/mDNS resource records will not be returned. + + + + + + $SYSTEMD_NSS_RESOLVE_TRUST_ANCHOR + + Takes a boolean argument. When false, answers using locally configured trust anchors + will not be used. + + + + + + $SYSTEMD_NSS_RESOLVE_NETWORK + + Takes a boolean argument. When false, answers will be returned without using the + network, i.e. either from local sources or the cache in systemd-resolved. + + + + + + + Example + + Here is an example /etc/nsswitch.conf file that enables + nss-resolve correctly: + + +passwd: compat systemd +group: compat [SUCCESS=merge] systemd +shadow: compat systemd +gshadow: files systemd + +hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis + + + + See Also + + systemd1, + systemd-resolved8, + nss-systemd8, + nss-myhostname8, + nss-mymachines8, + nsswitch.conf5, + systemd.syntax5 + + + + diff --git a/man/nss-systemd.xml b/man/nss-systemd.xml new file mode 100644 index 0000000..b7b4538 --- /dev/null +++ b/man/nss-systemd.xml @@ -0,0 +1,183 @@ + + + + + + + + nss-systemd + systemd + + + + nss-systemd + 8 + + + + nss-systemd + libnss_systemd.so.2 + UNIX user and group name resolution for user/group lookup via Varlink + + + + libnss_systemd.so.2 + + + + Description + + nss-systemd is a plug-in module for the GNU Name Service Switch (NSS) + functionality of the GNU C Library (glibc), providing UNIX user and group name + resolution for services implementing the User/Group Record + Lookup API via Varlink, such as the system and service manager + systemd1 (for its + DynamicUser= feature, see + systemd.exec5 for + details), + systemd-homed.service8, or systemd-machined.service8. + + This module also ensures that the root and nobody users and groups (i.e. the users/groups with the UIDs/GIDs + 0 and 65534) remain resolvable at all times, even if they aren't listed in /etc/passwd or + /etc/group, or if these files are missing. + + This module preferably utilizes + systemd-userdbd.service8 + for resolving users and groups, but also works without the service running. + + To activate the NSS module, add systemd to the lines starting with + passwd:, group:, shadow: and + gshadow: in /etc/nsswitch.conf. + + It is recommended to place systemd after the files or + compat entry of the /etc/nsswitch.conf lines so that + /etc/passwd, /etc/group, /etc/shadow and + /etc/gshadow based mappings take precedence. + + + + Static Drop-In JSON User/Group Records + + Besides user/group records acquired via the aforementioned Varlink IPC interfaces and the + synthesized root and nobody accounts, this module also makes user and group accounts available to the + system that are defined in static drop-in files in the /etc/userdb/, + /run/userdb/, /run/host/userdb/ and + /usr/lib/userdb/ directories. + + This is a simple mechanism to provide static user and group records via JSON drop-in files. Such + user records should be defined in the format described by the JSON User Records specification and be placed in one of the + aforementioned directories under a file name composed of the user name suffixed with + .user, with a world-readable access mode. A symlink named after the user record's + UID formatted in decimal and suffixed with .user pointing to the primary record file + should be created as well, in order to allow both lookups by username and by UID. Privileged user record + data (e.g. hashed UNIX passwords) may optionally be provided as well, in a pair of separate companion + files with the .user-privileged suffix. The data should be stored in a regular file + named after the user name, suffixed with .user-privileged, and a symlink pointing to + it, named after the used numeric UID formatted in decimal with the same suffix. These companion files + should not be readable to anyone but root. Example: + + -rw-r--r--. 1 root root 723 May 10 foobar.user +-rw-------. 1 root root 123 May 10 foobar.user-privileged +lrwxrwxrwx. 1 root root 19 May 10 4711.user -> foobar.user +lrwxrwxrwx. 1 root root 19 May 10 4711.user-privileged -> foobar.user-privileged + + Similarly, group records following the format described in JSON Group Record may be defined, using the file suffixes + .group and .group-privileged. + + The primary user/group record files (i.e. those with the .user and + .group suffixes) should not contain the privileged section as + described in the specifications. The privileged user/group record files (i.e. those with the + .user-privileged and .group-privileged suffixes) should + contain this section, exclusively. + + Note that static user/group records generally do not override conflicting records in + /etc/passwd or /etc/group or other account databases. In fact, + before dropping in these files a reasonable level of care should be taken to avoid user/group name and + UID/GID conflicts. + + + + Configuration in <filename>/etc/nsswitch.conf</filename> + + Here is an example /etc/nsswitch.conf file that enables + nss-systemd correctly: + + + passwd: compat systemd +group: compat [SUCCESS=merge] systemd +shadow: compat systemd +gshadow: files systemd + +hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns +networks: files + +protocols: db files +services: db files +ethers: db files +rpc: db files + +netgroup: nis + + + + + Example: Mappings provided by <filename>systemd-machined.service</filename> + + The container rawhide is spawned using + systemd-nspawn1: + + + # systemd-nspawn -M rawhide --boot --network-veth --private-users=pick +Spawning container rawhide on /var/lib/machines/rawhide. +Selected user namespace base 20119552 and range 65536. +... + +$ machinectl --max-addresses=3 +MACHINE CLASS SERVICE OS VERSION ADDRESSES +rawhide container systemd-nspawn fedora 30 169.254.40.164 fe80::94aa:3aff:fe7b:d4b9 + +$ getent passwd vu-rawhide-0 vu-rawhide-81 +vu-rawhide-0:*:20119552:65534:vu-rawhide-0:/:/usr/sbin/nologin +vu-rawhide-81:*:20119633:65534:vu-rawhide-81:/:/usr/sbin/nologin + +$ getent group vg-rawhide-0 vg-rawhide-81 +vg-rawhide-0:*:20119552: +vg-rawhide-81:*:20119633: + +$ ps -o user:15,pid,tty,command -e|grep '^vu-rawhide' +vu-rawhide-0 692 ? /usr/lib/systemd/systemd +vu-rawhide-0 731 ? /usr/lib/systemd/systemd-journald +vu-rawhide-192 734 ? /usr/lib/systemd/systemd-networkd +vu-rawhide-193 738 ? /usr/lib/systemd/systemd-resolved +vu-rawhide-0 742 ? /usr/lib/systemd/systemd-logind +vu-rawhide-81 744 ? /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only +vu-rawhide-0 746 ? /usr/sbin/sshd -D ... +vu-rawhide-0 752 ? /usr/lib/systemd/systemd --user +vu-rawhide-0 753 ? (sd-pam) +vu-rawhide-0 1628 ? login -- zbyszek +vu-rawhide-1000 1630 ? /usr/lib/systemd/systemd --user +vu-rawhide-1000 1631 ? (sd-pam) +vu-rawhide-1000 1637 pts/8 -zsh + + + + + See Also + + systemd1, + systemd.exec5, + nss-resolve8, + nss-myhostname8, + nss-mymachines8, + systemd-userdbd.service8, + systemd-homed.service8, + systemd-machined.service8, + nsswitch.conf5, + getent1 + + + + diff --git a/man/oomctl.xml b/man/oomctl.xml new file mode 100644 index 0000000..950e79d --- /dev/null +++ b/man/oomctl.xml @@ -0,0 +1,86 @@ + + + + + + + + oomctl + systemd + + + + oomctl + 1 + + + + oomctl + Analyze the state stored in systemd-oomd + + + + + oomctl + OPTIONS + COMMAND + + + + + Description + + oomctl may be used to get information about the various contexts read in by + the systemd1 userspace + out-of-memory (OOM) killer, + systemd-oomd8. + + + + + Commands + + The following commands are understood: + + + + dump + + Show the current state of the cgroups and system contexts stored by + systemd-oomd. + + + + + + + + Options + + The following options are understood: + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + See Also + + systemd1, + systemd-oomd.service8, + oomd.conf5 + + + + diff --git a/man/oomd.conf.xml b/man/oomd.conf.xml new file mode 100644 index 0000000..1092fee --- /dev/null +++ b/man/oomd.conf.xml @@ -0,0 +1,100 @@ + + + + + + + oomd.conf + systemd + + + + oomd.conf + 5 + + + + oomd.conf + oomd.conf.d + Global systemd-oomd configuration files + + + + /etc/systemd/oomd.conf + /etc/systemd/oomd.conf.d/*.conf + /usr/lib/systemd/oomd.conf.d/*.conf + + + + Description + + These files configure the various parameters of the + systemd1 userspace + out-of-memory (OOM) killer, + systemd-oomd.service8. + See systemd.syntax7 + for a general description of the syntax. + + + + + + + [OOM] Section Options + + The following options are available in the [OOM] section: + + + + SwapUsedLimit= + + Sets the limit for memory and swap usage on the system before systemd-oomd + will take action. If the fraction of memory used and the fraction of swap used on the system are both more than + what is defined here, systemd-oomd will act on eligible descendant control groups with swap + usage greater than 5% of total swap, starting from the ones with the highest swap usage. Which + control groups are monitored and what action gets taken depends on what the unit has configured for + ManagedOOMSwap=. Takes a value specified in percent (when suffixed with "%"), + permille ("‰") or permyriad ("‱"), between 0% and 100%, inclusive. Defaults to 90%. + + + + DefaultMemoryPressureLimit= + + Sets the limit for memory pressure on the unit's control group before + systemd-oomd will take action. A unit can override this value with + ManagedOOMMemoryPressureLimit=. The memory pressure for this property represents + the fraction of time in a 10 second window in which all tasks in the control group were delayed. For + each monitored control group, if the memory pressure on that control group exceeds the limit set for + longer than the duration set by DefaultMemoryPressureDurationSec=, + systemd-oomd will act on eligible descendant control groups, starting from the + ones with the most reclaim activity to the least reclaim activity. Which control groups are monitored + and what action gets taken depends on what the unit has configured for + ManagedOOMMemoryPressure=. Takes a fraction specified in the same way as + SwapUsedLimit= above. Defaults to 60%. + + + + DefaultMemoryPressureDurationSec= + + Sets the amount of time a unit's control group needs to have exceeded memory pressure + limits before systemd-oomd will take action. Memory pressure limits are defined by + DefaultMemoryPressureLimit= and ManagedOOMMemoryPressureLimit=. + Must be set to 0, or at least 1 second. Defaults to 30 seconds when unset or 0. + + + + + + + See Also + + systemd1, + systemd.resource-control5, + systemd-oomd.service8, + oomctl1 + + + + diff --git a/man/org.freedesktop.LogControl1.xml b/man/org.freedesktop.LogControl1.xml new file mode 100644 index 0000000..1694453 --- /dev/null +++ b/man/org.freedesktop.LogControl1.xml @@ -0,0 +1,143 @@ + + + + + + + org.freedesktop.LogControl1 + systemd + + + + org.freedesktop.LogControl1 + 5 + + + + org.freedesktop.LogControl1 + D-Bus interface to query and set logging configuration + + + + Introduction + + org.freedesktop.LogControl1 is a generic interface that is intended + to be used by any daemon which allows the log level and target to be set over D-Bus. It is implemented by + various daemons that are part of the + systemd1 suite. + + It is assumed that those settings are global for the whole program, so a fixed object path is + used. The interface should always be available under the path + /org/freedesktop/LogControl1. + + + + Description + + The following interface is exposed: + + +node /org/freedesktop/LogControl1 { + interface org.freedesktop.LogControl1 { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s LogLevel = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s LogTarget = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s SyslogIdentifier = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + Properties + + LogLevel describes the + syslog3-style + log-level, and should be one of emerg, alert, + crit, err, warning, notice, + info, debug, in order of increasing verbosity. + + LogTarget describes the log target (mechanism). It should be one of + console (log to the console or standard output), + kmsg (log to the kernel ring buffer), + journal (log to the journal natively, see + systemd-journald.service8), + syslog (log using the + syslog3 call). + + + Those two properties are writable, so they may be set by sufficiently privileged users. + + SyslogIdentifier is a read-only property that shows the "syslog identifier". + It is a short string that identifies the program that is the source of log messages that is passed to + the syslog3 call. + + + + + + Tools + + journalctl option / may be used + to filter log messages by log level, option / may be + used to by the syslog identifier, and filters like _TRANSPORT=syslog, + _TRANSPORT=journal, and _TRANSPORT=kernel may be used to filter + messages by the mechanism through which they reached systemd-journald. + + systemctl log-level and systemctl log-target verbs may be + used to query and set the LogLevel and LogTarget properties of the + service manager. systemctl service-log-level and systemctl + service-log-target may similarly be used for individual services. (Services must have the + BusName= property set and must implement the interface described here. See + systemd.service5 + for details about BusName=.) + + + + Example + + + Create a simple listener on the bus that implements LogControl1 + + + + This creates a simple server on the bus. It implements the LogControl1 interface by providing + the required properties and allowing to set the writable ones. It logs at the configured log level using + sd_journal_print3. + + + + + See Also + + systemd1, + journalctl1, + systemctl1, + systemd.service5, + syslog3 + + + diff --git a/man/org.freedesktop.home1.xml b/man/org.freedesktop.home1.xml new file mode 100644 index 0000000..f217fb8 --- /dev/null +++ b/man/org.freedesktop.home1.xml @@ -0,0 +1,533 @@ + + + + + + + org.freedesktop.home1 + systemd + + + + org.freedesktop.home1 + 5 + + + + org.freedesktop.home1 + The D-Bus interface of systemd-homed + + + + Introduction + + systemd-homed.service8 + is a system service which may be used to create, remove, change or inspect home areas. This page + describes the D-Bus interface. + + + + + The Manager Object + + The service exposes the following interfaces on the Manager object on the bus: + + +node /org/freedesktop/home1 { + interface org.freedesktop.home1.Manager { + methods: + GetHomeByName(in s user_name, + out u uid, + out s home_state, + out u gid, + out s real_name, + out s home_directory, + out s shell, + out o bus_path); + GetHomeByUID(in u uid, + out s user_name, + out s home_state, + out u gid, + out s real_name, + out s home_directory, + out s shell, + out o bus_path); + GetUserRecordByName(in s user_name, + out s user_record, + out b incomplete, + out o bus_path); + GetUserRecordByUID(in u uid, + out s user_record, + out b incomplete, + out o bus_path); + ListHomes(out a(susussso) home_areas); + @org.freedesktop.systemd1.Privileged("true") + ActivateHome(in s user_name, + in s secret); + @org.freedesktop.systemd1.Privileged("true") + DeactivateHome(in s user_name); + RegisterHome(in s user_record); + UnregisterHome(in s user_name); + CreateHome(in s user_record); + RealizeHome(in s user_name, + in s secret); + RemoveHome(in s user_name); + @org.freedesktop.systemd1.Privileged("true") + FixateHome(in s user_name, + in s secret); + AuthenticateHome(in s user_name, + in s secret); + UpdateHome(in s user_record); + ResizeHome(in s user_name, + in t size, + in s secret); + ChangePasswordHome(in s user_name, + in s new_secret, + in s old_secret); + @org.freedesktop.systemd1.Privileged("true") + LockHome(in s user_name); + @org.freedesktop.systemd1.Privileged("true") + UnlockHome(in s user_name, + in s secret); + AcquireHome(in s user_name, + in s secret, + in b please_suspend, + out h send_fd); + @org.freedesktop.systemd1.Privileged("true") + RefHome(in s user_name, + in b please_suspend, + out h send_fd); + @org.freedesktop.systemd1.Privileged("true") + ReleaseHome(in s user_name); + @org.freedesktop.systemd1.Privileged("true") + LockAllHomes(); + @org.freedesktop.systemd1.Privileged("true") + DeactivateAllHomes(); + @org.freedesktop.systemd1.Privileged("true") + Rebalance(); + properties: + readonly a(sso) AutoLogin = [...]; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + GetHomeByName() returns basic user information (a minimal subset of the full + user record), provided a user name. The information supplied more or less matches what + getpwnam3 returns: + the numeric UID and GID, the real name, home directory and shell. In addition it returns a state + identifier describing the state the user's home directory is in, as well as a bus path referring to the + bus object encapsulating the user record and home directory. This object implements the + org.freedesktop.home1.Home interface documented below. + + GetHomeByUID() is similar to GetHomeByName() but + acquires the information based on the numeric UID of the user. + + GetUserRecordByName() is also similar to + GetHomeByName() but returns the full JSON user record data instead of the broken + down records. An additional returned boolean indicates whether the record is complete or not. A record + is considered complete when its privileged section is included, and incomplete if it + was removed (see JSON User Records for details + about the various sections of a user record). Generally, only privileged clients and clients running + under the identity of the user itself get access to the privileged section and will + thus see complete records. + + GetUserRecordByUID() is similar to GetUserRecordByName() + but returns the user record matching the specified numeric UID. + + ListHomes() returns an array of all locally managed users. The array + contains the same fields GetHomeByName() returns: user name, numeric UID, state, + numeric GID, real name, home directory, shell and bus path of the matching bus object. + + ActivateHome() activates (i.e. mounts) the home directory of the specified + user. The second argument shall contain a user record consisting only of a secret + section (all other sections should be stripped, see JSON + User Records for details), and should contain only the secret credentials necessary for + unlocking the home directory. Typically a client would invoke this function first with an entirely + empty record (which is possibly sufficient if single-factor authentication with a plugged-in security + token is configured), and would then retry with a record populated with more information, depending on + the returned error code, in case more credentials are necessary. This function is synchronous and + returns only after the home directory was fully activated (or the operation failed), which might take + some time. Clients must be prepared for that, and typically should extend the D-Bus method call + timeout accordingly. This method is equivalent to the Activate() method on the + org.freedesktop.home1.Home interface documented below, but may be called on the + manager object and takes a user name as additional argument, instead. + + DeactivateHome() deactivates (i.e. unmounts) the home directory of the + specified user. It is equivalent to the Deactivate() method on the + org.freedesktop.home1.Home interface documented below. + + RegisterHome() registers a new home directory locally. It receives the JSON + user record as only argument (which typically excludes the secret + section). Registering a home directory just makes the user record known to the system, it does not + create a home directory or such (which is expected to exist already, or created later). This operation + is useful to register home directories locally that are not located where + systemd-homed.service would find them automatically. + + UnregisterHome() unregisters an existing home directory. It takes a user + name as argument and undoes what RegisterHome() does. It does not attempt to + remove the home directory itself, it just unregisters it with the local system. Note that if the home + directory is placed where systemd-homed.service looks for home directories anyway + this call will only undo fixation (see below), but the record will remain known to + systemd-homed.service and be listed among known records. Since the user record is + embedded into the home directory this operation generally does not discard data belonging to the user + or their record. This method is equivalent to + Unregister() on the org.freedesktop.home1.Home + interface. + + CreateHome() registers and creates a new home directory. This takes a fully + specified JSON user record as argument (including the secret section). This registers + the user record locally and creates a home directory matching it, depending on the settings specified + in the record in combination with local configuration. + + RealizeHome() creates a home directory whose user record is already + registered locally. This takes a user name plus a user record consisting only of the + secret section. Invoking RegisterHome() followed by + RealizeHome() is mostly equivalent to calling CreateHome(), + except that the latter combines the two in atomic fashion. This method is equivalent to + Realize() on the org.freedesktop.home1.Home + interface. + + RemoveHome() unregisters a user record locally, and removes the home + directory belonging to it, if it is accessible. It takes a user name as argument. This method is equivalent to + Remove() on the org.freedesktop.home1.Home + interface. + + FixateHome() fixates an automatically discovered home + directory. systemd-homed.service automatically discovers home directories dropped + in our plugged in and adds them to the runtime list of user records it manages. A user record + discovered that way may be fixated, in which case it is copied out of the home + directory, onto persistent storage, to fixate the UID/GID assignment of the record, and extract + additional (typically previously encrypted) user record data from the home directory. A home directory + mus be fixated before it can be logged into. This method call takes a user name and a JSON user record + consisting only of the secret section as argument. This method is equivalent to + Fixate() on the org.freedesktop.home1.Home interface. + + AuthenticateHome() checks passwords or other authentication credentials + associated with the home directory. It takes a user name and a JSON user record consisting only of the + secret section as argument. Note that many of the other method calls authenticate + the user first, in order to execute some other operation. This method call only authenticates and + executes no further operation. Like ActivateHome() it is usually first invoked + with an empty JSON user record, which is then populated for subsequent tries with additional + authentication data supplied. This method is equivalent to + Authenticate() on the org.freedesktop.home1.Home + interface. + + UpdateHome() updates a locally registered user record. Takes a fully + specified JSON user record as argument (including the secret section). A user with a + matching name and realm must be registered locally already, and the last change timestamp of the newly + supplied record must be newer than the previously existing user record. Note this operation updates the + user record only, it does not propagate passwords/authentication tokens from the user record to the + storage back-end, or resizes the storage back-end. Typically a home directory is first updated, and then + the password of the underlying storage updated using ChangePasswordHome() as well + as the storage resized using ResizeHome(). This method is equivalent to + Update() on the org.freedesktop.home1.Home interface. + + ResizeHome() resizes the storage associated with a user record. Takes a user + name, a disk size in bytes and a user record consisting only of the secret section + as argument. If the size is specified as UINT64_MAX the storage is resized to the + size already specified in the user record. Typically, if the user record is updated using + UpdateHome() above this is used to propagate the size configured there-in down to + the underlying storage back-end. This method is equivalent to + Resize() on the org.freedesktop.home1.Home + interface. + + ChangePasswordHome() changes the passwords/authentication tokens of a home + directory. Takes a user name, and two JSON user record objects, each consisting only of the + secret section, for the old and for the new passwords/authentication tokens. If the + user record with the new passwords/authentication token data is specified as empty the existing user + record's settings are propagated down to the home directory storage. This is typically used after a + user record is updated using UpdateHome() in order to propagate the + secrets/authentication tokens down to the storage. Background: depending on the backend the user's + authentication credentials are stored at multiple places: the user record kept on the host, the user + record kept in the home directory and the encrypted LUKS volume slot. If the home directory is used on + a different machined temporarily, and the password is changed there, and then is moved back to the + original host, the passwords of the three might get out of sync. By issuing + ChangePasswordHome() the three locations are updated to match the newest + information. This method is equivalent to ChangePassword() on the + org.freedesktop.home1.Home interface. + + LockHome() temporarily suspends access to a home directory, flushing out any + cryptographic keys from memory. This is only supported on some back-ends, and usually done during system + suspend, in order to effectively secure home directories while the system is sleeping. Takes a user + name as single argument. If an application attempts to access a home directory while it is locked it + will typically freeze until the home directory is unlocked again. This method is equivalent to + Lock() on the org.freedesktop.home1.Home interface. + + UnlockHome() undoes the effect of LockHome(). Takes a + user name and a user record consisting only of the secret section as arguments. This + method is equivalent to Unlock() on the + org.freedesktop.home1.Home interface. + + AcquireHome() activates or unlocks a home directory in a reference counted + mode of operation. Takes a user name and user record consisting only of secret + section as argument. If the home directory is not active yet, it is activated. If it is currently + locked it is unlocked. After completion a reference to the activation/unlocking of the home directory + is returned via a file descriptor. When the last client which acquired such a file descriptor closes it + the home directory is automatically deactivated again. This method is typically invoked when a user + logs in, and the file descriptor is held until the user logs out again, thus ensuring the user's home + directory can be unmounted automatically again in a robust fashion, when the user logs out. The third + argument is a boolean which indicates whether the client invoking the call is able to automatically + re-authenticate when the system comes back from suspending. It should be set by all clients that + implement a secure lock screen running outside of the user's context, that is brought up when the + system comes back from suspend and can be used to re-acquire the credentials to unlock the user's home + directory. If a home directory has at least one client with an open reference to the home directory + that does not support this it is not suspended automatically at system suspend, otherwise it is. This + method is equivalent to Acquire() on the + org.freedesktop.home1.Home interface. + + RefHome() is similar to AcquireHome() but takes no user + record with secret section, i.e. will take an additional reference to an already + activated/unlocked home directory without attempting to activate/unlock it itself. It will fail if the + home directory is not already activated. This method is equivalent to + Ref() on the org.freedesktop.home1.Home + interface. + + ReleaseHome() releases a home directory again, if all file descriptors + referencing it are already closed, that where acquired through AcquireHome() or + RefHome(). Note that this call does not actually cause the deactivation of the + home directory (which happens automatically when the last referencing file descriptor is closed), but + is simply a synchronization mechanism that allows delaying of the user session's termination until any + triggered deactivation is completed. This method is equivalent to Release() on the + org.freedesktop.home1.Home interface. + + LockAllHomes() locks all active home directories that only have references + that opted into automatic suspending during system suspend. This is usually invoked automatically + shortly before system suspend. + + DeactivateAllHomes() deactivates all home areas that are currently + active. This is usually invoked automatically shortly before system shutdown. + + Rebalance() synchronously rebalances free disk space between home + areas. This only executes an operation if at least one home area using the LUKS2 backend is active and + has rebalancing enabled, and is otherwise a NOP. + + + + Properties + + AutoLogin exposes an array of structures consisting of user name, seat name + and object path of an home directory object. All locally managed users that have the + autoLogin field set are listed here, with the seat name they are associated with. A + display manager may watch this property and pre-fill the login screen with the users exposed this + way. + + + + + The Home Object + + +node /org/freedesktop/home1/home { + interface org.freedesktop.home1.Home { + methods: + @org.freedesktop.systemd1.Privileged("true") + Activate(in s secret); + @org.freedesktop.systemd1.Privileged("true") + Deactivate(); + Unregister(); + Realize(in s secret); + Remove(); + @org.freedesktop.systemd1.Privileged("true") + Fixate(in s secret); + Authenticate(in s secret); + Update(in s user_record); + Resize(in t size, + in s secret); + ChangePassword(in s new_secret, + in s old_secret); + @org.freedesktop.systemd1.Privileged("true") + Lock(); + @org.freedesktop.systemd1.Privileged("true") + Unlock(in s secret); + @org.freedesktop.systemd1.Privileged("true") + Acquire(in s secret, + in b please_suspend, + out h send_fd); + @org.freedesktop.systemd1.Privileged("true") + Ref(in b please_suspend, + out h send_fd); + @org.freedesktop.systemd1.Privileged("true") + Release(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UserName = '...'; + readonly u UID = ...; + readonly (suusss) UnixRecord = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s State = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly (sb) UserRecord = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.DBus.ObjectManager { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Activate(), Deactivate(), + Unregister(), Realize(), Remove(), + Fixate(), Authenticate(), Update(), + Resize(), ChangePassword(), Lock(), + Unlock(), Acquire(), Ref(), + Release() operate like their matching counterparts on the + org.freedesktop.home1.Manager interface (see above). The main difference is that + they are methods of the home directory objects, and hence carry no additional user name + parameter. Which of the two flavors of methods to call depends on the handles to the user known on the + client side: if only the user name is known, it's preferable to use the methods on the manager object + since they operate with user names only. If however the home object path was already acquired some way + it is preferable to operate on the org.freedesktop.home1.Home objects + instead. + + + + Properties + + UserName contains the user name of the user account/home directory. + + UID contains the numeric UNIX UID of the user account. + + UnixRecord contains a structure encapsulating the six fields a + struct passwd typically contains (the password field is suppressed). + + State exposes the current state home the home directory. + + UserRecord contains the full JSON user record string of the user account. + + + + + + + See Also + + systemd1, + systemd-homed.service8, + homectl1 + + + + diff --git a/man/org.freedesktop.hostname1.xml b/man/org.freedesktop.hostname1.xml new file mode 100644 index 0000000..d6d4b0e --- /dev/null +++ b/man/org.freedesktop.hostname1.xml @@ -0,0 +1,403 @@ + + + +%entities; +]> + + + + + org.freedesktop.hostname1 + systemd + + + + org.freedesktop.hostname1 + 5 + + + + org.freedesktop.hostname1 + The D-Bus interface of systemd-hostnamed + + + + Introduction + + + systemd-hostnamed.service8 + is a system service that can be used to control the hostname and related machine metadata from user + programs. This page describes the hostname semantics and the D-Bus interface. + + + + The D-Bus API + + The service exposes the following interfaces on the bus: + + +node /org/freedesktop/hostname1 { + interface org.freedesktop.hostname1 { + methods: + SetHostname(in s hostname, + in b interactive); + SetStaticHostname(in s hostname, + in b interactive); + SetPrettyHostname(in s hostname, + in b interactive); + SetIconName(in s icon, + in b interactive); + SetChassis(in s chassis, + in b interactive); + SetDeployment(in s deployment, + in b interactive); + SetLocation(in s location, + in b interactive); + GetProductUUID(in b interactive, + out ay uuid); + GetHardwareSerial(out s serial); + Describe(out s json); + properties: + readonly s Hostname = '...'; + readonly s StaticHostname = '...'; + readonly s PrettyHostname = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s DefaultHostname = '...'; + readonly s HostnameSource = '...'; + readonly s IconName = '...'; + readonly s Chassis = '...'; + readonly s Deployment = '...'; + readonly s Location = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KernelName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KernelRelease = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KernelVersion = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OperatingSystemPrettyName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OperatingSystemCPEName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HomeURL = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HardwareVendor = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HardwareModel = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s FirmwareVersion = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Whenever the hostname or other metadata is changed via the daemon, + PropertyChanged signals are sent out to subscribed clients. Changing a hostname + using this interface is authenticated via + polkit. + + + + Semantics + + The StaticHostname property exposes the "static" hostname configured in + /etc/hostname. It is not always in sync with the current hostname as returned by the + gethostname3 + system call. If no static hostname is configured this property will be the empty string. + + When systemd1 or + systemd-hostnamed.service8 + set the hostname, this static hostname has the highest priority. + + The Hostname property exposes the actual hostname configured in the kernel via + sethostname2. + It can be different from the static hostname. This property is never empty. + + The PrettyHostname property exposes the pretty hostname + which is a free-form UTF-8 hostname for presentation to the user. User interfaces should ensure that the + pretty hostname and the static hostname stay in sync. E.g. when the former is Lennart’s + Computer the latter should be lennarts-computer. If no pretty hostname is + set this setting will be the empty string. Applications should then find a suitable fallback, such as the + dynamic hostname. + + The DefaultHostname property exposes the default hostname (configured through + os-release5, or a + fallback set at compilation time). + + The HostnameSource property exposes the origin of the currently configured + hostname. One of static (set from /etc/hostname), + transient (a non-permanent hostname from an external source), + default (the value from os-release or the compiled-in + fallback). + + The IconName property exposes the icon name following the + XDG icon naming spec. If not set, information such as the chassis type (see below) is used to find a + suitable fallback icon name (i.e. computer-laptop + vs. computer-desktop is picked based on the chassis information). If no such data is + available, the empty string is returned. In that case an application should fall back to a replacement + icon, for example computer. If this property is set to the empty string, the automatic + fallback name selection is enabled again. + + The Chassis property exposes a chassis type, one of the + currently defined chassis types: desktop, laptop, + server, tablet, handset, as well as the special + chassis types vm and container for virtualized systems. Note that + in most cases the chassis type will be determined automatically from DMI/SMBIOS/ACPI firmware + information. Writing to this setting is hence useful only to override misdetected chassis types, or to + configure the chassis type if it could not be auto-detected. Set this property to the empty string to + reenable the automatic detection of the chassis type from firmware information. + + Note that systemd-hostnamed starts only on request and terminates after a + short idle period. This effectively means that PropertyChanged messages are not sent + out for changes made directly on the files (as in: administrator edits the files with vi). This is + the intended behavior: manual configuration changes should require manual reloading. + + The transient (dynamic) hostname exposed by the Hostname property maps directly + to the kernel hostname. This hostname should be assumed to be highly dynamic, and hence should be watched + directly, without depending on PropertyChanged messages from + systemd-hostnamed. To accomplish this, open + /proc/sys/kernel/hostname and + poll3 + for SIGHUP which is triggered by the kernel every time the hostname changes. Again: + this is special for the transient (dynamic) hostname, and does not apply to the configured (fixed) + hostname. + + Applications may read the hostname data directly if hostname change notifications + are not necessary. Use + gethostname2, + /etc/hostname (possibly with per-distribution fallbacks), and + machine-info3 + for that. For more information on these files and syscalls see the respective man pages. + + KernelName, KernelRelease, and + KernelVersion expose the kernel name (e.g. Linux), release + (e.g. 5.0.0-11), and version (i.e. the build number, e.g. #11) as + reported by uname2. + OperatingSystemPrettyName, OperatingSystemCPEName, and + HomeURL expose the PRETTY_NAME=, CPE_NAME= and + HOME_URL= fields from + os-release5. The + purpose of those properties is to allow remote clients to access this information over D-Bus. Local + clients can access the information directly. + + + Methods + + SetHostname() sets the transient (dynamic) hostname, which is used if no + static hostname is set. This value must be an internet-style hostname, 7-bit lowercase ASCII, no + special chars/spaces. An empty string will unset the transient hostname. + + SetStaticHostname() sets the static hostname which is exposed by the + StaticHostname property. When called with an empty argument, the static + configuration in /etc/hostname is removed. Since the static hostname has the + highest priority, calling this function usually affects also the Hostname property + and the effective hostname configured in the kernel. + + SetPrettyHostname() sets the pretty hostname which is exposed by the + PrettyHostname property. + + SetIconName(), SetChassis(), + SetDeployment(), and SetLocation() set the properties + IconName (the name of the icon representing for the machine), + Chassis (the machine form factor), Deployment (the system + deployment environment), and Location (physical system location), respectively. + + + PrettyHostname, IconName, Chassis, + Deployment, and Location are stored in + /etc/machine-info. See + machine-info5 for + the semantics of those settings. + + GetProductUUID() returns the "product UUID" as exposed by the kernel based + on DMI information in /sys/class/dmi/id/product_uuid. Reading the file directly + requires root privileges, and this method allows access to unprivileged clients through the polkit + framework. + + Describe() returns a JSON representation of all properties in one. + + + + Security + + The interactive boolean parameters can be used to control whether polkit + should interactively ask the user for authentication credentials if required. + + The polkit action for SetHostname() is + org.freedesktop.hostname1.set-hostname. For + SetStaticHostname() and SetPrettyHostname() it is + org.freedesktop.hostname1.set-static-hostname. For + SetIconName(), SetChassis(), SetDeployment() + and SetLocation() it is + org.freedesktop.hostname1.set-machine-info. + + + + + Recommendations + + Here are three examples that show how the pretty hostname and the icon name should be used: + + When registering DNS-SD services: use the pretty hostname in the service name, and pass + the icon name in the TXT data, if there is an icon name. Browsing clients can then show the server icon + on each service. This is especially useful for WebDAV applications or UPnP media sharing. + + + Set the bluetooth name to the pretty hostname. + + When your file browser has a "Computer" icon, replace the name with the pretty hostname + if set, and the icon with the icon name, if it is set. + + + To properly handle name lookups with changing local hostnames without having to edit + /etc/hosts, we recommend using systemd-hostnamed in combination + with nss-myhostname3. + + + Here are some recommendations to follow when generating a static (internet) hostname from a pretty + name: + + Generate a single DNS label only, not an FQDN. That means no dots allowed. Strip them, + or replace them with -. + + It's probably safer to not use any non-ASCII chars, even if DNS allows this in some way + these days. In fact, restrict your charset to a-zA-Z0-9 and -. + Strip other chars, or try to replace them in some smart way with chars from this set, for example + ä → ae, and use - as the replacement for all + punctuation characters and whitespace. + + Try to avoid creating repeated -, as well as - as + the first or last char. + + Limit the hostname to 63 chars, which is the length of a DNS label. + + If after stripping special chars the empty string is the result, you can pass this + as-is to systemd-hostnamed in which case it will automatically use a suitable + fallback. + + Uppercase charaacters should be replaced with their lowercase equivalents. + + + + Note that while systemd-hostnamed applies some checks to the hostname you pass + they are much looser than the recommendations above. For example, systemd-hostnamed + will also accept _ in the hostname, but we recommend not using this to avoid clashes + with DNS-SD service types. Also systemd-hostnamed allows longer hostnames, but + because of the DNS label limitations, we recommend not making use of this. + + Here are a couple of example conversions: + + Lennart's PC → lennarts-pc + Müllers Computer → muellers-computer + Voran! → voran + Es war einmal ein Männlein → es-war-einmal-ein-maennlein + Jawoll. Ist doch wahr! → jawoll-ist-doch-wahr + レナート → localhost + ...zack!!! zack!... → zack-zack + + + Of course, an already valid internet hostname label you enter and pass through this + conversion should stay unmodified, so that users have direct control of it, if they want — by simply + ignoring the fact that the pretty hostname is pretty and just edit it as if it was the normal internet + name. + + + + + + Examples + + + Introspect <interfacename>org.freedesktop.hostname1</interfacename> on the bus + + $ gdbus introspect --system \ + --dest org.freedesktop.hostname1 \ + --object-path /org/freedesktop/hostname1 + + + + + + See also + + David Zeuthen's original Fedora + Feature page about xdg-hostname + + diff --git a/man/org.freedesktop.import1.xml b/man/org.freedesktop.import1.xml new file mode 100644 index 0000000..62d753e --- /dev/null +++ b/man/org.freedesktop.import1.xml @@ -0,0 +1,343 @@ + + + + + + + org.freedesktop.import1 + systemd + + + + org.freedesktop.import1 + 5 + + + + org.freedesktop.import1 + The D-Bus interface of systemd-importd + + + + Introduction + + + systemd-importd.service8 + is a system service which may be used to import, export and download additional system images. These + images can be used by tools such as + systemd-nspawn1 + to run local containers. The service is used as the backend for machinectl pull-raw, + machinectl pull-tar and related commands. This page describes the D-Bus interface. + + + Note that + systemd-importd.service8 + is mostly a small companion service for + systemd-machined.service8. + Many operations to manipulate local container and VM images are hence available via the systemd-machined D-Bus API, c.f. + org.freedesktop.machine15. + + + + + The Manager Object + + The service exposes the following interfaces on the Manager object on the bus: + + +node /org/freedesktop/import1 { + interface org.freedesktop.import1.Manager { + methods: + ImportTar(in h fd, + in s local_name, + in b force, + in b read_only, + out u transfer_id, + out o transfer_path); + ImportRaw(in h fd, + in s local_name, + in b force, + in b read_only, + out u transfer_id, + out o transfer_path); + ImportFileSystem(in h fd, + in s local_name, + in b force, + in b read_only, + out u transfer_id, + out o transfer_path); + ExportTar(in s local_name, + in h fd, + in s format, + out u transfer_id, + out o transfer_path); + ExportRaw(in s local_name, + in h fd, + in s format, + out u transfer_id, + out o transfer_path); + PullTar(in s url, + in s local_name, + in s verify_mode, + in b force, + out u transfer_id, + out o transfer_path); + PullRaw(in s url, + in s local_name, + in s verify_mode, + in b force, + out u transfer_id, + out o transfer_path); + ListTransfers(out a(usssdo) transfers); + CancelTransfer(in u transfer_id); + signals: + TransferNew(u transfer_id, + o transfer_path); + TransferRemoved(u transfer_id, + o transfer_path, + s result); + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + ImportTar() and ImportRaw() import a system image and + place it into /var/lib/machines/. The first argument should be a file descriptor + (opened for reading) referring to the tar or raw file to import. It should reference a file on disk, + a pipe or a socket. When ImportTar() is used the file descriptor should + refer to a tar file, optionally compressed with + gzip1, + bzip21, + or + xz1. + systemd-importd will detect the used compression scheme (if any) automatically. When + ImportRaw() is used the file descriptor should refer to a raw or qcow2 disk image + containing an MBR or GPT disk label, also optionally compressed with gzip, bzip2 or xz. In either case, + if the file is specified as a file descriptor on disk, progress information is generated for the import + operation (as in that case we know the total size on disk). If a socket or pipe is specified, progress information is not + available. The file descriptor argument is followed by a local name for the image. This should be a + name suitable as a hostname and will be used to name the imported image below + /var/lib/machines/. A tar import is placed as a directory tree or a + btrfs8 + subvolume below /var/lib/machines/ under the specified name with no suffix + appended. A raw import is placed as a file in /var/lib/machines/ with the + .raw suffix appended. If the argument is true, any + pre-existing image with the same name is removed before starting the operation. Otherwise, the + operation fails if an image with the same name already exists. Finally, the + argument controls + whether to create a writable or read-only image. Both methods return immediately after starting the import, + with the import transfer ongoing. They return a pair of transfer identifier and object path, which may + be used to retrieve progress information about the transfer or to cancel it. The transfer identifier is a + simple numeric identifier, the object path references an + org.freedesktop.import1.Transfer object, see below. Listen for a + TransferRemoved signal for the transfer ID in order to detect when a transfer is + complete. The returned transfer object is useful to determine the current progress or log output of the + ongoing import operation. + + ExportTar() and ExportRaw() implement the reverse + operation, and may be used to export a system image in order to place it in a tar or raw image. They + take the machine name to export as their first parameter, followed by a file descriptor (opened for writing) + where the tar or raw file will be written. It may either reference a file on disk or a pipe/socket. The + third argument specifies in which compression format to write the image. It takes one of + uncompressed, xz, bzip2 or + gzip, depending on which compression scheme is required. The image written to the + specified file descriptor will be a tar file in case of ExportTar() or a raw disk + image in case of ExportRaw(). Note that currently raw disk images may not be + exported as tar files, and vice versa. This restriction might be lifted eventually. The method + returns a transfer identifier and object path for cancelling or tracking the export operation, similarly + to ImportTar() or ImportRaw() as described above. + + PullTar() and PullRaw() may be used to download, verify + and import a system image from a URL. They take an URL argument which should point to a tar or + raw file on the http:// or https:// protocols, possibly + compressed with xz, bzip2 or gzip. The second argument is a local name for the image. It should be + suitable as a hostname, similarly to the matching argument of the ImportTar() and + ImportRaw() methods above. The third argument indicates the verification mode for + the image. It may be one of no, checksum, + signature. no turns off any kind of verification of the image; + checksum looks for a SHA256SUM file next to the downloaded + image and verifies any SHA256 hash value in that file against the image; signature + does the same but also tries to authenticate the SHA256SUM file via + gpg8 + first. The last argument indicates whether to replace a possibly pre-existing image with the same local + name (if true), or whether to fail (if false). Like the import + and export calls above, these calls return a pair of transfer identifier and object path for the ongoing + download. + + ListTransfers() returns a list of ongoing import, export or download + operations as created with the six calls described above. It returns an array of structures which + consist of the numeric transfer identifier, a string indicating the operation (one of + import-tar, import-raw, export-tar, + export-raw, pull-tar or pull-raw), a string + describing the remote file (in case of download operations this is the source URL, in case of + import/export operations this is a short string describing the file descriptor passed in), a string + with the local machine image name, a progress value between 0.0 (for 0%) and 1.0 (for 100%), as well as + the transfer object path. + + CancelTransfer() may be used to cancel an ongoing import, export or download + operation. Simply specify the transfer identifier to cancel the ongoing operation. + + + + Signals + + The TransferNew signal is generated each time a new transfer is started with + the import, export or download calls described above. It carries the transfer ID and object path that + have just been created. + + The TransferRemoved signal is sent each time a transfer finishes, + is canceled or fails. It also carries the transfer ID and object path, followed by a string indicating + the result of the operation, which is one of done (on success), + canceled or failed. + + + + + The Transfer Object + + +node /org/freedesktop/import1/transfer/_1 { + interface org.freedesktop.import1.Transfer { + methods: + Cancel(); + signals: + LogMessage(u priority, + s line); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Id = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Local = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Remote = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Verify = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly d Progress = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + The Cancel() method may be used to cancel the transfer. It takes no + parameters. This method is pretty much equivalent to the CancelTransfer() method + on the Manager interface (see above), but is exposed on the + Transfer object itself instead of taking a transfer ID. + + + + Properties + + The Id property exposes the numeric transfer ID of the transfer object. + + The Local, Remote and Type properties + expose the local container name of this transfer, the remote source (in case of download: the URL, in + case of import/export: a string describing the file descriptor passed in), and the type of operation + (see the Manager's ListTransfer() method above for an explanation of the possible + values). + + The Verify property exposes the selected verification setting and is only + defined for download operations (see above). + + The Progress property exposes the current progress of the transfer as a value + between 0.0 and 1.0. To show a progress bar on screen we recommend to query this value in regular + intervals, for example every 500 ms or so. + + + + + Examples + + + Introspect <interfacename>org.freedesktop.import1.Manager</interfacename> on the bus + + $ gdbus introspect --system \ + --dest org.freedesktop.import1 \ + --object-path /org/freedesktop/import1 + + + + + Introspect <interfacename>org.freedesktop.import1.Transfer</interfacename> on the bus + + $ gdbus introspect --system \ + --dest org.freedesktop.import1 \ + --object-path /org/freedesktop/import1/transfer/_1 + + + + + + diff --git a/man/org.freedesktop.locale1.xml b/man/org.freedesktop.locale1.xml new file mode 100644 index 0000000..d5c93af --- /dev/null +++ b/man/org.freedesktop.locale1.xml @@ -0,0 +1,188 @@ + + + + + + + org.freedesktop.locale1 + systemd + + + + org.freedesktop.locale1 + 5 + + + + org.freedesktop.locale1 + The D-Bus interface of systemd-localed + + + + Introduction + + + systemd-localed.service8 + is a system service that can be used to control the system locale and keyboard mapping from user + programs. This page describes the D-Bus interface. + + + + The D-Bus API + + The service exposes the following interfaces on the bus: + + +node /org/freedesktop/locale1 { + interface org.freedesktop.locale1 { + methods: + SetLocale(in as locale, + in b interactive); + SetVConsoleKeyboard(in s keymap, + in s keymap_toggle, + in b convert, + in b interactive); + SetX11Keyboard(in s layout, + in s model, + in s variant, + in s options, + in b convert, + in b interactive); + properties: + readonly as Locale = ['...', ...]; + readonly s X11Layout = '...'; + readonly s X11Model = '...'; + readonly s X11Variant = '...'; + readonly s X11Options = '...'; + readonly s VConsoleKeymap = '...'; + readonly s VConsoleKeymapToggle = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + If you set a new system locale all old system locale settings will be dropped and the new + settings will be saved to disk. The locale will also be passed to the system manager, and subsequently started + daemons will inherit the new system locale. Note that already running daemons will not learn about the + new value. + + The SetVConsoleKeyboard() method may be used to set the key mapping for the + virtual console. Similarly, SetX11Keyboard() may be used to set the default key + mapping of any X11 servers. + + Note that SetVConsoleKeyboard() instantly applies the new key mapping to the + console, while SetX11Keyboard() simply sets a default that may be used by later + sessions. + + The boolean argument convert may be set to optionally convert the console + keyboard configuration to X11 keyboard mappings and vice versa. If true and + SetVConsoleKeyboard() is used, the nearest X11 keyboard setting for the chosen + console setting is set. If true and SetX11Keyboard() is used, the nearest console + keyboard setting for the chosen X11 setting is set. Hence, it is usually sufficient to call only one of the + two functions. + + For graphical UIs that need to set the system keyboard mapping simply invoke + SetX11Keyboard(), set convert=true and ignore + SetVConsoleKeyboard(). + + Use the empty string for the keymap parameters you wish not to set. + + The interactive boolean parameters can be used to control whether + polkit + should interactively ask the user for authentication credentials if required. + + + + Signals + + Whenever the system locale or keymap is changed via the daemon, + PropertyChanged signals are sent out to which clients can subscribe. + + + + Properties + + The system locale is shown in the Locale property. It is an array containing + environment-variable-assignment-like strings. The following strings are known: + LANG=, LC_CTYPE=, LC_NUMERIC=, + LC_TIME=, LC_COLLATE=, LC_MONETARY=, + LC_MESSAGES=, LC_PAPER=, LC_NAME=, + LC_ADDRESS=, LC_TELEPHONE=, LC_MEASUREMENT=, + LC_IDENTIFICATION=. + + The X11Layout, X11Model, X11Variant, and + X11Options properties show values configurable with + SetX11Keyboard() described above (or SetVConsoleKeyboard() + with convert=true). The VConsoleKeymap and + VConsoleKeymapToggle properties show values configurable with + SetVConsoleKeyboard() (or SetX11Keyboard() with + convert=true). + + + + Security + + Changing the system locale or keymap using this interface is authenticated via polkit. The + polkit action for SetLocale() is + org.freedesktop.locale1.set-locale. The polkit action for + SetX11Keyboard() and SetVConsoleKeyboard() is + org.freedesktop.locale1.set-keyboard. + + + + + Examples + + + Introspect <interfacename>org.freedesktop.locale1</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.locale1 \ + --object-path /org/freedesktop/locale1 + + + + + + Versioning + + These D-Bus interfaces follow + the usual interface versioning guidelines. + + diff --git a/man/org.freedesktop.login1.xml b/man/org.freedesktop.login1.xml new file mode 100644 index 0000000..639b09a --- /dev/null +++ b/man/org.freedesktop.login1.xml @@ -0,0 +1,1489 @@ + + + + + + + org.freedesktop.login1 + systemd + + + + org.freedesktop.login1 + 5 + + + + org.freedesktop.login1 + The D-Bus interface of systemd-logind + + + + Introduction + + systemd-logind.service8 + is a system service that keeps track of user logins and seats. + + The daemon provides both a C library interface as well as a D-Bus interface. The library interface + may be used to introspect and watch the state of user logins and seats. The bus interface provides the + same functionality but in addition may also be used to make changes to the system state. For more information please + consult sd-login3. + + + + + The Manager Object + + The service exposes the following interfaces on the Manager object on the bus: + + +node /org/freedesktop/login1 { + interface org.freedesktop.login1.Manager { + methods: + GetSession(in s session_id, + out o object_path); + GetSessionByPID(in u pid, + out o object_path); + GetUser(in u uid, + out o object_path); + GetUserByPID(in u pid, + out o object_path); + GetSeat(in s seat_id, + out o object_path); + ListSessions(out a(susso) sessions); + ListUsers(out a(uso) users); + ListSeats(out a(so) seats); + ListInhibitors(out a(ssssuu) inhibitors); + @org.freedesktop.systemd1.Privileged("true") + CreateSession(in u uid, + in u pid, + in s service, + in s type, + in s class, + in s desktop, + in s seat_id, + in u vtnr, + in s tty, + in s display, + in b remote, + in s remote_user, + in s remote_host, + in a(sv) properties, + out s session_id, + out o object_path, + out s runtime_path, + out h fifo_fd, + out u uid, + out s seat_id, + out u vtnr, + out b existing); + @org.freedesktop.systemd1.Privileged("true") + ReleaseSession(in s session_id); + ActivateSession(in s session_id); + ActivateSessionOnSeat(in s session_id, + in s seat_id); + LockSession(in s session_id); + UnlockSession(in s session_id); + LockSessions(); + UnlockSessions(); + KillSession(in s session_id, + in s who, + in i signal_number); + KillUser(in u uid, + in i signal_number); + TerminateSession(in s session_id); + TerminateUser(in u uid); + TerminateSeat(in s seat_id); + SetUserLinger(in u uid, + in b enable, + in b interactive); + AttachDevice(in s seat_id, + in s sysfs_path, + in b interactive); + FlushDevices(in b interactive); + PowerOff(in b interactive); + PowerOffWithFlags(in t flags); + Reboot(in b interactive); + RebootWithFlags(in t flags); + Halt(in b interactive); + HaltWithFlags(in t flags); + Suspend(in b interactive); + SuspendWithFlags(in t flags); + Hibernate(in b interactive); + HibernateWithFlags(in t flags); + HybridSleep(in b interactive); + HybridSleepWithFlags(in t flags); + SuspendThenHibernate(in b interactive); + SuspendThenHibernateWithFlags(in t flags); + CanPowerOff(out s result); + CanReboot(out s result); + CanHalt(out s result); + CanSuspend(out s result); + CanHibernate(out s result); + CanHybridSleep(out s result); + CanSuspendThenHibernate(out s result); + ScheduleShutdown(in s type, + in t usec); + CancelScheduledShutdown(out b cancelled); + Inhibit(in s what, + in s who, + in s why, + in s mode, + out h pipe_fd); + CanRebootParameter(out s result); + SetRebootParameter(in s parameter); + CanRebootToFirmwareSetup(out s result); + SetRebootToFirmwareSetup(in b enable); + CanRebootToBootLoaderMenu(out s result); + SetRebootToBootLoaderMenu(in t timeout); + CanRebootToBootLoaderEntry(out s result); + SetRebootToBootLoaderEntry(in s boot_loader_entry); + SetWallMessage(in s wall_message, + in b enable); + signals: + SessionNew(s session_id, + o object_path); + SessionRemoved(s session_id, + o object_path); + UserNew(u uid, + o object_path); + UserRemoved(u uid, + o object_path); + SeatNew(s seat_id, + o object_path); + SeatRemoved(s seat_id, + o object_path); + PrepareForShutdown(b start); + PrepareForSleep(b start); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite b EnableWallMessages = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s WallMessage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u NAutoVTs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as KillOnlyUsers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as KillExcludeUsers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b KillUserProcesses = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s RebootParameter = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b RebootToFirmwareSetup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t RebootToBootLoaderMenu = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s RebootToBootLoaderEntry = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as BootLoaderEntries = ['...', ...]; + readonly b IdleHint = ...; + readonly t IdleSinceHint = ...; + readonly t IdleSinceHintMonotonic = ...; + readonly s BlockInhibited = '...'; + readonly s DelayInhibited = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InhibitDelayMaxUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UserStopDelayUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandlePowerKey = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandlePowerKeyLongPress = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleRebootKey = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleRebootKeyLongPress = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleSuspendKey = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleSuspendKeyLongPress = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleHibernateKey = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleHibernateKeyLongPress = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleLidSwitch = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleLidSwitchExternalPower = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s HandleLidSwitchDocked = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t HoldoffTimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s IdleAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t IdleActionUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b PreparingForShutdown = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b PreparingForSleep = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (st) ScheduledShutdown = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Docked = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b LidClosed = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b OnExternalPower = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeDirectorySize = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeDirectoryInodesMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InhibitorsMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t NCurrentInhibitors = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SessionsMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t NCurrentSessions = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t StopIdleSessionUSec = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + GetSession() may be used to get the session object path for the session with + the specified ID. Similarly, GetUser() and GetSeat() get the + user and seat objects, respectively. GetSessionByPID() and + GetUserByPID() get the session/user object the specified PID belongs to if there + is any. + + ListSessions() returns an array of all current sessions. The structures in + the array consist of the following fields: session id, user id, user name, seat id, session object + path. If a session does not have a seat attached, the seat id field will be an empty string. + + ListUsers() returns an array of all currently logged in users. The + structures in the array consist of the following fields: user id, user name, user object path. + + ListSeats() returns an array of all currently available seats. The + structure in the array consists of the following fields: seat id, seat object path. + + ListInhibitors() lists all currently active inhibitors. It returns an array of + structures consisting of what, who, why, + mode, uid (user ID), and pid (process ID). + + CreateSession() and ReleaseSession() may be used to + open or close login sessions. These calls should never be invoked directly by + clients. Creating/closing sessions is exclusively the job of PAM and its + pam_systemd8 + module. + + ActivateSession() brings the session with the specified ID into the + foreground. ActivateSessionOnSeat() does the same, but only if the seat id + matches. + + LockSession() asks the session with the specified ID to activate the screen + lock. UnlockSession() asks the session with the specified ID to remove an active + screen lock, if there is any. This is implemented by sending out the Lock() and Unlock() signals from + the respective session object which session managers are supposed to listen on. + + LockSessions() asks all sessions to activate their screen locks. This may be + used to lock access to the entire machine in one action. Similarly, UnlockSessions() + asks all sessions to deactivate their screen locks. + + KillSession() may be used to send a Unix signal to one or all processes of a + session. As arguments it takes the session id, either the string leader or + all and a signal number. If leader is passed only the session + leader is killed. If all is passed all processes of the session + are killed. + + KillUser() may be used to send a Unix signal to all processes of a user. As + arguments it takes the user id and a signal number. + + TerminateSession(), TerminateUser(), + TerminateSeat() may be used to forcibly terminate one specific session, all + processes of a user, and all sessions attached to a specific seat, respectively. The session, user, + and seat are identified by their respective IDs. + + SetUserLinger() enables or disables user lingering. If enabled, the runtime + directory of a user is kept around and they may continue to run processes while logged out. If + disabled, the runtime directory goes away as soon as they log out. SetUserLinger() + expects three arguments: the UID, a boolean whether to enable/disable and a boolean controlling the + polkit + authorization interactivity (see below). Note that the user linger state is persistently + stored on disk. + + AttachDevice() may be used to assign a specific device to a specific + seat. The device is identified by its /sys/ path and must be eligible for seat + assignments. AttachDevice() takes three arguments: the seat id, the sysfs path, + and a boolean for controlling polkit interactivity (see below). Device assignments are persistently + stored on disk. To create a new seat, simply specify a previously unused seat id. For more information + about the seat assignment logic see + sd-login3. + + FlushDevices() removes all explicit seat assignments for devices, resetting + all assignments to the automatic defaults. The only argument it takes is the polkit interactivity + boolean (see below). + + PowerOff(), Reboot(), Halt(), + Suspend(), and Hibernate() result in the system being powered + off, rebooted, halted (shut down without turning off power), suspended (the system state is + saved to RAM and the CPU is turned off), or hibernated (the system state is saved to disk and + the machine is powered down). HybridSleep() results in the system entering a + hybrid-sleep mode, i.e. the system is both hibernated and suspended. + SuspendThenHibernate() results in the system being suspended, then later woken + using an RTC timer and hibernated. The only argument is the polkit interactivity boolean + interactive (see below). The main purpose of these calls is that they enforce + polkit policy and hence allow powering off/rebooting/suspending/hibernating even by unprivileged + users. They also enforce inhibition locks for non-privileged users. UIs should expose these calls + as the primary mechanism to poweroff/reboot/suspend/hibernate the machine. Methods + PowerOffWithFlags(), RebootWithFlags(), + HaltWithFlags(), SuspendWithFlags(), + HibernateWithFlags(), HybridSleepWithFlags() and + SuspendThenHibernateWithFlags() add flags to allow for + extendability, defined as follows: + +#define SD_LOGIND_ROOT_CHECK_INHIBITORS (UINT64_C(1) << 0) +#define SD_LOGIND_KEXEC_REBOOT (UINT64_C(1) << 1) + + When the flags is 0 then these methods behave just like the versions + without flags. When SD_LOGIND_ROOT_CHECK_INHIBITORS (0x01) is set, active + inhibitors are honoured for privileged users too. When SD_LOGIND_KEXEC_REBOOT + (0x02) is set, then RebootWithFlags() perform kexec reboot if kexec + kernel is loaded. + + SetRebootParameter() sets a parameter for a subsequent reboot operation. + See the description of reboot in + systemctl1 and + reboot2 + for more information. + + SetRebootToFirmwareSetup(), + SetRebootToBootLoaderMenu(), and SetRebootToBootLoaderEntry() + configure the action to be taken from the boot loader after a reboot: respectively entering firmware + setup mode, the boot loader menu, or a specific boot loader entry. See + systemctl1 for the + corresponding command line interface. + + CanPowerOff(), CanReboot(), + CanHalt(), CanSuspend(), CanHibernate(), + CanHybridSleep(), CanSuspendThenHibernate(), + CanRebootParameter(), CanRebootToFirmwareSetup(), + CanRebootToBootLoaderMenu(), and + CanRebootToBootLoaderEntry() test whether the system supports the respective + operation and whether the calling user is allowed to execute it. Returns one of na, + yes, no, and challenge. If + na is returned, the operation is not available because hardware, kernel, or drivers + do not support it. If yes is returned, the operation is supported and the user may + execute the operation without further authentication. If no is returned, the + operation is available but the user is not allowed to execute the operation. If + challenge is returned, the operation is available but only after + authorization. + + ScheduleShutdown() schedules a shutdown operation type at + time usec in microseconds since the UNIX epoch. type can be one + of poweroff, dry-poweroff, reboot, + dry-reboot, halt, and dry-halt. (The + dry- variants do not actually execute the shutdown action.) + CancelScheduledShutdown() cancels a scheduled shutdown. The output parameter + cancelled is true if a shutdown operation was scheduled. + + SetWallMessage() sets the wall message (the message that will be sent out to + all terminals and stored in a + utmp5 record) for a + subsequent scheduled shutdown operation. The parameter wall_message specifies the + shutdown reason (and may be empty) which will be included in the shutdown message. The parameter + enable specifies whether to print a wall message on shutdown. + + Inhibit() creates an inhibition lock. It takes four parameters: + what, who, why, and + mode. what is one or more of shutdown, + sleep, idle, handle-power-key, + handle-suspend-key, handle-hibernate-key, + handle-lid-switch, separated by colons, for inhibiting poweroff/reboot, + suspend/hibernate, the automatic idle logic, or hardware key handling. who should be + a short human readable string identifying the application taking the lock. why + should be a short human readable string identifying the reason why the lock is taken. Finally, + mode is either block or delay which encodes + whether the inhibit shall be consider mandatory or whether it should just delay the operation to a + certain maximum time. The method returns a file descriptor. The lock is released the moment this file + descriptor and all its duplicates are closed. For more information on the inhibition logic see + Inhibitor Locks. + + + + + Signals + + Whenever the inhibition state or idle hint changes, PropertyChanged + signals are sent out to which clients can subscribe. + + The SessionNew, SessionRemoved, + UserNew, UserRemoved, SeatNew, and + SeatRemoved signals are sent each time a session is created or removed, a user + logs in or out, or a seat is added or removed. They each contain the ID of the object plus the object + path. + + The PrepareForShutdown() and PrepareForSleep() signals + are sent right before (with the argument true) or after (with the argument + false) the system goes down for reboot/poweroff and suspend/hibernate, + respectively. This may be used by applications to save data on disk, release memory, or do other jobs + that should be done shortly before shutdown/sleep, in conjunction with delay inhibitor locks. After + completion of this work they should release their inhibition locks in order to not delay the operation + any further. For more information see + Inhibitor Locks. + + + + + Properties + + Most properties simply reflect the configuration, see + logind.conf5. This + includes: NAutoVTs, KillOnlyUsers, + KillExcludeUsers, KillUserProcesses, IdleAction, + InhibitDelayMaxUSec, + InhibitorsMax, + UserStopDelayUSec, + HandlePowerKey, HandleSuspendKey, + HandleHibernateKey, HandleLidSwitch, + HandleLidSwitchExternalPower, HandleLidSwitchDocked, + IdleActionUSec, HoldoffTimeoutUSec, + RemoveIPC, RuntimeDirectorySize, + RuntimeDirectoryInodesMax, InhibitorsMax, and + SessionsMax. + + + The IdleHint property reflects the idle hint state of the system. If the + system is idle it might get into automatic suspend or shutdown depending on the configuration. + + IdleSinceHint and IdleSinceHintMonotonic encode the + timestamps of the last change of the idle hint boolean, in CLOCK_REALTIME and + CLOCK_MONOTONIC timestamps, respectively, in microseconds since the epoch. + + The BlockInhibited and DelayInhibited properties encode + the currently active locks of the respective modes. They are colon separated lists of + shutdown, sleep, and idle (see above). + + NCurrentSessions and NCurrentInhibitors contain the number + of currently registered sessions and inhibitors. + + The BootLoaderEntries property contains a list of boot loader entries. + This includes boot loader entries defined in configuration and any additional loader entries + reported by the boot loader. See + systemd-boot7 + for more information. + + The PreparingForShutdown and PreparingForSleep boolean + properties are true during the interval between the two PrepareForShutdown and + PrepareForSleep signals respectively. Note that these properties do not + send out PropertyChanged signals. + + The RebootParameter property shows the value set with the + SetRebootParameter() method described above. + + ScheduledShutdown shows the value pair set with the + ScheduleShutdown() method described above. + + RebootToFirmwareSetup, RebootToBootLoaderMenu, and + RebootToBootLoaderEntry are true when the resprective post-reboot operation was + selected with SetRebootToFirmwareSetup, + SetRebootToBootLoaderMenu, or + SetRebootToBootLoaderEntry. + + The WallMessage and EnableWallMessages properties reflect the + shutdown reason and wall message enablement switch which can be set with the + SetWallMessage() method described above. + + Docked is true if the machine is connected to a dock. + LidClosed is true when the lid (of a laptop) is closed. + OnExternalPower is true when the machine is connected to an external power supply. + + + + + Security + + A number of operations are protected via the polkit privilege + system. SetUserLinger() requires the + org.freedesktop.login1.set-user-linger + privilege. AttachDevice() requires + org.freedesktop.login1.attach-device and + FlushDevices() requires + org.freedesktop.login1.flush-devices. PowerOff(), + Reboot(), Halt(), Suspend(), + Hibernate() require + org.freedesktop.login1.power-off, + org.freedesktop.login1.power-off-multiple-sessions, + org.freedesktop.login1.power-off-ignore-inhibit, + org.freedesktop.login1.reboot, + org.freedesktop.login1.reboot-multiple-sessions, + org.freedesktop.login1.reboot-ignore-inhibit, + org.freedesktop.login1.halt, + org.freedesktop.login1.halt-multiple-sessions, + org.freedesktop.login1.halt-ignore-inhibit, + org.freedesktop.login1.suspend, + org.freedesktop.login1.suspend-multiple-sessions, + org.freedesktop.login1.suspend-ignore-inhibit, + org.freedesktop.login1.hibernate, + org.freedesktop.login1.hibernate-multiple-sessions, + org.freedesktop.login1.hibernate-ignore-inhibit, + respectively depending on whether there are other sessions around or active inhibits are present. + HybridSleep() and SuspendThenHibernate() + use the same privileges as Hibernate(). + SetRebootParameter() requires + org.freedesktop.login1.set-reboot-parameter. + + SetRebootToFirmwareSetup requires + org.freedesktop.login1.set-reboot-to-firmware-setup. + SetRebootToBootLoaderMenu requires + org.freedesktop.login1.set-reboot-to-boot-loader-menu. + SetRebootToBootLoaderEntry requires + org.freedesktop.login1.set-reboot-to-boot-loader-entry. + + + ScheduleShutdown and CancelScheduledShutdown require + the same privileges (listed above) as the immediate poweroff/reboot/halt operations. + + Inhibit() is protected via one of + org.freedesktop.login1.inhibit-block-shutdown, + org.freedesktop.login1.inhibit-delay-shutdown, + org.freedesktop.login1.inhibit-block-sleep, + org.freedesktop.login1.inhibit-delay-sleep, + org.freedesktop.login1.inhibit-block-idle, + org.freedesktop.login1.inhibit-handle-power-key, + org.freedesktop.login1.inhibit-handle-suspend-key, + org.freedesktop.login1.inhibit-handle-hibernate-key, + org.freedesktop.login1.inhibit-handle-lid-switch depending on the lock + type and mode taken. + + The interactive boolean parameters can be used to control whether polkit + should interactively ask the user for authentication credentials if required. + + + + + Seat Objects + + +node /org/freedesktop/login1/seat/seat0 { + interface org.freedesktop.login1.Seat { + methods: + Terminate(); + ActivateSession(in s session_id); + SwitchTo(in u vtnr); + SwitchToNext(); + SwitchToPrevious(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Id = '...'; + readonly (so) ActiveSession = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanTTY = ...; + readonly b CanGraphical = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(so) Sessions = [...]; + readonly b IdleHint = ...; + readonly t IdleSinceHint = ...; + readonly t IdleSinceHintMonotonic = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Terminate() and ActivateSession() work similarly to + TerminateSeat() and ActivationSessionOnSeat() on the Manager + object. + + SwitchTo() switches to the session on the virtual terminal + vtnr. SwitchToNext() and + SwitchToPrevious() switch to, respectively, the next and previous sessions on the + seat in the order of virtual terminals. If there is no active session, they switch to, respectively, + the first and last session on the seat. + + + + Signals + + Whenever ActiveSession, Sessions, + CanGraphical, CanTTY, + or the idle state changes, PropertyChanged signals are sent out to which clients + can subscribe. + + + + Properties + + The Id property encodes the ID of the seat. + + ActiveSession encodes the currently active session if there is one. It is a + structure consisting of the session id and the object path. + + CanTTY encodes whether the session is suitable for text logins, and + CanGraphical whether it is suitable for graphical sessions. + + The Sessions property is an array of all current sessions of this seat, each + encoded in a structure consisting of the ID and the object path. + + The IdleHint, IdleSinceHint, and + IdleSinceHintMonotonic properties encode the idle state, similarly to the ones + exposed on the Manager object, but specific for this seat. + + + + + User Objects + + +node /org/freedesktop/login1/user/_1000 { + interface org.freedesktop.login1.User { + methods: + Terminate(); + Kill(in i signal_number); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u GID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Name = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t Timestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Service = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Slice = '...'; + readonly (so) Display = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s State = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(so) Sessions = [...]; + readonly b IdleHint = ...; + readonly t IdleSinceHint = ...; + readonly t IdleSinceHintMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Linger = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Terminate() and Kill() work similarly to the + TerminateUser() and KillUser() methods on the manager + object. + + + + Signals + + Whenever Sessions or the idle state changes, + PropertyChanged signals are sent out to which clients can subscribe. + + + + Properties + + The UID and GID properties encode the Unix UID and primary + GID of the user. + + The Name property encodes the user name. + + Timestamp and TimestampMonotonic encode the login time of + the user in microseconds since the epoch, in the CLOCK_REALTIME and + CLOCK_MONOTONIC clocks, respectively. + + RuntimePath encodes the runtime path of the user, + i.e. $XDG_RUNTIME_DIR. For details see the + + XDG Basedir Specification + . + + Service contains the unit name of the user systemd service of this + user. Each logged in user is assigned a user service that runs a user systemd instance. This is + usually an instance of user@.service. + + Slice contains the unit name of the user systemd slice of this user. Each + logged in user gets a private slice. + + Display encodes which graphical session should be used as the primary UI display + for the user. It is a structure encoding the session ID and the object path of the session to use. + + State encodes the user state and is one of offline, + lingering, online, active, or + closing. See + sd_uid_get_state3 + for more information about the states. + + Sessions is an array of structures encoding all current sessions of the + user. Each structure consists of the ID and object path. + + The IdleHint, IdleSinceHint, and + IdleSinceHintMonotonic properties encode the idle hint state of the user, similarly + to the Manager's properties, but specific for this user. + + The Linger property shows whether lingering is enabled for this user. + + + + + Session Objects + + +node /org/freedesktop/login1/session/1 { + interface org.freedesktop.login1.Session { + methods: + Terminate(); + Activate(); + Lock(); + Unlock(); + SetIdleHint(in b idle); + SetLockedHint(in b locked); + Kill(in s who, + in i signal_number); + TakeControl(in b force); + ReleaseControl(); + SetType(in s type); + SetDisplay(in s display); + TakeDevice(in u major, + in u minor, + out h fd, + out b inactive); + ReleaseDevice(in u major, + in u minor); + PauseDeviceComplete(in u major, + in u minor); + SetBrightness(in s subsystem, + in s name, + in u brightness); + signals: + PauseDevice(u major, + u minor, + s type); + ResumeDevice(u major, + u minor, + h fd); + Lock(); + Unlock(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Id = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (uo) User = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Name = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t Timestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u VTNr = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (so) Seat = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTY = '...'; + readonly s Display = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Remote = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RemoteHost = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RemoteUser = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Service = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Desktop = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Scope = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Leader = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Audit = ...; + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Class = '...'; + readonly b Active = ...; + readonly s State = '...'; + readonly b IdleHint = ...; + readonly t IdleSinceHint = ...; + readonly t IdleSinceHintMonotonic = ...; + readonly b LockedHint = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Terminate(), Activate(), Lock(), + Unlock(), and Kill() work similarly to the respective calls on + the Manager object. + + SetIdleHint() is called by the session object to update the idle state + of the session whenever it changes. + + TakeControl() allows a process to take exclusive managed device + access-control for that session. Only one D-Bus connection can be a controller for a given session at any + time. If the force argument is set (root only), an existing controller is kicked + out and replaced. Otherwise, this method fails if there is already a controller. Note that this method is + limited to D-Bus users with the effective UID set to the user of the session or root. + + ReleaseControl() drops control of a given session. Closing the D-Bus + connection implicitly releases control as well. See TakeControl() for more + information. This method also releases all devices for which the controller requested ownership via + TakeDevice(). + + SetType() allows the type of the session to be changed dynamically. It can + only be called by session's current controller. If TakeControl() has not been + called, this method will fail. In addition, the session type will be reset to its original value once + control is released, either by calling ReleaseControl() or closing the D-Bus + connection. This should help prevent a session from entering an inconsistent state, for example if the + controller crashes. The only argument type is the new session type. + + SetDisplay() allows the display name of the graphical session to be changed. This is + useful if the display server is started as part of the session. It can only be called by session's current + controller. If TakeControl() has not been called, this method will fail. The only argument + display is the new display name. + + TakeDevice() allows a session controller to get a file descriptor for a + specific device. Pass in the major and minor numbers of the character device and + systemd-logind will return a file descriptor for the device. Only a limited set of + device-types is currently supported (but may be extended). systemd-logind + automatically mutes the file descriptor if the session is inactive and resumes it once the session is + activated again. This guarantees that a session can only access session devices if the session is + active. Note that this revoke/resume mechanism is asynchronous and may happen at any given time. This + only works on devices that are attached to the seat of the given session. A process is not required to + have direct access to the device node. systemd-logind only requires you to be the + active session controller (see TakeControl()). Also note that any device can only + be requested once. As long as you don't release it, further TakeDevice() calls + will fail. + + ReleaseDevice() releases a device again (see + TakeDevice()). This is also implicitly done by + ReleaseControl() or when closing the D-Bus connection. + + PauseDeviceComplete() allows a session controller to synchronously pause a + device after receiving a PauseDevice(pause) signal. Forced + signals (or after an internal timeout) are automatically completed by + systemd-logind asynchronously. + + SetLockedHint() may be used to set the "locked hint" to + locked, i.e. information whether the session is locked. This is intended to be used + by the desktop environment to tell systemd-logind when the session is locked and + unlocked. + + SetBrightness() may be used to set the display brightness. This is intended + to be used by the desktop environment and allows unprivileged programs to access hardware settings in + a controlled way. The subsystem parameter specifies a kernel subsystem, either + backlight or leds. The name parameter + specifies a device name under the specified subsystem. The brightness parameter + specifies the brightness. The range is defined by individual drivers, see + /sys/class/subsystem/name/max_brightness. + + + + + Signals + + The active session controller exclusively gets PauseDevice and + ResumeDevice events for any device it requested via + TakeDevice(). They notify the controller whenever a device is paused or resumed. A + device is never resumed if its session is inactive. Also note that PauseDevice + signals are sent before the PropertyChanged signal for the + Active state. The inverse is true for ResumeDevice. A device + may remain paused for unknown reasons even though the Session is active. + + + A PauseDevice signal carries the major and minor numbers and a string describing the + type as arguments. force means the device was already paused by + systemd-logind and the signal is only an asynchronous + notification. pause means systemd-logind grants you a limited amount of time to pause the device. You must respond to this via + PauseDeviceComplete(). This synchronous pausing mechanism is used for + backwards-compatibility to VTs and systemd-logind is free to not make use of + it. It is also free to send a forced PauseDevice if you don't respond in a timely + manner (or for any other reason). gone means the device was unplugged from the + system and you will no longer get any notifications about it. There is no need to call + ReleaseDevice(). You may call TakeDevice() again if a new + device is assigned the major+minor combination. + + ResumeDevice is sent whenever a session is active and a device is + resumed. It carries the major/minor numbers as arguments and provides a new open file descriptor. You should + switch to the new descriptor and close the old one. They are not guaranteed to have the same underlying + open file descriptor in the kernel (except for a limited set of device types). + + Whenever Active or the idle state changes, + PropertyChanged signals are sent out to which clients can subscribe. + + Lock/Unlock is sent when the session is asked to be + screen-locked/unlocked. A session manager of the session should listen to this signal and act + accordingly. This signal is sent out as a result of the Lock() and + Unlock() methods, respectively. + + + + Properties + + Id encodes the session ID. + + User encodes the user ID of the user this session belongs to. This is a + structure consisting of the Unix UID and the object path. + + Name encodes the user name. + + Timestamp and TimestampMonotonic encode the microseconds + since the epoch when the session was created, in CLOCK_REALTIME or + CLOCK_MONOTONIC, respectively. + + VTNr encodes the virtual terminal number of the session if there is any, 0 + otherwise. + + Seat encodes the seat this session belongs to if there is any. This is a + structure consisting of the ID and the seat object path. + + TTY encodes the kernel TTY path of the session if this is a text login. If not + this is an empty string. + + Display encodes the X11 display name if this is a graphical login. If not, + this is an empty string. + + Remote encodes whether the session is local or remote. + + RemoteHost and RemoteUser encode the remote host and user + if this is a remote session, or an empty string otherwise. + + Service encodes the PAM service name that registered the session. + + Desktop describes the desktop environment running in the session (if + known). + + Scope contains the systemd scope unit name of this session. + + Leader encodes the PID of the process that registered the session. + + Audit encodes the Kernel Audit session ID of the session if auditing is + available. + + Type encodes the session type. It's one of unspecified (for + cron PAM sessions and suchlike), tty (for text logins) or + x11/mir/wayland (for graphical logins). + + Class encodes the session class. It's one of user (for + normal user sessions), greeter (for display manager pseudo-sessions), or + lock-screen (for display lock screens). + + Active is a boolean that is true if the session is active, i.e. currently in the + foreground. This field is semi-redundant due to State. + + State encodes the session state and one of online, + active, or closing. See + sd_session_get_state3 + for more information about the states. + + IdleHint, IdleSinceHint, and + IdleSinceHintMonotonic encapsulate the idle hint state of this session, similarly to + how the respective properties on the manager object do it for the whole system. + + LockedHint shows the locked hint state of this session, as set by the + SetLockedHint() method described above. + + + + + Examples + + + Introspect the logind manager on the bus + + $ gdbus introspect --system --dest org.freedesktop.login1 \ + --object-path /org/freedesktop/login1 + + + or + + $ busctl introspect org.freedesktop.login1 /org/freedesktop/login1 + + + + + Introspect the default seat on the bus + + $ gdbus introspect --system --dest org.freedesktop.login1 \ + --object-path /org/freedesktop/login1/seat/seat0 + + + or + + $ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/seat/seat0 + + + Seat seat0 is the default seat, so it'll be present unless local configuration + is made to reassign all devices to a different seat. The list of seats and users can be acquired with + loginctl list-sessions. + + + + Introspect a single user on the bus + + $ gdbus introspect --system --dest org.freedesktop.login1 \ + --object-path /org/freedesktop/login1/user/_1000 + + + or + + $ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/user/_1000 + + + + + Introspect <interfacename>org.freedesktop.login1.Session</interfacename> on the bus + + $ gdbus introspect --system --dest org.freedesktop.login1 \ + --object-path /org/freedesktop/login1/session/45 + + + or + + $ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/session/45 + + + + + + diff --git a/man/org.freedesktop.machine1.xml b/man/org.freedesktop.machine1.xml new file mode 100644 index 0000000..c366c1b --- /dev/null +++ b/man/org.freedesktop.machine1.xml @@ -0,0 +1,673 @@ + + + + + + + org.freedesktop.machine1 + systemd + + + + org.freedesktop.machine1 + 5 + + + + org.freedesktop.machine1 + The D-Bus interface of systemd-machined + + + + Introduction + + + systemd-machined.service8 + is a system service that keeps track of locally running virtual machines and containers. + This page describes the D-Bus interface. + + + + The Manager Object + + The service exposes the following interfaces on the Manager object on the bus: + + +node /org/freedesktop/machine1 { + interface org.freedesktop.machine1.Manager { + methods: + GetMachine(in s name, + out o machine); + GetImage(in s name, + out o image); + GetMachineByPID(in u pid, + out o machine); + ListMachines(out a(ssso) machines); + ListImages(out a(ssbttto) images); + @org.freedesktop.systemd1.Privileged("true") + CreateMachine(in s name, + in ay id, + in s service, + in s class, + in u leader, + in s root_directory, + in a(sv) scope_properties, + out o path); + @org.freedesktop.systemd1.Privileged("true") + CreateMachineWithNetwork(in s name, + in ay id, + in s service, + in s class, + in u leader, + in s root_directory, + in ai ifindices, + in a(sv) scope_properties, + out o path); + @org.freedesktop.systemd1.Privileged("true") + RegisterMachine(in s name, + in ay id, + in s service, + in s class, + in u leader, + in s root_directory, + out o path); + @org.freedesktop.systemd1.Privileged("true") + RegisterMachineWithNetwork(in s name, + in ay id, + in s service, + in s class, + in u leader, + in s root_directory, + in ai ifindices, + out o path); + UnregisterMachine(in s name); + TerminateMachine(in s id); + KillMachine(in s name, + in s who, + in i signal); + GetMachineAddresses(in s name, + out a(iay) addresses); + GetMachineOSRelease(in s name, + out a{ss} fields); + @org.freedesktop.systemd1.Privileged("true") + OpenMachinePTY(in s name, + out h pty, + out s pty_path); + OpenMachineLogin(in s name, + out h pty, + out s pty_path); + OpenMachineShell(in s name, + in s user, + in s path, + in as args, + in as environment, + out h pty, + out s pty_path); + BindMountMachine(in s name, + in s source, + in s destination, + in b read_only, + in b mkdir); + CopyFromMachine(in s name, + in s source, + in s destination); + CopyToMachine(in s name, + in s source, + in s destination); + CopyFromMachineWithFlags(in s name, + in s source, + in s destination, + in t flags); + CopyToMachineWithFlags(in s name, + in s source, + in s destination, + in t flags); + OpenMachineRootDirectory(in s name, + out h fd); + GetMachineUIDShift(in s name, + out u shift); + RemoveImage(in s name); + RenameImage(in s name, + in s new_name); + CloneImage(in s name, + in s new_name, + in b read_only); + MarkImageReadOnly(in s name, + in b read_only); + GetImageHostname(in s name, + out s hostname); + GetImageMachineID(in s name, + out ay id); + GetImageMachineInfo(in s name, + out a{ss} machine_info); + GetImageOSRelease(in s name, + out a{ss} os_release); + SetPoolLimit(in t size); + SetImageLimit(in s name, + in t size); + CleanPool(in s mode, + out a(st) images); + MapFromMachineUser(in s name, + in u uid_inner, + out u uid_outer); + MapToMachineUser(in u uid_outer, + out s machine_name, + out o machine_path, + out u uid_inner); + MapFromMachineGroup(in s name, + in u gid_inner, + out u gid_outer); + MapToMachineGroup(in u gid_outer, + out s machine_name, + out o machine_path, + out u gid_inner); + signals: + MachineNew(s machine, + o path); + MachineRemoved(s machine, + o path); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s PoolPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t PoolUsage = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t PoolLimit = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + GetMachine() may be used to get the machine object path for the machine with + the specified name. Similarly, GetMachineByPID() gets the machine object the + specified PID belongs to if there is any. + + GetImage() may be used to get the image object path of the image with the + specified name. + + ListMachines() returns an array of all currently registered machines. The + structures in the array consist of the following fields: machine name, machine class, an identifier for + the service that registered the machine and the machine object path. + + ListImages() returns an array of all currently known images. The + structures in the array consist of the following fields: image name, type, read-only flag, creation + time, modification time, current disk space, and image object path. + + CreateMachine() may be used to register a new virtual machine or container + with systemd-machined, creating a scope unit for it. It accepts the following arguments: a + machine name chosen by the registrar, an optional UUID as a 32 byte array, a string that identifies the + service that registers the machine, a class string, the PID of the leader process of the machine, an + optional root directory of the container, and an array of additional properties to use for the scope + registration. The virtual machine name must be suitable as a hostname, and hence should follow the usual + DNS hostname rules, as well as the Linux hostname restrictions. Specifically, only 7 bit ASCII is + permitted, a maximum length of 64 characters is enforced, only characters from the set + a-zA-Z0-9-_. are allowed, the name may not begin with a dot, and it may not contain + two dots immediately following each other. Container and VM managers should ideally use the hostname + used internally in the machine for this parameter. This recommendation is made in order to make the + machine name naturally resolvable using + nss-mymachines8. If + a container manager needs to embed characters outside of the indicated range, escaping is required, + possibly using _ as the escape character. Another (somewhat natural) option would be + to utilize Internet IDNA encoding. The UUID is passed as a 32 byte array or, if no suitable UUID is + available, an empty array (zero length) or zeroed out array shall be passed. The UUID should identify + the virtual machine/container uniquely and should ideally be the same UUID that + /etc/machine-id in the VM/container is initialized from. The service string can be + free-form, but it is recommended to pass a short lowercase identifier like + systemd-nspawn, libvirt-lxc or similar. The class string should + be either container or vm indicating whether the machine to + register is of the respective class. The leader PID should be the host PID of the init process of the + container or the encapsulating process of the VM. If the root directory of the container is known and + available in the host's hierarchy, it should be passed. Otherwise, pass the empty string instead. Finally, the + scope properties are passed as array in the same way as to PID1's + StartTransientUnit() method. Calling this method will internally register a transient scope + unit for the calling client (utilizing the passed scope_properties) and move the leader PID into + it. The method returns an object path for the registered machine object that implements the + org.freedesktop.machine1.Machine interface (see below). Also see the + New Control Group + Interfaces for details about scope units and how to alter resource control settings on the + created machine at runtime. + + RegisterMachine() is similar to CreateMachine(). + However, it only registers a machine and does not create a scope unit for it. Instead, the caller's unit is + registered. We recommend to only use this method for container or VM managers that are run + multiple times, one instance for each container/VM they manage, and are invoked as system + services. + + CreateMachineWithNetwork() and + RegisterMachineWithNetwork() are similar to CreateMachine() + and RegisterMachine() but take an extra argument: an array of network interface + indices that point towards the virtual machine or container. The interface indices should reference one + or more network interfaces on the host that can be used to communicate with the guest. Commonly, the + passed interface index refers to the host side of a "veth" link (in case of containers), a + "tun"/"tap" link (in case of VMs), or the host side of a bridge interface that bridges access to the + VM/container interfaces. Specifying this information is useful to enable support for link-local IPv6 + communication to the machines since the scope field of sockaddr_in6 can be initialized by the + specified ifindex. + nss-mymachines8 + makes use of this information. + + KillMachine() sends a UNIX signal to the machine's processes. As its arguments, it takes a + machine name (as originally passed to CreateMachine() or returned by + ListMachines()), an identifier that specifies what precisely to send the signal to (either + leader or all), and a numeric UNIX signal integer. + + TerminateMachine() terminates a virtual machine, killing its processes. It + takes a machine name as its only argument. + + GetMachineAddresses() retrieves the IP addresses of a container. This method + returns an array of pairs consisting of an address family specifier (AF_INET or + AF_INET6) and a byte array containing the addresses. This is only supported for + containers that make use of network namespacing. + + GetMachineOSRelease() retrieves the OS release information of a + container. This method returns an array of key value pairs read from the + os-release5 file in + the container and is useful to identify the operating system used in a container. + + OpenMachinePTY() allocates a pseudo TTY in the container and returns a file + descriptor and its path. This is equivalent to transitioning into the container and invoking + posix_openpt3. + + + OpenMachineLogin() allocates a pseudo TTY in the container and ensures that + a getty login prompt of the container is running on the other end. It returns the file descriptor of + the PTY and the PTY path. This is useful for acquiring a pty with a login prompt from the + container. + + OpenMachineShell() allocates a pseudo TTY in the container, as the specified + user, and invokes the executable at the specified path with a list of arguments (starting from + argv[0]) and an environment block. It then returns the file descriptor of the PTY and the PTY + path. + + BindMountMachine() bind mounts a file or directory from the host into the + container. Its arguments consist of a machine name, the source directory on the host, the destination directory in the + container, and two booleans, one indicating whether the bind mount shall be + read-only, the other indicating whether the destination mount point shall be created first, if it is + missing. + + CopyFromMachine() copies files or directories from a container into the + host. It takes a container name, a source directory in the container and a destination directory on the + host as arguments. + CopyToMachine() does the opposite and copies files from a source + directory on the host into a destination directory in the container. + CopyFromMachineWithFlags() and CopyToMachineWithFlags do the same but take an additional flags argument. + + RemoveImage() removes the image with the specified name. + + RenameImage() renames the specified image. + + CloneImage() clones the specified image under a new name. It also takes a + boolean argument indicating whether the resulting image shall be read-only or not. + + MarkImageReadOnly() toggles the read-only flag of an image. + + SetPoolLimit() sets an overall quota limit on the pool of images. + + SetImageLimit() sets a per-image quota limit. + + MapFromMachineUser(), MapToMachineUser(), + MapFromMachineGroup(), and MapToMachineGroup() may be used to map + UIDs/GIDs from the host user namespace to a container user namespace or vice versa. + + + + Signals + + MachineNew and MachineRemoved are sent whenever a new + machine is registered or removed. These signals carry the machine name and the object path to the corresponding + org.freedesktop.machine1.Machine interface (see below). + + + + Properties + + PoolPath specifies the file system path where images are written to. + + PoolUsage specifies the current usage size of the image pool in bytes. + + PoolLimit specifies the size limit of the image pool in bytes. + + + + + Machine Objects + + +node /org/freedesktop/machine1/machine/rawhide { + interface org.freedesktop.machine1.Machine { + methods: + Terminate(); + Kill(in s who, + in i signal); + GetAddresses(out a(iay) addresses); + GetOSRelease(out a{ss} fields); + GetUIDShift(out u shift); + OpenPTY(out h pty, + out s pty_path); + OpenLogin(out h pty, + out s pty_path); + OpenShell(in s user, + in s path, + in as args, + in as environment, + out h pty, + out s pty_path); + BindMount(in s source, + in s destination, + in b read_only, + in b mkdir); + CopyFrom(in s source, + in s destination); + CopyTo(in s source, + in s destination); + CopyFromWithFlags(in s source, + in s destination, + in t flags); + CopyToWithFlags(in s source, + in s destination, + in t flags); + OpenRootDirectory(out h fd); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Name = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay Id = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t Timestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Service = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Unit = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Leader = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Class = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ai NetworkInterfaces = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s State = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Terminate() and Kill() terminate/kill the machine. These methods + take the same arguments as TerminateMachine() and + KillMachine() on the Manager interface, respectively. + + GetAddresses() and GetOSRelease() get the IP address and OS + release information from the machine. These methods take the same arguments as + GetMachineAddresses() and GetMachineOSRelease() of the + Manager interface, respectively. + + + + Properties + + Name is the machine name as it was passed in during registration with + CreateMachine() on the manager object. + + Id is the machine UUID. + + Timestamp and TimestampMonotonic are the realtime and + monotonic timestamps when the virtual machines where created in microseconds since the epoch. + + Service contains a short string identifying the registering service as passed + in during registration of the machine. + + Unit is the systemd scope or service unit name for the machine. + + Leader is the PID of the leader process of the machine. + + Class is the class of the machine and is either the string "vm" (for real VMs + based on virtualized hardware) or "container" (for light-weight userspace virtualization sharing the + same kernel as the host). + + RootDirectory is the root directory of the container if it is known and + applicable or the empty string. + + NetworkInterfaces contains an array of network interface indices that point + towards the container, the VM or the host. For details about this information see the description of + CreateMachineWithNetwork() above. + + State is the state of the machine and is one of opening, + running, or closing. Note that the state machine is not considered + part of the API and states might be removed or added without this being considered API breakage. + + + + + + Examples + + + Introspect <interfacename>org.freedesktop.machine1.Manager</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.machine1 \ + --object-path /org/freedesktop/machine1 + + + + + Introspect <interfacename>org.freedesktop.machine1.Machine</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.machine1 \ + --object-path /org/freedesktop/machine1/machine/rawhide + + + + + + diff --git a/man/org.freedesktop.network1.xml b/man/org.freedesktop.network1.xml new file mode 100644 index 0000000..a4b5385 --- /dev/null +++ b/man/org.freedesktop.network1.xml @@ -0,0 +1,502 @@ + + + +%entities; +]> + + + + + org.freedesktop.network1 + systemd + + + + org.freedesktop.network1 + 5 + + + + org.freedesktop.network1 + The D-Bus interface of systemd-networkd + + + + Introduction + + + systemd-networkd.service8 + is a system service that manages and configures network interfaces. This page describes the D-Bus + interface. + + + + The Manager Object + + The service exposes the following interfaces on the Manager object on the bus: + + +node /org/freedesktop/network1 { + interface org.freedesktop.network1.Manager { + methods: + ListLinks(out a(iso) links); + GetLinkByName(in s name, + out i ifindex, + out o path); + GetLinkByIndex(in i ifindex, + out s name, + out o path); + SetLinkNTP(in i ifindex, + in as servers); + SetLinkDNS(in i ifindex, + in a(iay) addresses); + SetLinkDNSEx(in i ifindex, + in a(iayqs) addresses); + SetLinkDomains(in i ifindex, + in a(sb) domains); + SetLinkDefaultRoute(in i ifindex, + in b enable); + SetLinkLLMNR(in i ifindex, + in s mode); + SetLinkMulticastDNS(in i ifindex, + in s mode); + SetLinkDNSOverTLS(in i ifindex, + in s mode); + SetLinkDNSSEC(in i ifindex, + in s mode); + SetLinkDNSSECNegativeTrustAnchors(in i ifindex, + in as names); + RevertLinkNTP(in i ifindex); + RevertLinkDNS(in i ifindex); + RenewLink(in i ifindex); + ForceRenewLink(in i ifindex); + ReconfigureLink(in i ifindex); + Reload(); + DescribeLink(in i ifindex, + out s json); + Describe(out s json); + properties: + readonly s OperationalState = '...'; + readonly s CarrierState = '...'; + readonly s AddressState = '...'; + readonly s IPv4AddressState = '...'; + readonly s IPv6AddressState = '...'; + readonly s OnlineState = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t NamespaceId = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Provides information about the manager. + + + + + Link Object + + +node /org/freedesktop/network1/link/_1 { + interface org.freedesktop.network1.Link { + methods: + SetNTP(in as servers); + SetDNS(in a(iay) addresses); + SetDNSEx(in a(iayqs) addresses); + SetDomains(in a(sb) domains); + SetDefaultRoute(in b enable); + SetLLMNR(in s mode); + SetMulticastDNS(in s mode); + SetDNSOverTLS(in s mode); + SetDNSSEC(in s mode); + SetDNSSECNegativeTrustAnchors(in as names); + RevertNTP(); + RevertDNS(); + Renew(); + ForceRenew(); + Reconfigure(); + Describe(out s json); + properties: + readonly s OperationalState = '...'; + readonly s CarrierState = '...'; + readonly s AddressState = '...'; + readonly s IPv4AddressState = '...'; + readonly s IPv6AddressState = '...'; + readonly s OnlineState = '...'; + readonly s AdministrativeState = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (tt) BitRates = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.network1.DHCPServer { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Provides information about interfaces. + + + + + Network Object + + +node /org/freedesktop/network1/network/_1 { + interface org.freedesktop.network1.Network { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Description = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SourcePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as MatchMAC = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as MatchPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as MatchDriver = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as MatchType = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as MatchName = ['...', ...]; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Provides information about .network files. + + + + + DHCP Server Object + + +node /org/freedesktop/network1/link/_1 { + interface org.freedesktop.network1.DHCPServer { + properties: + readonly a(uayayayayt) Leases = [...]; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + Provides information about leases. + + + + + Examples + + + Introspect <interfacename>org.freedesktop.network1.Manager</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.network1 \ + --object-path /org/freedesktop/network1 + + + + + Introspect <interfacename>org.freedesktop.network1.Link</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.network1 \ + --object-path /org/freedesktop/network1/link/_11 + + + + + + diff --git a/man/org.freedesktop.oom1.xml b/man/org.freedesktop.oom1.xml new file mode 100644 index 0000000..c6b8c7f --- /dev/null +++ b/man/org.freedesktop.oom1.xml @@ -0,0 +1,98 @@ + + + + + + + org.freedesktop.oom1 + systemd + + + + org.freedesktop.oom1 + 5 + + + + org.freedesktop.oom1 + The D-Bus interface of systemd-oomd + + + + Introduction + + + systemd-oomd.service8 + is a system service which implements a userspace out-of-memory (OOM) killer. This page describes the + D-Bus interface. + + + + The Manager Object + + The service exposes the following interfaces on the Manager object on the bus: + + +node /org/freedesktop/oom1 { + interface org.freedesktop.oom1.Manager { + methods: + DumpByFileDescriptor(out h fd); + signals: + Killed(s cgroup, + s reason); + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + Methods + + Killed signal is sent when any cgroup is killed by oomd. + Note that more reasons will be added in the future, and the table below will be expanded accordingly. + + Killing reasons + + + + + + Reason + Description + + + + + memory-used + Application took too much memory and swap. + + + memory-pressure + Application took enough memory and swap to cause sufficient slowdown of other applications. + + + +
+ + + + + diff --git a/man/org.freedesktop.portable1.xml b/man/org.freedesktop.portable1.xml new file mode 100644 index 0000000..00db6f8 --- /dev/null +++ b/man/org.freedesktop.portable1.xml @@ -0,0 +1,569 @@ + + + + + + + org.freedesktop.portable1 + systemd + + + + org.freedesktop.portable1 + 5 + + + + org.freedesktop.portable1 + The D-Bus interface of systemd-portabled + + + + Introduction + + + systemd-portabled.service8 + is a system service that may be used to attach, detach and inspect portable services. This page describes the + D-Bus interface. + + + + The Manager Object + + The service exposes the following interfaces on the Manager object on the bus: + + +node /org/freedesktop/portable1 { + interface org.freedesktop.portable1.Manager { + methods: + GetImage(in s image, + out o object); + ListImages(out a(ssbtttso) images); + GetImageOSRelease(in s image, + out a{ss} os_release); + GetImageMetadata(in s image, + in as matches, + out s image, + out ay os_release, + out a{say} units); + GetImageMetadataWithExtensions(in s image, + in as extensions, + in as matches, + in t flags, + out s image, + out ay os_release, + out a{say} extensions, + out a{say} units); + GetImageState(in s image, + out s state); + GetImageStateWithExtensions(in s image, + in as extensions, + in t flags, + out s state); + AttachImage(in s image, + in as matches, + in s profile, + in b runtime, + in s copy_mode, + out a(sss) changes); + AttachImageWithExtensions(in s image, + in as extensions, + in as matches, + in s profile, + in s copy_mode, + in t flags, + out a(sss) changes); + DetachImage(in s image, + in b runtime, + out a(sss) changes); + DetachImageWithExtensions(in s image, + in as extensions, + in t flags, + out a(sss) changes); + ReattachImage(in s image, + in as matches, + in s profile, + in b runtime, + in s copy_mode, + out a(sss) changes_removed, + out a(sss) changes_updated); + ReattachImageWithExtensions(in s image, + in as extensions, + in as matches, + in s profile, + in s copy_mode, + in t flags, + out a(sss) changes_removed, + out a(sss) changes_updated); + RemoveImage(in s image); + MarkImageReadOnly(in s image, + in b read_only); + SetImageLimit(in s image, + in t limit); + SetPoolLimit(in t limit); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s PoolPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t PoolUsage = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t PoolLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as Profiles = ['...', ...]; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + GetImage() may be used to get the image object path of the image with the + specified name. + + ListImages() returns an array of all currently known images. The + structures in the array consist of the following fields: image name, type, read-only flag, creation + time, modification time, current disk space, usage and image object path. + + GetImageOSRelease() retrieves the OS release information of an image. + This method returns an array of key value pairs read from the + os-release5 file in + the image and is useful to identify the operating system used in a portable service. + + GetImageMetadata() retrieves metadata associated with an image. + This method returns the image name, the image's os-release + 5 content in the form of a (streamable) array of bytes, + and a list of portable units contained in the image, in the form of a string (unit name) and + an array of bytes with the content. + + GetImageMetadataWithExtensions() retrieves metadata associated with an + image. This method is a superset of GetImageMetadata() with the addition of a list + of extensions as input parameter, which were overlaid on top of the main image via + AttachImageWithExtensions(). The path of each extension and an array of bytes with + the content of the respective extension-release file are returned, one such structure for each + extension named in the input arguments. + + GetImageState() retrieves the image state as one of the following + strings: + + detached + + attached + + attached-runtime + + enabled + + enabled-runtime + + running + + running-runtime + + + GetImageStateWithExtensions() is a superset of + GetImageState(), with additional support for a list of extensions + as input parameters, which is necessary to query the state in case the image was attached + in that particular way. The flag parameter is currently unused and + reserved for future purposes. + + AttachImage() attaches a portable image to the system. + This method takes an image path or name, a list of strings that will be used to search for + unit files inside the image (partial or complete matches), a string indicating which + portable profile to use for the image (see Profiles property for + a list of available profiles), a boolean indicating whether to attach the image only + for the current boot session, and a string representing the preferred copy mode + (whether to copy the image or to just symlink it) with the following possible values: + + (null) + + copy + + symlink + + This method returns the list of changes applied to the system (for example, which unit was + added and is now available as a system service). Each change is represented as a triplet of + strings: the type of change applied, the path on which it was applied, and the source + (if any). The type of change applied will be one of the following possible values: + + copy + + symlink + + write + + mkdir + + Note that an image cannot be attached if a unit that it contains is already present + on the system. + + AttachImageWithExtensions() attaches a portable image to the system. + This method is a superset of AttachImage() with the addition of + a list of extensions as input parameter, which will be overlaid on top of the main + image. When this method is used, detaching must be done by passing the same arguments via the + DetachImageWithExtensions() method. For more details on this functionality, + see the MountImages= entry on + systemd.exec5 + and systemd-sysext8. + + + DetachImage() detaches a portable image from the system. + This method takes an image path or name, and a boolean indicating whether the image to + detach was attached only for the current boot session or persistently. This method + returns the list of changes applied to the system (for example, which unit was removed + and is no longer available as a system service). Each change is represented as a triplet of + strings: the type of change applied, the path on which it was applied, and the source + (if any). The type of change applied will be one of the following possible values: + + unlink + + Note that an image cannot be detached if a unit that it contains is running. + + DetachImageWithExtensions() detaches a portable image from the system. + This method is a superset of DetachImage() with the addition of + a list of extensions as input parameter, which were overlaid on top of the main + image via AttachImageWithExtensions(). + The flag parameter is currently unused and reserved for future purposes. + + ReattachImage() combines the effects of the + AttachImage() method and the DetachImage() method. + The difference is that it is allowed to reattach an image while one or more of its units + are running. The reattach operation will fail if no matching image is attached. + The input parameters match the AttachImage() method, and the return + parameters are the combination of the return parameters of the + DetachImage() method (first array, units that were removed) and the + AttachImage() method (second array, units that were updated or added). + + ReattachImageWithExtensions() reattaches a portable image to the system. + This method is a superset of ReattachImage() with the addition of + a list of extensions as input parameter, which will be overlaid on top of the main + image. For more details on this functionality, see the MountImages= entry on + systemd.exec5 + and systemd-sysext8. + The flag parameter is currently unused and reserved for future purposes + + RemoveImage() removes the image with the specified name. + + MarkImageReadOnly() toggles the read-only flag of an image. + + SetPoolLimit() sets an overall quota limit on the pool of images. + + SetImageLimit() sets a per-image quota limit. + + The AttachImageWithExtensions(), + DetachImageWithExtensions() and + ReattachImageWithExtensions() methods take in options as flags instead of + booleans to allow for extendability. SD_SYSTEMD_PORTABLE_FORCE_ATTACH will cause + safety checks that ensure the units are not running while the new image is attached or detached + to be skipped. SD_SYSTEMD_PORTABLE_FORCE_SYSEXT will cause the check that the + extension-release.NAME file in the extension image + matches the image name to be skipped. They are defined as follows: + + +#define SD_SYSTEMD_PORTABLE_RUNTIME (UINT64_C(1) << 0) +#define SD_SYSTEMD_PORTABLE_FORCE_ATTACH (UINT64_C(1) << 1) +#define SD_SYSTEMD_PORTABLE_FORCE_SYSEXT (UINT64_C(1) << 2) + + + + + Properties + + PoolPath specifies the file system path where images are written to. + + PoolUsage specifies the current usage size of the image pool in bytes. + + PoolLimit specifies the size limit of the image pool in bytes. + + Profiles specifies the available runtime profiles for portable services. + + + + + The Image Object + + The service exposes the following interfaces on the Image object on the bus: + + +node /org/freedesktop/portable1 { + interface org.freedesktop.portable1.Image { + methods: + GetOSRelease(out a{ss} os_release); + GetMetadata(in as matches, + out s image, + out ay os_release, + out a{say} units); + GetMetadataWithExtensions(in as extensions, + in as matches, + in t flags, + out s image, + out ay os_release, + out a{say} extensions, + out a{say} units); + GetState(out s state); + GetStateWithExtensions(in as extensions, + in t flags, + out s state); + Attach(in as matches, + in s profile, + in b runtime, + in s copy_mode, + out a(sss) changes); + AttachWithExtensions(in as extensions, + in as matches, + in s profile, + in s copy_mode, + in t flags, + out a(sss) changes); + Detach(in b runtime, + out a(sss) changes); + DetachWithExtensions(in as extensions, + in t flags, + out a(sss) changes); + Reattach(in as matches, + in s profile, + in b runtime, + in s copy_mode, + out a(sss) changes_removed, + out a(sss) changes_updated); + ReattacheWithExtensions(in as extensions, + in as matches, + in s profile, + in s copy_mode, + in t flags, + out a(sss) changes_removed, + out a(sss) changes_updated); + Remove(); + MarkReadOnly(in b read_only); + SetLimit(in t limit); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Name = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Path = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b ReadOnly = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CreationTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ModificationTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t Usage = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t Limit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t UsageExclusive = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t LimitExclusive = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + The following methods implement the same operation as the respective methods on the + Manager object (see above). However, these methods operate on the image + object and hence does not take an image name parameter. Invoking the methods directly on the Manager + object has the advantage of not requiring a GetImage() call to get the image object + for a specific image name. Calling the methods on the Manager object is hence a round trip + optimization. List of methods: + + GetOSRelease() + + GetMetadata() + + GetMetadataWithExtensions() + + GetState() + + Attach() + + AttachWithExtensions() + + Detach() + + DetachWithExtensions() + + Reattach() + + ReattacheWithExtensions() + + Remove() + + MarkReadOnly() + + SetLimit() + + + + + Properties + + Name specifies the image name. + + Path specifies the file system path where image is stored. + + Type specifies the image type. + + ReadOnly specifies whether the image is read-only. + + CreationTimestamp specifies the image creation timestamp. + + ModificationTimestamp specifies the image modification timestamp. + + Usage specifies the image disk usage. + + Limit specifies the image disk usage limit. + + UsageExclusive specifies the image disk usage (exclusive). + + LimitExclusive specifies the image disk usage limit (exclusive). + + + + + diff --git a/man/org.freedesktop.resolve1.xml b/man/org.freedesktop.resolve1.xml new file mode 100644 index 0000000..54f0a18 --- /dev/null +++ b/man/org.freedesktop.resolve1.xml @@ -0,0 +1,895 @@ + + + +%entities; +]> + + + + + org.freedesktop.resolve1 + systemd + + + + org.freedesktop.resolve1 + 5 + + + + org.freedesktop.resolve1 + The D-Bus interface of systemd-resolved + + + + Introduction + + + systemd-resolved.service8 + is a system service that provides hostname resolution and caching using DNS, LLMNR, and mDNS. It also + does DNSSEC validation. This page describes the resolve semantics and the D-Bus interface. + + This page contains an API reference only. If you are looking for a longer explanation how to use + this API, please consult + + Writing Network Configuration Managers and + Writing Resolver + Clients. + + + + + The Manager Object + + The service exposes the following interfaces on the Manager object on the bus: + + +node /org/freedesktop/resolve1 { + interface org.freedesktop.resolve1.Manager { + methods: + ResolveHostname(in i ifindex, + in s name, + in i family, + in t flags, + out a(iiay) addresses, + out s canonical, + out t flags); + ResolveAddress(in i ifindex, + in i family, + in ay address, + in t flags, + out a(is) names, + out t flags); + ResolveRecord(in i ifindex, + in s name, + in q class, + in q type, + in t flags, + out a(iqqay) records, + out t flags); + ResolveService(in i ifindex, + in s name, + in s type, + in s domain, + in i family, + in t flags, + out a(qqqsa(iiay)s) srv_data, + out aay txt_data, + out s canonical_name, + out s canonical_type, + out s canonical_domain, + out t flags); + GetLink(in i ifindex, + out o path); + SetLinkDNS(in i ifindex, + in a(iay) addresses); + SetLinkDNSEx(in i ifindex, + in a(iayqs) addresses); + SetLinkDomains(in i ifindex, + in a(sb) domains); + SetLinkDefaultRoute(in i ifindex, + in b enable); + SetLinkLLMNR(in i ifindex, + in s mode); + SetLinkMulticastDNS(in i ifindex, + in s mode); + SetLinkDNSOverTLS(in i ifindex, + in s mode); + SetLinkDNSSEC(in i ifindex, + in s mode); + SetLinkDNSSECNegativeTrustAnchors(in i ifindex, + in as names); + RevertLink(in i ifindex); + RegisterService(in s name, + in s name_template, + in s type, + in q service_port, + in q service_priority, + in q service_weight, + in aa{say} txt_datas, + out o service_path); + UnregisterService(in o service_path); + ResetStatistics(); + FlushCaches(); + ResetServerFeatures(); + properties: + readonly s LLMNRHostname = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s LLMNR = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s MulticastDNS = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSOverTLS = '...'; + readonly a(iiay) DNS = [...]; + readonly a(iiayqs) DNSEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(iiay) FallbackDNS = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(iiayqs) FallbackDNSEx = [...]; + readonly (iiay) CurrentDNSServer = ...; + readonly (iiayqs) CurrentDNSServerEx = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(isb) Domains = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (tt) TransactionStatistics = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (ttt) CacheStatistics = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSSEC = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (tttt) DNSSECStatistics = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b DNSSECSupported = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DNSSECNegativeTrustAnchors = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSStubListener = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ResolvConfMode = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + ResolveHostname() takes a hostname and resolves it to one or more IP + addresses. As parameters it takes the Linux network interface index to execute the query on, or 0 if + it may be done on any suitable interface. The name parameter specifies the hostname + to resolve. Note that if required, IDNA conversion is applied to this name unless it is resolved via + LLMNR or MulticastDNS. The family parameter limits the results to a specific address + family. It may be AF_INET, AF_INET6 or + AF_UNSPEC. If AF_UNSPEC is specified (recommended), both + kinds are retrieved, subject to local network configuration (i.e. if no local, routable IPv6 address is + found, no IPv6 address is retrieved; and similarly for IPv4). A 64-bit flags field + may be used to alter the behaviour of the resolver operation (see below). The method returns an array + of address records. Each address record consists of the interface index the address belongs to, an + address family as well as a byte array with the actual IP address data (which either has 4 or 16 + elements, depending on the address family). The returned address family will be one of + AF_INET or AF_INET6. For IPv6, the returned address interface + index should be used to initialize the .sin6_scope_id field of a + struct sockaddr_in6 instance to permit support for resolution to link-local IP + addresses. The address array is followed by the canonical name of the host, which may or may not be + identical to the resolved hostname. Finally, a 64-bit flags field is returned that + is defined similarly to the flags field that was passed in, but contains information + about the resolved data (see below). If the hostname passed in is an IPv4 or IPv6 address formatted as + string, it is parsed, and the result is returned. In this case, no network communication is + done. + + ResolveAddress() executes the reverse operation: it takes an IP address and + acquires one or more hostnames for it. As parameters it takes the interface index to execute the query + on, or 0 if all suitable interfaces are OK. The family + parameter indicates the address family of the IP address to resolve. It may be either + AF_INET or AF_INET6. The address parameter + takes the raw IP address data (as either a 4 or 16 byte array). The flags input + parameter may be used to alter the resolver operation (see below). The method returns an array of name + records, each consisting of an interface index and a hostname. The flags output + field contains additional information about the resolver operation (see below). + + ResolveRecord() takes a DNS resource record (RR) type, class and name, and + retrieves the full resource record set (RRset), including the RDATA, for it. As parameter it takes the + Linux network interface index to execute the query on, or 0 if it may be done on + any suitable interface. The name parameter specifies the RR domain name to look up + (no IDNA conversion is applied), followed by the 16-bit class and type fields (which may be + ANY). Finally, a flags field may be passed in to alter behaviour of the look-up (see + below). On completion, an array of RR items is returned. Each array entry consists of the network interface + index the RR was discovered on, the type and class field of the RR found, and a byte array of the raw + RR discovered. The raw RR data starts with the RR's domain name, in the original casing, followed + by the RR type, class, TTL and RDATA, in the binary format documented in + RFC 1035. For RRs that support name + compression in the payload (such as MX or PTR), the compression is expanded in the returned + data. + + Note that currently, the class field has to be specified as IN or ANY. Specifying a different + class will return an error indicating that look-ups of this kind are unsupported. Similarly, some + special types are not supported either (AXFR, OPT, …). While systemd-resolved parses and validates resource + records of many types, it is crucial that clients using this API understand that the RR data originates + from the network and should be thoroughly validated before use. + + ResolveService() may be used to resolve a DNS + SRV service record, as well as the hostnames referenced in it, and + possibly an accompanying DNS-SD TXT record containing additional + service metadata. The primary benefit of using this method over ResolveRecord() + specifying the SRV type is that it will resolve the + SRV and TXT RRs as well as the + hostnames referenced in the SRV in a single operation. As parameters it takes a Linux network interface + index, a service name, a service type and a service domain. This method may be invoked in three + different modes: + + + To resolve a DNS-SD service, specify the service name (e.g. Lennart's + Files), the service type (e.g. _webdav._tcp) and the domain to search in + (e.g. local) as the three service parameters. The service name must be in UTF-8 + format, and no IDNA conversion is applied to it in this mode (as mandated by the DNS-SD + specifications). However, if necessary, IDNA conversion is applied to the domain parameter. + + + To resolve a plain SRV record, set the service name + parameter to the empty string and set the service type and domain properly. (IDNA conversion is + applied to the domain, if necessary.) + + Alternatively, leave both the service name and type empty and specify the full domain + name of the SRV record (i.e. prefixed with the service type) in the + domain parameter. (No IDNA conversion is applied in this mode.) + + + The family parameter of the ResolveService() method encodes + the desired family of the addresses to resolve (use AF_INET, + AF_INET6, or AF_UNSPEC). If this is enabled (Use the + NO_ADDRESS flag to turn address resolution off, see below). The + flags parameter takes a couple of flags that may be used to alter the resolver + operation. + + On completion, ResolveService() returns an array of + SRV record structures. Each items consisting of the priority, weight and port + fields as well as the hostname to contact, as encoded in the SRV + record. Immediately following is an array of the addresses of this hostname, with each item consisting + of the interface index, the address family and the address data in a byte array. This address array is + followed by the canonicalized hostname. After this array of SRV record + structures an array of byte arrays follows that encodes the TXT RR strings, in case DNS-SD look-ups are + enabled. The next parameters are the canonical service name, type and domain. This may or may not be + identical to the parameters passed in. Finally, a flags field is returned that + contains information about the resolver operation performed. + + The ResetStatistics() method resets the various statistics counters that + systemd-resolved maintains to zero. (For details, see the statistics properties below.) + + The GetLink() method takes a network interface index and returns the object + path to the org.freedesktop.resolve1.Link object corresponding to it. + + + The SetLinkDNS() method sets the DNS servers to use on a specific + interface. This method (and the following ones) may be used by network management software to configure + per-interface DNS settings. It takes a network interface index as well as an array of DNS server IP + address records. Each array item consists of an address family (either AF_INET or + AF_INET6), followed by a 4-byte or 16-byte array with the raw address data. This + method is a one-step shortcut for retrieving the Link object for a network interface using + GetLink() (see above) and then invoking the SetDNS() method + (see below) on it. + + SetLinkDNSEx() is similar to SetLinkDNS(), but allows + an IP port (instead of the default 53) and DNS name to be specified for each DNS server. The server + name is used for Server Name Indication (SNI), which is useful when DNS-over-TLS is + used. C.f. DNS= in + resolved.conf5. + + + SetLinkDefaultRoute() specifies whether the link shall be used as the + default route for name queries. See the description of name routing in + systemd-resolved.service8 + for details. + + The SetLinkDomains() method sets the search and routing domains to use on a + specific network interface for DNS look-ups. It takes a network interface index and an array of domains, + each with a boolean parameter indicating whether the specified domain shall be used as a search domain + (false), or just as a routing domain (true). Search domains are used for qualifying single-label names into + FQDN when looking up hostnames, as well as for making routing decisions on which interface to send + queries ending in the domain to. Routing domains are only used for routing decisions and not used for single-label + name qualification. Pass the search domains in the order they should be used. + + The SetLinkLLMNR() method enables or disables LLMNR support on a specific + network interface. It takes a network interface index as well as a string that may either be empty or one of + yes, no or resolve. If empty, the systemd-wide + default LLMNR setting is used. If yes, LLMNR is used for resolution of single-label + names and the local hostname is registered on all local LANs for LLMNR resolution by peers. If + no, LLMNR is turned off fully on this interface. If resolve, LLMNR + is only enabled for resolving names, but the local hostname is not registered for other peers to + use. + + Similarly, the SetLinkMulticastDNS() method enables or disables MulticastDNS + support on a specific interface. It takes the same parameters as SetLinkLLMNR() + described above. + + The SetLinkDNSSEC() method enables or disables DNSSEC validation on a + specific network interface. It takes a network interface index as well as a string that may either be + empty or one of yes, no, or allow-downgrade. When + empty, the system-wide default DNSSEC setting is used. If yes, full DNSSEC validation + is done for all look-ups. If the selected DNS server does not support DNSSEC, look-ups will fail if this + mode is used. If no, DNSSEC validation is fully disabled. If + allow-downgrade, DNSSEC validation is enabled, but is turned off automatically if the + selected server does not support it (thus opening up behaviour to downgrade attacks). Note that DNSSEC + only applies to traditional DNS, not to LLMNR or MulticastDNS. + + The SetLinkDNSSECNegativeTrustAnchors() method may be used to configure DNSSEC + Negative Trust Anchors (NTAs) for a specific network interface. It takes a network interface index and a + list of domains as arguments. + + The SetLinkDNSOverTLS() method enables or disables DNS-over-TLS. + C.f. DNSOverTLS= in + systemd-resolved.service8 + for details. + + Network management software integrating with systemd-resolved should call + SetLinkDNS() or SetLinkDNSEx(), + SetLinkDefaultRoute(), SetLinkDomains() and others after the + interface appeared in the kernel (and thus after a network interface index has been assigned), but + before the network interfaces is activated (IFF_UP set) so that all settings take + effect during the full time the network interface is up. It is safe to alter settings while the + interface is up, however. Use RevertLink() (described below) to reset all + per-interface settings. + + The RevertLink() method may be used to revert all per-link settings + described above to the defaults. + + + The Flags Parameter + + The four methods above accept and return a 64-bit flags value. In most cases passing 0 is sufficient + and recommended. However, the following flags are defined to alter the look-up: + + +#define SD_RESOLVED_DNS (UINT64_C(1) << 0) +#define SD_RESOLVED_LLMNR_IPV4 (UINT64_C(1) << 1) +#define SD_RESOLVED_LLMNR_IPV6 (UINT64_C(1) << 2) +#define SD_RESOLVED_MDNS_IPV4 (UINT64_C(1) << 3) +#define SD_RESOLVED_MDNS_IPV6 (UINT64_C(1) << 4) +#define SD_RESOLVED_NO_CNAME (UINT64_C(1) << 5) +#define SD_RESOLVED_NO_TXT (UINT64_C(1) << 6) +#define SD_RESOLVED_NO_ADDRESS (UINT64_C(1) << 7) +#define SD_RESOLVED_NO_SEARCH (UINT64_C(1) << 8) +#define SD_RESOLVED_AUTHENTICATED (UINT64_C(1) << 9) +#define SD_RESOLVED_NO_VALIDATE (UINT64_C(1) << 10) +#define SD_RESOLVED_NO_SYNTHESIZE (UINT64_C(1) << 11) +#define SD_RESOLVED_NO_CACHE (UINT64_C(1) << 12) +#define SD_RESOLVED_NO_ZONE (UINT64_C(1) << 13) +#define SD_RESOLVED_NO_TRUST_ANCHOR (UINT64_C(1) << 14) +#define SD_RESOLVED_NO_NETWORK (UINT64_C(1) << 15) +#define SD_RESOLVED_REQUIRE_PRIMARY (UINT64_C(1) << 16) +#define SD_RESOLVED_CLAMP_TTL (UINT64_C(1) << 17) +#define SD_RESOLVED_CONFIDENTIAL (UINT64_C(1) << 18) +#define SD_RESOLVED_SYNTHETIC (UINT64_C(1) << 19) +#define SD_RESOLVED_FROM_CACHE (UINT64_C(1) << 20) +#define SD_RESOLVED_FROM_ZONE (UINT64_C(1) << 21) +#define SD_RESOLVED_FROM_TRUST_ANCHOR (UINT64_C(1) << 22) +#define SD_RESOLVED_FROM_NETWORK (UINT64_C(1) << 23) + + + On input, the first five flags control the protocols to use for the look-up. They refer to + classic unicast DNS, LLMNR via IPv4/UDP and IPv6/UDP respectively, as well as MulticastDNS via + IPv4/UDP and IPv6/UDP. If all of these five bits are off on input (which is strongly recommended) the + look-up will be done via all suitable protocols for the specific look-up. Note that these flags + operate as filter only, but cannot force a look-up to be done via a protocol. Specifically, + systemd-resolved will only route look-ups within the .local TLD to MulticastDNS + (plus some reverse look-up address domains), and single-label names to LLMNR (plus some reverse + address lookup domains). It will route neither of these to Unicast DNS servers. Also, it will do + LLMNR and Multicast DNS only on interfaces suitable for multicast. + + On output, these five flags indicate which protocol was used to execute the operation, and hence + where the data was found. + + The primary use cases for these five flags are follow-up look-ups based on DNS data retrieved + earlier. In this case it is often a good idea to limit the follow-up look-up to the protocol that was + used to discover the first DNS result. + + The NO_CNAME flag controls whether CNAME/DNAME resource records shall be followed during the + look-up. This flag is only available at input, none of the functions will return it on output. If a + CNAME/DNAME RR is discovered while resolving a hostname, an error is returned instead. By default, + when the flag is off, CNAME/DNAME RRs are followed. + + The NO_TXT and NO_ADDRESS flags only influence operation of the + ResolveService() method. They are only defined for input, not output. If NO_TXT + is set, the DNS-SD TXT RR look-up is not done in the same operation. If NO_ADDRESS is set, the + discovered hostnames are not implicitly translated to their addresses. + + The NO_SEARCH flag turns off the search domain logic. It is only defined for input in + ResolveHostname(). When specified, single-label hostnames are not qualified + using defined search domains, if any are configured. Note that ResolveRecord() + will never qualify single-label domain names using search domains. Also note that + multi-label hostnames are never subject to search list expansion. + + The AUTHENTICATED bit is defined only in the output flags of the four functions. If set, the + returned data has been fully authenticated. Specifically, this bit is set for all DNSSEC-protected + data for which a full trust chain may be established to a trusted domain anchor. It is also set for + locally synthesized data, such as localhost or data from + /etc/hosts. Moreover, it is set for all LLMNR or mDNS RRs which originate from + the local host. Applications that require authenticated RR data for operation should check this flag + before trusting the data. Note that systemd-resolved will never return + invalidated data, hence this flag simply allows one to discern the cases where data is known to be + trusted, or where there is proof that the data is "rightfully" unauthenticated (which includes cases + where the underlying protocol or server does not support authenticating data). + + NO_VALIDATE can be set to disable validation via DNSSEC even if it would normally be used. + + + The next four flags allow disabling certain sources during resolution. NO_SYNTHESIZE disables + synthetic records, e.g. the local host name, see section SYNTHETIC RECORDS in + systemd-resolved.service8 + for more information. NO_CACHE disables the use of the cache of previously resolved records. NO_ZONE + disables answers using locally registered public LLMNR/mDNS resource records. NO_TRUST_ANCHOR + disables answers using locally configured trust anchors. NO_NETWORK requires all answers to be + provided without using the network, i.e. either from local sources or the cache. + + With REQUIRE_PRIMARY the request must be answered from a "primary" answer, i.e. not from + resource records acquired as a side-effect of a previous transaction. + + With CLAMP_TTL, if reply is answered from cache, the TTLs will be adjusted by age of cache + entry. + + The next six bits flags are used in output and provide information about the source of the answer. + CONFIDENTIAL means the query was resolved via encrypted channels or never left this system. + FROM_SYNTHETIC means the query was (at least partially) synthesized. + FROM_CACHE means the query was answered (at least partially) using the cache. + FROM_ZONE means the query was answered (at least partially) using LLMNR/mDNS. + FROM_TRUST_ANCHOR means the query was answered (at least partially) using local trust anchors. + FROM_NETWORK means the query was answered (at least partially) using the network. + + + + + + Properties + + The LLMNR and MulticastDNS properties report whether LLMNR + and MulticastDNS are (globally) enabled. Each may be one of yes, + no, and resolve. See SetLinkLLMNR() + and SetLinkMulticastDNS() above. + + LLMNRHostname contains the hostname currently exposed on the network via + LLMNR. It usually follows the system hostname as may be queried via + gethostname3, + but may differ if a conflict is detected on the network. + + DNS and DNSEx contain arrays of all DNS servers currently + used by systemd-resolved. DNS contains information similar to + the DNS server data in /run/systemd/resolve/resolv.conf. Each structure in the + array consists of a numeric network interface index, an address family, and a byte array containing the + DNS server address (either 4 bytes in length for IPv4 or 16 bytes in lengths for IPv6). + DNSEx is similar, but additionally contains the IP port and server name (used for + Server Name Indication, SNI). Both arrays contain DNS servers configured system-wide, including those + possibly read from a foreign /etc/resolv.conf or the DNS= + setting in /etc/systemd/resolved.conf, as well as per-interface DNS server + information either retrieved from + systemd-networkd8, + or configured by external software via SetLinkDNS() or + SetLinkDNSEx() (see above). The network interface index will be 0 for the + system-wide configured services and non-zero for the per-link servers. + + FallbackDNS and FallbackDNSEx contain arrays of all DNS + servers configured as fallback servers, if any, using the same format as DNS and + DNSEx described above. See the description of FallbackDNS= in + resolved.conf5 for + the description of when those servers are used. + + CurrentDNSServer and CurrentDNSServerEx specify the server + that is currently used for query resolution, in the same format as a single entry in the + DNS and DNSEx arrays described above. + + Similarly, the Domains property contains an array of all search and routing + domains currently used by systemd-resolved. Each entry consists of a network + interface index (again, 0 encodes system-wide entries), the actual domain name, and whether the entry + is used only for routing (true) or for both routing and searching (false). + + The TransactionStatistics property contains information about the number of + transactions systemd-resolved has processed. It contains a pair of unsigned 64-bit counters, the first + containing the number of currently ongoing transactions, the second the number of total transactions + systemd-resolved is processing or has processed. The latter value may be reset using the + ResetStatistics() method described above. Note that the number of transactions does + not directly map to the number of issued resolver bus method calls. While simple look-ups usually require a + single transaction only, more complex look-ups might result in more, for example when CNAMEs or DNSSEC + are in use. + + The CacheStatistics property contains information about the executed cache + operations so far. It exposes three 64-bit counters: the first being the total number of current cache + entries (both positive and negative), the second the number of cache hits, and the third the number of + cache misses. The latter counters may be reset using ResetStatistics() (see + above). + + The DNSSEC property specifies current status of DNSSEC validation. It is one + of yes (validation is enforced), no (no validation is done), + allow-downgrade (validation is done if the current DNS server supports it). See the + description of DNSSEC= in + resolved.conf5. + + + The DNSSECStatistics property contains information about the DNSSEC + validations executed so far. It contains four 64-bit counters: the number of secure, insecure, bogus, + and indeterminate DNSSEC validations so far. The counters are increased for each validated RRset, and + each non-existence proof. The secure counter is increased for each operation that successfully verified + a signed reply, the insecure counter is increased for each operation that successfully verified that an + unsigned reply is rightfully unsigned. The bogus counter is increased for each operation where the + validation did not check out and the data is likely to have been tempered with. Finally the + indeterminate counter is increased for each operation which did not complete because the necessary keys + could not be acquired or the cryptographic algorithms were unknown. + + The DNSSECSupported boolean property reports whether DNSSEC is enabled and + the selected DNS servers support it. It combines information about system-wide and per-link DNS + settings (see below), and only reports true if DNSSEC is enabled and supported on every interface for + which DNS is configured and for the system-wide settings if there are any. Note that systemd-resolved assumes + DNSSEC is supported by DNS servers until it verifies that this is not the case. Thus, the reported + value may initially be true, until the first transactions are executed. + + The DNSOverTLS boolean property reports whether DNS-over-TLS is enabled. + + + The ResolvConfMode property exposes how /etc/resolv.conf + is managed on the host. Currently, the values uplink, stub, + static (these three correspond to the three different files + systemd-resolved.service provides), foreign (the file is + managed by admin or another service, systemd-resolved.service just consumes it), + missing (/etc/resolv.conf is missing). + + The DNSStubListener property reports whether the stub listener on port 53 is + enabled. Possible values are yes (enabled), no (disabled), + udp (only the UDP listener is enabled), and tcp (only the TCP + listener is enabled). + + + + + Link Object + + +node /org/freedesktop/resolve1/link/_1 { + interface org.freedesktop.resolve1.Link { + methods: + SetDNS(in a(iay) addresses); + SetDNSEx(in a(iayqs) addresses); + SetDomains(in a(sb) domains); + SetDefaultRoute(in b enable); + SetLLMNR(in s mode); + SetMulticastDNS(in s mode); + SetDNSOverTLS(in s mode); + SetDNSSEC(in s mode); + SetDNSSECNegativeTrustAnchors(in as names); + Revert(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ScopesMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iay) DNS = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayqs) DNSEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (iay) CurrentDNSServer = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (iayqs) CurrentDNSServerEx = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(sb) Domains = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b DefaultRoute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s LLMNR = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s MulticastDNS = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSOverTLS = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DNSSEC = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DNSSECNegativeTrustAnchors = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b DNSSECSupported = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + For each Linux network interface a "Link" object is created which exposes per-link DNS + configuration and state. Use GetLink() on the Manager interface to retrieve the + object path for a link object given the network interface index (see above). + + + Methods + + The various methods exposed by the Link interface are equivalent to their similarly named + counterparts on the Manager interface. e.g. SetDNS() on the Link object maps to + SetLinkDNS() on the Manager object, the main difference being that the later + expects an interface index to be specified. Invoking the methods on the Manager interface has the + benefit of reducing roundtrips, as it is not necessary to first request the Link object path via + GetLink() before invoking the methods. The same relationship holds for + SetDNSEx(), SetDomains(), + SetDefaultRoute(), SetLLMNR(), + SetMulticastDNS(), SetDNSOverTLS(), + SetDNSSEC(), SetDNSSECNegativeTrustAnchors(), and + Revert(). For further details on these methods see the + Manager documentation above. + + + + Properties + + ScopesMask defines which resolver scopes are currently active on this + interface. This 64-bit unsigned integer field is a bit mask consisting of a subset of the bits of the + flags parameter describe above. Specifically, it may have the DNS, LLMNR and MDNS bits (the latter in + IPv4 and IPv6 flavours) set. Each individual bit is set when the protocol applies to a specific + interface and is enabled for it. It is unset otherwise. Specifically, a multicast-capable interface in + the "UP" state with an IP address is suitable for LLMNR or MulticastDNS, and any interface that is UP and + has an IP address is suitable for DNS. Note the relationship of the bits exposed here with the LLMNR + and MulticastDNS properties also exposed on the Link interface. The latter expose what is *configured* + to be used on the interface, the former expose what is actually used on the interface, taking into + account the abilities of the interface. + + DNSSECSupported exposes a boolean field that indicates whether DNSSEC is + currently configured and in use on the interface. Note that if DNSSEC is enabled on an interface, it is + assumed available until it is detected that the configured server does not actually support it. Thus, + this property may initially report that DNSSEC is supported on an interface. + + DefaultRoute exposes a boolean field that indicates whether the interface will + be used as default route for name queries. See SetLinkDefaultRoute() above. + + The other properties reflect the state of the various configuration settings for the link which + may be set with the various methods calls such as SetDNS() or + SetLLMNR(). + + + + + Common Errors + + Many bus methods systemd-resolved exposes (in particular the resolver methods such + as ResolveHostname() on the Manager interface) may return + some of the following errors: + + + org.freedesktop.resolve1.NoNameServers + No suitable DNS servers were found to resolve a request. + + + org.freedesktop.resolve1.InvalidReply + A response from the selected DNS server was not understood. + + + org.freedesktop.resolve1.NoSuchRR + The requested name exists, but there is no resource record of the requested type for + it. (This is the DNS NODATA case). + + org.freedesktop.resolve1.CNameLoop + The look-up failed because a CNAME or DNAME loop was detected. + + + org.freedesktop.resolve1.Aborted + The look-up was aborted because the selected protocol became unavailable while the + operation was ongoing. + + + org.freedesktop.resolve1.NoSuchService + A service look-up was successful, but the SRV record + reported that the service is not available. + + org.freedesktop.resolve1.DnssecFailed + The acquired response did not pass DNSSEC validation. + + + org.freedesktop.resolve1.NoTrustAnchor + No chain of trust could be established for the response to a configured DNSSEC trust + anchor. + + + org.freedesktop.resolve1.ResourceRecordTypeUnsupported + The requested resource record type is not supported on the selected DNS servers. This + error is generated for example when an RRSIG record is requested from a DNS server that does not + support DNSSEC. + + + + org.freedesktop.resolve1.NoSuchLink + No network interface with the specified network interface index exists. + + + org.freedesktop.resolve1.LinkBusy + The requested configuration change could not be made because + systemd-networkd8, + already took possession of the interface and supplied configuration data for it. + + + org.freedesktop.resolve1.NetworkDown + The requested look-up failed because the system is currently not connected to any + suitable network. + + org.freedesktop.resolve1.DnsError.NXDOMAIN + org.freedesktop.resolve1.DnsError.REFUSED + ... + The look-up failed with a DNS return code reporting a failure. The error names used as + suffixes here are defined in by IANA in + DNS RCODEs. + + + + + + + Examples + + + Introspect <interfacename>org.freedesktop.resolve1.Manager</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.resolve1 \ + --object-path /org/freedesktop/resolve1 + + + + + Introspect <interfacename>org.freedesktop.resolve1.Link</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.resolve1 \ + --object-path /org/freedesktop/resolve1/link/_11 + + + + + + diff --git a/man/org.freedesktop.systemd1.xml b/man/org.freedesktop.systemd1.xml new file mode 100644 index 0000000..0332632 --- /dev/null +++ b/man/org.freedesktop.systemd1.xml @@ -0,0 +1,10819 @@ + + + + + + + org.freedesktop.systemd1 + systemd + + + + org.freedesktop.systemd1 + 5 + + + + org.freedesktop.systemd1 + The D-Bus interface of systemd + + + + Introduction + + + systemd1 and its + auxiliary daemons expose a number of APIs over D-Bus. This page only describes the various APIs exposed by the + system and service manager itself. It does not cover the auxiliary daemons. + + + The service manager exposes a number of objects on the bus: one + Manager object as a central entry point for clients along with individual objects + for each unit and for each queued job. The unit objects implement a generic + Unit interface as well as a type-specific interface. For example, service units + implement both org.freedesktop.systemd1.Unit and + org.freedesktop.system1.Service. The manager object can list + unit and job objects or directly convert a unit name or job identifier to a bus path of the corresponding + D-Bus object. + + Properties exposing time values are usually encoded in microseconds (µs) on the bus, even if + their corresponding settings in the unit files are in seconds. + + PID 1 uses polkit to + allow access to privileged operations for unprivileged processes. Some operations (such as + shutdown/reboot/suspend) are also available through the D-Bus API of logind, see + org.freedesktop.login15. + + + + + The Manager Object + + The main entry point object is available on the fixed + /org/freedesktop/systemd1 object path: + + +node /org/freedesktop/systemd1 { + interface org.freedesktop.systemd1.Manager { + methods: + GetUnit(in s name, + out o unit); + GetUnitByPID(in u pid, + out o unit); + GetUnitByInvocationID(in ay invocation_id, + out o unit); + GetUnitByControlGroup(in s cgroup, + out o unit); + LoadUnit(in s name, + out o unit); + StartUnit(in s name, + in s mode, + out o job); + StartUnitWithFlags(in s name, + in s mode, + in t flags, + out o job); + StartUnitReplace(in s old_unit, + in s new_unit, + in s mode, + out o job); + StopUnit(in s name, + in s mode, + out o job); + ReloadUnit(in s name, + in s mode, + out o job); + RestartUnit(in s name, + in s mode, + out o job); + TryRestartUnit(in s name, + in s mode, + out o job); + ReloadOrRestartUnit(in s name, + in s mode, + out o job); + ReloadOrTryRestartUnit(in s name, + in s mode, + out o job); + EnqueueUnitJob(in s name, + in s job_type, + in s job_mode, + out u job_id, + out o job_path, + out s unit_id, + out o unit_path, + out s job_type, + out a(uosos) affected_jobs); + KillUnit(in s name, + in s whom, + in i signal); + CleanUnit(in s name, + in as mask); + FreezeUnit(in s name); + ThawUnit(in s name); + ResetFailedUnit(in s name); + SetUnitProperties(in s name, + in b runtime, + in a(sv) properties); + BindMountUnit(in s name, + in s source, + in s destination, + in b read_only, + in b mkdir); + MountImageUnit(in s name, + in s source, + in s destination, + in b read_only, + in b mkdir, + in a(ss) options); + RefUnit(in s name); + UnrefUnit(in s name); + StartTransientUnit(in s name, + in s mode, + in a(sv) properties, + in a(sa(sv)) aux, + out o job); + GetUnitProcesses(in s name, + out a(sus) processes); + AttachProcessesToUnit(in s unit_name, + in s subcgroup, + in au pids); + AbandonScope(in s name); + GetJob(in u id, + out o job); + GetJobAfter(in u id, + out a(usssoo) jobs); + GetJobBefore(in u id, + out a(usssoo) jobs); + CancelJob(in u id); + ClearJobs(); + ResetFailed(); + SetShowStatus(in s mode); + ListUnits(out a(ssssssouso) units); + ListUnitsFiltered(in as states, + out a(ssssssouso) units); + ListUnitsByPatterns(in as states, + in as patterns, + out a(ssssssouso) units); + ListUnitsByNames(in as names, + out a(ssssssouso) units); + ListJobs(out a(usssoo) jobs); + Subscribe(); + Unsubscribe(); + Dump(out s output); + DumpUnitsMatchingPatterns(in as patterns, + out s output); + DumpByFileDescriptor(out h fd); + DumpUnitsMatchingPatternsByFileDescriptor(in as patterns, + out h fd); + Reload(); + @org.freedesktop.DBus.Method.NoReply("true") + Reexecute(); + @org.freedesktop.systemd1.Privileged("true") + Exit(); + @org.freedesktop.systemd1.Privileged("true") + Reboot(); + @org.freedesktop.systemd1.Privileged("true") + PowerOff(); + @org.freedesktop.systemd1.Privileged("true") + Halt(); + @org.freedesktop.systemd1.Privileged("true") + KExec(); + @org.freedesktop.systemd1.Privileged("true") + SwitchRoot(in s new_root, + in s init); + SetEnvironment(in as assignments); + UnsetEnvironment(in as names); + UnsetAndSetEnvironment(in as names, + in as assignments); + EnqueueMarkedJobs(out ao jobs); + ListUnitFiles(out a(ss) unit_files); + ListUnitFilesByPatterns(in as states, + in as patterns, + out a(ss) unit_files); + GetUnitFileState(in s file, + out s state); + EnableUnitFiles(in as files, + in b runtime, + in b force, + out b carries_install_info, + out a(sss) changes); + DisableUnitFiles(in as files, + in b runtime, + out a(sss) changes); + EnableUnitFilesWithFlags(in as files, + in t flags, + out b carries_install_info, + out a(sss) changes); + DisableUnitFilesWithFlags(in as files, + in t flags, + out a(sss) changes); + ReenableUnitFiles(in as files, + in b runtime, + in b force, + out b carries_install_info, + out a(sss) changes); + LinkUnitFiles(in as files, + in b runtime, + in b force, + out a(sss) changes); + PresetUnitFiles(in as files, + in b runtime, + in b force, + out b carries_install_info, + out a(sss) changes); + PresetUnitFilesWithMode(in as files, + in s mode, + in b runtime, + in b force, + out b carries_install_info, + out a(sss) changes); + MaskUnitFiles(in as files, + in b runtime, + in b force, + out a(sss) changes); + UnmaskUnitFiles(in as files, + in b runtime, + out a(sss) changes); + RevertUnitFiles(in as files, + out a(sss) changes); + SetDefaultTarget(in s name, + in b force, + out a(sss) changes); + GetDefaultTarget(out s name); + PresetAllUnitFiles(in s mode, + in b runtime, + in b force, + out a(sss) changes); + AddDependencyUnitFiles(in as files, + in s target, + in s type, + in b runtime, + in b force, + out a(sss) changes); + GetUnitFileLinks(in s name, + in b runtime, + out as links); + SetExitCode(in y number); + LookupDynamicUserByName(in s name, + out u uid); + LookupDynamicUserByUID(in u uid, + out s name); + GetDynamicUsers(out a(us) users); + signals: + UnitNew(s id, + o unit); + UnitRemoved(s id, + o unit); + JobNew(u id, + o job, + s unit); + JobRemoved(u id, + o job, + s unit, + s result); + StartupFinished(t firmware, + t loader, + t kernel, + t initrd, + t userspace, + t total); + UnitFilesChanged(); + Reloading(b active); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Version = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Features = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Virtualization = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Architecture = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Tainted = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t FirmwareTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t FirmwareTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LoaderTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LoaderTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t KernelTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t KernelTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UserspaceTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UserspaceTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t FinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t FinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SecurityStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SecurityStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SecurityFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SecurityFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t GeneratorsStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t GeneratorsStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t GeneratorsFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t GeneratorsFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t UnitsLoadTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDSecurityStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDSecurityStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDSecurityFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDSecurityFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDGeneratorsStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDGeneratorsStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDGeneratorsFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDGeneratorsFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDUnitsLoadStartTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDUnitsLoadStartTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDUnitsLoadFinishTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t InitRDUnitsLoadFinishTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s LogLevel = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s LogTarget = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NNames = ...; + readonly u NFailedUnits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NJobs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NInstalledJobs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NFailedJobs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly d Progress = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ConfirmSpawn = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b ShowStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnitPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s DefaultStandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s DefaultStandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WatchdogDevice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t WatchdogLastPingTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t WatchdogLastPingTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite t RuntimeWatchdogUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite t RuntimeWatchdogPreUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite s RuntimeWatchdogPreGovernor = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite t RebootWatchdogUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite t KExecWatchdogUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + @org.freedesktop.systemd1.Privileged("true") + readwrite b ServiceWatchdogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s SystemState = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly y ExitCode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultTimerAccuracyUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultTimeoutStartUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultTimeoutStopUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultTimeoutAbortUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultDeviceTimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultRestartUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultStartLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DefaultStartLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultCPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultBlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultMemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultTasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DefaultLimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultTasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s DefaultOOMPolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i DefaultOOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s CtrlAltDelBurstAction = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Note that many of the methods exist twice: once on the Manager + object and once on the respective unit objects. This is to optimize access times so that methods that + belong to unit objects do not have to be called with a resolved unit path, but can be called with only + the unit id, too. + + GetUnit() may be used to get the unit object path for a unit name. It takes + the unit name and returns the object path. If a unit has not been loaded yet by this name this method + will fail. + + GetUnitByPID() may be used to get the unit object path of the unit a process + ID belongs to. It takes a UNIX PID and returns the object path. The PID must refer to an existing system process. + + LoadUnit() is similar to GetUnit() but will load the + unit from disk if possible. + + StartUnit() enqueues a start job and possibly depending jobs. It takes the unit + to activate and a mode string as arguments. The mode needs to be one of replace, + fail, isolate, ignore-dependencies, or + ignore-requirements. If replace, the method will start the unit and + its dependencies, possibly replacing already queued jobs that conflict with it. If + fail, the method will start the unit and its dependencies, but will fail if this would + change an already queued job. If isolate, the method will start the unit in question + and terminate all units that aren't dependencies of it. If ignore-dependencies, it + will start a unit but ignore all its dependencies. If ignore-requirements, it will + start a unit but only ignore the requirement dependencies. It is not recommended to make use of the + latter two options. On completion, this method returns the newly created job object. + + StartUnitReplace() is similar to StartUnit() but + replaces a job that is queued for one unit by a job for another unit. + + StartUnitWithFlags() is similar to StartUnit() but + allows the caller to pass an extra flags parameter, which does not support any + flags for now, and is reserved for future extensions. + + StopUnit() is similar to StartUnit() but stops the + specified unit rather than starting it. Note that the isolate mode is invalid for this + method. + + ReloadUnit(), RestartUnit(), + TryRestartUnit(), ReloadOrRestartUnit(), or + ReloadOrTryRestartUnit() may be used to restart and/or reload a unit. These methods take + similar arguments as StartUnit(). Reloading is done only if the unit is already + running and fails otherwise. If a service is restarted that isn't running, it will be started unless + the "Try" flavor is used in which case a service that isn't running is not affected by the restart. The + "ReloadOrRestart" flavors attempt a reload if the unit supports it and use a restart otherwise. + + EnqueueMarkedJobs() creates reload/restart jobs for units which have been + appropriately marked, see Markers property above. This is equivalent to calling + TryRestartUnit() or ReloadOrTryRestartUnit() for the marked + units. + + BindMountUnit() can be used to bind mount new files or directories into + a running service mount namespace. + + MountImageUnit() can be used to mount new images into a running service + mount namespace. + + KillUnit() may be used to kill (i.e. send a signal to) all processes of a + unit. It takes the unit name, an enum who and a UNIX + signal number to send. The who enum is one of + main, control or all. If + main, only the main process of the unit is killed. If control, only + the control process of the unit is killed. If all, all processes are killed. A + control process is for example a process that is configured via + ExecStop= and is spawned in parallel to the main daemon process in order to shut it + down. + + GetJob() returns the job object path for a specific job, identified by its + id. + + CancelJob() cancels a specific job identified by its numeric ID. This + operation is also available in the Cancel() method of Job objects (see below) and + exists primarily to reduce the necessary round trips to execute this operation. Note that this will not + have any effect on jobs whose execution has already begun. + + ClearJobs() flushes the job queue, removing all jobs that are still + queued. Note that this does not have any effect on jobs whose execution has already begun. It only + flushes jobs that are queued and have not yet begun execution. + + ResetFailedUnit() resets the "failed" state of a specific unit. + + ResetFailed() resets the "failed" state of all units. + + ListUnits() returns an array of all currently loaded units. Note that + units may be known by multiple names at the same time, and hence there might be more unit names loaded + than actual units behind them. The array consists of structures with the following elements: + + The primary unit name as string + + The human readable description string + + The load state (i.e. whether the unit file has been loaded + successfully) + + The active state (i.e. whether the unit is currently started or + not) + + The sub state (a more fine-grained version of the active state that is specific to + the unit type, which the active state is not) + + A unit that is being followed in its state by this unit, if there is any, otherwise + the empty string. + + The unit object path + + If there is a job queued for the job unit, the numeric job id, 0 + otherwise + + The job type as string + + The job object path + + + ListJobs() returns an array with all currently queued jobs. Returns an array + consisting of structures with the following elements: + + The numeric job id + + The primary unit name for this job + + The job type as string + + The job state as string + + The job object path + + The unit object path + + + Subscribe() enables most bus signals to be sent out. Clients which are + interested in signals need to call this method. Signals are only sent out if at least one client + invoked this method. Unsubscribe() reverts the signal subscription that + Subscribe() implements. It is not necessary to invoke + Unsubscribe() as clients are tracked. Signals are no longer sent out as soon as + 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. Similarly, DumpUnitsMatchingPatterns() returns + the internal state of units whose names match the glob expressions specified in the + patterns argument. The + DumpByFileDescriptor()/DumpUnitsMatchingPatternsByFileDescriptor() + methods are identical to Dump()/DumpUnitsMatchingPatterns(), + but return 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 + strings, + DumpByFileDescriptor()/DumpUnitsMatchingPatternsByFileDescriptor() + are usually the preferred interface, since it ensures the data can be passed reliably from the service + manager to the client. Note though that they cannot work when communicating with the service manager + remotely, as file descriptors are strictly local to a system. All the Dump*() + methods are rate limited for unprivileged users. + + Reload() may be invoked to reload all unit files. + + Reexecute() may be invoked to reexecute the main manager process. It will + serialize its state, reexecute, and deserizalize the state again. This is useful for upgrades and is a + more comprehensive version of Reload(). + + Exit() may be invoked to ask the manager to exit. This is not available for + the system manager and is useful only for user session managers. + + Reboot(), PowerOff(), Halt(), or + KExec() may be used to ask for immediate reboot, powering down, halt or kexec + based reboot of the system. Note that this does not shut down any services and immediately transitions + into the reboot process. These functions are normally only called as the last step of shutdown and should + not be called directly. To shut down the machine, it is generally a better idea to invoke + Reboot() or PowerOff() on the + systemd-logind manager object; see + org.freedesktop.login15 + for more information. + + SwitchRoot() may be used to transition to a new root directory. This is + intended to be used in the initrd, and also to transition from the host system into a shutdown initrd. + The method takes two arguments: the new root directory (which needs to be specified) and an init binary + path (which may be left empty, in which case it is automatically searched for). The state of the system + manager will be serialized before the transition. After the transition, the manager binary on the main + system is invoked and replaces the old PID 1. All state will then be deserialized. + + SetEnvironment() may be used to alter the environment block that is passed + to all spawned processes. It takes a string array of environment variable assignments. Any previously set + environment variables will be overridden. + + UnsetEnvironment() may be used to unset environment variables. It takes a + string array of environment variable names. All variables specified will be unset (if they have been + set previously) and no longer be passed to all spawned processes. This method has no effect for variables + that were previously not set, but will not fail in that case. + + UnsetAndSetEnvironment() is a combination of + UnsetEnvironment() and SetEnvironment(). It takes two + lists. The first list contains variables to unset, the second one contains assignments to set. If a + variable is listed in both, the variable is set after this method returns, i.e. the set list overrides the + unset list. + + ListUnitFiles() returns an array of unit names and their enablement + status. Note that ListUnit() returns a list of units currently loaded into memory, + while ListUnitFiles() returns a list of unit files that were + found on disk. Note that while most units are read directly from a unit file with the same name, some + units are not backed by files and some files (templates) cannot directly be loaded as units but need + to be instantiated instead. + + GetUnitFileState() returns the current enablement status of a specific unit + file. + + EnableUnitFiles() may be used to enable one or more units in the system (by + creating symlinks to them in /etc/ or /run/). It takes a list + of unit files to enable (either just file names or full absolute paths if the unit files are residing + outside the usual unit search paths) and two booleans: the first controls whether the unit shall be + enabled for runtime only (true, /run/), or persistently (false, + /etc/). The second one controls whether symlinks pointing to other units shall be + replaced if necessary. This method returns one boolean and an array of the changes made. The boolean + signals whether the unit files contained any enablement information (i.e. an [Install]) section. The + changes array consists of structures with three strings: the type of the change (one of + symlink or unlink), the file name of the symlink and the + destination of the symlink. Note that most of the following calls return a changes list in the same + format. + + Similarly, DisableUnitFiles() disables one or more units in the system, + i.e. removes all symlinks to them in /etc/ and /run/. + + The EnableUnitFilesWithFlags() and DisableUnitFilesWithFlags() + take in options as flags instead of booleans to allow for extendability, defined as follows: + + +#define SD_SYSTEMD_UNIT_RUNTIME (UINT64_C(1) << 0) +#define SD_SYSTEMD_UNIT_FORCE (UINT64_C(1) << 1) +#define SD_SYSTEMD_UNIT_PORTABLE (UINT64_C(1) << 2) + + + SD_SYSTEMD_UNIT_RUNTIME will enable or disable the unit for runtime only, + SD_SYSTEMD_UNIT_FORCE controls whether symlinks pointing to other units shall be + replaced if necessary. SD_SYSTEMD_UNIT_PORTABLE will add or remove the symlinks in + /etc/systemd/system.attached and /run/systemd/system.attached. + + Similarly, ReenableUnitFiles() applies the changes to one or more units that + would result from disabling and enabling the unit quickly one after the other in an atomic + fashion. This is useful to apply updated [Install] information contained in unit files. + + Similarly, LinkUnitFiles() links unit files (that are located outside of the + usual unit search paths) into the unit search path. + + Similarly, PresetUnitFiles() enables/disables one or more unit files + according to the preset policy. See + systemd.preset7 for more + information. + + Similarly, MaskUnitFiles() masks unit files and + UnmaskUnitFiles() unmasks them again. + + SetDefaultTarget() changes the default.target link. See + bootup7 for more + information. + + GetDefaultTarget() retrieves the name of the unit to which + default.target is aliased. + + SetUnitProperties() may be used to modify certain unit properties at + runtime. Not all properties may be changed at runtime, but many resource management settings (primarily + those listed in + systemd.resource-control5) + may. The changes are applied instantly and stored on disk for future boots, unless + runtime is true, in which case the settings only apply until the next + reboot. name is the name of the unit to modify. properties are + the settings to set, encoded as an array of property name and value pairs. Note that this is not a + dictionary! Also note that when setting array properties with this method usually results in appending to + the pre-configured array. To reset the configured arrays, set the property to an empty array first and + then append to it. + + StartTransientUnit() may be used to create and start a transient unit which + will be released as soon as it is not running or referenced anymore or the system is + rebooted. name is the unit name including its suffix and must be + unique. mode is the same as in StartUnit(), + properties contains properties of the unit, specified like in + SetUnitProperties(). aux is currently unused and should be + passed as an empty array. See the + New Control Group + Interface for more information how to make use of this functionality for resource control + purposes. + + + + Signals + + Note that most signals are sent out only after Subscribe() has been invoked + by at least one client. Make sure to invoke this method when subscribing to these signals! + + UnitNew() and UnitRemoved() are sent out each time a + new unit is loaded or unloaded. Note that this has little to do with whether a unit is available on + disk or not, and simply reflects the units that are currently loaded into memory. The signals take two + parameters: the primary unit name and the object path. + + JobNew() and JobRemoved() are sent out each time a new + job is queued or dequeued. Both signals take the numeric job ID, the bus path and the primary unit name + for this job as arguments. JobRemoved() also includes a result string which is one + of done, canceled, timeout, + failed, dependency, or + skipped. done indicates successful execution of a + job. canceled indicates that a job has been canceled (via + CancelJob() above) before it finished execution (this doesn't necessarily mean + though that the job operation is actually cancelled too, see above). timeout + indicates that the job timeout was reached. failed indicates that the job + failed. dependency indicates that a job this job depended on failed and the job hence + was removed as well. skipped indicates that a job was skipped because + it didn't apply to the unit's current state. + + StartupFinished() is sent out when startup finishes. It carries six + microsecond timespan values, each indicating how much boot time has been spent in the firmware (if + known), in the boot loader (if known), in the kernel initialization phase, in the initrd (if known), in + userspace and in total. These values may also be calculated from the + FirmwareTimestampMonotonic, LoaderTimestampMonotonic, + InitRDTimestampMonotonic, UserspaceTimestampMonotonic, and + FinishTimestampMonotonic properties (see below). + + UnitFilesChanged() is sent out each time the list of enabled or masked unit + files on disk have changed. + + Reloading() is sent out immediately before a daemon reload is done (with the + boolean parameter set to True) and after a daemon reload is completed (with the boolean parameter set + to False). This may be used by UIs to optimize UI updates. + + + + Properties + + Most properties simply reflect the respective options in + /etc/systemd/system.conf and the kernel command line. + + The others: + + Version encodes the version string of the running systemd instance. Note that + the version string is purely informational. It should not be parsed and one may not assume the version to + be formatted in any particular way. We take the liberty to change the versioning scheme at any time and + it is not part of the public API. + + Features encodes the features that have been enabled and disabled for this + build. Enabled options are prefixed with +, disabled options with + -. + + Tainted encodes taint flags as a colon-separated list. When systemd detects it + is running on a system with a certain problem, it will set an appropriate taint flag. Taints may be + used to lower the chance of bogus bug reports. The following taints are currently known: + + + + split-usr + + /usr/ was not available when systemd was first invoked. It + must either be part of the root file system, or it must be mounted before + systemd is invoked. See + + Booting Without /usr is Broken for details why this is bad. + + + + + unmerged-usr + + /bin, /sbin and + /lib* are not symlinks to their counterparts under /usr/. + For more information on this issue consult + + The Case for the /usr Merge + . + + + + + cgroups-missing + + Support for cgroups is unavailable. + + + + cgroupsv1 + + The system is using the old cgroup hierarchy. + + + + local-hwclock + + The local hardware clock (RTC) is configured to be in local time rather than + UTC. + + + + support-ended + + The system is running past the end of support declared by the vendor. See the + description of SUPPORT_END= in + os-release5. + + + + + old-kernel + + The system is running a kernel version that is older than the minimum supported by + this version of systemd. + + + + var-run-bad + + /run/ does not exist or /var/run is not a + symlink to /run/. + + + + overflowuid-not-65534 + overflowgid-not-65534 + + The kernel overflow UID or GID have a value other than 65534. + + + + short-uid-range + short-gid-range + + The UID or GID range assigned to the running systemd instance covers less than + 0…65534. + + + + + + FirmwareTimestamp, FirmwareTimestampMonotonic, + LoaderTimestamp, LoaderTimestampMonotonic, + KernelTimestamp, KernelTimestampMonotonic, + InitRDTimestamp, InitRDTimestampMonotonic, + UserspaceTimestamp, UserspaceTimestampMonotonic, + FinishTimestamp, and FinishTimestampMonotonic encode + CLOCK_REALTIME and CLOCK_MONOTONIC microsecond timestamps + taken when the firmware first began execution, when the boot loader first began execution, when the + kernel first began execution, when the initrd first began execution, when the main systemd instance + began execution and finally, when all queued startup jobs finished execution. These values are useful + for determining boot-time performance. Note that as monotonic time begins with the kernel startup, the + KernelTimestampMonotonic timestamp will always be 0 and + FirmwareTimestampMonotonic and LoaderTimestampMonotonic are to + be read as negative values. Also, not all fields are always available, depending on the used firmware, + boot loader or initrd implementation. In these cases the respective pairs of timestamps are both 0, + indicating that no data is available. + + UnitsLoadTimestamp and UnitsLoadTimestampMonotonic encode + CLOCK_REALTIME and CLOCK_MONOTONIC microseconds timestamps + (as described above). The timestamps are taken every time when the manager starts loading unit files. + + + Similarly, the SecurityStartTimestamp, + GeneratorsStartTimestamp and LoadUnitTimestamp (as well as their + monotonic and stop counterparts) expose performance data for uploading the security policies to the + kernel (such as the SELinux, IMA, or SMACK policies), for running the generator tools and for loading + the unit files. + + NNames encodes how many unit names are currently known. This only includes + names of units that are currently loaded and can be more than the amount of actually loaded units since + units may have more than one name. + + NJobs encodes how many jobs are currently queued. + + NInstalledJobs encodes how many jobs have ever been queued in total. + + NFailedJobs encodes how many jobs have ever failed in total. + + Progress encodes boot progress as a floating point value between 0.0 and + 1.0. This value begins at 0.0 at early-boot and ends at 1.0 when boot is finished and is based on the + number of executed and queued jobs. After startup, this field is always 1.0 indicating a finished + boot. + + Environment encodes the environment block passed to all executed services. It + may be altered with bus calls such as SetEnvironment() (see above). + + UnitPath encodes the currently active unit file search path. It is an array of + file system paths encoded as strings. + + Virtualization contains a short ID string describing the virtualization + technology the system runs in. On bare-metal hardware this is the empty string. Otherwise, it contains + an identifier such as kvm, vmware and so on. For a full list of + IDs see + systemd-detect-virt1. + Note that only the "innermost" virtualization technology is exported here. This detects both + full-machine virtualizations (VMs) and shared-kernel virtualization (containers). + + Architecture contains a short ID string describing the architecture the + systemd instance is running on. This follows the same vocabulary as + ConditionArchitectures=. + + ControlGroup contains the root control group path of this system manager. Note + that the root path is encoded as the empty string here (not as /!), so that it can be + appended to /sys/fs/cgroup/systemd easily. This value will be set to the empty + string for the host instance and some other string for container instances. + + AccessSELinuxContext contains the SELinux context that is used to control + access to the unit. It's read from the unit file when it is loaded and cached until the service manager + is reloaded. This property contains an empty string if SELinux is not used or if no label could be read + (for example because the unit is not backed by a file on disk). + + + + Security + + Read access is generally granted to all clients. Additionally, for unprivileged clients, some + operations are allowed through the polkit privilege system. Operations which modify unit state + (StartUnit(), StopUnit(), KillUnit(), + RestartUnit() and similar, SetProperty()) require + org.freedesktop.systemd1.manage-units. Operations which modify unit file + enablement state (EnableUnitFiles(), DisableUnitFiles(), + EnableUnitFilesWithFlags(), DisableUnitFilesWithFlags(), + ReenableUnitFiles(), LinkUnitFiles(), + PresetUnitFiles, MaskUnitFiles, and similar) require + org.freedesktop.systemd1.manage-unit-files. Operations which modify the + exported environment (SetEnvironment(), UnsetEnvironment(), + UnsetAndSetEnvironment()) require + org.freedesktop.systemd1.set-environment. Reload() + and Reexecute() require + org.freedesktop.systemd1.reload-daemon. Operations which dump internal + state require org.freedesktop.systemd1.bypass-dump-ratelimit to avoid + rate limits. + + + + + + Unit Objects + + +node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice { + interface org.freedesktop.systemd1.Unit { + methods: + Start(in s mode, + out o job); + Stop(in s mode, + out o job); + Reload(in s mode, + out o job); + Restart(in s mode, + out o job); + TryRestart(in s mode, + out o job); + ReloadOrRestart(in s mode, + out o job); + ReloadOrTryRestart(in s mode, + out o job); + EnqueueJob(in s job_type, + in s job_mode, + out u job_id, + out o job_path, + out s unit_id, + out o unit_path, + out s job_type, + out a(uosos) affected_jobs); + Kill(in s whom, + in i signal); + ResetFailed(); + SetProperties(in b runtime, + in a(sv) properties); + Ref(); + Unref(); + Clean(in as mask); + Freeze(); + Thaw(); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Id = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Names = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Following = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Requires = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Requisite = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Wants = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as BindsTo = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PartOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Upholds = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RequiredBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RequisiteOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as WantedBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as BoundBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UpheldBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConsistsOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Conflicts = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConflictedBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Before = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as After = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as OnSuccess = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as OnSuccessOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as OnFailure = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as OnFailureOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Triggers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as TriggeredBy = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PropagatesReloadTo = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReloadPropagatedFrom = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PropagatesStopTo = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StopPropagatedFrom = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as JoinsNamespaceOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SliceOf = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RequiresMountsFor = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Documentation = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Description = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s AccessSELinuxContext = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LoadState = '...'; + readonly s ActiveState = '...'; + readonly s FreezerState = '...'; + readonly s SubState = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s FragmentPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SourcePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as DropInPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s UnitFileState = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s UnitFilePreset = '...'; + readonly t StateChangeTimestamp = ...; + readonly t StateChangeTimestampMonotonic = ...; + readonly t InactiveExitTimestamp = ...; + readonly t InactiveExitTimestampMonotonic = ...; + readonly t ActiveEnterTimestamp = ...; + readonly t ActiveEnterTimestampMonotonic = ...; + readonly t ActiveExitTimestamp = ...; + readonly t ActiveExitTimestampMonotonic = ...; + readonly t InactiveEnterTimestamp = ...; + readonly t InactiveEnterTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanStart = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanStop = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanReload = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanIsolate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CanClean = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CanFreeze = ...; + readonly (uo) Job = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b StopWhenUnneeded = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RefuseManualStart = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RefuseManualStop = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b AllowIsolate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DefaultDependencies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OnSuccessJobMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OnFailureJobMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreOnIsolate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b NeedDaemonReload = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as Markers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t JobTimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t JobRunningTimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s JobTimeoutAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s JobTimeoutRebootArgument = '...'; + readonly b ConditionResult = ...; + readonly b AssertResult = ...; + readonly t ConditionTimestamp = ...; + readonly t ConditionTimestampMonotonic = ...; + readonly t AssertTimestamp = ...; + readonly t AssertTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sbbsi) Conditions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sbbsi) Asserts = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (ss) LoadError = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Transient = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Perpetual = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t StartLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StartLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StartLimitAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s FailureAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FailureActionExitStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SuccessAction = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SuccessActionExitStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RebootArgument = '...'; + readonly ay InvocationID = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s CollectMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as Refs = ['...', ...]; + readonly a(ss) ActivationDetails = [...]; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Start(), Stop(), Reload(), + Restart(), TryRestart(), + ReloadOrRestart(), ReloadOrTryRestart(), + Kill(), ResetFailed(), and + SetProperties() implement the same operation as the respective methods on the + Manager object (see above). However, these methods operate on the unit + object and hence do not take a unit name parameter. Invoking the methods directly on the Manager + object has the advantage of not requiring a GetUnit() call to get the unit object + for a specific unit name. Calling the methods on the Manager object is hence a round trip + optimization. + + + + Properties + + Id contains the primary name of the unit. + + Names contains all names of the unit, including the primary name that is also + exposed in Id. + + Following either contains the empty string or contains the name of another + unit that this unit follows in state. This is used for some device units which reflect the unit state + machine of another unit, and which other unit this is might possibly change. + + Requires, RequiresOverridable, + Requisite, RequisiteOverridable, Wants, + BindsTo, RequiredBy, RequiredByOverridable, + WantedBy, BoundBy, Conflicts, + ConflictedBy, Before, After, + OnFailure, Triggers, TriggeredBy, + PropagatesReloadTo, and RequiresMountsFor contain arrays which encode + the dependencies and their inverse dependencies (where this applies) as configured in the unit file or + determined automatically. + + Description contains the human readable description string for the + unit. + + SourcePath contains the path to a configuration file this unit is + automatically generated from in case it is not a native unit (in which case it contains the empty + string). For example, all mount units generated from /etc/fstab have this field + set to /etc/fstab. + + Documentation contains a string array with URLs of documentation for this + unit. + + LoadState contains a state value that reflects whether the configuration file + of this unit has been loaded. The following states are currently defined: loaded, + error, and masked. loaded indicates that the + configuration was successfully loaded. error indicates that the configuration failed + to load. The LoadError field (see below) contains information about the cause of + this failure. masked indicates that the unit is currently masked out (i.e. symlinked + to /dev/null or empty). Note that the LoadState is fully + orthogonal to the ActiveState (see below) as units without valid loaded + configuration might be active (because configuration might have been reloaded at a time where a unit + was already active). + + ActiveState contains a state value that reflects whether the unit is currently + active or not. The following states are currently defined: active, + reloading, inactive, failed, + activating, and deactivating. active indicates + that unit is active (obviously...). reloading indicates that the unit is active and + currently reloading its configuration. inactive indicates that it is inactive and + the previous run was successful or no previous run has taken place yet. failed + indicates that it is inactive and the previous run was not successful (more information about the + reason for this is available on the unit type specific interfaces, for example for services in the + Result property, see below). activating indicates that the unit + has previously been inactive but is currently in the process of entering an active state. Conversely + deactivating indicates that the unit is currently in the process of + deactivation. + + SubState encodes states of the same state machine that + ActiveState covers, but knows more fine-grained states that are + unit-type-specific. Where ActiveState only covers six high-level states, + SubState covers possibly many more low-level unit-type-specific states that are + mapped to the six high-level states. Note that multiple low-level states might map to the same + high-level state, but not vice versa. Not all high-level states have low-level counterparts on all unit + types. At this point the low-level states are not documented here, and are more likely to be extended + later on than the common high-level states explained above. + + FragmentPath contains the unit file path this unit was read from, if there is + one (if not, it contains the empty string). + + UnitFileState encodes the install state of the unit file of + FragmentPath. It currently knows the following states: enabled, + enabled-runtime, linked, linked-runtime, + masked, masked-runtime, static, + disabled, and invalid. enabled indicates that a + unit file is permanently enabled. enable-runtime indicates the unit file is only + temporarily enabled and will no longer be enabled after a reboot (that means, it is enabled via + /run/ symlinks, rather than /etc/). linked + indicates that a unit is linked into /etc/ permanently. linked-runtime + indicates that a unit is linked into /run/ temporarily (until the next + reboot). masked indicates that the unit file is masked permanently. + masked-runtime indicates that it is masked in /run/ temporarily + (until the next reboot). static indicates that the unit is statically enabled, i.e. + always enabled and doesn't need to be enabled explicitly. invalid indicates that it + could not be determined whether the unit file is enabled. + + InactiveExitTimestamp, InactiveExitTimestampMonotonic, + ActiveEnterTimestamp, ActiveEnterTimestampMonotonic, + ActiveExitTimestamp, ActiveExitTimestampMonotonic, + InactiveEnterTimestamp, and InactiveEnterTimestampMonotonic + contain CLOCK_REALTIME and CLOCK_MONOTONIC 64-bit microsecond + timestamps of the last time a unit left the inactive state, entered the active state, exited the active + state, or entered an inactive state. These are the points in time where the unit transitioned + inactive/failed → activating, + activating → active, active → + deactivating, and finally deactivating → + inactive/failed. The fields are 0 in case such a transition has + not yet been recorded on this boot. + + CanStart, CanStop, and CanReload encode + as booleans whether the unit supports the start, stop or reload operations. Even if a unit supports + such an operation, the client might not necessary have the necessary privileges to execute them. + + CanIsolate encodes as a boolean whether the unit may be started in isolation + mode. + + Job encodes the job ID and job object path of the job currently scheduled or + executed for this unit, if there is any. If no job is scheduled or executed, the job id field will be + 0. + + StopWhenUnneeded, RefuseManualStart, + RefuseManualStop, AllowIsolate, + DefaultDependencies, OnFailureIsolate, + IgnoreOnIsolate, IgnoreOnSnapshot map directly to the + corresponding configuration booleans in the unit file. + + NeedDaemonReload is a boolean that indicates whether the configuration file + this unit is loaded from (i.e. FragmentPath or SourcePath) has + changed since the configuration was read and hence whether a configuration reload is recommended. + + + Markers is an array of string flags that can be set using + SetUnitProperties() to indicate that the service should be reloaded or + restarted. Currently known values are needs-restart and + needs-reload. Package scripts may use the first to mark units for later restart when + a new version of the package is installed. Configuration management scripts may use the second to mark + units for a later reload when the configuration is adjusted. Those flags are not set by the manager, + except to unset as appropriate when the unit is stopped, restarted, or reloaded. + + JobTimeoutUSec maps directly to the corresponding configuration setting in the + unit file. + + ConditionTimestamp and ConditionTimestampMonotonic contain + the CLOCK_REALTIME/CLOCK_MONOTONIC microsecond timestamps of + the last time the configured conditions of the unit have been checked or 0 if they have never been + checked. Conditions are checked when a unit is requested to start. + + ConditionResult contains the condition result of the last time the configured + conditions of this unit were checked. + + Conditions contains all configured conditions of the unit. For each condition, + five fields are given: condition type (e.g. ConditionPathExists), whether the + condition is a trigger condition, whether the condition is reversed, the right hand side of the + condition (e.g. the path in case of ConditionPathExists), and the status. The status + can be 0, in which case the condition hasn't been checked yet, a positive value, in which case the + condition passed, or a negative value, in which case the condition failed. Currently only 0, +1, and -1 + are used, but additional values may be used in the future, retaining the meaning of + zero/positive/negative values. + + LoadError contains a pair of strings. If the unit failed to load (as encoded + in LoadState, see above), then this will include a D-Bus error pair consisting of + the error ID and an explanatory human readable string of what happened. If it loaded successfully, this + will be a pair of empty strings. + + Transient contains a boolean that indicates whether the unit was created as a + transient unit (i.e. via StartTransientUnit() on the manager object). + + ActivationDetails contains a list of string pairs, key and value, that + describe the event that caused the unit to be activated, if any. The key describes the information + (e.g.: trigger_unit, with value foo.service). This is only filled + in if the unit was triggered by a Path or Timer unit, and it is + only provided in a best effort fashion: it is not guaranteed to be set, and it is not guaranteed to be + the only trigger. It is only guaranteed to be a valid trigger that caused the activation job to be + enqueued and complete successfully. The key value pairs correspond (in lowercase) to the environment + variables described in the Environment Variables Set on Triggered Units section in + systemd.exec1. + Note that new key value pair may be added at any time in future versions. Existing entries will not be + removed. + + + + Security + + Similarly to methods on the Manager object, read-only access is + allowed for everyone. All operations are allowed for clients with the + CAP_SYS_ADMIN capability or when the + org.freedesktop.systemd1.manage-units privilege is granted by + polkit. + + + + + Service Unit Objects + + All service unit objects implement the + org.freedesktop.systemd1.Service interface (described here) in addition to + the generic org.freedesktop.systemd1.Unit interface (see above). + + +node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice { + interface org.freedesktop.systemd1.Service { + methods: + BindMount(in s source, + in s destination, + in b read_only, + in b mkdir); + MountImage(in s source, + in s destination, + in b read_only, + in b mkdir, + in a(ss) options); + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ExitType = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Restart = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PIDFile = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NotifyAccess = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestartUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutStartUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutStopUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TimeoutAbortUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TimeoutStartFailureMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TimeoutStopFailureMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeMaxUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeRandomizedExtraUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t WatchdogUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t WatchdogTimestamp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t WatchdogTimestampMonotonic = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RootDirectoryStartOnly = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemainAfterExit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b GuessMainPID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (aiai) RestartPreventExitStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (aiai) RestartForceExitStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (aiai) SuccessExitStatus = ...; + readonly u MainPID = ...; + readonly u ControlPID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s BusName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u FileDescriptorStoreMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NFileDescriptorStore = ...; + readonly s StatusText = '...'; + readonly i StatusErrno = ...; + readonly s Result = '...'; + readonly s ReloadResult = '...'; + readonly s CleanResult = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s USBFunctionDescriptors = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s USBFunctionStrings = '...'; + readonly u UID = ...; + readonly u GID = ...; + readonly u NRestarts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OOMPolicy = '...'; + readonly t ExecMainStartTimestamp = ...; + readonly t ExecMainStartTimestampMonotonic = ...; + readonly t ExecMainExitTimestamp = ...; + readonly t ExecMainExitTimestampMonotonic = ...; + readonly u ExecMainPID = ...; + readonly i ExecMainCode = ...; + readonly i ExecMainStatus = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecCondition = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecConditionEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStartPre = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStartPreEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStart = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStartEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStartPost = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStartPostEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecReload = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecReloadEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStop = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStopEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStopPost = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasasttttuii) ExecStopPostEx = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ControlGroupId = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryAvailable = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u ManagedOOMMemoryPressureLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMPreference = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) BPFProgram = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (bas) RestrictNetworkInterfaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sb) EnvironmentFiles = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PassEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnsetEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WorkingDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootImage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) RootImageOptions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHash = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHashSignature = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashSignaturePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootVerity = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExtensionDirectories = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sba(ss)) ExtensionImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssba(ss)) MountImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i OOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CoredumpFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Nice = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingClass = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay CPUAffinity = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUAffinityFromNUMA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i NUMAPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay NUMAMask = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUSchedulingResetOnFork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NonBlocking = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay StandardInputData = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardErrorFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTYPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYReset = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVHangup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVTDisallocate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly q TTYRows = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly q TTYColumns = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SyslogIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SyslogLevelPrefix = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogLevel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogFacility = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i LogLevelMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LogRateLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogRateLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly aay LogExtraFields = [[...], ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LogNamespace = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SecureBits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CapabilityBoundingSet = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AmbientCapabilities = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s User = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Group = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DynamicUser = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredentialEncrypted = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredentialEncrypted = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SupplementaryGroups = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PAMName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadWritePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadOnlyPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as InaccessiblePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExecPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as NoExecPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExecSearchPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t MountFlags = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateTmp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateDevices = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectClock = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelTunables = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelModules = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelLogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectControlGroups = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateNetwork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateUsers = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateMounts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectHome = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectSystem = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SameProcessGroup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SELinuxContext = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) AppArmorProfile = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SmackProcessLabel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreSIGPIPE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoNewPrivileges = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SystemCallArchitectures = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SystemCallErrorNumber = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallLog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Personality = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LockPersonality = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictAddressFamilies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) RuntimeDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimeDirectoryPreserve = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u RuntimeDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RuntimeDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) StateDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StateDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StateDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) CacheDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u CacheDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CacheDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) LogsDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogsDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as LogsDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u ConfigurationDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConfigurationDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutCleanUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MemoryDenyWriteExecute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictRealtime = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictSUIDSGID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestrictNamespaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictFileSystems = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindReadOnlyPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) TemporaryFileSystem = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MountAPIVFS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KeyringMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectProc = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProcSubset = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectHostname = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NetworkNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s IPCNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + BindMount() and MountImage() implement the same operations + as the respective methods on the Manager object (see above). However, these + methods operate on the service object and hence do not take a unit name parameter. Invoking the methods + directly on the Manager object has the advantage of not requiring a GetUnit() call + to get the unit object for a specific unit name. Calling the methods on the Manager object is hence a round + trip optimization. + + + + Properties + + Most properties of the Service interface map directly to the corresponding settings in service + unit files. For the sake of brevity, here's a list of all exceptions only: + + TimeoutStartUSec, TimeoutStopUSec and + TimeoutAbortUSec contain the start, stop and abort timeouts, in microseconds. Note + the slight difference in naming when compared to the matching unit file settings (see + systemd.service7): + these bus properties strictly use microseconds (and thus are suffixed …USec) while + the unit file settings default to a time unit of seconds (and thus are suffixed + …Sec), unless a different unit is explicitly specified. This reflects that fact that + internally the service manager deals in microsecond units only, and the bus properties are a relatively + low-level (binary) concept exposing this. The unit file settings on the other hand are relatively + high-level (string-based) concepts and thus support more user friendly time specifications which + default to second time units but allow other units too, if specified. + + WatchdogTimestamp and WatchdogTimestampMonotonic contain + CLOCK_REALTIME/CLOCK_MONOTONIC microsecond timestamps of the + last watchdog ping received from the service, or 0 if none was ever received. + + ExecStartPre, ExecStart, ExecStartPost, + ExecReload, ExecStop, and ExecStop are arrays + of structures where each struct contains: the binary path to execute; an array with all arguments to + pass to the executed command, starting with argument 0; a boolean whether it should be considered a + failure if the process exits uncleanly; two pairs of + CLOCK_REALTIME/CLOCK_MONOTONIC microsecond timestamps when + the process began and finished running the last time, or 0 if it never ran or never finished running; + the PID of the process, or 0 if it has not run yet; the exit code and status of the last run. This + field hence maps more or less to the corresponding setting in the service unit file but is augmented + with runtime data. + + LimitCPU (and related properties) map more or less directly to the + corresponding settings in the service unit files except that if they aren't set, their value is + 18446744073709551615 (i.e. -1). + + Capabilities contains the configured capabilities, as formatted with + cap_to_text3. + + + SecureBits, CapabilityBoundingSet, + MountFlags also correspond to the configured settings of the unit files, but + instead of being formatted as strings, they are encoded as the actual binary flags they are. + + + ExecMainStartTimestamp, ExecMainStartTimestampMonotonic, + ExecMainExitTimestamp, ExecMainExitTimestampMonotonic, + ExecMainPID, ExecMainCode, ExecMainStatus + contain information about the main process of the service as far as it is known. This is often the same + runtime information that is stored in ExecStart. However, it deviates for + Type=forking services where the main process of the service is not forked off + systemd directly. These fields either contain information of the last run of the process or of the + current running process. + + MainPID and ControlPID contain the main and control PID of + the service. The main PID is the current main PID of the service and is 0 when the service currently + has no main PID. The control PID is the PID of the current start/stop/reload process running and is 0 + if no such process is currently running. That means that ExecMainPID and + MainPID differ in the way that the latter immediately reflects whether a main + process is currently running while the latter possible contains information collected from the last run + even if the process is no longer around. + + StatusText contains the status text passed to the service manager via a call + to + sd_notify3. + This may be used by services to inform the service manager about its internal state with a nice + explanatory string. + + Result encodes the execution result of the last run of the service. It is + useful to determine the reason a service failed if it is in the failed state (see + ActiveState above). The following values are currently known: + success is set if the unit didn't fail. resources indicates that + not enough resources were available to fork off and execute the service + processes. timeout indicates that a timeout occurred while executing a service + operation. exit-code indicates that a service process exited with an unclean exit + code. signal indicates that a service process exited with an uncaught + signal. core-dump indicates that a service process exited uncleanly and dumped + core. watchdog indicates that a service did not send out watchdog ping messages + often enough. start-limit indicates that a service has been started too frequently + in a specific time frame (as configured in StartLimitInterval, + StartLimitBurst). + + ControlGroup indicates the control group path the processes of this service + unit are placed in. + + The following properties map 1:1 to corresponding settings in the unit file: + RootDirectory + RootImage + RootImageOptions + RootVerity + RootHash + RootHashSignature + MountImages + ExtensionImages + ExtensionDirectories + see systemd.exec(5) for their meaning. + + MemoryAvailable indicates how much unused memory is available to the unit before + the MemoryMax or MemoryHigh (whichever is lower) limit set by the cgroup + memory controller is reached. It will take into consideration limits on all parent slices, other than the + limits set on the unit itself. + + RuntimeDirectorySymlink, StateDirectorySymlink, + CacheDirectorySymlink and LogsDirectorySymlink respectively + implement the destination parameter of the unit files settings RuntimeDirectory, + StateDirectory, CacheDirectory and LogsDirectory, + which will create a symlink of the given name to the respective directory. The messages take an unused + flags parameter, reserved for future backward-compatible changes. + + + + + Socket Unit Objects + + +node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2esocket { + interface org.freedesktop.systemd1.Socket { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s BindIPv6Only = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Backlog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s BindToDevice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SocketUser = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SocketGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u SocketMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Accept = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b FlushPending = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Writable = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b KeepAlive = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t KeepAliveTimeUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t KeepAliveIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u KeepAliveProbes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t DeferAcceptUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoDelay = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Priority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t ReceiveBuffer = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t SendBuffer = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IPTOS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IPTTL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t PipeSize = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b FreeBind = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Transparent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Broadcast = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PassCredentials = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PassSecurity = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PassPacketInfo = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Timestamping = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveOnStop = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) Listen = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Symlinks = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Mark = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u MaxConnections = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u MaxConnectionsPerSource = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly x MessageQueueMaxMessages = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly x MessageQueueMessageSize = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TCPCongestion = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ReusePort = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SmackLabel = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SmackLabelIPIn = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SmackLabelIPOut = '...'; + readonly u ControlPID = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NConnections = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NAccepted = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u NRefused = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s FileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SocketProtocol = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TriggerLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u TriggerLimitBurst = ...; + readonly u UID = ...; + readonly u GID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStartPre = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStartPost = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStopPre = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecStopPost = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ControlGroupId = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryAvailable = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u ManagedOOMMemoryPressureLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMPreference = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) BPFProgram = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (bas) RestrictNetworkInterfaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sb) EnvironmentFiles = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PassEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnsetEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WorkingDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootImage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) RootImageOptions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHash = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHashSignature = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashSignaturePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootVerity = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExtensionDirectories = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sba(ss)) ExtensionImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssba(ss)) MountImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i OOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CoredumpFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Nice = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingClass = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay CPUAffinity = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUAffinityFromNUMA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i NUMAPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay NUMAMask = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUSchedulingResetOnFork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NonBlocking = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay StandardInputData = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardErrorFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTYPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYReset = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVHangup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVTDisallocate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly q TTYRows = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly q TTYColumns = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SyslogIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SyslogLevelPrefix = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogLevel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogFacility = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i LogLevelMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LogRateLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogRateLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly aay LogExtraFields = [[...], ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LogNamespace = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SecureBits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CapabilityBoundingSet = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AmbientCapabilities = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s User = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Group = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DynamicUser = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredentialEncrypted = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredentialEncrypted = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SupplementaryGroups = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PAMName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadWritePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadOnlyPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as InaccessiblePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExecPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as NoExecPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExecSearchPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t MountFlags = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateTmp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateDevices = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectClock = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelTunables = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelModules = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelLogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectControlGroups = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateNetwork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateUsers = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateMounts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectHome = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectSystem = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SameProcessGroup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SELinuxContext = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) AppArmorProfile = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SmackProcessLabel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreSIGPIPE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoNewPrivileges = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SystemCallArchitectures = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SystemCallErrorNumber = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallLog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Personality = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LockPersonality = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictAddressFamilies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) RuntimeDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimeDirectoryPreserve = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u RuntimeDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RuntimeDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) StateDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StateDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StateDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) CacheDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u CacheDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CacheDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) LogsDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogsDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as LogsDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u ConfigurationDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConfigurationDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutCleanUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MemoryDenyWriteExecute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictRealtime = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictSUIDSGID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestrictNamespaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictFileSystems = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindReadOnlyPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) TemporaryFileSystem = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MountAPIVFS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KeyringMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectProc = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProcSubset = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectHostname = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NetworkNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s IPCNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Properties + + Most of the properties map directly to the corresponding settings in socket unit files. As socket + units can include ExecStartPre (and similar) fields which contain information about + processes to execute. They also share most of the fields related to the execution context that Service + objects expose (see above). + + In addition to these properties there are the following: + + NAccepted contains the accumulated number of connections ever accepted on this + socket. This only applies to sockets with Accept set to yes, + i.e. those where systemd is responsible for accepted connections. + + Similarly NConnections contains the number of currently open connections on + this socket. It only applies only to socket units with Accept set to + yes. + + Result encodes the reason why a socket unit failed if it is in the + failed state (see ActiveState above). The values + success, resources, timeout, + exit-code, signal and core-dump have the same + meaning as they have for the corresponding field of service units (see above). In addition to that, + the value service-failed-permanent indicates that the service of this socket failed + continuously. + + FlushPending specifies whether to flush the socket + just before entering the listening state. This setting only applies to sockets with + Accept= set to no. + + + + + Target Unit Objects + + +node /org/freedesktop/systemd1/unit/basic_2etarget { + interface org.freedesktop.systemd1.Target { + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + Target units have neither type-specific methods nor properties. + + + + + Device Unit Objects + + All device unit objects implement the org.freedesktop.systemd1.Device interface (described here) + in addition to the generic org.freedesktop.systemd1.Unit interface (see above). + + +node /org/freedesktop/systemd1/unit/dev_2dttyS0_2edevice { + interface org.freedesktop.systemd1.Device { + properties: + readonly s SysFSPath = '...'; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + Properties + + Device units only expose a single type-specific property: + + SysFSPath contains the sysfs path of the kernel device this object corresponds + to. + + + + + Mount Unit Objects + + All mount unit objects implement the org.freedesktop.systemd1.Mount + interface (described here) in addition to the generic + org.freedesktop.systemd1.Unit interface (see above). + + +node /org/freedesktop/systemd1/unit/home_2emount { + interface org.freedesktop.systemd1.Mount { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Where = '...'; + readonly s What = '...'; + readonly s Options = '...'; + readonly s Type = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutUSec = ...; + readonly u ControlPID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SloppyOptions = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LazyUnmount = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ForceUnmount = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ReadWriteOnly = ...; + readonly s Result = '...'; + readonly u UID = ...; + readonly u GID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecMount = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecUnmount = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecRemount = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ControlGroupId = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryAvailable = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u ManagedOOMMemoryPressureLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMPreference = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) BPFProgram = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (bas) RestrictNetworkInterfaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sb) EnvironmentFiles = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PassEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnsetEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WorkingDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootImage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) RootImageOptions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHash = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHashSignature = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashSignaturePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootVerity = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExtensionDirectories = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sba(ss)) ExtensionImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssba(ss)) MountImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i OOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CoredumpFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Nice = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingClass = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay CPUAffinity = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUAffinityFromNUMA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i NUMAPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay NUMAMask = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUSchedulingResetOnFork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NonBlocking = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay StandardInputData = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardErrorFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTYPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYReset = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVHangup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVTDisallocate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly q TTYRows = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly q TTYColumns = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SyslogIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SyslogLevelPrefix = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogLevel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogFacility = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i LogLevelMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LogRateLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogRateLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly aay LogExtraFields = [[...], ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LogNamespace = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SecureBits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CapabilityBoundingSet = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AmbientCapabilities = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s User = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Group = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DynamicUser = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredentialEncrypted = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredentialEncrypted = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SupplementaryGroups = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PAMName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadWritePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadOnlyPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as InaccessiblePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExecPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as NoExecPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExecSearchPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t MountFlags = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateTmp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateDevices = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectClock = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelTunables = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelModules = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelLogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectControlGroups = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateNetwork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateUsers = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateMounts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectHome = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectSystem = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SameProcessGroup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SELinuxContext = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) AppArmorProfile = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SmackProcessLabel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreSIGPIPE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoNewPrivileges = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SystemCallArchitectures = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SystemCallErrorNumber = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallLog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Personality = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LockPersonality = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictAddressFamilies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) RuntimeDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimeDirectoryPreserve = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u RuntimeDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RuntimeDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) StateDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StateDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StateDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) CacheDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u CacheDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CacheDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) LogsDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogsDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as LogsDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u ConfigurationDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConfigurationDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutCleanUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MemoryDenyWriteExecute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictRealtime = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictSUIDSGID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestrictNamespaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictFileSystems = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindReadOnlyPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) TemporaryFileSystem = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MountAPIVFS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KeyringMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectProc = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProcSubset = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectHostname = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NetworkNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s IPCNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Properties + + Most of the properties map directly to the corresponding settings in mount unit files. As mount + units invoke the /usr/bin/mount command, their bus objects include implicit + ExecMount (and similar) fields which contain information about processes to + execute. They also share most of the fields related to the execution context that Service objects + expose (see above). In addition to these properties there are the following: + + ControlPID contains the PID of the currently running + /usr/bin/mount or /usr/bin/umount command if there is one + running, otherwise 0. + + Result contains a value explaining why a mount unit failed if it failed. It + can take the values success, resources, + timeout, exit-code, signal, or + core-dump which have the identical meaning as the corresponding values of the + corresponding field of service unit objects (see above). + + + + + Automount Unit Objects + + All automount unit objects implement the + org.freedesktop.systemd1.Automount interface (described here) in addition + to the generic org.freedesktop.systemd1.Unit interface (see above). + + +node /org/freedesktop/systemd1/unit/proc_2dsys_2dfs_2dbinfmt_5fmisc_2eautomount { + interface org.freedesktop.systemd1.Automount { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Where = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ExtraOptions = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DirectoryMode = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutIdleUSec = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Properties + + Most of the properties map directly to the corresponding settings in the automount unit + files. + + Result knows the values success and + resources at this time. They have the same meanings as the corresponding values of + the corresponding field of the Service object. + + + + + + Timer Unit Objects + + All timer unit objects implement the org.freedesktop.systemd1.Timer + interface (described here) in addition to the generic + org.freedesktop.systemd1.Unit interface (see above). + + +node /org/freedesktop/systemd1/unit/systemd_2dtmpfiles_2dclean_2etimer { + interface org.freedesktop.systemd1.Timer { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Unit = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(stt) TimersMonotonic = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sst) TimersCalendar = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b OnClockChange = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b OnTimezoneChange = ...; + readonly t NextElapseUSecRealtime = ...; + readonly t NextElapseUSecMonotonic = ...; + readonly t LastTriggerUSec = ...; + readonly t LastTriggerUSecMonotonic = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AccuracyUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RandomizedDelayUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b FixedRandomDelay = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b Persistent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b WakeSystem = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemainAfterElapse = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Properties + + Unit contains the name of the unit to activate when the timer elapses. + + TimersMonotonic contains an array of structs that contain information about + all monotonic timers of this timer unit. The structs contain a string identifying the timer base, which + is one of OnActiveUSec, OnBootUSec, + OnStartupUSec, OnUnitActiveUSec, or + OnUnitInactiveUSec which correspond to the settings of the same names in the timer + unit files; the microsecond offset from this timer base in monotonic time; the next elapsation point on + the CLOCK_MONOTONIC clock, relative to its epoch. + + TimersCalendar contains an array of structs that contain information about all + realtime/calendar timers of this timer unit. The structs contain a string identifying the timer base, + which may only be OnCalendar for now; the calendar specification string; the next + elapsation point on the CLOCK_REALTIME clock, relative to its epoch. + + NextElapseUSecRealtime contains the next elapsation point on the + CLOCK_REALTIME clock in miscroseconds since the epoch, or 0 if this timer event + does not include at least one calendar event. + + Similarly, NextElapseUSecMonotonic contains the next elapsation point on the + CLOCK_MONOTONIC clock in microseconds since the epoch, or 0 if this timer event + does not include at least one monotonic event. + + Result knows the values success and + resources with the same meanings as the matching values of the corresponding + property of the service interface. + + + + + Swap Unit Objects + + All swap unit objects implement the org.freedesktop.systemd1.Swap + interface (described here) in addition to the generic + org.freedesktop.systemd1.Unit interface (see above). + + +node /org/freedesktop/systemd1/unit/dev_2dsda3_2eswap { + interface org.freedesktop.systemd1.Swap { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + readonly s What = '...'; + readonly i Priority = ...; + readonly s Options = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutUSec = ...; + readonly u ControlPID = ...; + readonly s Result = '...'; + readonly u UID = ...; + readonly u GID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecActivate = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates") + readonly a(sasbttttuii) ExecDeactivate = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ControlGroupId = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryAvailable = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u ManagedOOMMemoryPressureLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMPreference = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) BPFProgram = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (bas) RestrictNetworkInterfaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as Environment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sb) EnvironmentFiles = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as PassEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as UnsetEnvironment = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u UMask = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPU = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCPUSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitFSIZESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitDATASoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSTACKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitCORESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRSSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNOFILESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitAS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitASSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNPROCSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCK = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMEMLOCKSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitLOCKSSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDING = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitSIGPENDINGSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitMSGQUEUESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitNICESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIO = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTPRIOSoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIME = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LimitRTTIMESoft = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s WorkingDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootDirectory = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootImage = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) RootImageOptions = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHash = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay RootHashSignature = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootHashSignaturePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RootVerity = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExtensionDirectories = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sba(ss)) ExtensionImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssba(ss)) MountImages = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i OOMScoreAdjust = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CoredumpFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i Nice = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingClass = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i IOSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i CPUSchedulingPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay CPUAffinity = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUAffinityFromNUMA = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i NUMAPolicy = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay NUMAMask = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimerSlackNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b CPUSchedulingResetOnFork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NonBlocking = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardInputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly ay StandardInputData = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutput = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardOutputFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardError = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s StandardErrorFileDescriptorName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s TTYPath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYReset = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVHangup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b TTYVTDisallocate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly q TTYRows = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly q TTYColumns = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogPriority = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s SyslogIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SyslogLevelPrefix = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogLevel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SyslogFacility = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i LogLevelMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t LogRateLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogRateLimitBurst = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly aay LogExtraFields = [[...], ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s LogNamespace = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SecureBits = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t CapabilityBoundingSet = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t AmbientCapabilities = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s User = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Group = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b DynamicUser = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RemoveIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(say) SetCredentialEncrypted = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredential = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) LoadCredentialEncrypted = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SupplementaryGroups = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s PAMName = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadWritePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ReadOnlyPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as InaccessiblePaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExecPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as NoExecPaths = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ExecSearchPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t MountFlags = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateTmp = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateDevices = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectClock = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelTunables = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelModules = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectKernelLogs = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectControlGroups = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateNetwork = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateUsers = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateMounts = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b PrivateIPC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectHome = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectSystem = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SameProcessGroup = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpIdentifier = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s UtmpMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SELinuxContext = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) AppArmorProfile = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bs) SmackProcessLabel = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b IgnoreSIGPIPE = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b NoNewPrivileges = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallFilter = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as SystemCallArchitectures = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i SystemCallErrorNumber = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) SystemCallLog = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Personality = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b LockPersonality = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictAddressFamilies = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) RuntimeDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s RuntimeDirectoryPreserve = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u RuntimeDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as RuntimeDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) StateDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u StateDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as StateDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) CacheDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u CacheDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as CacheDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(sst) LogsDirectorySymlink = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u LogsDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as LogsDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u ConfigurationDirectoryMode = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly as ConfigurationDirectory = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutCleanUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MemoryDenyWriteExecute = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictRealtime = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b RestrictSUIDSGID = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RestrictNamespaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (bas) RestrictFileSystems = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ssbt) BindReadOnlyPaths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) TemporaryFileSystem = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MountAPIVFS = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KeyringMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProtectProc = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s ProcSubset = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b ProtectHostname = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s NetworkNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s IPCNamespacePath = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Properties + + Most of the properties map directly to the corresponding settings in swap unit files. As mount + units invoke the + swapon8 command, + their bus objects include implicit ExecActivate (and similar) fields which contain + information about processes to execute. They also share most of the fields related to the execution + context that Service objects expose (see above). In addition to these properties there are the + following: + + ControlPID contains the PID of the currently running + swapon8 or + swapoff8 + command if there is one running, otherwise 0. + + Result contains a value explaining why a mount unit failed if it failed. It + can take the values success, resources, + timeout, exit-code, signal, or + core-dump which have the identical meanings as the corresponding values of the + corresponding field of service unit objects (see above). + + + + + + Path Unit Objects + + +node /org/freedesktop/systemd1/unit/cups_2epath { + interface org.freedesktop.systemd1.Path { + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s Unit = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) Paths = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b MakeDirectory = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u DirectoryMode = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TriggerLimitIntervalUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u TriggerLimitBurst = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Properties + + Most properties correspond directly with the matching settings in path unit files. + + The others: + + Paths contains an array of structs. Each struct contains the condition to + watch, which can be one of PathExists, PathExistsGlob, + PathChanged, PathModified, or DirectoryNotEmpty + which correspond directly to the matching settings in the path unit files; and the path to watch, + possibly including glob expressions. + + Result contains a result value which can be success or + resources which have the same meaning as the corresponding field of the Service + interface. + + + + + Slice Unit Objects + + All slice unit objects implement the org.freedesktop.systemd1.Slice + interface (described here) in addition to the generic + org.freedesktop.systemd1.Unit interface (see above). + + +node /org/freedesktop/systemd1/unit/system_2eslice { + interface org.freedesktop.systemd1.Slice { + methods: + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ControlGroupId = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryAvailable = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u ManagedOOMMemoryPressureLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMPreference = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) BPFProgram = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (bas) RestrictNetworkInterfaces = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Properties + + Most properties correspond directly with the matching settings in slice unit files. + + + + + Scope Unit Objects + + All scope unit objects implement the org.freedesktop.systemd1.Scope + interface (described here) in addition to the generic + org.freedesktop.systemd1.Unit interface (see above). + + +node /org/freedesktop/systemd1/unit/session_2d1_2escope { + interface org.freedesktop.systemd1.Scope { + methods: + Abandon(); + GetProcesses(out a(sus) processes); + AttachProcesses(in s subcgroup, + in au pids); + signals: + RequestStop(); + properties: + readonly s Controller = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t TimeoutStopUSec = ...; + readonly s Result = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeMaxUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly t RuntimeRandomizedExtraUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s OOMPolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s Slice = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ControlGroup = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t ControlGroupId = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryAvailable = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUUsageNSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay EffectiveMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksCurrent = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPIngressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IPEgressPackets = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOReadOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteBytes = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWriteOperations = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b Delegate = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DelegateControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CPUAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupCPUShares = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPerSecUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t CPUQuotaPeriodUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedCPUs = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay AllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly ay StartupAllowedMemoryNodes = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t IOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteBandwidthMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOReadIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IOWriteIOPSMax = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) IODeviceLatencyTargetUSec = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b BlockIOAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t BlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t StartupBlockIOWeight = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIODeviceWeight = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOReadBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(st) BlockIOWriteBandwidth = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b MemoryAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t DefaultMemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMin = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLow = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryHigh = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemorySwapMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t MemoryLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s DevicePolicy = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) DeviceAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b TasksAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TasksMax = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b IPAccounting = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iayu) IPAddressDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPIngressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as IPEgressFilterPath = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly as DisableControllers = ['...', ...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMSwap = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMMemoryPressure = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly u ManagedOOMMemoryPressureLimit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly s ManagedOOMPreference = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(ss) BPFProgram = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindAllow = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly a(iiqq) SocketBindDeny = [...]; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly (bas) RestrictNetworkInterfaces = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s KillMode = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i KillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i RestartKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i FinalKillSignal = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGKILL = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly b SendSIGHUP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly i WatchdogSignal = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; + interface org.freedesktop.systemd1.Unit { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Abandon() may be used to place a scope unit in the "abandoned" state. This + may be used to inform the system manager that the manager that created the scope lost interest in the + scope (for example, because it is terminating), without wanting to shut down the scope entirely. + + + + Signals + + RequestStop is sent to the peer that is configured in the + Controller property when systemd is requested to terminate the scope unit. A program + registering a scope can use this to cleanly shut down the processes it added to the scope instead of + letting systemd do it with the usual SIGTERM logic. + + + + Properties + + All properties correspond directly with the matching properties of service units. + + Controller contains the bus name (unique or well-known) that is notified when + the scope unit is to be shut down via a RequestStop signal (see below). This is + set when the scope is created. If not set, the scope's processes will terminated with + SIGTERM directly. + + + + + + Job Objects + + Job objects encapsulate scheduled or running jobs. Each unit can have none or one jobs in the + execution queue. Each job is attached to exactly one unit. + + +node /org/freedesktop/systemd1/job/666 { + interface org.freedesktop.systemd1.Job { + methods: + Cancel(); + GetAfter(out a(usssoo) jobs); + GetBefore(out a(usssoo) jobs); + properties: + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly u Id = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly (so) Unit = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly s JobType = '...'; + readonly s State = '...'; + @org.freedesktop.DBus.Property.EmitsChangedSignal("const") + readonly a(ss) ActivationDetails = [...]; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Cancel() cancels the job. Note that this will remove a job from the queue if + it is not yet executed but generally will not cause a job that is already in the process of being + executed to be aborted. This operation may also be requested via the CancelJob() + method of the Manager object (see above), which is sometimes useful to reduce roundtrips. + + + + Properties + + Id is the numeric Id of the job. During the runtime of a systemd instance each + numeric ID is only assigned once. + + Unit refers to the unit this job belongs to. It is a structure consisting of + the name of the unit and a bus path to the unit's object. + + JobType refers to the job's type and is one of start, + verify-active, stop, reload, + restart, try-restart, or reload-or-start. Note + that later versions might define additional values. + + State refers to the job's state and is one of waiting and + running. The former indicates that a job is currently queued but has not begun to + execute yet. The latter indicates that a job is currently being executed. + + ActivationDetails has the same content as the property of the same name under + the org.freedesktop.systemd1.Unit interface. + + + + + Examples + + + Introspect <interfacename>org.freedesktop.systemd1.Manager</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.systemd1 \ + --object-path /org/freedesktop/systemd1 + + + + + Introspect a unit on the bus + + +$ busctl introspect org.freedesktop.systemd1 \ + $(busctl call org.freedesktop.systemd1 \ + /org/freedesktop/systemd1 \ + org.freedesktop.systemd1.Manager \ + GetUnit s systemd-resolved.service | cut -d'"' -f2) + + + + + Introspect <interfacename>org.freedesktop.systemd1.Job</interfacename> on the bus + + +$ gdbus introspect --system --dest org.freedesktop.systemd1 \ + --object-path /org/freedesktop/systemd1/job/1292 + + + + + + diff --git a/man/org.freedesktop.timedate1.xml b/man/org.freedesktop.timedate1.xml new file mode 100644 index 0000000..54f4018 --- /dev/null +++ b/man/org.freedesktop.timedate1.xml @@ -0,0 +1,200 @@ + + + + + + + org.freedesktop.timedate1 + systemd + + + + org.freedesktop.timedate1 + 5 + + + + org.freedesktop.timedate1 + The D-Bus interface of systemd-timedated + + + + Introduction + + + systemd-timedated.service8 + is a system service that can be used to control the system time and related settings. This page + describes the D-Bus interface. + + + + The D-Bus API + + The service exposes the following interfaces on the bus: + + +node /org/freedesktop/timedate1 { + interface org.freedesktop.timedate1 { + methods: + SetTime(in x usec_utc, + in b relative, + in b interactive); + SetTimezone(in s timezone, + in b interactive); + SetLocalRTC(in b local_rtc, + in b fix_system, + in b interactive); + SetNTP(in b use_ntp, + in b interactive); + ListTimezones(out as timezones); + properties: + readonly s Timezone = '...'; + readonly b LocalRTC = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b CanNTP = ...; + readonly b NTP = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly b NTPSynchronized = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t TimeUSec = ...; + @org.freedesktop.DBus.Property.EmitsChangedSignal("false") + readonly t RTCTimeUSec = ...; + }; + interface org.freedesktop.DBus.Peer { ... }; + interface org.freedesktop.DBus.Introspectable { ... }; + interface org.freedesktop.DBus.Properties { ... }; +}; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Methods + + Use SetTime() to change the system clock. Pass a value of microseconds since + the UNIX epoch (1 Jan 1970 UTC). If relative is true, the passed usec value will be + added to the current system time. If it is false, the current system time will be set to the passed usec + value. If the system time is set with this method, the RTC will be updated as well. + + Use SetTimezone() to set the system timezone. Pass a value like + Europe/Berlin to set the timezone. Valid timezones are listed in + /usr/share/zoneinfo/zone.tab. If the RTC is configured to be maintained in local + time, it will be updated accordingly. + + Use SetLocalRTC() to control whether the RTC is in local time or UTC. It is + strongly recommended to maintain the RTC in UTC. However, some OSes (Windows) maintain the RTC in local + time, which might make it necessary to enable this feature. Note that this might create various problems as + daylight changes could be missed. If fix_system is true, + the time from the RTC is read again and the system clock is adjusted according to the new setting. If + fix_system is false, the system time is written to the RTC + taking the new setting into account. Use fix_system=true in installers and livecds + where the RTC is probably more reliable than the system time. Use fix_system=false + in configuration UIs that are run during normal operation and where the system clock is probably more + reliable than the RTC. + + Use SetNTP() to control whether the system clock is synchronized with the + network using systemd-timesyncd. This will enable and start or disable and stop + the chosen time synchronization service. + + ListTimezones() returns a list of time zones known on the local system as an + array of names (["Africa/Abidjan", "Africa/Accra", ..., "UTC"]). + + + + Properties + + Timezone shows the currently configured time zone. + LocalRTC shows whether the RTC is configured to use UTC (false), or the local time + zone (true). CanNTP shows whether a service to perform time synchronization over the + network is available, and NTP shows whether such a service is enabled. + + NTPSynchronized shows whether the kernel reports the time as synchronized + (c.f. + adjtimex3). + TimeUSec and RTCTimeUSec show the current time on the system and + in the RTC. The purpose of those three properties is to allow remote clients to access this information + over D-Bus. Local clients can access the information directly. + + Whenever the Timezone and LocalRTC settings are changed via + the daemon, PropertyChanged signals are sent out to which clients can subscribe. + + + Note that this service will not inform you about system time changes. Use + timerfd3 + with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET for that. + + + + + Security + + The interactive boolean parameters can be used to control whether + polkit + should interactively ask the user for authentication credentials if required. + + The polkit action for SetTimezone() is + org.freedesktop.timedate1.set-timezone. For + SetLocalRTC() it is + org.freedesktop.timedate1.set-local-rtc, for + SetTime() it is org.freedesktop.timedate1.set-time + and for SetNTP() it is + org.freedesktop.timedate1.set-ntp. + ListTimezones() does not require any privileges. + + + + + + Examples + + + Introspect <interfacename>org.freedesktop.timedate1</interfacename> on the bus + + +$ gdbus introspect --system \ + --dest org.freedesktop.timedate1 \ + --object-path /org/freedesktop/timedate1 + + + + + + + + See also + + More information on how the system clock and RTC interact + + diff --git a/man/os-release.xml b/man/os-release.xml new file mode 100644 index 0000000..c1819ff --- /dev/null +++ b/man/os-release.xml @@ -0,0 +1,565 @@ + + + + + + + os-release + systemd + + + + os-release + 5 + + + + os-release + initrd-release + extension-release + Operating system identification + + + + /etc/os-release + /usr/lib/os-release + /etc/initrd-release + /usr/lib/extension-release.d/extension-release.IMAGE + + + + Description + + The /etc/os-release and + /usr/lib/os-release files contain operating + system identification data. + + The format of os-release is a newline-separated list of + environment-like shell-compatible variable assignments. It is possible to source the configuration from + Bourne shell scripts, however, beyond mere variable assignments, no shell features are supported (this + means variable expansion is explicitly not supported), allowing applications to read the file without + implementing a shell compatible execution engine. Variable assignment values must be enclosed in double + or single quotes if they include spaces, semicolons or other special characters outside of A–Z, a–z, + 0–9. (Assignments that do not include these special characters may be enclosed in quotes too, but this is + optional.) Shell special characters ("$", quotes, backslash, backtick) must be escaped with backslashes, + following shell style. All strings should be in UTF-8 encoding, and non-printable characters should not + be used. Concatenation of multiple individually quoted strings is not supported. Lines beginning with "#" + are treated as comments. Blank lines are permitted and ignored. + + The file /etc/os-release takes + precedence over /usr/lib/os-release. + Applications should check for the former, and exclusively use its + data if it exists, and only fall back to + /usr/lib/os-release if it is missing. + Applications should not read data from both files at the same + time. /usr/lib/os-release is the recommended + place to store OS release information as part of vendor trees. + /etc/os-release should be a relative symlink + to /usr/lib/os-release, to provide + compatibility with applications only looking at + /etc/. A relative symlink instead of an + absolute symlink is necessary to avoid breaking the link in a + chroot or initrd environment such as dracut. + + os-release contains data that is + defined by the operating system vendor and should generally not be + changed by the administrator. + + As this file only encodes names and identifiers it should + not be localized. + + The /etc/os-release and + /usr/lib/os-release files might be symlinks + to other files, but it is important that the file is available + from earliest boot on, and hence must be located on the root file + system. + + os-release must not contain repeating keys. Nevertheless, readers should pick + the entries later in the file in case of repeats, similarly to how a shell sourcing the file would. A + reader may warn about repeating entries. + + For a longer rationale for os-release + please refer to the Announcement of /etc/os-release. + + + <filename>/etc/initrd-release</filename> + + In the initrd, + /etc/initrd-release plays the same role as os-release in the + main system. Additionally, the presence of that file means that the system is in the initrd phase. + /etc/os-release should be symlinked to /etc/initrd-release + (or vice versa), so programs that only look for /etc/os-release (as described + above) work correctly. + + The rest of this document that talks about os-release should be understood + to apply to initrd-release too. + + + + <filename>/usr/lib/extension-release.d/extension-release.<replaceable>IMAGE</replaceable></filename> + + /usr/lib/extension-release.d/extension-release.IMAGE + plays the same role for extension images as os-release for the main system, and + follows the syntax and rules as described in the Portable Services Documentation. The purpose of this + file is to identify the extension and to allow the operating system to verify that the extension image + matches the base OS. This is typically implemented by checking that the ID= options + match, and either SYSEXT_LEVEL= exists and matches too, or if it is not present, + VERSION_ID= exists and matches. This ensures ABI/API compatibility between the + layers and prevents merging of an incompatible image in an overlay. + + In the extension-release.IMAGE filename, the + IMAGE part must exactly match the file name of the containing image with the + suffix removed. In case it is not possible to guarantee that an image file name is stable and doesn't + change between the build and the deployment phases, it is possible to relax this check: if exactly one + file whose name matches extension-release.* is present in this + directory, and the file is tagged with a user.extension-release.strict + xattr7 set to the + string 0, it will be used instead. + + The rest of this document that talks about os-release should be understood + to apply to extension-release too. + + + + + Options + + The following OS identifications parameters may be set using + os-release: + + + General information identifying the operating system + + + + NAME= + + A string identifying the operating system, without a version component, and + suitable for presentation to the user. If not set, a default of NAME=Linux may + be used. + + Examples: NAME=Fedora, NAME="Debian GNU/Linux". + + + + + ID= + + A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" + and "-") identifying the operating system, excluding any version information and suitable for + processing by scripts or usage in generated filenames. If not set, a default of + ID=linux may be used. Note that even though this string may not include + characters that require shell quoting, quoting may nevertheless be used. + + Examples: ID=fedora, ID=debian. + + + + ID_LIKE= + + A space-separated list of operating system identifiers in the same syntax as the + ID= setting. It should list identifiers of operating systems that are closely + related to the local operating system in regards to packaging and programming interfaces, for + example listing one or more OS identifiers the local OS is a derivative from. An OS should + generally only list other OS identifiers it itself is a derivative of, and not any OSes that are + derived from it, though symmetric relationships are possible. Build scripts and similar should + check this variable if they need to identify the local operating system and the value of + ID= is not recognized. Operating systems should be listed in order of how + closely the local operating system relates to the listed ones, starting with the closest. This + field is optional. + + Examples: for an operating system with ID=centos, an assignment of + ID_LIKE="rhel fedora" would be appropriate. For an operating system with + ID=ubuntu, an assignment of ID_LIKE=debian is appropriate. + + + + + PRETTY_NAME= + + A pretty operating system name in a format suitable for presentation to the + user. May or may not contain a release code name or OS version of some kind, as suitable. If not + set, a default of PRETTY_NAME="Linux" may be used + + Example: PRETTY_NAME="Fedora 17 (Beefy Miracle)". + + + + CPE_NAME= + + A CPE name for the operating system, in URI binding syntax, following the Common Platform Enumeration Specification as + proposed by the NIST. This field is optional. + + Example: CPE_NAME="cpe:/o:fedoraproject:fedora:17" + + + + VARIANT= + + A string identifying a specific variant or edition of the operating system suitable + for presentation to the user. This field may be used to inform the user that the configuration of + this system is subject to a specific divergent set of rules or default configuration settings. This + field is optional and may not be implemented on all systems. + + Examples: VARIANT="Server Edition", VARIANT="Smart Refrigerator + Edition". + + Note: this field is for display purposes only. The VARIANT_ID field should + be used for making programmatic decisions. + + + + VARIANT_ID= + + A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" and + "-"), identifying a specific variant or edition of the operating system. This may be interpreted by + other packages in order to determine a divergent default configuration. This field is optional and + may not be implemented on all systems. + + Examples: VARIANT_ID=server, VARIANT_ID=embedded. + + + + + + + Information about the version of the operating system + + + + VERSION= + + A string identifying the operating system version, excluding any OS name + information, possibly including a release code name, and suitable for presentation to the + user. This field is optional. + + Examples: VERSION=17, VERSION="17 (Beefy Miracle)". + + + + + VERSION_ID= + + A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, + a–z, ".", "_" and "-") identifying the operating system version, excluding any OS name information + or release code name, and suitable for processing by scripts or usage in generated filenames. This + field is optional. + + Examples: VERSION_ID=17, VERSION_ID=11.04. + + + + + VERSION_CODENAME= + + A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" + and "-") identifying the operating system release code name, excluding any OS name information or + release version, and suitable for processing by scripts or usage in generated filenames. This field + is optional and may not be implemented on all systems. + + Examples: VERSION_CODENAME=buster, + VERSION_CODENAME=xenial. + + + + BUILD_ID= + + A string uniquely identifying the system image originally used as the installation + base. In most cases, VERSION_ID or + IMAGE_ID+IMAGE_VERSION are updated when the entire system + image is replaced during an update. BUILD_ID may be used in distributions where + the original installation image version is important: VERSION_ID would change + during incremental system updates, but BUILD_ID would not. This field is + optional. + + Examples: BUILD_ID="2013-03-20.3", BUILD_ID=201303203. + + + + + IMAGE_ID= + + A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" + and "-"), identifying a specific image of the operating system. This is supposed to be used for + environments where OS images are prepared, built, shipped and updated as comprehensive, consistent + OS images. This field is optional and may not be implemented on all systems, in particularly not on + those that are not managed via images but put together and updated from individual packages and on + the local system. + + Examples: IMAGE_ID=vendorx-cashier-system, + IMAGE_ID=netbook-image. + + + + IMAGE_VERSION= + + A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, + a–z, ".", "_" and "-") identifying the OS image version. This is supposed to be used together with + IMAGE_ID described above, to discern different versions of the same image. + + + Examples: IMAGE_VERSION=33, IMAGE_VERSION=47.1rc1. + + + + + To summarize: if the image updates are built and shipped as comprehensive units, + IMAGE_ID+IMAGE_VERSION is the best fit. Otherwise, if updates + eventually completely replace previously installed contents, as in a typical binary distribution, + VERSION_ID should be used to identify major releases of the operating system. + BUILD_ID may be used instead or in addition to VERSION_ID when + the original system image version is important. + + + + Presentation information and links + + + + HOME_URL= + DOCUMENTATION_URL= + SUPPORT_URL= + BUG_REPORT_URL= + PRIVACY_POLICY_URL= + + Links to resources on the Internet related to the operating system. + HOME_URL= should refer to the homepage of the operating system, or alternatively + some homepage of the specific version of the operating system. + DOCUMENTATION_URL= should refer to the main documentation page for this + operating system. SUPPORT_URL= should refer to the main support page for the + operating system, if there is any. This is primarily intended for operating systems which vendors + provide support for. BUG_REPORT_URL= should refer to the main bug reporting page + for the operating system, if there is any. This is primarily intended for operating systems that + rely on community QA. PRIVACY_POLICY_URL= should refer to the main privacy + policy page for the operating system, if there is any. These settings are optional, and providing + only some of these settings is common. These URLs are intended to be exposed in "About this system" + UIs behind links with captions such as "About this Operating System", "Obtain Support", "Report a + Bug", or "Privacy Policy". The values should be in RFC3986 format, and should be + http: or https: URLs, and possibly mailto: + or tel:. Only one URL shall be listed in each setting. If multiple resources + need to be referenced, it is recommended to provide an online landing page linking all available + resources. + + Examples: HOME_URL="https://fedoraproject.org/", + BUG_REPORT_URL="https://bugzilla.redhat.com/". + + + + SUPPORT_END= + + The date at which support for this version of the OS ends. (What exactly "lack of + support" means varies between vendors, but generally users should assume that updates, including + security fixes, will not be provided.) The value is a date in the ISO 8601 format + YYYY-MM-DD, and specifies the first day on which support is + not provided. + + For example, SUPPORT_END=2001-01-01 means that the system was supported + until the end of the last day of the previous millennium. + + + + LOGO= + + A string, specifying the name of an icon as defined by freedesktop.org Icon Theme + Specification. This can be used by graphical applications to display an operating system's + or distributor's logo. This field is optional and may not necessarily be implemented on all + systems. + + Examples: LOGO=fedora-logo, LOGO=distributor-logo-opensuse + + + + + ANSI_COLOR= + + A suggested presentation color when showing the OS name on the console. This should + be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting + graphical rendition. This field is optional. + + Examples: ANSI_COLOR="0;31" for red, ANSI_COLOR="1;34" + for light blue, or ANSI_COLOR="0;38;2;60;110;180" for Fedora blue. + + + + + + + Distribution-level defaults and metadata + + + + DEFAULT_HOSTNAME= + + A string specifying the hostname if + hostname5 is not + present and no other configuration source specifies the hostname. Must be either a single DNS label + (a string composed of 7-bit ASCII lower-case characters and no spaces or dots, limited to the + format allowed for DNS domain name labels), or a sequence of such labels separated by single dots + that forms a valid DNS FQDN. The hostname must be at most 64 characters, which is a Linux + limitation (DNS allows longer names). + + See org.freedesktop.hostname15 + for a description of how + systemd-hostnamed.service8 + determines the fallback hostname. + + + + ARCHITECTURE= + A string that specifies which CPU architecture the userspace binaries require. + The architecture identifiers are the same as for ConditionArchitecture= + described in systemd.unit5. + The field is optional and should only be used when just single architecture is supported. + It may provide redundant information when used in a GPT partition with a GUID type that already + encodes the architecture. If this is not the case, the architecture should be specified in + e.g., an extension image, to prevent an incompatible host from loading it. + + + + + SYSEXT_LEVEL= + + A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, + a–z, ".", "_" and "-") identifying the operating system extensions support level, to indicate which + extension images are supported. See /usr/lib/extension-release.d/extension-release.IMAGE, + initrd and + systemd-sysext8) + for more information. + + Examples: SYSEXT_LEVEL=2, SYSEXT_LEVEL=15.14. + + + + + SYSEXT_SCOPE= + Takes a space-separated list of one or more of the strings + system, initrd and portable. This field is + only supported in extension-release.d/ files and indicates what environments + the system extension is applicable to: i.e. to regular systems, to initrds, or to portable service + images. If unspecified, SYSEXT_SCOPE=system portable is implied, i.e. any system + extension without this field is applicable to regular systems and to portable service environments, + but not to initrd environments. + + + + PORTABLE_PREFIXES= + Takes a space-separated list of one or more valid prefix match strings for the + Portable Services logic. This field + serves two purposes: it is informational, identifying portable service images as such (and thus + allowing them to be distinguished from other OS images, such as bootable system images). It is also + used when a portable service image is attached: the specified or implied portable service prefix is + checked against the list specified here, to enforce restrictions how images may be attached to a + system. + + + + + + Notes + + If you are using this file to determine the OS or a specific version of it, use the + ID and VERSION_ID fields, possibly with + ID_LIKE as fallback for ID. When looking for an OS identification + string for presentation to the user use the PRETTY_NAME field. + + Note that operating system vendors may choose not to provide version information, for example to + accommodate for rolling releases. In this case, VERSION and + VERSION_ID may be unset. Applications should not rely on these fields to be + set. + + Operating system vendors may extend the file format and introduce new fields. It is highly + recommended to prefix new fields with an OS specific name in order to avoid name clashes. Applications + reading this file must ignore unknown fields. + + Example: DEBIAN_BTS="debbugs://bugs.debian.org/". + + Container and sandbox runtime managers may make the host's identification data available to + applications by providing the host's /etc/os-release (if available, otherwise + /usr/lib/os-release as a fallback) as + /run/host/os-release. + + + + + Examples + + + <filename>os-release</filename> file for Fedora Workstation + + NAME=Fedora +VERSION="32 (Workstation Edition)" +ID=fedora +VERSION_ID=32 +PRETTY_NAME="Fedora 32 (Workstation Edition)" +ANSI_COLOR="0;38;2;60;110;180" +LOGO=fedora-logo-icon +CPE_NAME="cpe:/o:fedoraproject:fedora:32" +HOME_URL="https://fedoraproject.org/" +DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/" +SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" +BUG_REPORT_URL="https://bugzilla.redhat.com/" +REDHAT_BUGZILLA_PRODUCT="Fedora" +REDHAT_BUGZILLA_PRODUCT_VERSION=32 +REDHAT_SUPPORT_PRODUCT="Fedora" +REDHAT_SUPPORT_PRODUCT_VERSION=32 +PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" +VARIANT="Workstation Edition" +VARIANT_ID=workstation + + + + <filename>extension-release</filename> file for an extension for Fedora Workstation 32 + + ID=fedora +VERSION_ID=32 + + + + Reading <filename>os-release</filename> in + <citerefentry project='man-pages'><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> + + + + + + Reading <filename>os-release</filename> in + <citerefentry project='die-net'><refentrytitle>python</refentrytitle><manvolnum>1</manvolnum></citerefentry> (versions >= 3.10) + + + + See docs for + platform.freedesktop_os_release for more details. + + + + + Reading <filename>os-release</filename> in + <citerefentry project='die-net'><refentrytitle>python</refentrytitle><manvolnum>1</manvolnum></citerefentry> (any version) + + + + Note that the above version that uses the built-in implementation is preferred + in most cases, and the open-coded version here is provided for reference. + + + + + + See Also + + systemd1, + lsb_release1, + hostname5, + machine-id5, + machine-info5 + + + + diff --git a/man/pam_systemd.xml b/man/pam_systemd.xml new file mode 100644 index 0000000..be8ac5a --- /dev/null +++ b/man/pam_systemd.xml @@ -0,0 +1,349 @@ + + + + + + + + pam_systemd + systemd + + + + pam_systemd + 8 + + + + pam_systemd + Register user sessions in the systemd login manager + + + + pam_systemd.so + + + + Description + + pam_systemd registers user sessions with + the systemd login manager + systemd-logind.service8, + and hence the systemd control group hierarchy. + + The module also applies various resource management and runtime parameters to the new session, as + configured in the JSON User Records of the user, when + one is defined. + + On login, this module — in conjunction with systemd-logind.service — ensures the + following: + + + If it does not exist yet, the user runtime directory /run/user/$UID is + either created or mounted as new tmpfs file system with quota applied, and its ownership + changed to the user that is logging in. + + The $XDG_SESSION_ID environment variable is initialized. If auditing is + available and pam_loginuid.so was run before this module (which is highly recommended), the + variable is initialized from the auditing session id (/proc/self/sessionid). Otherwise, an + independent session counter is used. + + A new systemd scope unit is created for the session. If this is the first concurrent session of + the user, an implicit per-user slice unit below user.slice is automatically created and the + scope placed into it. An instance of the system service user@.service, which runs the + systemd user manager instance, is started. + + The $TZ, $EMAIL and $LANG + environment variables are configured for the user, based on the respective data from the user's JSON + record (if it is defined). Moreover, any environment variables explicitly configured in the user record + are imported, and the umask, nice level, and resource limits initialized. + + + On logout, this module ensures the following: + + + If enabled in + logind.conf + 5 (KillUserProcesses=), all processes of the session are + terminated. If the last concurrent session of a user ends, the user's systemd instance will be terminated too, + and so will the user's slice unit. + + If the last concurrent session of a user ends, + the user runtime directory /run/user/$UID and all its + contents are removed, too. + + + If the system was not booted up with systemd as init system, + this module does nothing and immediately returns + PAM_SUCCESS. + + + + + Options + + The following options are understood: + + + + + class= + + Takes a string argument which sets the session class. The XDG_SESSION_CLASS + environment variable (see below) takes precedence. One of user, greeter, + lock-screen or background. See + sd_session_get_class3 for + details about the session class. + + + + type= + + Takes a string argument which sets the session type. The XDG_SESSION_TYPE + environment variable (see below) takes precedence. One of unspecified, + tty, x11, wayland or mir. See + sd_session_get_type3 for + details about the session type. + + + + desktop= + + Takes a single, short identifier string for the desktop environment. The + XDG_SESSION_DESKTOP environment variable (see below) takes precedence. This may be used to + indicate the session desktop used, where this applies and if this information is available. For example: + GNOME, or KDE. It is recommended to use the same identifiers and + capitalization as for $XDG_CURRENT_DESKTOP, as defined by the Desktop Entry + Specification. (However, note that the option only takes a single item, and not a colon-separated list + like $XDG_CURRENT_DESKTOP.) See + sd_session_get_desktop3 for + further details. + + + + debug= + + Takes an optional boolean argument. If yes or without the argument, the module will log + debugging information as it operates. + + + + + + Module Types Provided + + Only is provided. + + + + Environment + + The following environment variables are initialized by the module and available to the processes of the + user's session: + + + + $XDG_SESSION_ID + + A short session identifier, suitable to be used in filenames. The string itself should be + considered opaque, although often it is just the audit session ID as reported by + /proc/self/sessionid. Each ID will be assigned only once during machine uptime. It may + hence be used to uniquely label files or other resources of this session. Combine this ID with the boot + identifier, as returned by + sd_id128_get_boot3, for a + globally unique identifier. + + + + $XDG_RUNTIME_DIR + + Path to a user-private user-writable directory + that is bound to the user login time on the machine. It is + automatically created the first time a user logs in and + removed on the user's final logout. If a user logs in twice at + the same time, both sessions will see the same + $XDG_RUNTIME_DIR and the same contents. If + a user logs in once, then logs out again, and logs in again, + the directory contents will have been lost in between, but + applications should not rely on this behavior and must be able + to deal with stale files. To store session-private data in + this directory, the user should include the value of + $XDG_SESSION_ID in the filename. This + directory shall be used for runtime file system objects such + as AF_UNIX sockets, FIFOs, PID files and + similar. It is guaranteed that this directory is local and + offers the greatest possible file system feature set the + operating system provides. For further details, see the XDG + Base Directory Specification. $XDG_RUNTIME_DIR + is not set if the current user is not the original user of the session. + + + + $TZ + $EMAIL + $LANG + + If a JSON user record is known for the user logging in these variables are + initialized from the respective data in the record. + + + + + The following environment variables are read by the module and may be used by the PAM service to pass + metadata to the module. If these variables are not set when the PAM module is invoked but can be determined + otherwise they are set by the module, so that these variables are initialized for the session and applications if + known at all. + + + + $XDG_SESSION_TYPE + + The session type. This may be used instead of type= on the module parameter + line, and is usually preferred. + + + + $XDG_SESSION_CLASS + + The session class. This may be used instead of class= on the module parameter + line, and is usually preferred. + + + + $XDG_SESSION_DESKTOP + + The desktop identifier. This may be used instead of desktop= on the module + parameter line, and is usually preferred. + + + + $XDG_SEAT + + The seat name the session shall be registered + for, if any. + + + + $XDG_VTNR + + The VT number the session shall be registered + for, if any. (Only applies to seats with a VT available, such + as seat0) + + + + If not set, pam_systemd will initialize + $XDG_SEAT and $XDG_VTNR + based on the $DISPLAY variable (if the latter is set). + + + + Session limits + + PAM modules earlier in the stack, that is those that come before pam_systemd.so, + can set session scope limits using the PAM context objects. The data for these objects is provided as NUL-terminated C strings + and maps directly to the respective unit resource control directives. Note that these limits apply to individual sessions of the user, + they do not apply to all user processes as a combined whole. In particular, the per-user user@.service unit instance, + which runs the systemd --user manager process and its children, and is tracked outside of any session, being shared + by all the user's sessions, is not covered by these limits. + + + See + systemd.resource-control5 for more information about the resources. + Also, see pam_set_data3 for additional information about how to set + the context objects. + + + + + systemd.memory_max= + + Sets unit MemoryMax=. + + + + systemd.tasks_max= + + Sets unit TasksMax=. + + + + systemd.cpu_weight= + + Sets unit CPUWeight=. + + + + systemd.io_weight= + + Sets unit IOWeight=. + + + + systemd.runtime_max_sec= + + Sets unit RuntimeMaxSec=. + + + + Example data as can be provided from an another PAM module: + +pam_set_data(handle, "systemd.memory_max", (void *)"200M", cleanup); +pam_set_data(handle, "systemd.tasks_max", (void *)"50", cleanup); +pam_set_data(handle, "systemd.cpu_weight", (void *)"100", cleanup); +pam_set_data(handle, "systemd.io_weight", (void *)"340", cleanup); +pam_set_data(handle, "systemd.runtime_max_sec", (void *)"3600", cleanup); + + + + + + + Example + + Here's an example PAM configuration fragment that allows users sessions to be managed by + systemd-logind.service: + + #%PAM-1.0 +auth sufficient pam_unix.so +-auth sufficient pam_systemd_home.so +auth required pam_deny.so + +account required pam_nologin.so +-account sufficient pam_systemd_home.so +account sufficient pam_unix.so +account required pam_permit.so + +-password sufficient pam_systemd_home.so +password sufficient pam_unix.so sha512 shadow try_first_pass +password required pam_deny.so + +-session optional pam_keyinit.so revoke +-session optional pam_loginuid.so +-session optional pam_systemd_home.so +-session optional pam_systemd.so +session required pam_unix.so + + + + See Also + + systemd1, + systemd-logind.service8, + logind.conf5, + loginctl1, + pam_systemd_home8, + pam.conf5, + pam.d5, + pam8, + pam_loginuid8, + systemd.scope5, + systemd.slice5, + systemd.service5 + + + + diff --git a/man/pam_systemd_home.xml b/man/pam_systemd_home.xml new file mode 100644 index 0000000..ff4735c --- /dev/null +++ b/man/pam_systemd_home.xml @@ -0,0 +1,175 @@ + + + + + + + + pam_systemd_home + systemd + + + + pam_systemd_home + 8 + + + + pam_systemd_home + Authenticate users and mount home directories via systemd-homed.service + + + + + pam_systemd_home.so + + + + Description + + pam_systemd_home ensures that home directories managed by + systemd-homed.service8 + are automatically activated (mounted) on user login, and are deactivated (unmounted) when the last + session of the user ends. For such users, it also provides authentication (when per-user disk encryption + is used, the disk encryption key is derived from the authentication credential supplied at login time), + account management (the JSON user record embedded in + the home store contains account details), and implements the updating of the encryption password (which + is also used for user authentication). + + + + Options + + The following options are understood: + + + + + suspend= + + Takes a boolean argument. If true, the home directory of the user will be suspended + automatically during system suspend; if false it will remain active. Automatic suspending of the home + directory improves security substantially as secret key material is automatically removed from memory + before the system is put to sleep and must be re-acquired (through user re-authentication) when + coming back from suspend. It is recommended to set this parameter for all PAM applications that have + support for automatically re-authenticating via PAM on system resume. If multiple sessions of the + same user are open in parallel the user's home directory will be left unsuspended on system suspend + as long as at least one of the sessions does not set this parameter to on. Defaults to + off. + + Note that TTY logins generally do not support re-authentication on system resume. + Re-authentication on system resume is primarily a concept implementable in graphical environments, in + the form of lock screens brought up automatically when the system goes to sleep. This means that if a + user concurrently uses graphical login sessions that implement the required re-authentication + mechanism and console logins that do not, the home directory is not locked during suspend, due to the + logic explained above. That said, it is possible to set this field for TTY logins too, ignoring the + fact that TTY logins actually don't support the re-authentication mechanism. In that case the TTY + sessions will appear hung until the user logs in on another virtual terminal (regardless if via + another TTY session or graphically) which will resume the home directory and unblock the original TTY + session. (Do note that lack of screen locking on TTY sessions means even though the TTY session + appears hung, keypresses can still be queued into it, and the existing screen contents be read + without re-authentication; this limitation is unrelated to the home directory management + pam_systemd_home and systemd-homed.service implement.) + + Turning this option on by default is highly recommended for all sessions, but only if the + service managing these sessions correctly implements the aforementioned re-authentication. Note that + the re-authentication must take place from a component running outside of the user's context, so that + it does not require access to the user's home directory for operation. Traditionally, most desktop + environments do not implement screen locking this way, and need to be updated + accordingly. + + This setting may also be controlled via the $SYSTEMD_HOME_SUSPEND + environment variable (see below), which pam_systemd_home reads during initialization and sets + for sessions. If both the environment variable is set and the module parameter specified the latter + takes precedence. + + + + debug= + + Takes an optional boolean argument. If yes or without the argument, the module will log + debugging information as it operates. + + + + + + Module Types Provided + + The module implements all four PAM operations: (reason: to allow + authentication using the encrypted data), (reason: users with + systemd-homed.service user accounts are described in a JSON user record and may be configured in more detail than + in the traditional Linux user database), (user sessions must be tracked in order + to implement automatic release when the last session of the user is gone), (to + change the encryption password — also used for user authentication — through PAM). + + + + Environment + + The following environment variables are initialized by the module and available to the processes of the + user's session: + + + + $SYSTEMD_HOME=1 + + Indicates that the user's home directory is managed by systemd-homed.service. + + + + $SYSTEMD_HOME_SUSPEND= + + Indicates whether the session has been registered with the suspend mechanism enabled + or disabled (see above). The variable's value is either 0 or + 1. Note that the module both reads the variable when initializing, and sets it for + sessions. + + + + + + + Example + + Here's an example PAM configuration fragment that permits users managed by + systemd-homed.service to log in: + + #%PAM-1.0 +auth sufficient pam_unix.so +-auth sufficient pam_systemd_home.so +auth required pam_deny.so + +account required pam_nologin.so +-account sufficient pam_systemd_home.so +account sufficient pam_unix.so +account required pam_permit.so + +-password sufficient pam_systemd_home.so +password sufficient pam_unix.so sha512 shadow try_first_pass +password required pam_deny.so + +-session optional pam_keyinit.so revoke +-session optional pam_loginuid.so +-session optional pam_systemd_home.so +-session optional pam_systemd.so +session required pam_unix.so + + + + See Also + + systemd1, + systemd-homed.service8, + homed.conf5, + homectl1, + pam_systemd8, + pam.conf5, + pam.d5, + pam8 + + + + diff --git a/man/path-documents.c b/man/path-documents.c new file mode 100644 index 0000000..a357dd6 --- /dev/null +++ b/man/path-documents.c @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include + +int main(void) { + int r; + char *t; + + r = sd_path_lookup(SD_PATH_USER_DOCUMENTS, NULL, &t); + if (r < 0) + return EXIT_FAILURE; + + printf("~/Documents: %s\n", t); + free(t); + + return EXIT_SUCCESS; +} diff --git a/man/portablectl.xml b/man/portablectl.xml new file mode 100644 index 0000000..963361e --- /dev/null +++ b/man/portablectl.xml @@ -0,0 +1,474 @@ + + + + + + + + portablectl + systemd + + + + portablectl + 1 + + + + portablectl + Attach, detach or inspect portable service images + + + + + portablectl + OPTIONS + COMMAND + NAME + + + + + Description + + portablectl may be used to attach, detach or inspect portable service images. It's + primarily a command interfacing with + systemd-portabled.service8. + + Portable service images contain an OS file system tree along with + systemd1 unit file + information. A service image may be "attached" to the local system. If attached, a set of unit files are copied + from the image to the host, and extended with RootDirectory= or RootImage= + assignments (in case of service units) pointing to the image file or directory, ensuring the services will run + within the file system context of the image. + + Portable service images are an efficient way to bundle multiple related services and other units together, + and transfer them as a whole between systems. When these images are attached the local system the contained units + may run in most ways like regular system-provided units, either with full privileges or inside strict sandboxing, + depending on the selected configuration. For more details, see + Portable Services. + + Specifically portable service images may be of the following kind: + + + Directory trees containing an OS, including the top-level directories /usr/, + /etc/, and so on. + + btrfs subvolumes containing OS trees, similar to normal directory trees. + + Binary "raw" disk images containing MBR or GPT partition tables and Linux file system + partitions. (These must be regular files, with the .raw suffix.) + + + + + + Commands + + The following commands are understood: + + + + + list + + List available portable service images. This will list all portable service images discovered + in the portable image search paths (see below), along with brief metadata and state information. Note that many + of the commands below may both operate on images inside and outside of the search paths. This command is hence + mostly a convenience option, the commands are generally not restricted to what this list + shows. + + + + attach IMAGE [PREFIX…] + + Attach a portable service image to the host system. Expects a file system path to a portable + service image file or directory as first argument. If the specified path contains no slash character + (/) it is understood as image filename that is searched for in the portable service image + search paths (see below). To reference a file in the current working directory prefix the filename with + ./ to avoid this search path logic. + + When a portable service is attached four operations are executed: + + + + All unit files of types .service, .socket, + .target, .timer and .path which match the + indicated unit file name prefix are copied from the image to the host's + /etc/systemd/system.attached/ directory (or + /run/systemd/system.attached/ — depending whether is + specified, see below), which is included in the built-in unit search path of the system service + manager. + + For unit files of type .service a drop-in is added to these copies that + adds RootDirectory= or RootImage= settings (see + systemd.unit5 for + details), that ensures these services are run within the file system of the originating portable service + image. + + A second drop-in is created: the "profile" drop-in, that may contain additional security + settings (and other settings). A number of profiles are available by default but administrators may define + their own ones. See below. + + If the portable service image file is not already in the search path (see below), a symbolic + link to it is created in /etc/portables/ or + /run/portables/, to make sure it is included in it. + + + By default all unit files whose names start with a prefix generated from the image's file name are copied + out. Specifically, the prefix is determined from the image file name with any suffix such as + .raw removed, truncated at the first occurrence of an underscore character + (_), if there is one. The underscore logic is supposed to be used to versioning so that the + an image file foobar_47.11.raw will result in a unit file matching prefix of + foobar. This prefix is then compared with all unit files names contained in the image in + the usual directories, but only unit file names where the prefix is followed by -, + . or @ are considered. Example: if a portable service image file is named + foobar_47.11.raw then by default all its unit files with names such as + foobar-quux-waldi.service, foobar.service or + foobar@.service will be considered. It's possible to override the matching prefix: all + strings listed on the command line after the image file name are considered prefixes, overriding the implicit + logic where the prefix is derived from the image file name. + + By default, after the unit files are attached the service manager's configuration is reloaded, except + when is specified (see below). This ensures that the new units made available to + the service manager are seen by it. + + If and/or are passed, the portable services are + immediately started (blocking operation unless is passed) and/or enabled after + attaching the image. + + + + + detach IMAGE [PREFIX…] + + Detaches a portable service image from the host. This undoes the operations executed by the + attach command above, and removes the unit file copies, drop-ins and image symlink + again. This command expects an image name or path as parameter. Note that if a path is specified only the last + component of it (i.e. the file or directory name itself, not the path to it) is used for finding matching unit + files. This is a convenience feature to allow all arguments passed as attach also to + detach. + + If and/or are passed, the portable services are + immediately stopped (blocking operation) and/or disabled before detaching the image. Prefix(es) are also accepted, + to be used in case the unit names do not match the image name as described in the attach. + + + + reattach IMAGE [PREFIX…] + + Detaches an existing portable service image from the host, and immediately attaches it again. + This is useful in case the image was replaced. Running units are not stopped during the process. Partial matching, + to allow for different versions in the image name, is allowed: only the part before the first _ + character has to match. If the new image doesn't exist, the existing one will not be detached. The parameters + follow the same syntax as the attach command. + + If and/or are passed, the portable services are + immediately stopped if removed, started and/or enabled if added, or restarted if updated. Prefixes are also + accepted, in the same way as described in the attach case. + + + + inspect IMAGE [PREFIX…] + + Extracts various metadata from a portable service image and presents it to the + caller. Specifically, the + os-release5 file of the + image is retrieved as well as all matching unit files. By default a short summary showing the most relevant + metadata in combination with a list of matching unit files is shown (that is the unit files + attach would install to the host system). If combined with (see + above), the os-release data and the units files' contents is displayed unprocessed. This + command is useful to determine whether an image qualifies as portable service image, and which unit files are + included. This command expects the path to the image as parameter, optionally followed by a list of unit file + prefixes to consider, similar to the attach command described above. + + + + + is-attached IMAGE + + Determines whether the specified image is currently attached or not. Unless combined with the + switch this will show a short state identifier for the image. Specifically: + + + Image attachment states + + + + + + State + Description + + + + + + The image is currently not attached. + + + + The image is currently attached, i.e. its unit files have been made available to the host system. + + + + Like , but the unit files have been made available transiently only, i.e. the attach command has been invoked with the option. + + + + The image is currently attached, and at least one unit file associated with it has been enabled. + + + + Like , but the unit files have been made available transiently only, i.e. the attach command has been invoked with the option. + + + + The image is currently attached, and at least one unit file associated with it is running. + + + + The image is currently attached transiently, and at least one unit file associated with it is running. + + + +
+ + + + + + read-only IMAGE [BOOL] + + Marks or (unmarks) a portable service image read-only. Takes an image name, followed by a + boolean as arguments. If the boolean is omitted, positive is implied, i.e. the image is marked + read-only. + + + + remove IMAGE… + + Removes one or more portable service images. Note that this command will only remove the + specified image path itself — it refers to a symbolic link then the symbolic link is removed and not the + image it points to. + + + + set-limit [IMAGE] BYTES + + Sets the maximum size in bytes that a specific portable service image, or all images, may grow + up to on disk (disk quota). Takes either one or two parameters. The first, optional parameter refers to a + portable service image name. If specified, the size limit of the specified image is changed. If omitted, the + overall size limit of the sum of all images stored locally is changed. The final argument specifies the size + limit in bytes, possibly suffixed by the usual K, M, G, T units. If the size limit shall be disabled, specify + - as size. + + Note that per-image size limits are only supported on btrfs file systems. Also, depending on + BindPaths= settings in the portable service's unit files directories from the host might be + visible in the image environment during runtime which are not affected by this setting, as only the image + itself is counted against this limit. + + + + + + + + Options + + The following options are understood: + + + + + + + Suppresses additional informational output while running. + + + + PROFILE + PROFILE + + When attaching an image, select the profile to use. By default the default + profile is used. For details about profiles, see below. + + + + + + When attaching an image, select whether to prefer copying or symlinking of files installed into + the host system. Takes one of copy (to prefer copying of files), symlink + (to prefer creation of symbolic links) or auto for an intermediary mode where security + profile drop-ins are symlinked while unit files are copied. Note that this option expresses a preference only, + in cases where symbolic links cannot be created — for example when the image operated on is a raw disk image, + and hence not directly referentiable from the host file system — copying of files is used + unconditionally. + + + + + + When specified the unit and drop-in files are placed in + /run/systemd/system.attached/ instead of + /etc/systemd/system.attached/. Images attached with this option set hence remain attached + only until the next reboot, while they are normally attached persistently. + + + + + + Don't reload the service manager after attaching or detaching a portable service + image. Normally the service manager is reloaded to ensure it is aware of added or removed unit + files. + + + + + + When inspecting portable service images, show the (unprocessed) contents of the metadata files + pulled from the image, instead of brief summaries. Specifically, this will show the + os-release5 and unit file + contents of the image. + + + + + + Immediately enable/disable the portable service after attaching/detaching. + + + + + + Immediately start/stop/restart the portable service after attaching/before + detaching/after upgrading. + + + + + + Don't block waiting for attach --now to complete. + + + + PATH + + Add an additional image PATH as an overlay on + top of IMAGE when attaching/detaching. This argument can be specified + multiple times, in which case the order in which images are laid down follows the rules specified in + systemd.exec5 + for the ExtensionImages= directive and for the + systemd-sysext8 tool. + The images must contain an extension-release file with metadata that matches + what is defined in the os-release of IMAGE. See: + os-release5. + Images can be block images, btrfs subvolumes or directories. For more information on portable + services with extensions, see the Extension Images paragraph on + Portable Services. + + + Note that the same extensions have to be specified, in the same order, when attaching + and detaching. + + + + + + Skip safety checks and attach or detach images (with extensions) without first ensuring + that the units are not running, and do not insist that the + extension-release.NAME file in the extension image has + to match the image filename. + + + + + + + + + + + + + + + Files and Directories + + Portable service images are preferably stored in /var/lib/portables/, but are also + searched for in /etc/portables/, /run/systemd/portables/, + /usr/local/lib/portables/ and /usr/lib/portables/. It's recommended not + to place image files directly in /etc/portables/ or + /run/systemd/portables/ (as these are generally not suitable for storing large or non-textual + data), but use these directories only for linking images located elsewhere into the image search path. + + When a portable service image is attached, matching unit files are copied onto the host into the + /etc/systemd/system.attached/ and /run/systemd/system.attached/ + directories. When an image is detached, the unit files are removed again from these directories. + + + + Profiles + + When portable service images are attached a "profile" drop-in is linked in, which may be used to enforce + additional security (and other) restrictions locally. Four profile drop-ins are defined by default, and shipped in + /usr/lib/systemd/portable/profile/. Additional, local profiles may be defined by placing them + in /etc/systemd/portable/profile/. The default profiles are: + + + Profiles + + + + + + Name + Description + + + + + default + This is the default profile if no other profile name is set via the (see above). It's fairly restrictive, but should be useful for common, unprivileged system workloads. This includes write access to the logging framework, as well as IPC access to the D-Bus system. + + + nonetwork + Very similar to default, but networking is turned off for any services of the portable service image. + + + strict + A profile with very strict settings. This profile excludes IPC (D-Bus) and network access. + + + trusted + A profile with very relaxed settings. In this profile the services run with full privileges. + + + +
+ + For details on these profiles and their effects see their precise definitions, + e.g. /usr/lib/systemd/portable/profile/default/service.conf and similar. + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + + + See Also + + systemd1, + systemd-sysext8, + org.freedesktop.portable15, + systemd-portabled.service8 + + + + diff --git a/man/print-unit-path-call-method.c b/man/print-unit-path-call-method.c new file mode 100644 index 0000000..f73dd07 --- /dev/null +++ b/man/print-unit-path-call-method.c @@ -0,0 +1,51 @@ +/* SPDX-License-Identifier: MIT-0 */ + +/* This is equivalent to: + * busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \ + * org.freedesktop.systemd1.Manager GetUnitByPID $$ + * + * Compile with 'cc print-unit-path-call-method.c -lsystemd' + */ + +#include +#include +#include +#include + +#include + +#define _cleanup_(f) __attribute__((cleanup(f))) +#define DESTINATION "org.freedesktop.systemd1" +#define PATH "/org/freedesktop/systemd1" +#define INTERFACE "org.freedesktop.systemd1.Manager" +#define MEMBER "GetUnitByPID" + +static int log_error(int error, const char *message) { + errno = -error; + fprintf(stderr, "%s: %m\n", message); + return error; +} + +int main(int argc, char **argv) { + _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL; + _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL; + _cleanup_(sd_bus_message_unrefp) sd_bus_message *reply = NULL; + int r; + + r = sd_bus_open_system(&bus); + if (r < 0) + return log_error(r, "Failed to acquire bus"); + + r = sd_bus_call_method(bus, DESTINATION, PATH, INTERFACE, MEMBER, &error, &reply, "u", (unsigned) getpid()); + if (r < 0) + return log_error(r, MEMBER " call failed"); + + const char *ans; + r = sd_bus_message_read(reply, "o", &ans); + if (r < 0) + return log_error(r, "Failed to read reply"); + + printf("Unit path is \"%s\".\n", ans); + + return 0; +} diff --git a/man/print-unit-path.c b/man/print-unit-path.c new file mode 100644 index 0000000..0b89318 --- /dev/null +++ b/man/print-unit-path.c @@ -0,0 +1,60 @@ +/* SPDX-License-Identifier: MIT-0 */ + +/* This is equivalent to: + * busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \ + * org.freedesktop.systemd1.Manager GetUnitByPID $$ + * + * Compile with 'cc print-unit-path.c -lsystemd' + */ + +#include +#include +#include +#include + +#include + +#define _cleanup_(f) __attribute__((cleanup(f))) +#define DESTINATION "org.freedesktop.systemd1" +#define PATH "/org/freedesktop/systemd1" +#define INTERFACE "org.freedesktop.systemd1.Manager" +#define MEMBER "GetUnitByPID" + +static int log_error(int error, const char *message) { + errno = -error; + fprintf(stderr, "%s: %m\n", message); + return error; +} + +int main(int argc, char **argv) { + _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL; + _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL; + _cleanup_(sd_bus_message_unrefp) sd_bus_message *reply = NULL, *m = NULL; + int r; + + r = sd_bus_open_system(&bus); + if (r < 0) + return log_error(r, "Failed to acquire bus"); + + r = sd_bus_message_new_method_call(bus, &m, + DESTINATION, PATH, INTERFACE, MEMBER); + if (r < 0) + return log_error(r, "Failed to create bus message"); + + r = sd_bus_message_append(m, "u", (unsigned) getpid()); + if (r < 0) + return log_error(r, "Failed to append to bus message"); + + r = sd_bus_call(bus, m, -1, &error, &reply); + if (r < 0) + return log_error(r, MEMBER " call failed"); + + const char *ans; + r = sd_bus_message_read(reply, "o", &ans); + if (r < 0) + return log_error(r, "Failed to read reply"); + + printf("Unit path is \"%s\".\n", ans); + + return 0; +} diff --git a/man/pstore.conf.xml b/man/pstore.conf.xml new file mode 100644 index 0000000..64e453b --- /dev/null +++ b/man/pstore.conf.xml @@ -0,0 +1,89 @@ + + + + + + + pstore.conf + systemd + + + + pstore.conf + 5 + + + + pstore.conf + pstore.conf.d + PStore configuration file + + + + + /etc/systemd/pstore.conf + /etc/systemd/pstore.conf.d/* + + + + + Description + + This file configures the behavior of + systemd-pstore8, + a tool for archiving the contents of the persistent storage filesystem, + pstore. + + + + + + + Options + + All options are configured in the + [PStore] section: + + + + + Storage= + + Controls where to archive (i.e. copy) files from the pstore filesystem. One of none, + external, and journal. When + none, the tool exits without processing files in the pstore filesystem. + When external (the default), files are archived into /var/lib/systemd/pstore/, + and logged into the journal. + When journal, pstore file contents are logged only in the journal. + + + + + + Unlink= + + Controls whether or not files are removed from pstore after processing. + Takes a boolean value. When true, a pstore file is removed from the pstore once it has been + archived (either to disk or into the journal). When false, processing of pstore files occurs + normally, but the files remain in the pstore. + The default is true in order to maintain the pstore in a nearly empty state, so that the pstore + has storage available for the next kernel error event. + + + + + The defaults for all values are listed as comments in the + template /etc/systemd/pstore.conf file that + is installed by default. + + + + See Also + + systemd-journald.service8 + + + + diff --git a/man/repart.d.xml b/man/repart.d.xml new file mode 100644 index 0000000..ebbb31c --- /dev/null +++ b/man/repart.d.xml @@ -0,0 +1,770 @@ + + + + + + + + repart.d + systemd + + + + repart.d + 5 + + + + repart.d + Partition Definition Files for Automatic Boot-Time Repartitioning + + + + /etc/repart.d/*.conf +/run/repart.d/*.conf +/usr/lib/repart.d/*.conf + + + + + Description + + repart.d/*.conf files describe basic properties of partitions of block + devices of the local system. They may be used to declare types, names and sizes of partitions that shall + exist. The + systemd-repart8 + service reads these files and attempts to add new partitions currently missing and enlarge existing + partitions according to these definitions. Operation is generally incremental, i.e. when applied, what + exists already is left intact, and partitions are never shrunk, moved or deleted. + + These definition files are useful for implementing operating system images that are prepared and + delivered with minimally sized images (for example lacking any state or swap partitions), and which on + first boot automatically take possession of any remaining disk space following a few basic rules. + + Currently, support for partition definition files is only implemented for GPT partitition + tables. + + Partition files are generally matched against any partitions already existing on disk in a simple + algorithm: the partition files are sorted by their filename (ignoring the directory prefix), and then + compared in order against existing partitions matching the same partition type UUID. Specifically, the + first existing partition with a specific partition type UUID is assigned the first definition file with + the same partition type UUID, and the second existing partition with a specific type UUID the second + partition file with the same type UUID, and so on. Any left-over partition files that have no matching + existing partition are assumed to define new partition that shall be created. Such partitions are + appended to the end of the partition table, in the order defined by their names utilizing the first + partition slot greater than the highest slot number currently in use. Any existing partitions that have + no matching partition file are left as they are. + + Note that these definitions may only be used to create and initialize new partitions or to grow + existing ones. In the latter case it will not grow the contained files systems however; separate + mechanisms, such as + systemd-growfs8 may be + used to grow the file systems inside of these partitions. Partitions may also be marked for automatic + growing via the GrowFileSystem= setting, in which case the file system is grown on + first mount by tools that respect this flag. See below for details. + + + + [Partition] Section Options + + + + Type= + + The GPT partition type UUID to match. This may be a GPT partition type UUID such as + 4f68bce3-e8cd-4db1-96e7-fbcaf984b709, or an identifier. + Architecture specific partition types can use one of these architecture identifiers: + alpha, arc, arm (32bit), + arm64 (64bit, aka aarch64), ia64, + loongarch64, mips-le, mips64-le, + parisc, ppc, ppc64, + ppc64-le, riscv32, riscv64, + s390, s390x, tilegx, + x86 (32bit, aka i386) and x86-64 (64bit, aka amd64). + + The supported identifiers are: + + + GPT partition type identifiers + + + + + + + + Identifier + Explanation + + + + + + esp + EFI System Partition + + + + xbootldr + Extended Boot Loader Partition + + + + swap + Swap partition + + + + home + Home (/home/) partition + + + + srv + Server data (/srv/) partition + + + + var + Variable data (/var/) partition + + + + tmp + Temporary data (/var/tmp/) partition + + + + linux-generic + Generic Linux file system partition + + + + root + Root file system partition type appropriate for the local architecture (an alias for an architecture root file system partition type listed below, e.g. root-x86-64) + + + + root-verity + Verity data for the root file system partition for the local architecture + + + + root-verity-sig + Verity signature data for the root file system partition for the local architecture + + + + root-secondary + Root file system partition of the secondary architecture of the local architecture (usually the matching 32bit architecture for the local 64bit architecture) + + + + root-secondary-verity + Verity data for the root file system partition of the secondary architecture + + + + root-secondary-verity-sig + Verity signature data for the root file system partition of the secondary architecture + + + + root-{arch} + Root file system partition of the given architecture (such as root-x86-64 or root-riscv64) + + + + root-{arch}-verity + Verity data for the root file system partition of the given architecture + + + + root-{arch}-verity-sig + Verity signature data for the root file system partition of the given architecture + + + + usr + /usr/ file system partition type appropriate for the local architecture (an alias for an architecture /usr/ file system partition type listed below, e.g. usr-x86-64) + + + + usr-verity + Verity data for the /usr/ file system partition for the local architecture + + + + usr-verity-sig + Verity signature data for the /usr/ file system partition for the local architecture + + + + usr-secondary + /usr/ file system partition of the secondary architecture of the local architecture (usually the matching 32bit architecture for the local 64bit architecture) + + + + usr-secondary-verity + Verity data for the /usr/ file system partition of the secondary architecture + + + + usr-secondary-verity-sig + Verity signature data for the /usr/ file system partition of the secondary architecture + + + + usr-{arch} + /usr/ file system partition of the given architecture + + + + usr-{arch}-verity + Verity data for the /usr/ file system partition of the given architecture + + + + usr-{arch}-verity-sig + Verity signature data for the /usr/ file system partition of the given architecture + + + +
+ + This setting defaults to linux-generic. + + Most of the partition type UUIDs listed above are defined in the Discoverable Partitions + Specification. + + + + Label= + + The textual label to assign to the partition if none is assigned yet. Note that this + setting is not used for matching. It is also not used when a label is already set for an existing + partition. It is thus only used when a partition is newly created or when an existing one had a no + label set (that is: an empty label). If not specified a label derived from the partition type is + automatically used. Simple specifier expansion is supported, see below. + + + + UUID= + + The UUID to assign to the partition if none is assigned yet. Note that this + setting is not used for matching. It is also not used when a UUID is already set for an existing + partition. It is thus only used when a partition is newly created or when an existing one had a + all-zero UUID set. If set to null, the UUID is set to all zeroes. If not specified + a UUID derived from the partition type is automatically used. + + + + Priority= + + A numeric priority to assign to this partition, in the range -2147483648…2147483647, + with smaller values indicating higher priority, and higher values indicating smaller priority. This + priority is used in case the configured size constraints on the defined partitions do not permit + fitting all partitions onto the available disk space. If the partitions do not fit, the highest + numeric partition priority of all defined partitions is determined, and all defined partitions with + this priority are removed from the list of new partitions to create (which may be multiple, if the + same priority is used for multiple partitions). The fitting algorithm is then tried again. If the + partitions still do not fit, the now highest numeric partition priority is determined, and the + matching partitions removed too, and so on. Partitions of a priority of 0 or lower are never + removed. If all partitions with a priority above 0 are removed and the partitions still do not fit on + the device the operation fails. Note that this priority has no effect on ordering partitions, for + that use the alphabetical order of the filenames of the partition definition files. Defaults to + 0. + + + + Weight= + + A numeric weight to assign to this partition in the range 0…1000000. Available disk + space is assigned the defined partitions according to their relative weights (subject to the size + constraints configured with SizeMinBytes=, SizeMaxBytes=), so + that a partition with weight 2000 gets double the space as one with weight 1000, and a partition with + weight 333 a third of that. Defaults to 1000. + + The Weight= setting is used to distribute available disk space in an + "elastic" fashion, based on the disk size and existing partitions. If a partition shall have a fixed + size use both SizeMinBytes= and SizeMaxBytes= with the same + value in order to fixate the size to one value, in which case the weight has no + effect. + + + + PaddingWeight= + + Similar to Weight=, but sets a weight for the free space after the + partition (the "padding"). When distributing available space the weights of all partitions and all + defined padding is summed, and then each partition and padding gets the fraction defined by its + weight. Defaults to 0, i.e. by default no padding is applied. + + Padding is useful if empty space shall be left for later additions or a safety margin at the + end of the device or between partitions. + + + + SizeMinBytes= + SizeMaxBytes= + + Specifies minimum and maximum size constraints in bytes. Takes the usual K, M, G, T, + … suffixes (to the base of 1024). If SizeMinBytes= is specified the partition is + created at or grown to at least the specified size. If SizeMaxBytes= is specified + the partition is created at or grown to at most the specified size. The precise size is determined + through the weight value configured with Weight=, see above. When + SizeMinBytes= is set equal to SizeMaxBytes= the configured + weight has no effect as the partition is explicitly sized to the specified fixed value. Note that + partitions are never created smaller than 4096 bytes, and since partitions are never shrunk the + previous size of the partition (in case the partition already exists) is also enforced as lower bound + for the new size. The values should be specified as multiples of 4096 bytes, and are rounded upwards + (in case of SizeMinBytes=) or downwards (in case of + SizeMaxBytes=) otherwise. If the backing device does not provide enough space to + fulfill the constraints placing the partition will fail. For partitions that shall be created, + depending on the setting of Priority= (see above) the partition might be dropped + and the placing algorithm restarted. By default a minimum size constraint of 10M and no maximum size + constraint is set. + + + + PaddingMinBytes= + PaddingMaxBytes= + + Specifies minimum and maximum size constraints in bytes for the free space after the + partition (the "padding"). Semantics are similar to SizeMinBytes= and + SizeMaxBytes=, except that unlike partition sizes free space can be shrunk and can + be as small as zero. By default no size constraints on padding are set, so that only + PaddingWeight= determines the size of the padding applied. + + + + CopyBlocks= + + Takes a path to a regular file, block device node or directory, or the special value + auto. If specified and the partition is newly created, the data from the specified + path is written to the newly created partition, on the block level. If a directory is specified, the + backing block device of the file system the directory is on is determined, and the data read directly + from that. This option is useful to efficiently replicate existing file systems onto new partitions + on the block level — for example to build a simple OS installer or an OS image builder. + + If the special value auto is specified, the source to copy from is + automatically picked up from the running system (or the image specified with + — if used). A partition that matches both the configured partition type (as + declared with Type= described above), and the currently mounted directory + appropriate for that partition type is determined. For example, if the partition type is set to + root the partition backing the root directory (/) is used as + source to copy from — if its partition type is set to root as well. If the + declared type is usr the partition backing /usr/ is used as + source to copy blocks from — if its partition type is set to usr too. The logic is + capable of automatically tracking down the backing partitions for encrypted and Verity-enabled + volumes. CopyBlocks=auto is useful for implementing "self-replicating" systems, + i.e. systems that are their own installer. + + The file specified here must have a size that is a multiple of the basic block size 512 and not + be empty. If this option is used, the size allocation algorithm is slightly altered: the partition is + created as least as big as required to fit the data in, i.e. the data size is an additional minimum + size value taken into consideration for the allocation algorithm, similar to and in addition to the + SizeMin= value configured above. + + This option has no effect if the partition it is declared for already exists, i.e. existing + data is never overwritten. Note that the data is copied in before the partition table is updated, + i.e. before the partition actually is persistently created. This provides robustness: it is + guaranteed that the partition either doesn't exist or exists fully populated; it is not possible that + the partition exists but is not or only partially populated. + + This option cannot be combined with Format= or + CopyFiles=. + + + + Format= + + Takes a file system name, such as ext4, btrfs, + xfs, vfat, squashfs, or the special value + swap. If specified and the partition is newly created it is formatted with the + specified file system (or as swap device). The file system UUID and label are automatically derived + from the partition UUID and label. If this option is used, the size allocation algorithm is slightly + altered: the partition is created as least as big as required for the minimal file system of the + specified type (or 4KiB if the minimal size is not known). + + This option has no effect if the partition already exists. + + Similarly to the behaviour of CopyBlocks=, the file system is formatted + before the partition is created, ensuring that the partition only ever exists with a fully + initialized file system. + + This option cannot be combined with CopyBlocks=. + + + + CopyFiles= + + Takes a pair of colon separated absolute file system paths. The first path refers to + a source file or directory on the host, the second path refers to a target in the file system of the + newly created partition and formatted file system. This setting may be used to copy files or + directories from the host into the file system that is created due to the Format= + option. If CopyFiles= is used without Format= specified + explicitly, Format= with a suitable default is implied (currently + ext4, but this may change in the future). This option may be used multiple times + to copy multiple files or directories from host into the newly formatted file system. The colon and + second path may be omitted in which case the source path is also used as the target path (relative to + the root of the newly created file system). If the source path refers to a directory it is copied + recursively. + + This option has no effect if the partition already exists: it cannot be used to copy additional + files into an existing partition, it may only be used to populate a file system created anew. + + The copy operation is executed before the file system is registered in the partition table, + thus ensuring that a file system populated this way only ever exists fully initialized. + + This option cannot be combined with CopyBlocks=. + + When systemd-repart is invoked with the or + command line switches the source paths specified are taken relative to the + specified root directory or disk image root. + + + + MakeDirectories= + + Takes one or more absolute paths, separated by whitespace, each declaring a directory + to create within the new file system. Behaviour is similar to CopyFiles=, but + instead of copying in a set of files this just creates the specified directories with the default + mode of 0755 owned by the root user and group, plus all their parent directories (with the same + ownership and access mode). To configure directories with different ownership or access mode, use + CopyFiles= and specify a source tree to copy containing appropriately + owned/configured directories. This option may be used more than once to create multiple + directories. When CopyFiles= and MakeDirectories= are used + together the former is applied first. If a directory listed already exists no operation is executed + (in particular, the ownership/access mode of the directories is left as is). + + The primary usecase for this option is to create a minimal set of directories that may be + mounted over by other partitions contained in the same disk image. For example, a disk image where + the root file system is formatted at first boot might want to automatically pre-create + /usr/ in it this way, so that the usr partition may + over-mount it. + + Consider using + systemd-tmpfiles8 + with its option to pre-create other, more complex directory hierarchies (as + well as other inodes) with fine-grained control of ownership, access modes and other file + attributes. + + + + Encrypt= + + Takes one of off, key-file, + tpm2 and key-file+tpm2 (alternatively, also accepts a boolean + value, which is mapped to off when false, and key-file when + true). Defaults to off. If not off the partition will be + formatted with a LUKS2 superblock, before the blocks configured with CopyBlocks= + are copied in or the file system configured with Format= is created. + + The LUKS2 UUID is automatically derived from the partition UUID in a stable fashion. If + key-file or key-file+tpm2 is used, a key is added to the LUKS2 + superblock, configurable with the option to + systemd-repart. If tpm2 or key-file+tpm2 is + used, a key is added to the LUKS2 superblock that is enrolled to the local TPM2 chip, as configured + with the and options to + systemd-repart. + + When used this slightly alters the size allocation logic as the implicit, minimal size limits + of Format= and CopyBlocks= are increased by the space necessary + for the LUKS2 superblock (see above). + + This option has no effect if the partition already exists. + + + + Verity= + + Takes one of off, data, + hash or signature. Defaults to off. If set + to off or data, the partition is populated with content as + specified by CopyBlocks= or CopyFiles=. If set to + hash, the partition will be populated with verity hashes from the matching verity + data partition. If set to signature, The partition will be populated with a JSON + object containing a signature of the verity root hash of the matching verity hash partition. + + A matching verity partition is a partition with the same verity match key (as configured with + VerityMatchKey=). + + If not explicitly configured, the data partition's UUID will be set to the first 128 + bits of the verity root hash. Similarly, if not configured, the hash partition's UUID will be set to + the final 128 bits of the verity root hash. The verity root hash itself will be included in the + output of systemd-repart. + + This option has no effect if the partition already exists. + + Usage of this option in combination with Encrypt= is not supported. + + For each unique VerityMatchKey= value, a single verity data partition + (Verity=data) and a single verity hash partition (Verity=hash) + must be defined. + + + + VerityMatchKey= + + Takes a short, user-chosen identifier string. This setting is used to find sibling + verity partitions for the current verity partition. See the description for + Verity=. + + + + FactoryReset= + + Takes a boolean argument. If specified the partition is marked for removal during a + factory reset operation. This functionality is useful to implement schemes where images can be reset + into their original state by removing partitions and creating them anew. Defaults to off. + + + + Flags= + + Configures the 64bit GPT partition flags field to set for the partition when creating + it. This option has no effect if the partition already exists. If not specified the flags values is + set to all zeroes, except for the three bits that can also be configured via + NoAuto=, ReadOnly= and GrowFileSystem=; see + below for details on the defaults for these three flags. Specify the flags value in hexadecimal (by + prefixing it with 0x), binary (prefix 0b) or decimal (no + prefix). + + + + NoAuto= + ReadOnly= + GrowFileSystem= + + Configures the No-Auto, Read-Only and Grow-File-System partition flags (bit 63, 60 + and 59) of the partition table entry, as defined by the Discoverable Partitions Specification. Only + available for partition types supported by the specification. This option is a friendly way to set + bits 63, 60 and 59 of the partition flags value without setting any of the other bits, and may be set + via Flags= too, see above. + + If Flags= is used in conjunction with one or more of + NoAuto=/ReadOnly=/GrowFileSystem= the latter + control the value of the relevant flags, i.e. the high-level settings + NoAuto=/ReadOnly=/GrowFileSystem= override + the relevant bits of the low-level setting Flags=. + + Note that the three flags affect only automatic partition mounting, as implemented by + systemd-gpt-auto-generator8 + or the option of various commands (such as + systemd-nspawn1). It + has no effect on explicit mounts, such as those done via mount8 or + fstab5. + + If both bit 50 and 59 are set for a partition (i.e. the partition is marked both read-only and + marked for file system growing) the latter is typically without effect: the read-only flag takes + precedence in most tools reading these flags, and since growing the file system involves writing to + the partition it is consequently ignored. + + NoAuto= defaults to off. ReadOnly= defaults to on for + Verity partition types, and off for all others. GrowFileSystem= defaults to on for + all partition types that support it, except if the partition is marked read-only (and thus + effectively, defaults to off for Verity partitions). + + + + SplitName= + + Configures the suffix to append to split artifacts when the + option of systemd-repart is used. Simple specifier expansion is supported, see + below. Defaults to %t. To disable split artifact generation for a partition, set + SplitName= to -. + + + + + + Specifiers + + Specifiers may be used in the Label=, CopyBlocks=, + CopyFiles=, MakeDirectories=, SplitName= + settings. The following expansions are understood: + + Specifiers available + + + + + + + Specifier + Meaning + Details + + + + + + + + + + + + + + + + + + + + +
+ + Additionally, for the SplitName= setting, the following specifiers are also + understood: + + Specifiers available + + + + + + + Specifier + Meaning + Details + + + + + %T + Partition Type UUID + The partition type UUID, as configured with Type= + + + %t + Partition Type Identifier + The partition type identifier corresponding to the partition type UUID + + + %U + Partition UUID + The partition UUID, as configured with UUID= + + + %n + Partition Number + The partition number assigned to the partition + + + +
+ + + + Examples + + + Grow the root partition to the full disk size at first boot + + With the following file the root partition is automatically grown to the full disk if possible during boot. + + # /usr/lib/repart.d/50-root.conf +[Partition] +Type=root + + + + + Create a swap and home partition automatically on boot, if missing + + The home partition gets all available disk space while the swap partition gets 1G at most and 64M + at least. We set a priority > 0 on the swap partition to ensure the swap partition is not used if not + enough space is available. For every three bytes assigned to the home partition the swap partition gets + assigned one. + + # /usr/lib/repart.d/60-home.conf +[Partition] +Type=home + + + # /usr/lib/repart.d/70-swap.conf +[Partition] +Type=swap +SizeMinBytes=64M +SizeMaxBytes=1G +Priority=1 +Weight=333 + + + + + Create B partitions in an A/B Verity setup, if missing + + Let's say the vendor intends to update OS images in an A/B setup, i.e. with two root partitions + (and two matching Verity partitions) that shall be used alternatingly during upgrades. To minimize + image sizes the original image is shipped only with one root and one Verity partition (the "A" set), + and the second root and Verity partitions (the "B" set) shall be created on first boot on the free + space on the medium. + + # /usr/lib/repart.d/50-root.conf +[Partition] +Type=root +SizeMinBytes=512M +SizeMaxBytes=512M + + + # /usr/lib/repart.d/60-root-verity.conf +[Partition] +Type=root-verity +SizeMinBytes=64M +SizeMaxBytes=64M + + + The definitions above cover the "A" set of root partition (of a fixed 512M size) and Verity + partition for the root partition (of a fixed 64M size). Let's use symlinks to create the "B" set of + partitions, since after all they shall have the same properties and sizes as the "A" set. + +# ln -s 50-root.conf /usr/lib/repart.d/70-root-b.conf +# ln -s 60-root-verity.conf /usr/lib/repart.d/80-root-verity-b.conf + + + + + Create a data and verity partition from a OS tree + + Assuming we have an OS tree at /var/tmp/os-tree that we want to package in a root partition + together with a matching verity partition, we can do so as follows: + + # 50-root.conf +[Partition] +Type=root +CopyFiles=/var/tmp/os-tree +Verity=data +VerityMatchKey=root + + + # 60-root-verity.conf +[Partition] +Type=root-verity +Verity=hash +VerityMatchKey=root + + + + + + + See Also + + systemd1, + systemd-repart8, + sfdisk8, + systemd-cryptenroll1 + + + + diff --git a/man/resolvectl.xml b/man/resolvectl.xml new file mode 100644 index 0000000..2cb855c --- /dev/null +++ b/man/resolvectl.xml @@ -0,0 +1,581 @@ + + + + + + + + resolvectl + systemd + + + + resolvectl + 1 + + + + resolvectl + resolvconf + Resolve domain names, IPV4 and IPv6 addresses, DNS resource records, and services; introspect and reconfigure the DNS resolver + + + + + resolvectl + OPTIONS + COMMAND + NAME + + + + + Description + + resolvectl may be used to resolve domain names, IPv4 and IPv6 addresses, DNS resource + records and services with the + systemd-resolved.service8 + resolver service. By default, the specified list of parameters will be resolved as hostnames, retrieving their IPv4 + and IPv6 addresses. If the parameters specified are formatted as IPv4 or IPv6 addresses the reverse operation is + done, and a hostname is retrieved for the specified addresses. + + The program's output contains information about the protocol used for the look-up and on which network + interface the data was discovered. It also contains information on whether the information could be + authenticated. All data for which local DNSSEC validation succeeds is considered authenticated. Moreover all data + originating from local, trusted sources is also reported authenticated, including resolution of the local host + name, the localhost hostname or all data from /etc/hosts. + + + + Commands + + + + query HOSTNAME|ADDRESS… + + Resolve domain names, as well as IPv4 and IPv6 addresses. When used in conjunction + with or (see below), resolves low-level DNS + resource records. + + If a single-label domain name is specified it is searched for according to the configured + search domains — unless or + / are specified, both of which turn this logic + off. + + If an international domain name is specified, it is automatically translated according to IDNA + rules when resolved via classic DNS — but not for look-ups via MulticastDNS or LLMNR. If + / is used IDNA translation is turned off and domain + names are processed as specified. + + + + service + [[NAME] TYPE] + DOMAIN + + Resolve DNS-SD and SRV services, depending on the specified list of + parameters. If three parameters are passed the first is assumed to be the DNS-SD service name, the + second the SRV service type, and the third the domain to search in. + In this case a full DNS-SD style SRV and TXT lookup is executed. If only two parameters are specified, the first is + assumed to be the SRV service type, and the second the domain to look + in. In this case no TXT resource record is requested. Finally, if + only one parameter is specified, it is assumed to be a domain name, that is already prefixed with an + SRV type, and an SRV lookup is done + (no TXT). + + + + openpgp EMAIL@DOMAIN… + + Query PGP keys stored as OPENPGPKEY resource records, + see RFC 7929. Specified e-mail addresses + are converted to the corresponding DNS domain name, and any OPENPGPKEY + keys are printed. + + + + tlsa + [FAMILY] + DOMAIN[:PORT]… + + Query TLS public keys stored as TLSA resource + records, see RFC 6698. A query will be + performed for each of the specified names prefixed with the port and family + (_port._family.domain). + The port number may be specified after a colon (:), otherwise + 443 will be used by default. The family may be specified as the first argument, + otherwise tcp will be used. + + + + status [LINK…] + + Shows the global and per-link DNS settings currently in effect. If no command is specified, + this is the implied default. + + + + statistics + + Shows general resolver statistics, including information whether DNSSEC is + enabled and available, as well as resolution and validation statistics. + + + + reset-statistics + + Resets the statistics counters shown in statistics to zero. + This operation requires root privileges. + + + + flush-caches + + Flushes all DNS resource record caches the service maintains locally. This is mostly + equivalent to sending the SIGUSR2 to the systemd-resolved + service. + + + + reset-server-features + + Flushes all feature level information the resolver learnt about specific servers, and ensures + that the server feature probing logic is started from the beginning with the next look-up request. This is + mostly equivalent to sending the SIGRTMIN+1 to the systemd-resolved + service. + + + + dns [LINK [SERVER…]] + domain [LINK [DOMAIN…]] + default-route [LINK [BOOL…]] + llmnr [LINK [MODE]] + mdns [LINK [MODE]] + dnssec [LINK [MODE]] + dnsovertls [LINK [MODE]] + nta [LINK [DOMAIN…]] + + + Get/set per-interface DNS configuration. These commands may be used to configure various DNS + settings for network interfaces. These commands may be used to inform + systemd-resolved or systemd-networkd about per-interface DNS + configuration determined through external means. The dns command expects IPv4 or + IPv6 address specifications of DNS servers to use. Each address can optionally take a port number + separated with :, a network interface name or index separated with + %, and a Server Name Indication (SNI) separated with #. When + IPv6 address is specified with a port number, then the address must be in the square brackets. That + is, the acceptable full formats are 111.222.333.444:9953%ifname#example.com for + IPv4 and [1111:2222::3333]:9953%ifname#example.com for IPv6. The + domain command expects valid DNS domains, possibly prefixed with + ~, and configures a per-interface search or route-only domain. The + default-route command expects a boolean parameter, and configures whether the + link may be used as default route for DNS lookups, i.e. if it is suitable for lookups on domains no + other link explicitly is configured for. The llmnr, mdns, + dnssec and dnsovertls commands may be used to configure the + per-interface LLMNR, MulticastDNS, DNSSEC and DNSOverTLS settings. Finally, nta + command may be used to configure additional per-interface DNSSEC NTA domains. + + Commands dns, domain and nta can take + a single empty string argument to clear their respective value lists. + + For details about these settings, their possible values and their effect, see the + corresponding settings in + systemd.network5. + + + + + revert LINK + + Revert the per-interface DNS configuration. If the DNS configuration is reverted all + per-interface DNS setting are reset to their defaults, undoing all effects of dns, + domain, default-route, llmnr, + mdns, dnssec, dnsovertls, + nta. Note that when a network interface disappears all configuration is lost + automatically, an explicit reverting is not necessary in that case. + + + + monitor + + Show a continuous stream of local client resolution queries and their + responses. Whenever a local query is completed the query's DNS resource lookup key and resource + records are shown. Note that this displays queries issued locally only, and does not immediately + relate to DNS requests submitted to configured DNS servers or the LLMNR or MulticastDNS zones, as + lookups may be answered from the local cache, or might result in multiple DNS transactions (for + example to validate DNSSEC information). If CNAME/CNAME redirection chains are followed, a separate + query will be displayed for each element of the chain. Use to enable JSON + output. + + + + + + + + Options + + + + + + By default, when resolving a hostname, both IPv4 and IPv6 + addresses are acquired. By specifying only IPv4 addresses are requested, by specifying + only IPv6 addresses are requested. + + + + + INTERFACE + INTERFACE + + Specifies the network interface to execute the query on. This may either be specified as numeric + interface index or as network interface string (e.g. en0). Note that this option has no + effect if system-wide DNS configuration (as configured in /etc/resolv.conf or + /etc/systemd/resolved.conf) in place of per-link configuration is used. + + + + PROTOCOL + PROTOCOL + + Specifies the network protocol for the query. May be one of dns + (i.e. classic unicast DNS), llmnr (Link-Local Multicast Name Resolution), + llmnr-ipv4, llmnr-ipv6 (LLMNR via the indicated underlying IP + protocols), mdns (Multicast DNS), + mdns-ipv4, mdns-ipv6 (MDNS via the indicated underlying IP protocols). + By default the lookup is done via all protocols suitable for the lookup. If used, limits the set of + protocols that may be used. Use this option multiple times to enable resolving via multiple protocols at the + same time. The setting llmnr is identical to specifying this switch once with + llmnr-ipv4 and once via llmnr-ipv6. Note that this option does not force + the service to resolve the operation with the specified protocol, as that might require a suitable network + interface and configuration. + The special value help may be used to list known values. + + + + + TYPE + TYPE + CLASS + CLASS + + When used in conjunction with the query command, specifies the DNS + resource record type (e.g. A, AAAA, + MX, …) and class (e.g. IN, + ANY, …) to look up. If these options are used a DNS resource record set matching + the specified class and type is requested. The class defaults to IN if only a + type is specified. The special value help may be used to list known values. + + Without these options resolvectl query provides high-level domain name to + address and address to domain name resolution. With these options it provides low-level DNS resource + record resolution. The search domain logic is automatically turned off when these options are used, + i.e. specified domain names need to be fully qualified domain names. Moreover, IDNA internal domain + name translation is turned off as well, i.e. international domain names should be specified in + xn--… notation, unless look-up in MulticastDNS/LLMNR is desired, in which case + UTF-8 characters should be used. + + + + BOOL + + Takes a boolean parameter. If true (the default), when doing a service lookup with + the hostnames contained in the SRV + resource records are resolved as well. + + + + BOOL + + Takes a boolean parameter. If true (the default), when doing a DNS-SD service lookup + with the TXT service metadata record is + resolved as well. + + + + BOOL + + Takes a boolean parameter. If true (the default), DNS CNAME or DNAME redirections are + followed. Otherwise, if a CNAME or DNAME record is encountered while resolving, an error is + returned. + + + + BOOL + + Takes a boolean parameter; used in conjunction with query. If true + (the default), DNSSEC validation is applied as usual — under the condition that it is enabled for the + network and for systemd-resolved.service as a whole. If false, DNSSEC validation + is disabled for the specific query, regardless of whether it is enabled for the network or in the + service. Note that setting this option to true does not force DNSSEC validation on systems/networks + where DNSSEC is turned off. This option is only suitable to turn off such validation where otherwise + enabled, not enable validation where otherwise disabled. + + + + BOOL + + Takes a boolean parameter; used in conjunction with query. If true + (the default), select domains are resolved on the local system, among them + localhost, _gateway and _outbound, or + entries from /etc/hosts. If false these domains are not resolved locally, and + either fail (in case of localhost, _gateway or + _outbound and suchlike) or go to the network via regular DNS/mDNS/LLMNR lookups + (in case of /etc/hosts entries). + + + + BOOL + + Takes a boolean parameter; used in conjunction with query. If true + (the default), lookups use the local DNS resource record cache. If false, lookups are routed to the + network instead, regardless if already available in the local cache. + + + + BOOL + + Takes a boolean parameter; used in conjunction with query. If true + (the default), lookups are answered from locally registered LLMNR or mDNS resource records, if + defined. If false, locally registered LLMNR/mDNS records are not considered for the lookup + request. + + + + BOOL + + Takes a boolean parameter; used in conjunction with query. If true + (the default), lookups for DS and DNSKEY are answered from the local DNSSEC trust anchors if + possible. If false, the local trust store is not considered for the lookup request. + + + + BOOL + + Takes a boolean parameter; used in conjunction with query. If true + (the default), lookups are answered via DNS, LLMNR or mDNS network requests if they cannot be + synthesized locally, or be answered from the local cache, zone or trust anchors (see above). If false, + the request is not answered from the network and will thus fail if none of the indicated sources can + answer them. + + + + BOOL + + Takes a boolean parameter. If true (the default), any specified single-label + hostnames will be searched in the domains configured in the search domain list, if it is + non-empty. Otherwise, the search domain logic is disabled. Note that this option has no effect if + is used (see above), in which case the search domain logic is + unconditionally turned off. + + + + =payload|packet + + Dump the answer as binary data. If there is no argument or if the argument is + payload, the payload of the packet is exported. If the argument is + packet, the whole packet is dumped in wire format, prefixed by + length specified as a little-endian 64-bit number. This format allows multiple packets + to be dumped and unambiguously parsed. + + + + BOOL + + Takes a boolean parameter. If true (the default), column headers and meta information about the + query response are shown. Otherwise, this output is suppressed. + + + + + + + + Short for + + + + + + + + + + Compatibility with + <citerefentry project="debian"><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + resolvectl is a multi-call binary. When invoked as resolvconf + (generally achieved by means of a symbolic link of this name to the resolvectl binary) it + is run in a limited + resolvconf8 + compatibility mode. It accepts mostly the same arguments and pushes all data into + systemd-resolved.service8, + similar to how and commands operate. Note that + systemd-resolved.service is the only supported backend, which is different from other + implementations of this command. + + /etc/resolv.conf will only be updated with servers added with this command + when /etc/resolv.conf is a symlink to + /run/systemd/resolve/resolv.conf, and not a static file. See the discussion of + /etc/resolv.conf handling in + systemd-resolved.service8. + + + Not all operations supported by other implementations are supported natively. Specifically: + + + + + Registers per-interface DNS configuration data with + systemd-resolved. Expects a network interface name as only command line argument. Reads + resolv.conf5-compatible + DNS configuration data from its standard input. Relevant fields are nameserver and + domain/search. This command is mostly identical to invoking + resolvectl with a combination of and + commands. + + + + + Unregisters per-interface DNS configuration data with systemd-resolved. This + command is mostly identical to invoking resolvectl revert. + + + + + + When specified and will not complain about missing + network interfaces and will silently execute no operation in that case. + + + + + + This switch for "exclusive" operation is supported only partially. It is mapped to an + additional configured search domain of ~. — i.e. ensures that DNS traffic is preferably + routed to the DNS servers on this interface, unless there are other, more specific domains configured on other + interfaces. + + + + + + + These switches are not supported and are silently ignored. + + + + + + + + + + + + + + + + These switches are not supported and the command will fail if used. + + + + + See + resolvconf8 + for details on those command line options. + + + + Examples + + + Retrieve the addresses of the <literal>www.0pointer.net</literal> domain (<constant class='dns'>A</constant> and <constant class='dns'>AAAA</constant> resource records) + + $ resolvectl query www.0pointer.net +www.0pointer.net: 2a01:238:43ed:c300:10c3:bcf3:3266:da74 + 85.214.157.71 + +-- Information acquired via protocol DNS in 611.6ms. +-- Data is authenticated: no + + + + + Retrieve the domain of the <literal>85.214.157.71</literal> IP address + (<constant class='dns'>PTR</constant> resource record) + + $ resolvectl query 85.214.157.71 +85.214.157.71: gardel.0pointer.net + +-- Information acquired via protocol DNS in 1.2997s. +-- Data is authenticated: no + + + + + Retrieve the <constant class='dns'>MX</constant> record of the <literal>yahoo.com</literal> + domain + + $ resolvectl --legend=no -t MX query yahoo.com +yahoo.com. IN MX 1 mta7.am0.yahoodns.net +yahoo.com. IN MX 1 mta6.am0.yahoodns.net +yahoo.com. IN MX 1 mta5.am0.yahoodns.net + + + + + Resolve an <constant class='dns'>SRV</constant> service + + $ resolvectl service _xmpp-server._tcp gmail.com +_xmpp-server._tcp/gmail.com: alt1.xmpp-server.l.google.com:5269 [priority=20, weight=0] + 173.194.210.125 + alt4.xmpp-server.l.google.com:5269 [priority=20, weight=0] + 173.194.65.125 + … + + + + + Retrieve a PGP key (<constant class='dns'>OPENPGP</constant> resource record) + + $ resolvectl openpgp zbyszek@fedoraproject.org +d08ee310438ca124a6149ea5cc21b6313b390dce485576eff96f8722._openpgpkey.fedoraproject.org. IN OPENPGPKEY + mQINBFBHPMsBEACeInGYJCb+7TurKfb6wGyTottCDtiSJB310i37/6ZYoeIay/5soJjlMyf + MFQ9T2XNT/0LM6gTa0MpC1st9LnzYTMsT6tzRly1D1UbVI6xw0g0vE5y2Cjk3xUwAynCsSs + … + + + + + Retrieve a TLS key (<constant class='dns'>TLSA</constant> resource record) + + $ resolvectl tlsa tcp fedoraproject.org:443 +_443._tcp.fedoraproject.org IN TLSA 0 0 1 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0 + -- Cert. usage: CA constraint + -- Selector: Full Certificate + -- Matching type: SHA-256 + + + tcp and :443 are optional and could be skipped. + + + + + See Also + + systemd1, + systemd-resolved.service8, + systemd.dnssd5, + systemd-networkd.service8, + resolvconf8 + + + diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml new file mode 100644 index 0000000..2b9f482 --- /dev/null +++ b/man/resolved.conf.xml @@ -0,0 +1,352 @@ + + +%entities; +]> + + + + + resolved.conf + systemd + + + + resolved.conf + 5 + + + + resolved.conf + resolved.conf.d + Network Name Resolution configuration files + + + + /etc/systemd/resolved.conf + /etc/systemd/resolved.conf.d/*.conf + /run/systemd/resolved.conf.d/*.conf + /usr/lib/systemd/resolved.conf.d/*.conf + + + + Description + + These configuration files control local DNS and LLMNR + name resolution. + + + + + + + Options + + The following options are available in the [Resolve] section: + + + + + DNS= + A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. Each address can + optionally take a port number separated with :, a network interface name or index separated with + %, and a Server Name Indication (SNI) separated with #. When IPv6 address is + specified with a port number, then the address must be in the square brackets. That is, the acceptable full formats + are 111.222.333.444:9953%ifname#example.com for IPv4 and + [1111:2222::3333]:9953%ifname#example.com for IPv6. DNS requests are sent to one of the listed + DNS servers in parallel to suitable per-link DNS servers acquired from + systemd-networkd.service8 or + set at runtime by external applications. For compatibility reasons, if this setting is not specified, the DNS + servers listed in /etc/resolv.conf are used instead, if that file exists and any servers + are configured in it. This setting defaults to the empty list. + + + + FallbackDNS= + A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Please see + DNS= for acceptable format of addresses. Any per-link DNS servers obtained from + systemd-networkd.service8 + take precedence over this setting, as do any servers set via DNS= above or + /etc/resolv.conf. This setting is hence only used if no other DNS server information is + known. If this option is not given, a compiled-in list of DNS servers is used instead. + + + + Domains= + A space-separated list of domains, optionally prefixed with ~, + used for two distinct purposes described below. Defaults to the empty list. + + Any domains not prefixed with ~ are used as search + suffixes when resolving single-label hostnames (domain names which contain no dot), in order to + qualify them into fully-qualified domain names (FQDNs). These "search domains" are strictly processed + in the order they are specified in, until the name with the suffix appended is found. For + compatibility reasons, if this setting is not specified, the search domains listed in + /etc/resolv.conf with the search keyword are used instead, if + that file exists and any domains are configured in it. + + The domains prefixed with ~ are called "route-only domains". All domains + listed here (both search domains and route-only domains after removing the + ~ prefix) define a search path that preferably directs DNS queries to this + interface. This search path has an effect only when suitable per-link DNS servers are known. Such + servers may be defined through the DNS= setting (see above) and dynamically at run + time, for example from DHCP leases. If no per-link DNS servers are known, route-only domains have no + effect. + + Use the construct ~. (which is composed from ~ to + indicate a route-only domain and . to indicate the DNS root domain that is the + implied suffix of all DNS domains) to use the DNS servers defined for this link preferably for all + domains. + + See "Protocols and Routing" in + systemd-resolved.service8 + for details of how search and route-only domains are used. + + + + + LLMNR= + Takes a boolean argument or + resolve. Controls Link-Local Multicast Name + Resolution support (RFC 4795) on + the local host. If true, enables full LLMNR responder and + resolver support. If false, disables both. If set to + resolve, only resolution support is enabled, + but responding is disabled. Note that + systemd-networkd.service8 + also maintains per-link LLMNR settings. LLMNR will be + enabled on a link only if the per-link and the + global setting is on. + + + + MulticastDNS= + Takes a boolean argument or + resolve. Controls Multicast DNS support (RFC 6762) on + the local host. If true, enables full Multicast DNS responder and + resolver support. If false, disables both. If set to + resolve, only resolution support is enabled, + but responding is disabled. Note that + systemd-networkd.service8 + also maintains per-link Multicast DNS settings. Multicast DNS will be + enabled on a link only if the per-link and the + global setting is on. + + + + DNSSEC= + Takes a boolean argument or + allow-downgrade. If true all DNS lookups are + DNSSEC-validated locally (excluding LLMNR and Multicast + DNS). If the response to a lookup request is detected to be invalid + a lookup failure is returned to applications. Note that + this mode requires a DNS server that supports DNSSEC. If the + DNS server does not properly support DNSSEC all validations + will fail. If set to allow-downgrade DNSSEC + validation is attempted, but if the server does not support + DNSSEC properly, DNSSEC mode is automatically disabled. Note + that this mode makes DNSSEC validation vulnerable to + "downgrade" attacks, where an attacker might be able to + trigger a downgrade to non-DNSSEC mode by synthesizing a DNS + response that suggests DNSSEC was not supported. If set to + false, DNS lookups are not DNSSEC validated. + + Note that DNSSEC validation requires retrieval of + additional DNS data, and thus results in a small DNS look-up + time penalty. + + DNSSEC requires knowledge of "trust anchors" to prove + data integrity. The trust anchor for the Internet root domain + is built into the resolver, additional trust anchors may be + defined with + dnssec-trust-anchors.d5. + Trust anchors may change at regular intervals, and old trust + anchors may be revoked. In such a case DNSSEC validation is + not possible until new trust anchors are configured locally or + the resolver software package is updated with the new root + trust anchor. In effect, when the built-in trust anchor is + revoked and DNSSEC= is true, all further + lookups will fail, as it cannot be proved anymore whether + lookups are correctly signed, or validly unsigned. If + DNSSEC= is set to + allow-downgrade the resolver will + automatically turn off DNSSEC validation in such a case. + + Client programs looking up DNS data will be informed + whether lookups could be verified using DNSSEC, or whether the + returned data could not be verified (either because the data + was found unsigned in the DNS, or the DNS server did not + support DNSSEC or no appropriate trust anchors were known). In + the latter case it is assumed that client programs employ a + secondary scheme to validate the returned DNS data, should + this be required. + + It is recommended to set DNSSEC= to + true on systems where it is known that the DNS server supports + DNSSEC correctly, and where software or trust anchor updates + happen regularly. On other systems it is recommended to set + DNSSEC= to + allow-downgrade. + + In addition to this global DNSSEC setting + systemd-networkd.service8 + also maintains per-link DNSSEC settings. For system DNS + servers (see above), only the global DNSSEC setting is in + effect. For per-link DNS servers the per-link + setting is in effect, unless it is unset in which case the + global setting is used instead. + + Site-private DNS zones generally conflict with DNSSEC + operation, unless a negative (if the private zone is not + signed) or positive (if the private zone is signed) trust + anchor is configured for them. If + allow-downgrade mode is selected, it is + attempted to detect site-private DNS zones using top-level + domains (TLDs) that are not known by the DNS root server. This + logic does not work in all private zone setups. + + Defaults to &DEFAULT_DNSSEC_MODE;. + + + + + DNSOverTLS= + + Takes a boolean argument or opportunistic. If + true all connections to the server will be encrypted. Note that this + mode requires a DNS server that supports DNS-over-TLS and has a valid + certificate. If the hostname was specified in DNS= + by using the format address#server_name it + is used to validate its certificate and also to enable Server Name + Indication (SNI) when opening a TLS connection. Otherwise + the certificate is checked against the server's IP. + If the DNS server does not support DNS-over-TLS all DNS requests will fail. + + When set to opportunistic + DNS request are attempted to send encrypted with DNS-over-TLS. + If the DNS server does not support TLS, DNS-over-TLS is disabled. + Note that this mode makes DNS-over-TLS vulnerable to "downgrade" + attacks, where an attacker might be able to trigger a downgrade + to non-encrypted mode by synthesizing a response that suggests + DNS-over-TLS was not supported. If set to false, DNS lookups + are send over UDP. + + Note that DNS-over-TLS requires additional data to be + send for setting up an encrypted connection, and thus results + in a small DNS look-up time penalty. + + Note that in opportunistic mode the + resolver is not capable of authenticating the server, so it is + vulnerable to "man-in-the-middle" attacks. + + In addition to this global DNSOverTLS= setting + systemd-networkd.service8 + also maintains per-link DNSOverTLS= settings. For system DNS servers (see above), only the global + DNSOverTLS= setting is in effect. For per-link DNS servers the per-link setting is in effect, unless + it is unset in which case the global setting is used instead. + + Defaults to &DEFAULT_DNS_OVER_TLS_MODE;. + + + + + Cache= + Takes a boolean or no-negative as argument. If + yes (the default), resolving a domain name which already got queried earlier will + return the previous result as long as it is still valid, and thus does not result in a new network + request. Be aware that turning off caching comes at a performance penalty, which is particularly high + when DNSSEC is used. If no-negative, only positive answers are cached. + + Note that caching is turned off by default for host-local DNS servers. + See CacheFromLocalhost= for details. + + + + CacheFromLocalhost= + Takes a boolean as argument. If no (the default), and response cames from + host-local IP address (such as 127.0.0.1 or ::1), the result wouldn't be cached in order to avoid + potential duplicate local caching. + + + + + DNSStubListener= + Takes a boolean argument or one of udp and + tcp. If udp, a DNS stub resolver will listen for UDP requests + on addresses 127.0.0.53 and 127.0.0.54, port 53. If tcp, the stub will listen for + TCP requests on the same addresses and port. If yes (the default), the stub listens + for both UDP and TCP requests. If no, the stub listener is disabled. + + + + Note that the DNS stub listener is turned off implicitly when its listening address and port are already + in use. + + + + DNSStubListenerExtra= + Takes an IPv4 or IPv6 address to listen on. The address may be optionally + prefixed with a protocol name (udp or tcp) separated with + :. If the protocol is not specified, the service will listen on both UDP and + TCP. It may be also optionally suffixed by a numeric port number with separator + :. When an IPv6 address is specified with a port number, then the address + must be in the square brackets. If the port is not specified, then the service uses port 53. + Note that this is independent of the primary DNS stub configured with + DNSStubListener=, and only configures additional + sockets to listen on. This option can be specified multiple times. If an empty string is + assigned, then the all previous assignments are cleared. Defaults to unset. + + Examples: + DNSStubListenerExtra=192.168.10.10 +DNSStubListenerExtra=2001:db8:0:f102::10 +DNSStubListenerExtra=192.168.10.11:9953 +DNSStubListenerExtra=[2001:db8:0:f102::11]:9953 +DNSStubListenerExtra=tcp:192.168.10.12 +DNSStubListenerExtra=udp:2001:db8:0:f102::12 +DNSStubListenerExtra=tcp:192.168.10.13:9953 +DNSStubListenerExtra=udp:[2001:db8:0:f102::13]:9953 + + + + + ReadEtcHosts= + Takes a boolean argument. If yes (the default), + systemd-resolved will read /etc/hosts, and try to resolve + hosts or address by using the entries in the file before sending query to DNS servers. + + + + + ResolveUnicastSingleLabel= + Takes a boolean argument. When false (the default), + systemd-resolved will not resolve A and AAAA queries for single-label names over + classic DNS. Note that such names may still be resolved if search domains are specified (see + Domains= above), or using other mechanisms, in particular via LLMNR or from + /etc/hosts. When true, queries for single-label names will be forwarded to + global DNS servers even if no search domains are defined. + + + This option is provided for compatibility with configurations where public DNS + servers are not used. Forwarding single-label names to servers not under your control is + not standard-conformant, see IAB + Statement, and may create a privacy and security risk. + + + + + + See Also + + systemd1, + systemd-resolved.service8, + systemd-networkd.service8, + dnssec-trust-anchors.d5, + resolv.conf5 + + + + diff --git a/man/rules/meson.build b/man/rules/meson.build new file mode 100644 index 0000000..4819b15 --- /dev/null +++ b/man/rules/meson.build @@ -0,0 +1,1201 @@ +# SPDX-License-Identifier: LGPL-2.1-or-later + +# Do not edit. Generated by update-man-rules.py. +# Update with: +# ninja -C build update-man-rules +manpages = [ +['binfmt.d', '5', [], 'ENABLE_BINFMT'], + ['bootctl', '1', [], 'HAVE_GNU_EFI'], + ['bootup', '7', [], ''], + ['busctl', '1', [], ''], + ['coredump.conf', '5', ['coredump.conf.d'], 'ENABLE_COREDUMP'], + ['coredumpctl', '1', [], 'ENABLE_COREDUMP'], + ['crypttab', '5', [], 'HAVE_LIBCRYPTSETUP'], + ['daemon', '7', [], ''], + ['dnssec-trust-anchors.d', + '5', + ['systemd.negative', 'systemd.positive'], + 'ENABLE_RESOLVE'], + ['environment.d', '5', [], 'ENABLE_ENVIRONMENT_D'], + ['file-hierarchy', '7', [], ''], + ['halt', '8', ['poweroff', 'reboot'], ''], + ['homectl', '1', [], 'ENABLE_HOMED'], + ['homed.conf', '5', ['homed.conf.d'], 'ENABLE_HOMED'], + ['hostname', '5', [], ''], + ['hostnamectl', '1', [], 'ENABLE_HOSTNAMED'], + ['hwdb', '7', [], 'ENABLE_HWDB'], + ['integritytab', '5', [], 'HAVE_LIBCRYPTSETUP'], + ['journal-remote.conf', '5', ['journal-remote.conf.d'], 'HAVE_MICROHTTPD'], + ['journal-upload.conf', '5', ['journal-upload.conf.d'], 'HAVE_MICROHTTPD'], + ['journalctl', '1', [], ''], + ['journald.conf', '5', ['journald.conf.d', 'journald@.conf'], ''], + ['kernel-command-line', '7', [], ''], + ['kernel-install', '8', [], 'ENABLE_KERNEL_INSTALL'], + ['libudev', '3', [], ''], + ['loader.conf', '5', [], 'HAVE_GNU_EFI'], + ['locale.conf', '5', [], ''], + ['localectl', '1', [], 'ENABLE_LOCALED'], + ['localtime', '5', [], ''], + ['loginctl', '1', [], 'ENABLE_LOGIND'], + ['logind.conf', '5', ['logind.conf.d'], 'ENABLE_LOGIND'], + ['machine-id', '5', [], ''], + ['machine-info', '5', [], ''], + ['machinectl', '1', [], 'ENABLE_MACHINED'], + ['modules-load.d', '5', [], 'HAVE_KMOD'], + ['networkctl', '1', [], 'ENABLE_NETWORKD'], + ['networkd.conf', '5', ['networkd.conf.d'], 'ENABLE_NETWORKD'], + ['nss-myhostname', '8', ['libnss_myhostname.so.2'], 'ENABLE_NSS_MYHOSTNAME'], + ['nss-mymachines', '8', ['libnss_mymachines.so.2'], 'ENABLE_NSS_MYMACHINES'], + ['nss-resolve', '8', ['libnss_resolve.so.2'], 'ENABLE_NSS_RESOLVE'], + ['nss-systemd', '8', ['libnss_systemd.so.2'], 'ENABLE_NSS_SYSTEMD'], + ['oomctl', '1', [], 'ENABLE_OOMD'], + ['oomd.conf', '5', ['oomd.conf.d'], 'ENABLE_OOMD'], + ['org.freedesktop.LogControl1', '5', [], ''], + ['org.freedesktop.home1', '5', [], 'ENABLE_HOMED'], + ['org.freedesktop.hostname1', '5', [], 'ENABLE_HOSTNAMED'], + ['org.freedesktop.import1', '5', [], 'ENABLE_IMPORTD'], + ['org.freedesktop.locale1', '5', [], 'ENABLE_LOCALED'], + ['org.freedesktop.login1', '5', [], 'ENABLE_LOGIND'], + ['org.freedesktop.machine1', '5', [], 'ENABLE_MACHINED'], + ['org.freedesktop.network1', '5', [], 'ENABLE_NETWORKD'], + ['org.freedesktop.oom1', '5', [], 'ENABLE_OOMD'], + ['org.freedesktop.portable1', '5', [], 'ENABLE_PORTABLED'], + ['org.freedesktop.resolve1', '5', [], 'ENABLE_RESOLVE'], + ['org.freedesktop.systemd1', '5', [], ''], + ['org.freedesktop.timedate1', '5', [], 'ENABLE_TIMEDATED'], + ['os-release', '5', ['extension-release', 'initrd-release'], ''], + ['pam_systemd', '8', [], 'HAVE_PAM'], + ['pam_systemd_home', '8', [], 'ENABLE_PAM_HOME'], + ['portablectl', '1', [], 'ENABLE_PORTABLED'], + ['pstore.conf', '5', ['pstore.conf.d'], 'ENABLE_PSTORE'], + ['repart.d', '5', [], 'ENABLE_REPART'], + ['resolvectl', '1', ['resolvconf'], 'ENABLE_RESOLVE'], + ['resolved.conf', '5', ['resolved.conf.d'], 'ENABLE_RESOLVE'], + ['runlevel', '8', [], 'HAVE_SYSV_COMPAT'], + ['sd-bus-errors', + '3', + ['SD_BUS_ERROR_ACCESS_DENIED', + 'SD_BUS_ERROR_ADDRESS_IN_USE', + 'SD_BUS_ERROR_AUTH_FAILED', + 'SD_BUS_ERROR_BAD_ADDRESS', + 'SD_BUS_ERROR_DISCONNECTED', + 'SD_BUS_ERROR_FAILED', + 'SD_BUS_ERROR_FILE_EXISTS', + 'SD_BUS_ERROR_FILE_NOT_FOUND', + 'SD_BUS_ERROR_INCONSISTENT_MESSAGE', + 'SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED', + 'SD_BUS_ERROR_INVALID_ARGS', + 'SD_BUS_ERROR_INVALID_SIGNATURE', + 'SD_BUS_ERROR_IO_ERROR', + 'SD_BUS_ERROR_LIMITS_EXCEEDED', + 'SD_BUS_ERROR_MATCH_RULE_INVALID', + 'SD_BUS_ERROR_MATCH_RULE_NOT_FOUND', + 'SD_BUS_ERROR_NAME_HAS_NO_OWNER', + 'SD_BUS_ERROR_NOT_SUPPORTED', + 'SD_BUS_ERROR_NO_MEMORY', + 'SD_BUS_ERROR_NO_NETWORK', + 'SD_BUS_ERROR_NO_REPLY', + 'SD_BUS_ERROR_NO_SERVER', + 'SD_BUS_ERROR_PROPERTY_READ_ONLY', + 'SD_BUS_ERROR_SERVICE_UNKNOWN', + 'SD_BUS_ERROR_TIMEOUT', + 'SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN', + 'SD_BUS_ERROR_UNKNOWN_INTERFACE', + 'SD_BUS_ERROR_UNKNOWN_METHOD', + 'SD_BUS_ERROR_UNKNOWN_OBJECT', + 'SD_BUS_ERROR_UNKNOWN_PROPERTY'], + ''], + ['sd-bus', '3', [], ''], + ['sd-daemon', + '3', + ['SD_ALERT', + 'SD_CRIT', + 'SD_DEBUG', + 'SD_EMERG', + 'SD_ERR', + 'SD_INFO', + 'SD_NOTICE', + 'SD_WARNING'], + ''], + ['sd-device', '3', [], ''], + ['sd-event', '3', [], ''], + ['sd-hwdb', '3', [], ''], + ['sd-id128', + '3', + ['SD_ID128_ALLF', + 'SD_ID128_CONST_STR', + 'SD_ID128_FORMAT_STR', + 'SD_ID128_FORMAT_VAL', + 'SD_ID128_MAKE', + 'SD_ID128_MAKE_STR', + 'SD_ID128_MAKE_UUID_STR', + 'SD_ID128_NULL', + 'SD_ID128_UUID_FORMAT_STR', + 'sd_id128_equal', + 'sd_id128_in_set', + 'sd_id128_in_set_sentinel', + 'sd_id128_in_setv', + 'sd_id128_is_allf', + 'sd_id128_is_null', + 'sd_id128_string_equal', + 'sd_id128_t'], + ''], + ['sd-journal', '3', [], ''], + ['sd-login', '3', [], 'HAVE_PAM'], + ['sd_booted', '3', [], ''], + ['sd_bus_add_match', + '3', + ['sd_bus_add_match_async', + 'sd_bus_match_signal', + 'sd_bus_match_signal_async'], + ''], + ['sd_bus_add_node_enumerator', '3', [], ''], + ['sd_bus_add_object', + '3', + ['SD_BUS_METHOD', + 'SD_BUS_METHOD_WITH_NAMES', + 'SD_BUS_METHOD_WITH_NAMES_OFFSET', + 'SD_BUS_METHOD_WITH_OFFSET', + 'SD_BUS_PARAM', + 'SD_BUS_PROPERTY', + 'SD_BUS_SIGNAL', + 'SD_BUS_SIGNAL_WITH_NAMES', + 'SD_BUS_VTABLE_CAPABILITY', + 'SD_BUS_VTABLE_END', + 'SD_BUS_VTABLE_START', + 'SD_BUS_WRITABLE_PROPERTY', + 'sd_bus_add_fallback', + 'sd_bus_add_fallback_vtable', + 'sd_bus_add_filter', + 'sd_bus_add_object_vtable'], + ''], + ['sd_bus_add_object_manager', '3', [], ''], + ['sd_bus_attach_event', '3', ['sd_bus_detach_event', 'sd_bus_get_event'], ''], + ['sd_bus_call', '3', ['sd_bus_call_async'], ''], + ['sd_bus_call_method', + '3', + ['sd_bus_call_method_async', + 'sd_bus_call_method_asyncv', + 'sd_bus_call_methodv'], + ''], + ['sd_bus_can_send', '3', [], ''], + ['sd_bus_close', '3', ['sd_bus_default_flush_close', 'sd_bus_flush'], ''], + ['sd_bus_creds_get_pid', + '3', + ['sd_bus_creds_get_audit_login_uid', + 'sd_bus_creds_get_audit_session_id', + 'sd_bus_creds_get_cgroup', + 'sd_bus_creds_get_cmdline', + 'sd_bus_creds_get_comm', + 'sd_bus_creds_get_description', + 'sd_bus_creds_get_egid', + 'sd_bus_creds_get_euid', + 'sd_bus_creds_get_exe', + 'sd_bus_creds_get_fsgid', + 'sd_bus_creds_get_fsuid', + 'sd_bus_creds_get_gid', + 'sd_bus_creds_get_owner_uid', + 'sd_bus_creds_get_ppid', + 'sd_bus_creds_get_selinux_context', + 'sd_bus_creds_get_session', + 'sd_bus_creds_get_sgid', + 'sd_bus_creds_get_slice', + 'sd_bus_creds_get_suid', + 'sd_bus_creds_get_supplementary_gids', + 'sd_bus_creds_get_tid', + 'sd_bus_creds_get_tid_comm', + 'sd_bus_creds_get_tty', + 'sd_bus_creds_get_uid', + 'sd_bus_creds_get_unique_name', + 'sd_bus_creds_get_unit', + 'sd_bus_creds_get_user_slice', + 'sd_bus_creds_get_user_unit', + 'sd_bus_creds_get_well_known_names', + 'sd_bus_creds_has_bounding_cap', + 'sd_bus_creds_has_effective_cap', + 'sd_bus_creds_has_inheritable_cap', + 'sd_bus_creds_has_permitted_cap'], + ''], + ['sd_bus_creds_new_from_pid', + '3', + ['sd_bus_creds_get_augmented_mask', + 'sd_bus_creds_get_mask', + 'sd_bus_creds_ref', + 'sd_bus_creds_unref', + 'sd_bus_creds_unrefp'], + ''], + ['sd_bus_default', + '3', + ['sd_bus_default_system', + 'sd_bus_default_user', + 'sd_bus_open', + 'sd_bus_open_system', + 'sd_bus_open_system_machine', + 'sd_bus_open_system_remote', + 'sd_bus_open_system_with_description', + 'sd_bus_open_user', + 'sd_bus_open_user_machine', + 'sd_bus_open_user_with_description', + 'sd_bus_open_with_description'], + ''], + ['sd_bus_emit_signal', + '3', + ['sd_bus_emit_interfaces_added', + 'sd_bus_emit_interfaces_added_strv', + 'sd_bus_emit_interfaces_removed', + 'sd_bus_emit_interfaces_removed_strv', + 'sd_bus_emit_object_added', + 'sd_bus_emit_object_removed', + 'sd_bus_emit_properties_changed', + 'sd_bus_emit_properties_changed_strv', + 'sd_bus_emit_signalv'], + ''], + ['sd_bus_enqueue_for_read', '3', [], ''], + ['sd_bus_error', + '3', + ['SD_BUS_ERROR_MAKE_CONST', + 'SD_BUS_ERROR_NULL', + 'sd_bus_error_copy', + 'sd_bus_error_free', + 'sd_bus_error_get_errno', + 'sd_bus_error_has_name', + 'sd_bus_error_has_names', + 'sd_bus_error_has_names_sentinel', + 'sd_bus_error_is_set', + 'sd_bus_error_move', + 'sd_bus_error_set', + 'sd_bus_error_set_const', + 'sd_bus_error_set_errno', + 'sd_bus_error_set_errnof', + 'sd_bus_error_set_errnofv', + 'sd_bus_error_setf', + 'sd_bus_error_setfv'], + ''], + ['sd_bus_error_add_map', + '3', + ['SD_BUS_ERROR_END', 'SD_BUS_ERROR_MAP', 'sd_bus_error_map'], + ''], + ['sd_bus_get_current_handler', + '3', + ['sd_bus_get_current_message', + 'sd_bus_get_current_slot', + 'sd_bus_get_current_userdata'], + ''], + ['sd_bus_get_fd', '3', ['sd_bus_get_events', 'sd_bus_get_timeout'], ''], + ['sd_bus_get_n_queued_read', '3', ['sd_bus_get_n_queued_write'], ''], + ['sd_bus_get_name_creds', '3', ['sd_bus_get_owner_creds'], ''], + ['sd_bus_get_name_machine_id', '3', [], ''], + ['sd_bus_interface_name_is_valid', + '3', + ['sd_bus_member_name_is_valid', + 'sd_bus_object_path_is_valid', + 'sd_bus_service_name_is_valid'], + ''], + ['sd_bus_is_open', '3', ['sd_bus_is_ready'], ''], + ['sd_bus_list_names', '3', [], ''], + ['sd_bus_message_append', '3', ['sd_bus_message_appendv'], ''], + ['sd_bus_message_append_array', + '3', + ['sd_bus_message_append_array_iovec', + 'sd_bus_message_append_array_memfd', + 'sd_bus_message_append_array_space'], + ''], + ['sd_bus_message_append_basic', '3', [], ''], + ['sd_bus_message_append_string_memfd', + '3', + ['sd_bus_message_append_string_iovec', 'sd_bus_message_append_string_space'], + ''], + ['sd_bus_message_append_strv', '3', [], ''], + ['sd_bus_message_at_end', '3', [], ''], + ['sd_bus_message_copy', '3', [], ''], + ['sd_bus_message_dump', '3', [], ''], + ['sd_bus_message_get_cookie', '3', ['sd_bus_message_get_reply_cookie'], ''], + ['sd_bus_message_get_monotonic_usec', + '3', + ['sd_bus_message_get_realtime_usec', 'sd_bus_message_get_seqnum'], + ''], + ['sd_bus_message_get_signature', + '3', + ['sd_bus_message_has_signature', 'sd_bus_message_is_empty'], + ''], + ['sd_bus_message_get_type', + '3', + ['sd_bus_message_get_creds', + 'sd_bus_message_get_errno', + 'sd_bus_message_get_error', + 'sd_bus_message_is_method_call', + 'sd_bus_message_is_method_error', + 'sd_bus_message_is_signal'], + ''], + ['sd_bus_message_new', + '3', + ['SD_BUS_MESSAGE_METHOD_CALL', + 'SD_BUS_MESSAGE_METHOD_ERROR', + 'SD_BUS_MESSAGE_METHOD_RETURN', + 'SD_BUS_MESSAGE_SIGNAL', + 'sd_bus_message_get_bus', + 'sd_bus_message_ref', + 'sd_bus_message_unref', + 'sd_bus_message_unrefp'], + ''], + ['sd_bus_message_new_method_call', + '3', + ['sd_bus_message_new_method_return'], + ''], + ['sd_bus_message_new_method_error', + '3', + ['sd_bus_message_new_method_errno', + 'sd_bus_message_new_method_errnof', + 'sd_bus_message_new_method_errorf'], + ''], + ['sd_bus_message_new_signal', '3', [], ''], + ['sd_bus_message_open_container', + '3', + ['sd_bus_message_close_container', + 'sd_bus_message_enter_container', + 'sd_bus_message_exit_container'], + ''], + ['sd_bus_message_read', + '3', + ['sd_bus_message_peek_type', 'sd_bus_message_readv'], + ''], + ['sd_bus_message_read_array', '3', [], ''], + ['sd_bus_message_read_basic', '3', [], ''], + ['sd_bus_message_read_strv', '3', ['sd_bus_message_read_strv_extend'], ''], + ['sd_bus_message_rewind', '3', [], ''], + ['sd_bus_message_seal', '3', [], ''], + ['sd_bus_message_sensitive', '3', [], ''], + ['sd_bus_message_set_destination', + '3', + ['sd_bus_message_get_destination', + 'sd_bus_message_get_interface', + 'sd_bus_message_get_member', + 'sd_bus_message_get_path', + 'sd_bus_message_get_sender', + 'sd_bus_message_set_sender'], + ''], + ['sd_bus_message_set_expect_reply', + '3', + ['sd_bus_message_get_allow_interactive_authorization', + 'sd_bus_message_get_auto_start', + 'sd_bus_message_get_expect_reply', + 'sd_bus_message_set_allow_interactive_authorization', + 'sd_bus_message_set_auto_start'], + ''], + ['sd_bus_message_skip', '3', [], ''], + ['sd_bus_message_verify_type', '3', [], ''], + ['sd_bus_negotiate_fds', + '3', + ['sd_bus_get_creds_mask', + 'sd_bus_negotiate_creds', + 'sd_bus_negotiate_timestamp'], + ''], + ['sd_bus_new', + '3', + ['sd_bus_close_unref', + 'sd_bus_close_unrefp', + 'sd_bus_flush_close_unref', + 'sd_bus_flush_close_unrefp', + 'sd_bus_ref', + 'sd_bus_unref', + 'sd_bus_unrefp'], + ''], + ['sd_bus_path_encode', + '3', + ['sd_bus_path_decode', 'sd_bus_path_decode_many', 'sd_bus_path_encode_many'], + ''], + ['sd_bus_process', '3', [], ''], + ['sd_bus_query_sender_creds', '3', ['sd_bus_query_sender_privilege'], ''], + ['sd_bus_reply_method_error', + '3', + ['sd_bus_reply_method_errno', + 'sd_bus_reply_method_errnof', + 'sd_bus_reply_method_errnofv', + 'sd_bus_reply_method_errorf', + 'sd_bus_reply_method_errorfv'], + ''], + ['sd_bus_reply_method_return', '3', ['sd_bus_reply_method_returnv'], ''], + ['sd_bus_request_name', + '3', + ['sd_bus_release_name', + 'sd_bus_release_name_async', + 'sd_bus_request_name_async'], + ''], + ['sd_bus_send', '3', ['sd_bus_message_send', 'sd_bus_send_to'], ''], + ['sd_bus_set_address', '3', ['sd_bus_get_address', 'sd_bus_set_exec'], ''], + ['sd_bus_set_close_on_exit', '3', ['sd_bus_get_close_on_exit'], ''], + ['sd_bus_set_connected_signal', '3', ['sd_bus_get_connected_signal'], ''], + ['sd_bus_set_description', + '3', + ['sd_bus_get_allow_interactive_authorization', + 'sd_bus_get_description', + 'sd_bus_get_scope', + 'sd_bus_get_tid', + 'sd_bus_get_unique_name', + 'sd_bus_is_anonymous', + 'sd_bus_is_trusted', + 'sd_bus_set_allow_interactive_authorization', + 'sd_bus_set_anonymous', + 'sd_bus_set_trusted'], + ''], + ['sd_bus_set_exit_on_disconnect', '3', ['sd_bus_get_exit_on_disconnect'], ''], + ['sd_bus_set_fd', '3', [], ''], + ['sd_bus_set_method_call_timeout', + '3', + ['sd_bus_get_method_call_timeout'], + ''], + ['sd_bus_set_property', + '3', + ['sd_bus_get_property', + 'sd_bus_get_property_string', + 'sd_bus_get_property_strv', + 'sd_bus_get_property_trivial', + 'sd_bus_set_propertyv'], + ''], + ['sd_bus_set_sender', '3', ['sd_bus_get_sender'], ''], + ['sd_bus_set_server', + '3', + ['sd_bus_get_bus_id', + 'sd_bus_is_bus_client', + 'sd_bus_is_monitor', + 'sd_bus_is_server', + 'sd_bus_set_bus_client', + 'sd_bus_set_monitor'], + ''], + ['sd_bus_set_watch_bind', '3', ['sd_bus_get_watch_bind'], ''], + ['sd_bus_slot_get_bus', + '3', + ['sd_bus_slot_get_current_handler', + 'sd_bus_slot_get_current_message', + 'sd_bus_slot_get_current_userdata'], + ''], + ['sd_bus_slot_ref', '3', ['sd_bus_slot_unref', 'sd_bus_slot_unrefp'], ''], + ['sd_bus_slot_set_description', '3', ['sd_bus_slot_get_description'], ''], + ['sd_bus_slot_set_destroy_callback', + '3', + ['sd_bus_destroy_t', + 'sd_bus_slot_get_destroy_callback', + 'sd_bus_track_get_destroy_callback', + 'sd_bus_track_set_destroy_callback'], + ''], + ['sd_bus_slot_set_floating', '3', ['sd_bus_slot_get_floating'], ''], + ['sd_bus_slot_set_userdata', '3', ['sd_bus_slot_get_userdata'], ''], + ['sd_bus_start', '3', [], ''], + ['sd_bus_track_add_name', + '3', + ['sd_bus_track_add_sender', + 'sd_bus_track_contains', + 'sd_bus_track_count', + 'sd_bus_track_count_name', + 'sd_bus_track_count_sender', + 'sd_bus_track_first', + 'sd_bus_track_next', + 'sd_bus_track_remove_name', + 'sd_bus_track_remove_sender'], + ''], + ['sd_bus_track_new', + '3', + ['sd_bus_track_get_bus', + 'sd_bus_track_get_recursive', + 'sd_bus_track_get_userdata', + 'sd_bus_track_ref', + 'sd_bus_track_set_recursive', + 'sd_bus_track_set_userdata', + 'sd_bus_track_unref', + 'sd_bus_track_unrefp'], + ''], + ['sd_bus_wait', '3', [], ''], + ['sd_device_get_syspath', + '3', + ['sd_device_get_devname', + 'sd_device_get_devnum', + 'sd_device_get_devpath', + 'sd_device_get_devtype', + 'sd_device_get_diskseq', + 'sd_device_get_driver', + 'sd_device_get_ifindex', + 'sd_device_get_subsystem', + 'sd_device_get_sysname', + 'sd_device_get_sysnum'], + ''], + ['sd_device_ref', '3', ['sd_device_unref', 'sd_device_unrefp'], ''], + ['sd_event_add_child', + '3', + ['sd_event_add_child_pidfd', + 'sd_event_child_handler_t', + 'sd_event_source_get_child_pid', + 'sd_event_source_get_child_pidfd', + 'sd_event_source_get_child_pidfd_own', + 'sd_event_source_get_child_process_own', + 'sd_event_source_send_child_signal', + 'sd_event_source_set_child_pidfd_own', + 'sd_event_source_set_child_process_own'], + ''], + ['sd_event_add_defer', + '3', + ['sd_event_add_exit', 'sd_event_add_post', 'sd_event_handler_t'], + ''], + ['sd_event_add_inotify', + '3', + ['sd_event_add_inotify_fd', + 'sd_event_inotify_handler_t', + 'sd_event_source_get_inotify_mask'], + ''], + ['sd_event_add_io', + '3', + ['sd_event_io_handler_t', + 'sd_event_source', + 'sd_event_source_get_io_events', + 'sd_event_source_get_io_fd', + 'sd_event_source_get_io_fd_own', + 'sd_event_source_get_io_revents', + 'sd_event_source_set_io_events', + 'sd_event_source_set_io_fd', + 'sd_event_source_set_io_fd_own'], + ''], + ['sd_event_add_signal', + '3', + ['SD_EVENT_SIGNAL_PROCMASK', + 'sd_event_signal_handler_t', + 'sd_event_source_get_signal'], + ''], + ['sd_event_add_time', + '3', + ['sd_event_add_time_relative', + 'sd_event_source_get_time', + 'sd_event_source_get_time_accuracy', + 'sd_event_source_get_time_clock', + 'sd_event_source_set_time', + 'sd_event_source_set_time_accuracy', + 'sd_event_source_set_time_relative', + 'sd_event_time_handler_t'], + ''], + ['sd_event_exit', '3', ['sd_event_get_exit_code'], ''], + ['sd_event_get_fd', '3', [], ''], + ['sd_event_new', + '3', + ['sd_event', + 'sd_event_default', + 'sd_event_get_tid', + 'sd_event_ref', + 'sd_event_unref', + 'sd_event_unrefp'], + ''], + ['sd_event_now', '3', [], ''], + ['sd_event_run', '3', ['sd_event_loop'], ''], + ['sd_event_set_signal_exit', '3', [], ''], + ['sd_event_set_watchdog', '3', ['sd_event_get_watchdog'], ''], + ['sd_event_source_get_event', '3', [], ''], + ['sd_event_source_get_pending', '3', [], ''], + ['sd_event_source_set_description', + '3', + ['sd_event_source_get_description'], + ''], + ['sd_event_source_set_destroy_callback', + '3', + ['sd_event_destroy_t', 'sd_event_source_get_destroy_callback'], + ''], + ['sd_event_source_set_enabled', + '3', + ['SD_EVENT_OFF', + 'SD_EVENT_ON', + 'SD_EVENT_ONESHOT', + 'sd_event_source_get_enabled'], + ''], + ['sd_event_source_set_exit_on_failure', + '3', + ['sd_event_source_get_exit_on_failure'], + ''], + ['sd_event_source_set_floating', '3', ['sd_event_source_get_floating'], ''], + ['sd_event_source_set_prepare', '3', [], ''], + ['sd_event_source_set_priority', + '3', + ['SD_EVENT_PRIORITY_IDLE', + 'SD_EVENT_PRIORITY_IMPORTANT', + 'SD_EVENT_PRIORITY_NORMAL', + 'sd_event_source_get_priority'], + ''], + ['sd_event_source_set_ratelimit', + '3', + ['sd_event_source_get_ratelimit', + 'sd_event_source_is_ratelimited', + 'sd_event_source_set_ratelimit_expire_callback'], + ''], + ['sd_event_source_set_userdata', '3', ['sd_event_source_get_userdata'], ''], + ['sd_event_source_unref', + '3', + ['sd_event_source_disable_unref', + 'sd_event_source_disable_unrefp', + 'sd_event_source_ref', + 'sd_event_source_unrefp'], + ''], + ['sd_event_wait', + '3', + ['SD_EVENT_ARMED', + 'SD_EVENT_EXITING', + 'SD_EVENT_FINISHED', + 'SD_EVENT_INITIAL', + 'SD_EVENT_PENDING', + 'SD_EVENT_PREPARING', + 'SD_EVENT_RUNNING', + 'sd_event_dispatch', + 'sd_event_get_iteration', + 'sd_event_get_state', + 'sd_event_prepare'], + ''], + ['sd_get_seats', + '3', + ['sd_get_machine_names', 'sd_get_sessions', 'sd_get_uids'], + 'HAVE_PAM'], + ['sd_hwdb_get', + '3', + ['SD_HWDB_FOREACH_PROPERTY', 'sd_hwdb_enumerate', 'sd_hwdb_seek'], + ''], + ['sd_hwdb_new', + '3', + ['sd_hwdb_new_from_path', 'sd_hwdb_ref', 'sd_hwdb_unref'], + ''], + ['sd_id128_get_machine', + '3', + ['sd_id128_get_boot', + 'sd_id128_get_boot_app_specific', + 'sd_id128_get_invocation', + 'sd_id128_get_machine_app_specific'], + ''], + ['sd_id128_randomize', '3', [], ''], + ['sd_id128_to_string', + '3', + ['SD_ID128_STRING_MAX', + 'SD_ID128_TO_STRING', + 'SD_ID128_TO_UUID_STRING', + 'SD_ID128_UUID_STRING_MAX', + 'sd_id128_from_string', + 'sd_id128_to_uuid_string'], + ''], + ['sd_is_fifo', + '3', + ['sd_is_mq', + 'sd_is_socket', + 'sd_is_socket_inet', + 'sd_is_socket_sockaddr', + 'sd_is_socket_unix', + 'sd_is_special'], + ''], + ['sd_journal_add_match', + '3', + ['sd_journal_add_conjunction', + 'sd_journal_add_disjunction', + 'sd_journal_flush_matches'], + ''], + ['sd_journal_enumerate_fields', + '3', + ['SD_JOURNAL_FOREACH_FIELD', 'sd_journal_restart_fields'], + ''], + ['sd_journal_get_catalog', '3', ['sd_journal_get_catalog_for_message_id'], ''], + ['sd_journal_get_cursor', '3', ['sd_journal_test_cursor'], ''], + ['sd_journal_get_cutoff_realtime_usec', + '3', + ['sd_journal_get_cutoff_monotonic_usec'], + ''], + ['sd_journal_get_data', + '3', + ['SD_JOURNAL_FOREACH_DATA', + 'sd_journal_enumerate_available_data', + 'sd_journal_enumerate_data', + 'sd_journal_get_data_threshold', + 'sd_journal_restart_data', + 'sd_journal_set_data_threshold'], + ''], + ['sd_journal_get_fd', + '3', + ['SD_JOURNAL_APPEND', + 'SD_JOURNAL_INVALIDATE', + 'SD_JOURNAL_NOP', + 'sd_journal_get_events', + 'sd_journal_get_timeout', + 'sd_journal_process', + 'sd_journal_reliable_fd', + 'sd_journal_wait'], + ''], + ['sd_journal_get_realtime_usec', '3', ['sd_journal_get_monotonic_usec'], ''], + ['sd_journal_get_usage', '3', [], ''], + ['sd_journal_has_runtime_files', '3', ['sd_journal_has_persistent_files'], ''], + ['sd_journal_next', + '3', + ['SD_JOURNAL_FOREACH', + 'SD_JOURNAL_FOREACH_BACKWARDS', + 'sd_journal_next_skip', + 'sd_journal_previous', + 'sd_journal_previous_skip'], + ''], + ['sd_journal_open', + '3', + ['SD_JOURNAL_ALL_NAMESPACES', + 'SD_JOURNAL_CURRENT_USER', + 'SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE', + 'SD_JOURNAL_LOCAL_ONLY', + 'SD_JOURNAL_OS_ROOT', + 'SD_JOURNAL_RUNTIME_ONLY', + 'SD_JOURNAL_SYSTEM', + 'sd_journal', + 'sd_journal_close', + 'sd_journal_open_directory', + 'sd_journal_open_directory_fd', + 'sd_journal_open_files', + 'sd_journal_open_files_fd', + 'sd_journal_open_namespace'], + ''], + ['sd_journal_print', + '3', + ['SD_JOURNAL_SUPPRESS_LOCATION', + 'sd_journal_perror', + 'sd_journal_perror_with_location', + 'sd_journal_print_with_location', + 'sd_journal_printv', + 'sd_journal_printv_with_location', + 'sd_journal_send', + 'sd_journal_send_with_location', + 'sd_journal_sendv', + 'sd_journal_sendv_with_location'], + ''], + ['sd_journal_query_unique', + '3', + ['SD_JOURNAL_FOREACH_UNIQUE', + 'sd_journal_enumerate_available_unique', + 'sd_journal_enumerate_unique', + 'sd_journal_restart_unique'], + ''], + ['sd_journal_seek_head', + '3', + ['sd_journal_seek_cursor', + 'sd_journal_seek_monotonic_usec', + 'sd_journal_seek_realtime_usec', + 'sd_journal_seek_tail'], + ''], + ['sd_journal_stream_fd', '3', [], ''], + ['sd_listen_fds', + '3', + ['SD_LISTEN_FDS_START', 'sd_listen_fds_with_names'], + ''], + ['sd_login_monitor_new', + '3', + ['sd_login_monitor', + 'sd_login_monitor_flush', + 'sd_login_monitor_get_events', + 'sd_login_monitor_get_fd', + 'sd_login_monitor_get_timeout', + 'sd_login_monitor_unref', + 'sd_login_monitor_unrefp'], + 'HAVE_PAM'], + ['sd_machine_get_class', '3', ['sd_machine_get_ifindices'], ''], + ['sd_notify', + '3', + ['sd_notify_barrier', + 'sd_notifyf', + 'sd_pid_notify', + 'sd_pid_notify_with_fds', + 'sd_pid_notifyf'], + ''], + ['sd_path_lookup', '3', ['sd_path_lookup_strv'], ''], + ['sd_pid_get_owner_uid', + '3', + ['sd_peer_get_cgroup', + 'sd_peer_get_machine_name', + 'sd_peer_get_owner_uid', + 'sd_peer_get_session', + 'sd_peer_get_slice', + 'sd_peer_get_unit', + 'sd_peer_get_user_slice', + 'sd_peer_get_user_unit', + 'sd_pid_get_cgroup', + 'sd_pid_get_machine_name', + 'sd_pid_get_session', + 'sd_pid_get_slice', + 'sd_pid_get_unit', + 'sd_pid_get_user_slice', + 'sd_pid_get_user_unit'], + 'HAVE_PAM'], + ['sd_seat_get_active', + '3', + ['sd_seat_can_graphical', 'sd_seat_can_tty', 'sd_seat_get_sessions'], + 'HAVE_PAM'], + ['sd_session_is_active', + '3', + ['sd_session_get_class', + 'sd_session_get_desktop', + 'sd_session_get_display', + 'sd_session_get_remote_host', + 'sd_session_get_remote_user', + 'sd_session_get_seat', + 'sd_session_get_service', + 'sd_session_get_state', + 'sd_session_get_tty', + 'sd_session_get_type', + 'sd_session_get_uid', + 'sd_session_get_vt', + 'sd_session_is_remote'], + 'HAVE_PAM'], + ['sd_uid_get_state', + '3', + ['sd_uid_get_display', + 'sd_uid_get_seats', + 'sd_uid_get_sessions', + 'sd_uid_is_on_seat'], + 'HAVE_PAM'], + ['sd_watchdog_enabled', '3', [], ''], + ['shutdown', '8', [], ''], + ['sysctl.d', '5', [], ''], + ['systemctl', '1', [], ''], + ['systemd-analyze', '1', [], 'ENABLE_ANALYZE'], + ['systemd-ask-password-console.service', + '8', + ['systemd-ask-password-console.path', + 'systemd-ask-password-wall.path', + 'systemd-ask-password-wall.service'], + ''], + ['systemd-ask-password', '1', [], ''], + ['systemd-backlight@.service', '8', ['systemd-backlight'], 'ENABLE_BACKLIGHT'], + ['systemd-binfmt.service', '8', ['systemd-binfmt'], 'ENABLE_BINFMT'], + ['systemd-bless-boot-generator', '8', [], 'HAVE_GNU_EFI'], + ['systemd-bless-boot.service', '8', ['systemd-bless-boot'], 'HAVE_GNU_EFI'], + ['systemd-boot-check-no-failures.service', + '8', + ['systemd-boot-check-no-failures'], + ''], + ['systemd-boot-system-token.service', '8', [], 'HAVE_GNU_EFI'], + ['systemd-boot', '7', ['sd-boot'], 'HAVE_GNU_EFI'], + ['systemd-cat', '1', [], ''], + ['systemd-cgls', '1', [], ''], + ['systemd-cgtop', '1', [], ''], + ['systemd-coredump', + '8', + ['systemd-coredump.socket', 'systemd-coredump@.service'], + 'ENABLE_COREDUMP'], + ['systemd-creds', '1', [], ''], + ['systemd-cryptenroll', '1', [], 'HAVE_LIBCRYPTSETUP'], + ['systemd-cryptsetup-generator', '8', [], 'HAVE_LIBCRYPTSETUP'], + ['systemd-cryptsetup@.service', + '8', + ['systemd-cryptsetup'], + 'HAVE_LIBCRYPTSETUP'], + ['systemd-debug-generator', '8', [], ''], + ['systemd-delta', '1', [], ''], + ['systemd-detect-virt', '1', [], ''], + ['systemd-dissect', '1', [], 'HAVE_BLKID'], + ['systemd-environment-d-generator', + '8', + ['30-systemd-environment-d-generator'], + 'ENABLE_ENVIRONMENT_D'], + ['systemd-escape', '1', [], ''], + ['systemd-firstboot', '1', ['systemd-firstboot.service'], 'ENABLE_FIRSTBOOT'], + ['systemd-fsck@.service', + '8', + ['systemd-fsck', 'systemd-fsck-root.service', 'systemd-fsck-usr.service'], + ''], + ['systemd-fstab-generator', '8', [], ''], + ['systemd-getty-generator', '8', [], ''], + ['systemd-gpt-auto-generator', '8', [], 'HAVE_BLKID'], + ['systemd-halt.service', + '8', + ['systemd-kexec.service', + 'systemd-poweroff.service', + 'systemd-reboot.service', + 'systemd-shutdown'], + ''], + ['systemd-hibernate-resume-generator', '8', [], 'ENABLE_HIBERNATE'], + ['systemd-hibernate-resume@.service', + '8', + ['systemd-hibernate-resume'], + 'ENABLE_HIBERNATE'], + ['systemd-homed.service', '8', ['systemd-homed'], 'ENABLE_HOMED'], + ['systemd-hostnamed.service', '8', ['systemd-hostnamed'], 'ENABLE_HOSTNAMED'], + ['systemd-hwdb', '8', [], 'ENABLE_HWDB'], + ['systemd-id128', '1', [], ''], + ['systemd-importd.service', '8', ['systemd-importd'], 'ENABLE_IMPORTD'], + ['systemd-inhibit', '1', [], ''], + ['systemd-initctl.service', + '8', + ['systemd-initctl', 'systemd-initctl.socket'], + 'HAVE_SYSV_COMPAT'], + ['systemd-integritysetup-generator', '8', [], 'HAVE_LIBCRYPTSETUP'], + ['systemd-integritysetup@.service', + '8', + ['systemd-integritysetup'], + 'HAVE_LIBCRYPTSETUP'], + ['systemd-journal-gatewayd.service', + '8', + ['systemd-journal-gatewayd', 'systemd-journal-gatewayd.socket'], + 'HAVE_MICROHTTPD'], + ['systemd-journal-remote.service', + '8', + ['systemd-journal-remote', 'systemd-journal-remote.socket'], + 'HAVE_MICROHTTPD'], + ['systemd-journal-upload.service', + '8', + ['systemd-journal-upload'], + 'HAVE_MICROHTTPD'], + ['systemd-journald.service', + '8', + ['systemd-journald', + 'systemd-journald-audit.socket', + 'systemd-journald-dev-log.socket', + 'systemd-journald-varlink@.socket', + 'systemd-journald.socket', + 'systemd-journald@.service', + 'systemd-journald@.socket'], + ''], + ['systemd-localed.service', '8', ['systemd-localed'], 'ENABLE_LOCALED'], + ['systemd-logind.service', '8', ['systemd-logind'], 'ENABLE_LOGIND'], + ['systemd-machine-id-commit.service', '8', [], ''], + ['systemd-machine-id-setup', '1', [], ''], + ['systemd-machined.service', '8', ['systemd-machined'], 'ENABLE_MACHINED'], + ['systemd-makefs@.service', + '8', + ['systemd-growfs', + 'systemd-growfs-root.service', + 'systemd-growfs@.service', + 'systemd-makefs', + 'systemd-mkswap@.service'], + ''], + ['systemd-measure', '1', [], 'HAVE_GNU_EFI'], + ['systemd-modules-load.service', '8', ['systemd-modules-load'], 'HAVE_KMOD'], + ['systemd-mount', '1', ['systemd-umount'], ''], + ['systemd-network-generator.service', '8', ['systemd-network-generator'], ''], + ['systemd-networkd-wait-online.service', + '8', + ['systemd-networkd-wait-online', 'systemd-networkd-wait-online@.service'], + 'ENABLE_NETWORKD'], + ['systemd-networkd.service', '8', ['systemd-networkd'], 'ENABLE_NETWORKD'], + ['systemd-notify', '1', [], ''], + ['systemd-nspawn', '1', [], ''], + ['systemd-oomd.service', '8', ['systemd-oomd'], 'ENABLE_OOMD'], + ['systemd-path', '1', [], ''], + ['systemd-pcrphase.service', + '8', + ['systemd-pcrphase', + 'systemd-pcrphase-initrd.service', + 'systemd-pcrphase-sysinit.service'], + 'HAVE_GNU_EFI'], + ['systemd-portabled.service', '8', ['systemd-portabled'], 'ENABLE_PORTABLED'], + ['systemd-pstore.service', '8', ['systemd-pstore'], 'ENABLE_PSTORE'], + ['systemd-quotacheck.service', + '8', + ['systemd-quotacheck'], + 'ENABLE_QUOTACHECK'], + ['systemd-random-seed.service', + '8', + ['systemd-random-seed'], + 'ENABLE_RANDOMSEED'], + ['systemd-rc-local-generator', '8', ['rc-local.service'], 'HAVE_SYSV_COMPAT'], + ['systemd-remount-fs.service', '8', ['systemd-remount-fs'], ''], + ['systemd-repart', '8', ['systemd-repart.service'], 'ENABLE_REPART'], + ['systemd-resolved.service', '8', ['systemd-resolved'], 'ENABLE_RESOLVE'], + ['systemd-rfkill.service', + '8', + ['systemd-rfkill', 'systemd-rfkill.socket'], + 'ENABLE_RFKILL'], + ['systemd-run-generator', '8', [], ''], + ['systemd-run', '1', [], ''], + ['systemd-sleep.conf', '5', ['sleep.conf.d'], ''], + ['systemd-socket-activate', '1', [], ''], + ['systemd-socket-proxyd', '8', [], ''], + ['systemd-stdio-bridge', '1', [], ''], + ['systemd-stub', + '7', + ['linuxaa64.efi.stub', 'linuxia32.efi.stub', 'linuxx64.efi.stub', 'sd-stub'], + 'HAVE_GNU_EFI'], + ['systemd-suspend.service', + '8', + ['systemd-hibernate.service', + 'systemd-hybrid-sleep.service', + 'systemd-sleep', + 'systemd-suspend-then-hibernate.service'], + ''], + ['systemd-sysctl.service', '8', ['systemd-sysctl'], ''], + ['systemd-sysext', '8', ['systemd-sysext.service'], ''], + ['systemd-system-update-generator', '8', [], ''], + ['systemd-system.conf', + '5', + ['system.conf.d', 'systemd-user.conf', 'user.conf.d'], + ''], + ['systemd-sysupdate', + '8', + ['systemd-sysupdate-reboot.service', + 'systemd-sysupdate-reboot.timer', + 'systemd-sysupdate.service', + 'systemd-sysupdate.timer'], + 'ENABLE_SYSUPDATE'], + ['systemd-sysusers', '8', ['systemd-sysusers.service'], ''], + ['systemd-sysv-generator', '8', [], 'HAVE_SYSV_COMPAT'], + ['systemd-time-wait-sync.service', + '8', + ['systemd-time-wait-sync'], + 'ENABLE_TIMESYNCD'], + ['systemd-timedated.service', '8', ['systemd-timedated'], 'ENABLE_TIMEDATED'], + ['systemd-timesyncd.service', '8', ['systemd-timesyncd'], 'ENABLE_TIMESYNCD'], + ['systemd-tmpfiles', + '8', + ['systemd-tmpfiles-clean.service', + 'systemd-tmpfiles-clean.timer', + 'systemd-tmpfiles-setup-dev.service', + 'systemd-tmpfiles-setup.service'], + ''], + ['systemd-tty-ask-password-agent', '1', [], ''], + ['systemd-udev-settle.service', '8', [], ''], + ['systemd-udevd.service', + '8', + ['systemd-udevd', + 'systemd-udevd-control.socket', + 'systemd-udevd-kernel.socket'], + ''], + ['systemd-update-done.service', '8', ['systemd-update-done'], ''], + ['systemd-update-utmp.service', + '8', + ['systemd-update-utmp', 'systemd-update-utmp-runlevel.service'], + 'ENABLE_UTMP'], + ['systemd-user-sessions.service', '8', ['systemd-user-sessions'], 'HAVE_PAM'], + ['systemd-userdbd.service', '8', ['systemd-userdbd'], 'ENABLE_USERDB'], + ['systemd-vconsole-setup.service', + '8', + ['systemd-vconsole-setup'], + 'ENABLE_VCONSOLE'], + ['systemd-veritysetup-generator', '8', [], 'HAVE_LIBCRYPTSETUP'], + ['systemd-veritysetup@.service', + '8', + ['systemd-veritysetup'], + 'HAVE_LIBCRYPTSETUP'], + ['systemd-volatile-root.service', '8', ['systemd-volatile-root'], ''], + ['systemd-xdg-autostart-generator', '8', [], 'ENABLE_XDG_AUTOSTART'], + ['systemd', '1', ['init'], ''], + ['systemd.automount', '5', [], ''], + ['systemd.device', '5', [], ''], + ['systemd.dnssd', '5', [], 'ENABLE_RESOLVE'], + ['systemd.environment-generator', '7', [], 'ENABLE_ENVIRONMENT_D'], + ['systemd.exec', '5', [], ''], + ['systemd.generator', '7', [], ''], + ['systemd.journal-fields', '7', [], ''], + ['systemd.kill', '5', [], ''], + ['systemd.link', '5', [], ''], + ['systemd.mount', '5', [], ''], + ['systemd.net-naming-scheme', '7', [], ''], + ['systemd.netdev', '5', [], 'ENABLE_NETWORKD'], + ['systemd.network', '5', [], 'ENABLE_NETWORKD'], + ['systemd.nspawn', '5', [], ''], + ['systemd.offline-updates', '7', [], ''], + ['systemd.path', '5', [], ''], + ['systemd.preset', '5', [], ''], + ['systemd.resource-control', '5', [], ''], + ['systemd.scope', '5', [], ''], + ['systemd.service', '5', [], ''], + ['systemd.slice', '5', [], ''], + ['systemd.socket', '5', [], ''], + ['systemd.special', '7', [], ''], + ['systemd.swap', '5', [], ''], + ['systemd.syntax', '7', [], ''], + ['systemd.system-credentials', '7', [], ''], + ['systemd.target', '5', [], ''], + ['systemd.time', '7', [], ''], + ['systemd.timer', '5', [], ''], + ['systemd.unit', '5', [], ''], + ['sysupdate.d', '5', [], 'ENABLE_SYSUPDATE'], + ['sysusers.d', '5', [], 'ENABLE_SYSUSERS'], + ['telinit', '8', [], 'HAVE_SYSV_COMPAT'], + ['timedatectl', '1', [], 'ENABLE_TIMEDATECTL'], + ['timesyncd.conf', '5', ['timesyncd.conf.d'], 'ENABLE_TIMESYNCD'], + ['tmpfiles.d', '5', [], ''], + ['udev', '7', [], ''], + ['udev.conf', '5', [], ''], + ['udev_device_get_syspath', + '3', + ['udev_device_get_action', + 'udev_device_get_devnode', + 'udev_device_get_devnum', + 'udev_device_get_devpath', + 'udev_device_get_devtype', + 'udev_device_get_driver', + 'udev_device_get_is_initialized', + 'udev_device_get_parent', + 'udev_device_get_parent_with_subsystem_devtype', + 'udev_device_get_subsystem', + 'udev_device_get_sysname', + 'udev_device_get_sysnum', + 'udev_device_get_udev'], + ''], + ['udev_device_has_tag', + '3', + ['udev_device_get_current_tags_list_entry', + 'udev_device_get_devlinks_list_entry', + 'udev_device_get_properties_list_entry', + 'udev_device_get_property_value', + 'udev_device_get_sysattr_list_entry', + 'udev_device_get_sysattr_value', + 'udev_device_get_tags_list_entry', + 'udev_device_has_current_tag', + 'udev_device_set_sysattr_value'], + ''], + ['udev_device_new_from_syspath', + '3', + ['udev_device_new_from_device_id', + 'udev_device_new_from_devnum', + 'udev_device_new_from_environment', + 'udev_device_new_from_subsystem_sysname', + 'udev_device_ref', + 'udev_device_unref'], + ''], + ['udev_enumerate_add_match_subsystem', + '3', + ['udev_enumerate_add_match_is_initialized', + 'udev_enumerate_add_match_parent', + 'udev_enumerate_add_match_property', + 'udev_enumerate_add_match_sysattr', + 'udev_enumerate_add_match_sysname', + 'udev_enumerate_add_match_tag', + 'udev_enumerate_add_nomatch_subsystem', + 'udev_enumerate_add_nomatch_sysattr'], + ''], + ['udev_enumerate_new', + '3', + ['udev_enumerate_ref', 'udev_enumerate_unref'], + ''], + ['udev_enumerate_scan_devices', + '3', + ['udev_enumerate_add_syspath', + 'udev_enumerate_get_list_entry', + 'udev_enumerate_get_udev', + 'udev_enumerate_scan_subsystems'], + ''], + ['udev_list_entry', + '3', + ['udev_list_entry_get_by_name', + 'udev_list_entry_get_name', + 'udev_list_entry_get_next', + 'udev_list_entry_get_value'], + ''], + ['udev_monitor_filter_update', + '3', + ['udev_monitor_filter_add_match_subsystem_devtype', + 'udev_monitor_filter_add_match_tag', + 'udev_monitor_filter_remove'], + ''], + ['udev_monitor_new_from_netlink', + '3', + ['udev_monitor_ref', 'udev_monitor_unref'], + ''], + ['udev_monitor_receive_device', + '3', + ['udev_monitor_enable_receiving', + 'udev_monitor_get_fd', + 'udev_monitor_get_udev', + 'udev_monitor_set_receive_buffer_size'], + ''], + ['udev_new', '3', ['udev_ref', 'udev_unref'], ''], + ['udevadm', '8', [], ''], + ['user@.service', + '5', + ['systemd-user-runtime-dir', 'user-runtime-dir@.service'], + ''], + ['userdbctl', '1', [], 'ENABLE_USERDB'], + ['vconsole.conf', '5', [], 'ENABLE_VCONSOLE'], + ['veritytab', '5', [], 'HAVE_LIBCRYPTSETUP'] +] +# Really, do not edit. diff --git a/man/runlevel.xml b/man/runlevel.xml new file mode 100644 index 0000000..f5e1e00 --- /dev/null +++ b/man/runlevel.xml @@ -0,0 +1,162 @@ + + + + + + + + runlevel + systemd + + + + runlevel + 8 + + + + runlevel + Print previous and current SysV runlevel + + + + + runlevel + options + + + + + Overview + + "Runlevels" are an obsolete way to start and stop groups of + services used in SysV init. systemd provides a compatibility layer + that maps runlevels to targets, and associated binaries like + runlevel. Nevertheless, only one runlevel can + be "active" at a given time, while systemd can activate multiple + targets concurrently, so the mapping to runlevels is confusing + and only approximate. Runlevels should not be used in new code, + and are mostly useful as a shorthand way to refer the matching + systemd targets in kernel boot parameters. + + + Mapping between runlevels and systemd targets + + + + + + Runlevel + Target + + + + + 0 + poweroff.target + + + 1 + rescue.target + + + 2, 3, 4 + multi-user.target + + + 5 + graphical.target + + + 6 + reboot.target + + + +
+ + + + Description + + runlevel prints the previous and current + SysV runlevel if they are known. + + The two runlevel characters are separated by a single space + character. If a runlevel cannot be determined, N is printed + instead. If neither can be determined, the word "unknown" is + printed. + + Unless overridden in the environment, this will check the + utmp database for recent runlevel changes. + + + + Options + + The following option is understood: + + + + + + + + + + + + + Exit status + + If one or both runlevels could be determined, 0 is returned, + a non-zero failure code otherwise. + + + + + Environment + + + + $RUNLEVEL + + If $RUNLEVEL is set, + runlevel will print this value as current + runlevel and ignore utmp. + + + + $PREVLEVEL + + If $PREVLEVEL is set, + runlevel will print this value as previous + runlevel and ignore utmp. + + + + + + Files + + + + /run/utmp + + The utmp database runlevel reads the previous and current runlevel + from. + + + + + + See Also + + systemd1, + systemd.target5, + systemctl1 + + + diff --git a/man/sd-bus-container-append.c b/man/sd-bus-container-append.c new file mode 100644 index 0000000..8bb4f33 --- /dev/null +++ b/man/sd-bus-container-append.c @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include + +int append_strings_to_message(sd_bus_message *m, const char *const *arr) { + int r; + + r = sd_bus_message_open_container(m, 'a', "s"); + if (r < 0) + return r; + + for (const char *s = *arr; *s; s++) { + r = sd_bus_message_append(m, "s", s); + if (r < 0) + return r; + } + + return sd_bus_message_close_container(m); +} diff --git a/man/sd-bus-container-read.c b/man/sd-bus-container-read.c new file mode 100644 index 0000000..5ede316 --- /dev/null +++ b/man/sd-bus-container-read.c @@ -0,0 +1,27 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include + +#include + +int read_strings_from_message(sd_bus_message *m) { + int r; + + r = sd_bus_message_enter_container(m, 'a', "s"); + if (r < 0) + return r; + + for (;;) { + const char *s; + + r = sd_bus_message_read(m, "s", &s); + if (r < 0) + return r; + if (r == 0) + break; + + printf("%s\n", s); + } + + return sd_bus_message_exit_container(m); +} diff --git a/man/sd-bus-errors.xml b/man/sd-bus-errors.xml new file mode 100644 index 0000000..f3b1515 --- /dev/null +++ b/man/sd-bus-errors.xml @@ -0,0 +1,275 @@ + + + + + + + + sd-bus-errors + systemd + + + + sd-bus-errors + 3 + + + + sd-bus-errors + SD_BUS_ERROR_FAILED + SD_BUS_ERROR_NO_MEMORY + SD_BUS_ERROR_SERVICE_UNKNOWN + SD_BUS_ERROR_NAME_HAS_NO_OWNER + SD_BUS_ERROR_NO_REPLY + SD_BUS_ERROR_IO_ERROR + SD_BUS_ERROR_BAD_ADDRESS + SD_BUS_ERROR_NOT_SUPPORTED + SD_BUS_ERROR_LIMITS_EXCEEDED + SD_BUS_ERROR_ACCESS_DENIED + SD_BUS_ERROR_AUTH_FAILED + SD_BUS_ERROR_NO_SERVER + SD_BUS_ERROR_TIMEOUT + SD_BUS_ERROR_NO_NETWORK + SD_BUS_ERROR_ADDRESS_IN_USE + SD_BUS_ERROR_DISCONNECTED + SD_BUS_ERROR_INVALID_ARGS + SD_BUS_ERROR_FILE_NOT_FOUND + SD_BUS_ERROR_FILE_EXISTS + SD_BUS_ERROR_UNKNOWN_METHOD + SD_BUS_ERROR_UNKNOWN_OBJECT + SD_BUS_ERROR_UNKNOWN_INTERFACE + SD_BUS_ERROR_UNKNOWN_PROPERTY + SD_BUS_ERROR_PROPERTY_READ_ONLY + SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN + SD_BUS_ERROR_INVALID_SIGNATURE + SD_BUS_ERROR_INCONSISTENT_MESSAGE + SD_BUS_ERROR_MATCH_RULE_NOT_FOUND + SD_BUS_ERROR_MATCH_RULE_INVALID + SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED + + Standard D-Bus error names + + + + + #include <systemd/sd-bus.h> + +#define SD_BUS_ERROR_FAILED "org.freedesktop.DBus.Error.Failed" +#define SD_BUS_ERROR_NO_MEMORY "org.freedesktop.DBus.Error.NoMemory" +#define SD_BUS_ERROR_SERVICE_UNKNOWN "org.freedesktop.DBus.Error.ServiceUnknown" +#define SD_BUS_ERROR_NAME_HAS_NO_OWNER "org.freedesktop.DBus.Error.NameHasNoOwner" +#define SD_BUS_ERROR_NO_REPLY "org.freedesktop.DBus.Error.NoReply" +#define SD_BUS_ERROR_IO_ERROR "org.freedesktop.DBus.Error.IOError" +#define SD_BUS_ERROR_BAD_ADDRESS "org.freedesktop.DBus.Error.BadAddress" +#define SD_BUS_ERROR_NOT_SUPPORTED "org.freedesktop.DBus.Error.NotSupported" +#define SD_BUS_ERROR_LIMITS_EXCEEDED "org.freedesktop.DBus.Error.LimitsExceeded" +#define SD_BUS_ERROR_ACCESS_DENIED "org.freedesktop.DBus.Error.AccessDenied" +#define SD_BUS_ERROR_AUTH_FAILED "org.freedesktop.DBus.Error.AuthFailed" +#define SD_BUS_ERROR_NO_SERVER "org.freedesktop.DBus.Error.NoServer" +#define SD_BUS_ERROR_TIMEOUT "org.freedesktop.DBus.Error.Timeout" +#define SD_BUS_ERROR_NO_NETWORK "org.freedesktop.DBus.Error.NoNetwork" +#define SD_BUS_ERROR_ADDRESS_IN_USE "org.freedesktop.DBus.Error.AddressInUse" +#define SD_BUS_ERROR_DISCONNECTED "org.freedesktop.DBus.Error.Disconnected" +#define SD_BUS_ERROR_INVALID_ARGS "org.freedesktop.DBus.Error.InvalidArgs" +#define SD_BUS_ERROR_FILE_NOT_FOUND "org.freedesktop.DBus.Error.FileNotFound" +#define SD_BUS_ERROR_FILE_EXISTS "org.freedesktop.DBus.Error.FileExists" +#define SD_BUS_ERROR_UNKNOWN_METHOD "org.freedesktop.DBus.Error.UnknownMethod" +#define SD_BUS_ERROR_UNKNOWN_OBJECT "org.freedesktop.DBus.Error.UnknownObject" +#define SD_BUS_ERROR_UNKNOWN_INTERFACE "org.freedesktop.DBus.Error.UnknownInterface" +#define SD_BUS_ERROR_UNKNOWN_PROPERTY "org.freedesktop.DBus.Error.UnknownProperty" +#define SD_BUS_ERROR_PROPERTY_READ_ONLY "org.freedesktop.DBus.Error.PropertyReadOnly" +#define SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN "org.freedesktop.DBus.Error.UnixProcessIdUnknown" +#define SD_BUS_ERROR_INVALID_SIGNATURE "org.freedesktop.DBus.Error.InvalidSignature" +#define SD_BUS_ERROR_INCONSISTENT_MESSAGE "org.freedesktop.DBus.Error.InconsistentMessage" +#define SD_BUS_ERROR_MATCH_RULE_NOT_FOUND "org.freedesktop.DBus.Error.MatchRuleNotFound" +#define SD_BUS_ERROR_MATCH_RULE_INVALID "org.freedesktop.DBus.Error.MatchRuleInvalid" +#define SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED \ + "org.freedesktop.DBus.Error.InteractiveAuthorizationRequired" + + + + + + Description + + In addition to the error names user programs define, D-Bus + knows a number of generic, standardized error names that are + listed below. + + In addition to this list, in sd-bus, the special error + namespace System.Error. is used to map + arbitrary Linux system errors (as defined by errno3) + to D-Bus errors and back. For example, the error + EUCLEAN is mapped to + System.Error.EUCLEAN and back. + + + + + SD_BUS_ERROR_FAILED + A generic error indication. See the error + message for further details. This error name should be + avoided, in favor of a more expressive error + name. + + + + SD_BUS_ERROR_NO_MEMORY + A memory allocation failed, and the requested + operation could not be completed. + + + + SD_BUS_ERROR_SERVICE_UNKNOWN + The contacted bus service is unknown and + cannot be activated. + + + + SD_BUS_ERROR_NAME_HAS_NO_OWNER + The specified bus service name currently has + no owner. + + + SD_BUS_ERROR_NO_REPLY + A message did not receive a reply. This error + is usually generated after a timeout. + + + SD_BUS_ERROR_IO_ERROR + Generic input/output error, for example when + accessing a socket or other I/O context. + + + SD_BUS_ERROR_BAD_ADDRESS + The specified D-Bus bus address string is + malformed. + + + SD_BUS_ERROR_NOT_SUPPORTED + The requested operation is not supported on + the local system. + + + SD_BUS_ERROR_LIMITS_EXCEEDED + Some limited resource has been + exhausted. + + + SD_BUS_ERROR_ACCESS_DENIED + Access to a resource has been denied due to security restrictions. + + + SD_BUS_ERROR_AUTH_FAILED + Authentication did not complete successfully. + + + SD_BUS_ERROR_NO_SERVER + Unable to connect to the specified server. + + + SD_BUS_ERROR_TIMEOUT + An operation timed out. Note that method calls + which timeout generate a + SD_BUS_ERROR_NO_REPLY. + + + SD_BUS_ERROR_NO_NETWORK + No network available to execute requested network operation on. + + + SD_BUS_ERROR_ADDRESS_IN_USE + The specified network address is already being listened on. + + + SD_BUS_ERROR_DISCONNECTED + The connection has been terminated. + + + SD_BUS_ERROR_INVALID_ARGS + One or more invalid arguments have been passed. + + + SD_BUS_ERROR_FILE_NOT_FOUND + The requested file could not be found. + + + SD_BUS_ERROR_FILE_EXISTS + The requested file already exists. + + + SD_BUS_ERROR_UNKNOWN_METHOD + The requested method does not exist in the selected interface. + + + SD_BUS_ERROR_UNKNOWN_OBJECT + The requested object does not exist in the selected service. + + + SD_BUS_ERROR_UNKNOWN_INTERFACE + The requested interface does not exist on the selected object. + + + SD_BUS_ERROR_UNKNOWN_PROPERTY + The requested property does not exist in the selected interface. + + + SD_BUS_ERROR_PROPERTY_READ_ONLY + A write operation was requested on a read-only property. + + + SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN + The requested PID is not known. + + + SD_BUS_ERROR_INVALID_SIGNATURE + The specified message signature is not + valid. + + + + SD_BUS_ERROR_INCONSISTENT_MESSAGE + The passed message does not validate + correctly. + + + SD_BUS_ERROR_MATCH_RULE_NOT_FOUND + The specified match rule does not exist. + + + SD_BUS_ERROR_MATCH_RULE_INVALID + The specified match rule is invalid. + + + SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED + Access to the requested operation is not + permitted. However, it might be available after interactive + authentication. This is usually returned by method calls + supporting a framework for additional interactive + authorization, when interactive authorization was not enabled + with the + sd_bus_message_set_allow_interactive_authorization3 + for the method call message. + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_error3, + sd_bus_message_set_allow_interactive_authorization3, + errno3, + strerror_r3 + + + + diff --git a/man/sd-bus.xml b/man/sd-bus.xml new file mode 100644 index 0000000..f43af89 --- /dev/null +++ b/man/sd-bus.xml @@ -0,0 +1,192 @@ + + + + + + + + sd-bus + systemd + + + + sd-bus + 3 + + + + sd-bus + A lightweight D-Bus IPC client library + + + + + #include <systemd/sd-bus.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-bus.h provides an implementation of a D-Bus IPC client. See + + for more information about D-Bus IPC. + + + See + sd_bus_add_match3, +sd_bus_add_object3, +sd_bus_add_object_manager3, +sd_bus_add_object_vtable3, +sd_bus_add_fallback3, +sd_bus_add_fallback_vtable3, +sd_bus_add_filter3, +sd_bus_add_node_enumerator3, +sd_bus_attach_event3, +sd_bus_call3, +sd_bus_call_async3, +sd_bus_call_method3, +sd_bus_call_method_async3, +sd_bus_can_send3, +sd_bus_close3, +sd_bus_creds_get_pid3, +sd_bus_creds_new_from_pid3, +sd_bus_default3, +sd_bus_emit_interfaces_added3, +sd_bus_emit_interfaces_added_strv3, +sd_bus_emit_interfaces_removed3, +sd_bus_emit_interfaces_removed_strv3, +sd_bus_emit_object_added3, +sd_bus_emit_object_removed3, +sd_bus_emit_properties_changed3, +sd_bus_emit_properties_changed_strv3, +sd_bus_emit_signal3, +sd_bus_emit_signalv3, +sd-bus-errors3, +sd_bus_error3, +sd_bus_error_add_map3, +sd_bus_get_address3, +sd_bus_get_allow_interactive_authorization3, +sd_bus_get_bus_id3, +sd_bus_get_creds_mask3, +sd_bus_get_current_handler3, +sd_bus_get_current_message3, +sd_bus_get_current_slot3, +sd_bus_get_current_userdata3, +sd_bus_get_exit_on_disconnect3, +sd_bus_get_fd3, +sd_bus_get_method_call_timeout3, +sd_bus_get_n_queued_read3, +sd_bus_get_name_creds3, +sd_bus_get_name_machine_id3, +sd_bus_get_owner_creds3, +sd_bus_get_property3, +sd_bus_get_property_string3, +sd_bus_get_property_strv3, +sd_bus_get_property_trivial3, +sd_bus_get_scope3, +sd_bus_get_tid3, +sd_bus_get_unique_name3, +sd_bus_interface_name_is_valid3, +sd_bus_is_bus_client3, +sd_bus_is_monitor3, +sd_bus_is_server3, +sd_bus_list_names3, +sd_bus_message_append3, +sd_bus_message_append_array3, +sd_bus_message_append_basic3, +sd_bus_message_append_string_memfd3, +sd_bus_message_append_strv3, +sd_bus_message_at_end3, +sd_bus_message_close_container3, +sd_bus_message_copy3, +sd_bus_message_dump3, +sd_bus_message_enter_container3, +sd_bus_message_exit_container3, +sd_bus_message_get_allow_interactive_authorization3, +sd_bus_message_get_cookie3, +sd_bus_message_get_creds3, +sd_bus_message_get_errno3, +sd_bus_message_get_error3, +sd_bus_message_get_monotonic_usec3, +sd_bus_message_get_sender3, +sd_bus_message_get_signature3, +sd_bus_message_get_type3, +sd_bus_message_new3, +sd_bus_message_new_method_call3, +sd_bus_message_new_method_error3, +sd_bus_message_new_signal3, +sd_bus_message_open_container3, +sd_bus_message_peek_type3, +sd_bus_message_read3, +sd_bus_message_read_array3, +sd_bus_message_read_basic3, +sd_bus_message_read_strv3, +sd_bus_message_rewind3, +sd_bus_message_seal3, +sd_bus_message_send3, +sd_bus_message_set_allow_interactive_authorization3, +sd_bus_message_set_destination3, +sd_bus_message_set_expect_reply3, +sd_bus_message_set_sender3, +sd_bus_message_skip3, +sd_bus_message_verify_type3, +sd_bus_negotiate_fds3, +sd_bus_new3, +sd_bus_path_encode3, +sd_bus_process3, +sd_bus_query_sender_creds3, +sd_bus_query_sender_privilege3, +sd_bus_reply_method_error3, +sd_bus_reply_method_return3, +sd_bus_request_name3, +sd_bus_send3, +sd_bus_send_to3, +sd_bus_set_address3, +sd_bus_set_allow_interactive_authorization3, +sd_bus_set_bus_client3, +sd_bus_set_close_on_exit3, +sd_bus_set_connected_signal3, +sd_bus_set_description3, +sd_bus_set_exit_on_disconnect3, +sd_bus_set_method_call_timeout3, +sd_bus_set_monitor3, +sd_bus_set_property3, +sd_bus_set_propertyv3, +sd_bus_set_sender3, +sd_bus_set_server3, +sd_bus_set_watch_bind3 +sd_bus_slot_get_current_handler3, +sd_bus_slot_get_current_message3, +sd_bus_slot_get_current_userdata3, +sd_bus_slot_set_description3, +sd_bus_slot_set_destroy_callback3, +sd_bus_slot_set_floating3, +sd_bus_slot_set_userdata3, +sd_bus_start3, +sd_bus_track_add_name3, +sd_bus_track_new3 + + for more information about the functions available. + + + + + + See Also + + systemd1, + sd-event3, + busctl1, + dbus-daemon1, + dbus-send1 + + + + diff --git a/man/sd-daemon.xml b/man/sd-daemon.xml new file mode 100644 index 0000000..5dee3e8 --- /dev/null +++ b/man/sd-daemon.xml @@ -0,0 +1,114 @@ + + + + + + + + sd-daemon + systemd + + + + sd-daemon + 3 + + + + sd-daemon + SD_EMERG + SD_ALERT + SD_CRIT + SD_ERR + SD_WARNING + SD_NOTICE + SD_INFO + SD_DEBUG + APIs for + new-style daemons + + + + + #include <systemd/sd-daemon.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-daemon.h provides APIs for new-style + daemons, as implemented by the + systemd1 + service manager. + + See + sd_listen_fds3, + sd_notify3, + sd_booted3, + sd_is_fifo3, + sd_watchdog_enabled3 + for more information about the functions implemented. In addition + to these functions, a couple of logging prefixes are defined as + macros: + + #define SD_EMERG "<0>" /* system is unusable */ +#define SD_ALERT "<1>" /* action must be taken immediately */ +#define SD_CRIT "<2>" /* critical conditions */ +#define SD_ERR "<3>" /* error conditions */ +#define SD_WARNING "<4>" /* warning conditions */ +#define SD_NOTICE "<5>" /* normal but significant condition */ +#define SD_INFO "<6>" /* informational */ +#define SD_DEBUG "<7>" /* debug-level messages */ + + These prefixes are intended to be used in conjunction with stderr-based logging (or stdout-based + logging) as implemented by systemd. If a systemd service definition file is configured with + StandardError=journal or StandardError=kmsg (and similar with + StandardOutput=), these prefixes can be used to encode a log level in lines + printed. This is similar to the kernel printk()-style logging. See + klogctl2 for more + information. + + The log levels are identical to + syslog3's + log level system. To use these prefixes simply prefix every line + with one of these strings. A line that is not prefixed will be + logged at the default log level SD_INFO. + + + Hello World + + A daemon may log with the log level NOTICE by issuing this + call: + + fprintf(stderr, SD_NOTICE "Hello World!\n"); + + + + + + + See Also + + systemd1, + sd_listen_fds3, + sd_notify3, + sd_booted3, + sd_is_fifo3, + sd_watchdog_enabled3, + daemon7, + systemd.service5, + systemd.socket5, + fprintf3, + pkg-config1 + + + + diff --git a/man/sd-device.xml b/man/sd-device.xml new file mode 100644 index 0000000..7af839b --- /dev/null +++ b/man/sd-device.xml @@ -0,0 +1,62 @@ + + + + + + + + sd-device + systemd + + + + sd-device + 3 + + + + sd-device + API for enumerating and introspecting local devices + + + + + #include <systemd/sd-device.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-device.h provides an API to introspect and enumerate devices on the local + system. It provides a programmatic interface to the database of devices and their properties mananaged by + systemd-udevd.service8. + This API is a replacement for + libudev3 and + libudev.h. + + See + sd_device_get_syspath3, +sd_device_ref3 + + for more information about the functions available. + + + + + + See Also + + systemd1, + sd-event3, + udevadm8 + + + + diff --git a/man/sd-event.xml b/man/sd-event.xml new file mode 100644 index 0000000..1bcf4e3 --- /dev/null +++ b/man/sd-event.xml @@ -0,0 +1,164 @@ + + + + + + + + sd-event + systemd + + + + sd-event + 3 + + + + sd-event + A generic event loop implementation + + + + + #include <systemd/sd-event.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-event.h provides a generic event + loop implementation, based on Linux epoll7. + + + See + sd_event_new3, + sd_event_run3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_unref3, + sd_event_source_set_priority3, + sd_event_source_set_enabled3, + sd_event_source_set_userdata3, + sd_event_source_get_event3, + sd_event_source_get_pending3, + sd_event_source_set_description3, + sd_event_source_set_prepare3, + sd_event_source_set_ratelimit3, + sd_event_wait3, + sd_event_get_fd3, + sd_event_set_watchdog3, + sd_event_exit3, + sd_event_now3 + for more information about the functions available. + + The event loop design is targeted on running a separate + instance of the event loop in each thread; it has no concept of + distributing events from a single event loop instance onto + multiple worker threads. Dispatching events is strictly ordered + and subject to configurable priorities. In each event loop + iteration a single event source is dispatched. Each time an event + source is dispatched the kernel is polled for new events, before + the next event source is dispatched. The event loop is designed to + honor priorities and provide fairness within each priority. It is + not designed to provide optimal throughput, as this contradicts + these goals due the limitations of the underlying epoll7 + primitives. + + The event loop implementation provides the following features: + + + I/O event sources, based on epoll7's + file descriptor watching, including edge triggered events (EPOLLET). See sd_event_add_io3. + + Timer event sources, based on timerfd_create2, + supporting the CLOCK_MONOTONIC, + CLOCK_REALTIME, + CLOCK_BOOTIME clocks, as well as the + CLOCK_REALTIME_ALARM and + CLOCK_BOOTTIME_ALARM clocks that can resume + the system from suspend. When creating timer events a required + accuracy parameter may be specified which allows coalescing of + timer events to minimize power consumption. See sd_event_add_time3. + + UNIX process signal events, based on + signalfd2, + including full support for real-time signals, and queued parameters. See sd_event_add_signal3. + + Child process state change events, based on + waitid2. See sd_event_add_child3. + + Static event sources, of three types: defer, + post and exit, for invoking calls in each event loop, after + other event sources or at event loop termination. See + sd_event_add_defer3. + + Event sources may be assigned a 64bit priority + value, that controls the order in which event sources are + dispatched if multiple are pending simultaneously. See + sd_event_source_set_priority3. + + The event loop may automatically send watchdog + notification messages to the service manager. See + sd_event_set_watchdog3. + + The event loop may be integrated into foreign + event loops, such as the GLib one. See + sd_event_get_fd3 + for an example. + + + + + + + + See Also + + systemd1, + sd_event_new3, + sd_event_run3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_unref3, + sd_event_source_set_priority3, + sd_event_source_set_enabled3, + sd_event_source_set_userdata3, + sd_event_source_get_event3, + sd_event_source_get_pending3, + sd_event_source_set_description3, + sd_event_source_set_prepare3, + sd_event_source_set_ratelimit3, + sd_event_wait3, + sd_event_get_fd3, + sd_event_set_watchdog3, + sd_event_exit3, + sd_event_now3, + epoll7, + timerfd_create2, + signalfd2, + waitid2 + + + + diff --git a/man/sd-hwdb.xml b/man/sd-hwdb.xml new file mode 100644 index 0000000..254c218 --- /dev/null +++ b/man/sd-hwdb.xml @@ -0,0 +1,57 @@ + + + + + + + + sd-hwdb + systemd + + + + sd-hwdb + 3 + + + + sd-hwdb + Read-only access to the hardware description database + + + + + #include <systemd/sd-hwdb.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-hwdb.h allows read-only access the systemd database of hardware properties. + See hwdb7 and + systemd-hwdb8 for more + information about the database. + + See sd_hwdb_new3 + and sd_hwdb_get3 for + information about the functions available. + + + + + + See Also + + systemd1, + systemd-udevd.service8 + + + + diff --git a/man/sd-id128.xml b/man/sd-id128.xml new file mode 100644 index 0000000..c869943 --- /dev/null +++ b/man/sd-id128.xml @@ -0,0 +1,283 @@ + + + + + + + + sd-id128 + systemd + + + + sd-id128 + 3 + + + + sd-id128 + SD_ID128_ALLF + SD_ID128_CONST_STR + SD_ID128_FORMAT_STR + SD_ID128_FORMAT_VAL + SD_ID128_MAKE + SD_ID128_MAKE_STR + SD_ID128_MAKE_UUID_STR + SD_ID128_NULL + SD_ID128_UUID_FORMAT_STR + sd_id128_equal + sd_id128_string_equal + sd_id128_in_set + sd_id128_in_set_sentinel + sd_id128_in_setv + sd_id128_is_allf + sd_id128_is_null + sd_id128_t + APIs for processing 128-bit IDs + + + + + #include <systemd/sd-id128.h> + + + SD_ID128_ALLF + + + SD_ID128_NULL + + + SD_ID128_CONST_STR(id) + + + SD_ID128_FORMAT_STR + + + SD_ID128_FORMAT_VAL(id) + + + SD_ID128_MAKE(v0, v1, v2, v3, v4, v5, v6, v7, v8, v9, vA, vB, vC, vD, vE, vF) + + + SD_ID128_MAKE_STR(v0, v1, v2, v3, v4, v5, v6, v7, v8, v9, vA, vB, vC, vD, vE, vF) + + + SD_ID128_MAKE_UUID_STR(v0, v1, v2, v3, v4, v5, v6, v7, v8, v9, vA, vB, vC, vD, vE, vF) + + + SD_ID128_UUID_FORMAT_STR + + + + int sd_id128_equal + sd_id128_t a + sd_id128_t b + + + + int sd_id128_string_equal + const char *a + sd_id128_t b + + + + int sd_id128_is_null + sd_id128_t id + + + + int sd_id128_is_allf + sd_id128_t id + + + + int sd_id128_in_setv + sd_id128_t id + va_list ap + + + + int sd_id128_in_set_sentinel + sd_id128_t id + … + SD_ID128_NULL + + + + int sd_id128_in_set + sd_id128_t id + … + + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-id128.h provides APIs to generate, convert, and compare 128-bit ID values. + The 128-bit ID values processed and generated by these APIs are a generalization of OSF UUIDs as defined + by RFC 4122 but use a simpler string format. + These functions impose no structure on the used IDs, much unlike OSF UUIDs or Microsoft GUIDs, but are + mostly compatible with those types of IDs. + + + A 128-bit ID is implemented as the following + union type: + + typedef union sd_id128 { + uint8_t bytes[16]; + uint64_t qwords[2]; +} sd_id128_t; + + This union type allows accessing the 128-bit ID as 16 separate bytes or two 64-bit words. It is + generally safer to access the ID components by their 8-bit array to avoid endianness issues. This union + is intended to be passed by value (as opposed to pass-by-reference) and may be directly manipulated by + clients. + + A couple of macros are defined to denote and decode 128-bit + IDs: + + SD_ID128_MAKE() is used to write a constant ID in source code. A commonly used + idiom is to assign a name to an ID using this macro: + + #define SD_MESSAGE_COREDUMP SD_ID128_MAKE(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1) + + SD_ID128_NULL defines an ID consisting of only NUL bytes + (i.e. all bits off). + + SD_ID128_ALLF defines an ID consisting of only 0xFF bytes + (i.e. all bits on). + + SD_ID128_MAKE_STR() is similar to SD_ID128_MAKE(), but + creates a const char* expression that can be conveniently used in message formats and + such: + + #include <stdio.h> +#define SD_MESSAGE_COREDUMP_STR SD_ID128_MAKE_STR(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1) + +int main(int argc, char **argv) { + puts("Match for coredumps: MESSAGE_ID=" SD_MESSAGE_COREDUMP_STR); +} + + SD_ID128_CONST_STR() converts constant IDs into constant strings for + output. The following example code will output the string "fc2e22bc6ee647b6b90729ab34a250b1": + int main(int argc, char *argv[]) { + puts("Match for coredumps: %s", SD_ID128_CONST_STR(SD_MESSAGE_COREDUMP)); +} + + SD_ID128_FORMAT_STR and SD_ID128_FORMAT_VAL() is used to + format an ID in a printf3 format + string, as shown in the following example: + + int main(int argc, char *argv[]) { + sd_id128_t id; + id = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); + printf("The ID encoded in this C file is " SD_ID128_FORMAT_STR ".\n", SD_ID128_FORMAT_VAL(id)); + return 0; +} + + SD_ID128_UUID_FORMAT_STR and SD_ID128_MAKE_UUID_STR() + are similar to + SD_ID128_FORMAT_STR and SD_ID128_MAKE_STR(), + but include separating hyphens to conform to the + "canonical representation". + They format the string based on RFC4122 Variant 1 rules, i.e. converting from Big + Endian byte order. This matches behaviour of most other Linux userspace infrastructure. It's probably + best to avoid UUIDs of other variants, in order to avoid unnecessary ambiguities. All 128-bit IDs + generated by the sd-id128 APIs strictly conform to Variant 1 Version 4 UUIDs, as per RFC 4122. + + sd_id128_equal() compares two 128-bit IDs: + + int main(int argc, char *argv[]) { + sd_id128_t a, b, c; + a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); + b = SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e); + c = a; + assert(sd_id128_equal(a, c)); + assert(!sd_id128_equal(a, b)); + return 0; +} + + sd_id128_string_equal() is similar to sd_id128_equal(), + but the first ID is formatted as const char*. The same restrictions apply as to the first + argument of sd_id128_from_string(). + + sd_id128_is_null() checks if an ID consists of only NUL + bytes: + + assert(sd_id128_is_null(SD_ID128_NULL)); + + Similarly, sd_id128_is_allf() checks if an ID consists of only + 0xFF bytes (all bits on): + + assert(sd_id128_is_allf(SD_ID128_ALLF)); + + sd_id128_in_set_sentinel() takes a list of IDs and returns true if the first + argument is equal to any of the subsequent arguments. The argument list is terminated by an + SD_ID128_NULL sentinel, which must be present. + + sd_id128_in_set() is a convenience function that takes a list of IDs and + returns true if the first argument is equal to any of the subsequent arguments: + + int main(int argc, char *argv[]) { + sd_id12_t a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07); + assert(sd_id128_in_set(a, a)); + assert(sd_id128_in_set(a, a, a)); + assert(!sd_id128_in_set(a)); + assert(!sd_id128_in_set(a, + SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e) + SD_ID128_MAKE(2f,88,28,5f,9c,44,09,9d,d7,15,77,04,bc,85,7e,e3) + SD_ID128_ALLF)); + return 0; +} + + + sd_id128_in_set() is defined as a macro over + sd_id128_in_set_sentinel(), adding the SD_ID128_NULL sentinel + automatically. Since sd_id128_in_set_sentinel() uses + SD_ID128_NULL as the sentinel, SD_ID128_NULL cannot be + otherwise placed in the argument list. + + sd_id128_in_setv() is similar to + sd_id128_in_set_sentinel(), but takes a struct varargs + argument. + + New randomized IDs may be generated with + systemd-id1281's + new command. + + See + sd_id128_to_string3, + sd_id128_randomize3 + and + sd_id128_get_machine3 + for information about other implemented functions. + + + + + + See Also + + systemd1, + sd_id128_to_string3, + sd_id128_randomize3, + sd_id128_get_machine3, + printf3, + journalctl1, + sd-journal7, + pkg-config1, + machine-id5 + + + + diff --git a/man/sd-journal.xml b/man/sd-journal.xml new file mode 100644 index 0000000..4609868 --- /dev/null +++ b/man/sd-journal.xml @@ -0,0 +1,118 @@ + + + + + + + + sd-journal + systemd + + + + sd-journal + 3 + + + + sd-journal + APIs for submitting and querying log entries to and + from the journal + + + + + #include <systemd/sd-journal.h> + + + + pkg-config --cflags --libs libsystemd + + + + + + Description + + sd-journal.h provides APIs to submit + and query log entries. The APIs exposed act both as client for the + systemd-journald.service8 + journal service and as parser for the journal files on disk. + + + See + sd_journal_print3, + sd_journal_stream_fd3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_realtime_usec3, + sd_journal_add_match3, + sd_journal_seek_head3, + sd_journal_enumerate_fields3, + sd_journal_get_cursor3, + sd_journal_get_cutoff_realtime_usec3, + sd_journal_get_cutoff_monotonic_usec3, + sd_journal_get_usage3, + sd_journal_get_catalog3, + sd_journal_get_fd3, + sd_journal_has_runtime_files3 + and + sd_journal_has_persistent_files3 + for more information about the functions implemented. + + Command line access for submitting entries to the journal is + available with the + systemd-cat1 + tool. Command line access for querying entries from the journal is + available with the + journalctl1 + tool. + + + + Thread safety + + Functions that operate on sd_journal objects are thread agnostic — given + sd_journal pointer may only be used from one specific thread at all times (and it has to + be the very same one during the entire lifetime of the object), but multiple, independent threads may use multiple, + independent objects safely. Other functions — those that are used to send entries to the journal, like + sd_journal_print3 and similar, + or those that are used to retrieve global information like + sd_journal_stream_fd3 and + sd_journal_get_catalog_for_message_id3 + — are fully thread-safe and may be called from multiple threads in parallel. + + + + + + See Also + + systemd1, + sd_journal_print3, + sd_journal_stream_fd3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_data3, + sd_journal_get_realtime_usec3, + sd_journal_add_match3, + sd_journal_seek_head3, + sd_journal_enumerate_fields3, + sd_journal_get_cursor3, + sd_journal_get_cutoff_realtime_usec3, + sd_journal_get_cutoff_monotonic_usec3, + sd_journal_get_usage3, + sd_journal_get_fd3, + sd_journal_query_unique3, + sd_journal_get_catalog3, + sd_journal_has_runtime_files3, + sd_journal_has_persistent_files3, + journalctl1, + sd-id1283, + pkg-config1 + + + + diff --git a/man/sd-login.xml b/man/sd-login.xml new file mode 100644 index 0000000..0127b69 --- /dev/null +++ b/man/sd-login.xml @@ -0,0 +1,247 @@ + + + + + + + + sd-login + systemd + + + + sd-login + 3 + + + + sd-login + APIs for + tracking logins + + + + + #include <systemd/sd-login.h> + + + + pkg-config --cflags --libs libsystemd + + + + + Description + + sd-login.h provides APIs to introspect + and monitor seat, login session and user status information on the + local system. + + Note that these APIs only allow purely passive access and + monitoring of seats, sessions and users. To actively make changes + to the seat configuration, terminate login sessions, or switch + session on a seat you need to utilize the D-Bus API of + systemd-logind, instead. + + These functions synchronously access data in + /proc/, /sys/fs/cgroup/ + and /run/. All of these are virtual file + systems, hence the runtime cost of the accesses is relatively + cheap. + + It is possible (and often a very good choice) to mix calls + to the synchronous interface of sd-login.h + with the asynchronous D-Bus interface of systemd-logind. However, + if this is done you need to think a bit about possible races since + the stream of events from D-Bus and from + sd-login.h interfaces such as the login + monitor are asynchronous and not ordered against each + other. + + If the functions return string arrays, these are generally + NULL terminated and need to be freed by the + caller with the libc + free3 + call after use, including the strings referenced therein. + Similarly, individual strings returned need to be freed, as + well. + + As a special exception, instead of an empty string array + NULL may be returned, which should be treated + equivalent to an empty string array. + + See + sd_pid_get_session3, + sd_uid_get_state3, + sd_session_is_active3, + sd_seat_get_active3, + sd_get_seats3, + sd_login_monitor_new3 + for more information about the functions + implemented. + + + + Definition of Terms + + + + seat + + A seat consists of all hardware devices assigned to a specific + workplace. It consists of at least one graphics device, and usually also includes + keyboard, mouse. It can also include video cameras, sound cards and more. Seats + are identified by seat names, which are strings (<= 255 characters), that start + with the four characters seat followed by at least one + character from the range [a-zA-Z0-9], _ and + -. They are suitable for use as file names. Seat names may or + may not be stable and may be reused if a seat becomes available again. + + + + + session + + A session is defined by the time a user is logged in until they + log out. A session is bound to one or no seats (the latter for 'virtual' ssh + logins). Multiple sessions can be attached to the same seat, but only one of them + can be active, the others are in the background. A session is identified by a + short string. + + + systemd1 + ensures that audit sessions are identical to systemd sessions, and uses the audit + session ID as session ID in systemd (if auditing is enabled). In general the + session identifier is a short string consisting only of [a-zA-Z0-9], + _ and -, suitable for use as a file name. + Session IDs are unique on the local machine and are + never reused as long as the machine is online. A user (the way we know it on UNIX) + corresponds to the person using a computer. A single user can have multiple + sessions open at the same time. A user is identified by a numeric user id (UID) or + a user name (a string). A multi-session system allows multiple user sessions on + the same seat at the same time. A multi-seat system allows multiple independent + seats that can be individually and simultaneously used by different users. + + + + + All hardware devices that are eligible to being assigned to a seat, are assigned + to one. A device can be assigned to only one seat at a time. If a device is not + assigned to any particular other seat it is implicitly assigned to the special default + seat called seat0. + + Note that hardware like printers, hard disks or network cards is generally not + assigned to a specific seat. They are available to all seats equally. (Well, with one + exception: USB sticks can be assigned to a seat.) + + seat0 always exists. + + + + udev Rules + + Assignment of hardware devices to seats is managed inside the udev database, via + settings on the devices: + + + + Tag seat + + When set, a device is eligible to be assigned to a seat. This tag + is set for graphics devices, mice, keyboards, video cards, sound cards and + more. Note that some devices like sound cards consist of multiple subdevices + (i.e. a PCM for input and another one for output). This tag will be set only for + the originating device, not for the individual subdevices. A UI for configuring + assignment of devices to seats should enumerate and subscribe to all devices with + this tag set and show them in the UI. Note that USB hubs can be assigned to a seat + as well, in which case all (current and future) devices plugged into it will also + be assigned to the same seat (unless they are explicitly assigned to another + seat). + + + + + Tag master-of-seat + + When set, this device is enough for a seat to be considered + existent. This tag is usually set for the framebuffer device of graphics cards. A + seat hence consists of an arbitrary number of devices marked with the + seat tag, but (at least) one of these devices needs to be + tagged with master-of-seat before the seat is actually + considered to be around. + + + + Property ID_SEAT + + This property specifies the name of the seat a specific device is + assigned to. If not set the device is assigned to seat0. Also, + to speed up enumeration of hardware belonging to a specific seat, the seat is also + set as tag on the device. I.e. if the property + ID_SEAT=seat-waldo is set for a device, the tag + seat-waldo will be set as well. Note that if a device is + assigned to seat0, it will usually not carry such a tag and you + need to enumerate all devices and check the ID_SEAT property + manually. Again, if a device is assigned to seat0 this is visible on the device in + two ways: with a property ID_SEAT=seat0 and with no property + ID_SEAT set for it at all. + + + + Property ID_AUTOSEAT + + When set to 1, this device automatically + generates a new and independent seat, which is named after the path of the + device. This is set for specialized USB hubs like the Pluggable devices, which when + plugged in should create a hotplug seat without further configuration. + + + + + Property ID_FOR_SEAT + + When creating additional (manual) seats starting from a graphics + device this is a good choice to name the seat after. It is created from the path + of the device. This is useful in UIs for configuring seats: as soon as you create + a new seat from a graphics device, read this property and prefix it with + seat- and use it as name for the seat. + + + + A seat exists only and exclusively because a properly tagged device with the + right ID_SEAT property exists. Besides udev rules there is no + persistent data about seats stored on disk. + + Note that + systemd-logind8 + manages ACLs on a number of device classes, to allow user code to access the device + nodes attached to a seat as long as the user has an active session on it. This is + mostly transparent to applications. As mentioned above, for certain user software it + might be a good idea to watch whether they can access device nodes instead of thinking + about seats. + + + + + + See Also + + systemd1, + sd_pid_get_session3, + sd_uid_get_state3, + sd_session_is_active3, + sd_seat_get_active3, + sd_get_seats3, + sd_login_monitor_new3, + sd-daemon3, + pkg-config1 + + + + Multi-Seat on Linux + may also be of historical interest. + + + diff --git a/man/sd_booted.xml b/man/sd_booted.xml new file mode 100644 index 0000000..d9b3ddc --- /dev/null +++ b/man/sd_booted.xml @@ -0,0 +1,68 @@ + + + + + + + + sd_booted + systemd + + + + sd_booted + 3 + + + + sd_booted + Test whether the system is running the systemd init system + + + + + #include <systemd/sd-daemon.h> + + + int sd_booted + void + + + + + + Description + sd_booted() checks whether the system + was booted up using the systemd init system. + + + + Return Value + + On failure, this call returns a negative errno-style error + code. If the system was booted up with systemd as init system, + this call returns a positive return value, zero otherwise. + + + + Notes + + + + Internally, this function checks whether the directory + /run/systemd/system/ exists. A simple check + like this can also be implemented trivially in shell or any other + language. + + + + See Also + + systemd1, + sd-daemon3 + + + + diff --git a/man/sd_bus_add_match.xml b/man/sd_bus_add_match.xml new file mode 100644 index 0000000..429a2fd --- /dev/null +++ b/man/sd_bus_add_match.xml @@ -0,0 +1,173 @@ + + + + + + + + + sd_bus_add_match + systemd + + + + sd_bus_add_match + 3 + + + + sd_bus_add_match + sd_bus_add_match_async + sd_bus_match_signal + sd_bus_match_signal_async + + Add a match rule for incoming message dispatching + + + + + #include <systemd/sd-bus.h> + + + typedef int (*sd_bus_message_handler_t) + sd_bus_message *m + void *userdata + sd_bus_error *ret_error + + + + int sd_bus_add_match + sd_bus *bus + sd_bus_slot **slot + const char *match + sd_bus_message_handler_t callback + void *userdata + + + + int sd_bus_add_match_async + sd_bus *bus + sd_bus_slot **slot + const char *match + sd_bus_message_handler_t callback + sd_bus_message_handler_t install_callback + void *userdata + + + + int sd_bus_match_signal + sd_bus *bus + sd_bus_slot **slot + const char *sender + const char *path + const char *interface + const char *member + sd_bus_message_handler_t callback + void *userdata + + + + int sd_bus_match_signal_async + sd_bus *bus + sd_bus_slot **slot + const char *sender + const char *path + const char *interface + const char *member + sd_bus_message_handler_t callback + sd_bus_message_handler_t install_callback + void *userdata + + + + + + + Description + + sd_bus_add_match() installs a match rule for messages received on the specified bus + connection object bus. The syntax of the match rule expression passed in + match is described in the D-Bus Specification. The specified handler + function callback is called for each incoming message matching the specified expression, + the userdata parameter is passed as-is to the callback function. The match is installed + synchronously when connected to a bus broker, i.e. the call sends a control message requested the match to be added + to the broker and waits until the broker confirms the match has been installed successfully. + + sd_bus_add_match_async() operates very similarly to + sd_bus_add_match(), however it installs the match asynchronously, in a non-blocking + fashion: a request is sent to the broker, but the call does not wait for a response. The + install_callback function is called when the response is later received, with the response + message from the broker as parameter. If this function is specified as NULL a default + implementation is used that terminates the bus connection should installing the match fail. + + sd_bus_match_signal() is very similar to sd_bus_add_match(), but + only matches signals, and instead of a match expression accepts four parameters: sender (the + service name of the sender), path (the object path of the emitting object), + interface (the interface the signal belongs to), member (the signal + name), from which the match string is internally generated. Optionally, these parameters may be specified as + NULL in which case the relevant field of incoming signals is not tested. + + sd_bus_match_signal_async() combines the signal matching logic of + sd_bus_match_signal() with the asynchronous behaviour of + sd_bus_add_match_async(). + + On success, and if non-NULL, the slot return parameter will be + set to a slot object that may be used as a reference to the installed match, and may be utilized to remove it again + at a later time with + sd_bus_slot_unref3. If specified + as NULL the lifetime of the match is bound to the lifetime of the bus object itself, and the + match is generally not removed independently. See + sd_bus_slot_set_floating3 for + details. + + The message m passed to the callback is only borrowed, that is, the callback should + not call sd_bus_message_unref3 + on it. If the callback wants to hold on to the message beyond the lifetime of the callback, it needs to call + sd_bus_message_ref3 to create a + new reference. + + If an error occurs during the callback invocation, the callback should return a negative error number + (optionally, a more precise error may be returned in ret_error, as well). If it wants other + callbacks that match the same rule to be called, it should return 0. Otherwise it should return a positive integer. + + + If the bus refers to a direct connection (i.e. not a bus connection, as set with + sd_bus_set_bus_client3) the + match is only installed on the client side, and the synchronous and asynchronous functions operate the same. + + + + Return Value + + + On success, sd_bus_add_match() and the other calls return 0 or a positive integer. On + failure, they return a negative errno-style error code. + + + + + Notes + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_slot_unref3, + sd_bus_message_ref3, + sd_bus_set_bus_client3, + sd_bus_slot_set_floating3 + + + + diff --git a/man/sd_bus_add_node_enumerator.xml b/man/sd_bus_add_node_enumerator.xml new file mode 100644 index 0000000..c6beb1d --- /dev/null +++ b/man/sd_bus_add_node_enumerator.xml @@ -0,0 +1,138 @@ + + + + + + + + sd_bus_add_node_enumerator + systemd + + + + sd_bus_add_node_enumerator + 3 + + + + sd_bus_add_node_enumerator + + Add a node enumerator for a D-Bus object path prefix + + + + + #include <systemd/sd-bus.h> + + + typedef int (*sd_bus_node_enumerator_t) + sd_bus *bus + const char *prefix + void *userdata + char ***ret_nodes + sd_bus_error *ret_error + + + + int sd_bus_add_node_enumerator + sd_bus *bus + sd_bus_slot **slot + const char *path + sd_bus_node_enumerator_t callback + void *userdata + + + + + + Description + + sd_bus_add_node_enumerator() adds a D-Bus node enumerator for the + given path prefix. The given callback is called to enumerate all the available objects with + the given path prefix when required (e.g. when + org.freedesktop.DBus.Introspectable.Introspect or + org.freedesktop.DBus.ObjectManager.GetManagedObjects are called on a + D-Bus service managed by sd-bus). + + callback is called with the path and userdata pointer registered + with sd_bus_add_node_enumerator(). When called, it should store all the + child object paths of the given path prefix in ret_nodes with a NULL + terminator item. The callback should return a non-negative value on success. + If an error occurs, it can either return a + negative integer, set ret_error to a non-empty error or do both. Any + errors returned by the callback are encoded as D-Bus errors and sent back to the caller. Errors + in ret_error take priority over negative return values. + + Note that a node enumerator callback will only ever be called for a single path prefix + and hence, for normal operation, prefix can be ignored. Also, a node + enumerator is only used to enumerate the available child objects under a given prefix. To + install a handler for a set of dynamic child objects, use + sd_bus_add_fallback_vtable3. + + + When sd_bus_add_node_enumerator() succeeds, a slot is created + internally. If the output parameter slot is NULL, + a "floating" slot object is created, see + sd_bus_slot_set_floating3. + Otherwise, a pointer to the slot object is returned. In that case, the reference to the slot + object should be dropped when the node enumerator is not needed anymore, see + sd_bus_slot_unref3. + + + + + Return Value + + On success, sd_bus_add_node_enumerator() returns a non-negative + integer. On failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + One of the required parameters is NULL or + path is not a valid object path. + + + + + -ENOPKG + + The bus cannot be resolved. + + + + -ECHILD + + The bus was created in a different process. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + sd-bus3, + busctl1, + sd_bus_add_fallback_vtable3, + sd_bus_slot_unref3 + + + diff --git a/man/sd_bus_add_object.xml b/man/sd_bus_add_object.xml new file mode 100644 index 0000000..991f3a8 --- /dev/null +++ b/man/sd_bus_add_object.xml @@ -0,0 +1,692 @@ + + + + + + + + sd_bus_add_object + systemd + + + + sd_bus_add_object + 3 + + + + sd_bus_add_object + sd_bus_add_fallback + sd_bus_add_object_vtable + sd_bus_add_fallback_vtable + sd_bus_add_filter + SD_BUS_VTABLE_CAPABILITY + SD_BUS_VTABLE_START + SD_BUS_VTABLE_END + SD_BUS_METHOD_WITH_NAMES_OFFSET + SD_BUS_METHOD_WITH_NAMES + SD_BUS_METHOD_WITH_OFFSET + SD_BUS_METHOD + SD_BUS_SIGNAL_WITH_NAMES + SD_BUS_SIGNAL + SD_BUS_WRITABLE_PROPERTY + SD_BUS_PROPERTY + SD_BUS_PARAM + + Declare properties and methods for a D-Bus path + + + + + #include <systemd/sd-bus-vtable.h> + + + + + typedef int (*sd_bus_property_get_t) + sd_bus *bus + const char *path + const char *interface + const char *property + sd_bus_message *reply + void *userdata + sd_bus_error *ret_error + + + + typedef int (*sd_bus_property_set_t) + sd_bus *bus + const char *path + const char *interface + const char *property + sd_bus_message *value + void *userdata + sd_bus_error *ret_error + + + + typedef int (*sd_bus_object_find_t) + const char *path + const char *interface + void *userdata + void **ret_found + sd_bus_error *ret_error + + + + int sd_bus_add_object + sd_bus *bus + sd_bus_slot **slot + const char *path + sd_bus_message_handler_t callback + void *userdata + + + + int sd_bus_add_fallback + sd_bus *bus + sd_bus_slot **slot + const char *path + sd_bus_message_handler_t callback + void *userdata + + + + int sd_bus_add_object_vtable + sd_bus *bus + sd_bus_slot **slot + const char *path + const char *interface + const sd_bus_vtable *vtable + void *userdata + + + + int sd_bus_add_fallback_vtable + sd_bus *bus + sd_bus_slot **slot + const char *prefix + const char *interface + const sd_bus_vtable *vtable + sd_bus_object_find_t find + void *userdata + + + + int sd_bus_add_filter + sd_bus *bus + sd_bus_slot **slot + sd_bus_message_handler_t callback + void *userdata + + + + SD_BUS_VTABLE_CAPABILITY(capability) + + + + SD_BUS_VTABLE_START(flags) + + + SD_BUS_VTABLE_END + + + SD_BUS_METHOD_WITH_ARGS_OFFSET(member, + args, + result, + handler, + offset, + flags) + + + + SD_BUS_METHOD_WITH_ARGS(member, + args, + result, + handler, + flags) + + + + SD_BUS_METHOD_WITH_NAMES_OFFSET(member, + signature, + in_names, + result, + out_names, + handler, + offset, + flags) + + + + SD_BUS_METHOD_WITH_NAMES(member, + signature, + in_names, + result, + out_names, + handler, + flags) + + + + SD_BUS_METHOD_WITH_OFFSET(member, + signature, + result, + handler, + offset, + flags) + + + + SD_BUS_METHOD(member, + signature, + result, + handler, + flags) + + + + SD_BUS_SIGNAL_WITH_ARGS(member, + args, + flags) + + + + SD_BUS_SIGNAL_WITH_NAMES(member, + signature, + names, + flags) + + + + SD_BUS_SIGNAL(member, + signature, + flags) + + + + SD_BUS_WRITABLE_PROPERTY(member, + signature, + get, + set, + offset, + flags) + + + + SD_BUS_PROPERTY(member, + signature, + get, + offset, + flags) + + + + SD_BUS_PARAM(name) + + + SD_BUS_ARGS(...) + + + SD_BUS_RESULT(...) + + + SD_BUS_NO_ARGS + + + SD_BUS_NO_RESULT + + + + + + Description + + sd_bus_add_object_vtable() is used to declare attributes for the + object path path connected to the bus connection + bus under the interface interface. The table + vtable may contain property declarations using + SD_BUS_PROPERTY() or SD_BUS_WRITABLE_PROPERTY(), + method declarations using SD_BUS_METHOD(), + SD_BUS_METHOD_WITH_NAMES(), + SD_BUS_METHOD_WITH_OFFSET(), or + SD_BUS_METHOD_WITH_NAMES_OFFSET(), and signal declarations using + SD_BUS_SIGNAL_WITH_NAMES() or SD_BUS_SIGNAL(), see + below. The userdata parameter contains a pointer that will be passed + to various callback functions. It may be specified as NULL if no value is + necessary. An interface can have any number of vtables attached to it. + + sd_bus_add_fallback_vtable() is similar to + sd_bus_add_object_vtable(), but is used to register "fallback" attributes. + When looking for an attribute declaration, bus object paths registered with + sd_bus_add_object_vtable() are checked first. If no match is found, the + fallback vtables are checked for each prefix of the bus object path, i.e. with the last + slash-separated components successively removed. This allows the vtable to be used for an + arbitrary number of dynamically created objects. + + Parameter find is a function which is used to locate the target + object based on the bus object path path. It must return + 1 and set the ret_found output parameter if the + object is found, return 0 if the object was not found, and return a + negative errno-style error code or initialize the error structure + ret_error on error. The pointer passed in + ret_found will be used as the userdata parameter + for the callback functions (offset by the offset offsets as specified in + the vtable entries). + + sd_bus_add_object() attaches a callback directly to the object path + path. An object path can have any number of callbacks attached to it. + Each callback is prepended to the list of callbacks which are always called in order. + sd_bus_add_fallback() is similar to + sd_bus_add_object() but applies to fallback paths instead. + + sd_bus_add_filter() installs a callback that is invoked for each + incoming D-Bus message. Filters can be used to handle logic common to all messages received by + a service (e.g. authentication or authorization). + + When a request is received, any associated callbacks are called sequentially until a + callback returns a non-zero integer. Return zero from a callback to give other callbacks the + chance to process the request. Callbacks are called in the following order: first, global + callbacks installed with sd_bus_add_filter() are called. Second, callbacks + attached directly to the request object path are called, followed by any D-Bus method callbacks + attached to the request object path, interface and member. Finally, the property callbacks + attached to the request object path, interface and member are called. If the final callback + returns zero, an error reply is sent back to the caller indicating no matching object for the + request was found. + + Note that you can return a positive integer from a method callback without + immediately sending a reply. This informs sd-bus this callback will take responsibility for + replying to the request without forcing the callback to produce a reply immediately. This allows + a callback to perform any number of asynchronous operations required to construct a reply. + However, if producing a reply takes too long, the method call will time out at the caller. This is + only available to methods and not properties. + + If a callback was invoked to handle a request that expects a reply and the callback + returns a negative value, the value is interpreted as a negative errno-style error code and sent + back to the caller as a D-Bus error as if + sd_bus_reply_method_errno3 + was called. Additionally, all callbacks take a sd_bus_error output + parameter that can be used to provide more detailed error information. If + ret_error is set when the callback finishes, the corresponding D-Bus + error is sent back to the caller as if + sd_bus_reply_method_error3 + was called. Any error stored in ret_error takes priority over any + negative values returned by the same callback when determining which error to send back to + the caller. Use + sd_bus_error_set3 + or one of its variants to set ret_error and return a negative integer + from a callback with a single function call. To send an error reply after a callback has already + finished, use + sd_bus_reply_method_errno3 + or one of its variants. + + For all functions, a match slot is created internally. If the output parameter + slot is NULL, a "floating" slot object is + created, see + sd_bus_slot_set_floating3. + Otherwise, a pointer to the slot object is returned. In that case, the reference to the slot + object should be dropped when the vtable is not needed anymore, see + sd_bus_slot_unref3. + + + + The <structname>sd_bus_vtable</structname> array + + The array consists of the structures of type sd_bus_vtable, but it + should never be filled in manually, but through one of the following macros: + + + + SD_BUS_VTABLE_START(flags) + SD_BUS_VTABLE_END + + Those must always be the first and last element. The + flags parameter can be used to set attributes that apply to the whole + array; see the "Flags" section below. + + + + SD_BUS_METHOD_WITH_ARGS_OFFSET() + SD_BUS_METHOD_WITH_ARGS() + + Declare a D-Bus method with the name member, + arguments args and result result. + args expects a sequence of argument type/name pairs wrapped in the + SD_BUS_ARGS() macro. The elements at even indices in this list describe the + types of the method's arguments. The method's parameter signature is the concatenation of all the + string literals at even indices in args. If a method has no parameters, + pass SD_BUS_NO_ARGS to args. The elements at uneven + indices describe the names of the method's arguments. result expects a + sequence of type/name pairs wrapped in the SD_BUS_RESULT() macro in the same + format as SD_BUS_ARGS(). The method's result signature is the concatenation of + all the string literals at even indices in result. If a method has no + result, pass SD_BUS_NO_RESULT to result. Note that + argument types are expected to be quoted string literals and argument names are expected to be + unquoted string literals. See below for a complete example. + + The handler function handler must be of type + sd_bus_message_handler_t. It will be called to handle the incoming messages + that call this method. It receives a pointer that is the userdata + parameter passed to the registration function offset by offset bytes. + This may be used to pass pointers to different fields in the same data structure to different + methods in the same vtable. To send a reply from handler, call + sd_bus_reply_method_return3 + with the message the callback was invoked with. Parameter flags is a + combination of flags, see below. + + SD_BUS_METHOD_WITH_ARGS() is a shorthand for calling + SD_BUS_METHOD_WITH_ARGS_OFFSET() with an offset of zero. + + + + + SD_BUS_METHOD_WITH_NAMES_OFFSET() + SD_BUS_METHOD_WITH_NAMES() + SD_BUS_METHOD_WITH_OFFSET() + SD_BUS_METHOD() + + Declare a D-Bus method with the name member, + parameter signature signature, result signature + result. Parameters in_names and + out_names specify the argument names of the input and output + arguments in the function signature. in_names and + out_names should be created using the + SD_BUS_PARAM() macro, see below. In all other regards, this macro behaves + exactly the same as SD_BUS_METHOD_WITH_ARGS_OFFSET(). + + SD_BUS_METHOD_WITH_NAMES(), + SD_BUS_METHOD_WITH_OFFSET(), and SD_BUS_METHOD() + are variants which specify zero offset (userdata parameter is + passed with no change), leave the names unset (i.e. no parameter names), or both. + + Prefer using SD_BUS_METHOD_WITH_ARGS_OFFSET() and + SD_BUS_METHOD_WITH_ARGS() over these macros as they allow specifying argument + types and names next to each other which is less error-prone than first specifying all argument + types followed by specifying all argument names. + + + + + SD_BUS_SIGNAL_WITH_ARGS() + + Declare a D-Bus signal with the name member and + arguments args. args expects a sequence of + argument type/name pairs wrapped in the SD_BUS_ARGS() macro. The elements at + even indices in this list describe the types of the signal's arguments. The signal's parameter + signature is the concatenation of all the string literals at even indices in + args. If a signal has no parameters, pass + SD_BUS_NO_ARGS to args. The elements at uneven + indices describe the names of the signal's arguments. Parameter flags is + a combination of flags. See below for a complete example. + + + + SD_BUS_SIGNAL_WITH_NAMES() + SD_BUS_SIGNAL() + + Declare a D-Bus signal with the name member, + parameter signature signature, and argument names + names. names should be + created using the SD_BUS_PARAM() macro, see below. + Parameter flags is a combination of flags, see below. + + + SD_BUS_SIGNAL() is equivalent to + SD_BUS_SIGNAL_WITH_NAMES() with the names parameter + unset (i.e. no parameter names). + + Prefer using SD_BUS_SIGNAL_WITH_ARGS() over these macros as it allows + specifying argument types and names next to each other which is less error-prone than first + specifying all argument types followed by specifying all argument names. + + + + + SD_BUS_WRITABLE_PROPERTY() + SD_BUS_PROPERTY() + + Declare a D-Bus property with the name member + and value signature signature. Parameters + get and set are the getter and + setter methods. They are called with a pointer that is the + userdata parameter passed to the registration function offset + by offset bytes. This may be used pass pointers to different + fields in the same data structure to different setters and getters in the same vtable. + Parameter flags is a combination of flags, see below. + + The setter and getter methods may be omitted (specified as + NULL), if the property is one of the basic types or + as in case of read-only properties. In those cases, the + userdata and offset parameters must + together point to a valid variable of the corresponding type. A default setter and getter + will be provided, which simply copy the argument between this variable and the message. + + + SD_BUS_PROPERTY() is used to define a read-only property. + + + + + SD_BUS_PARAM() + Parameter names should be wrapped in this macro, see the example below. + + + + + + + Flags + + The flags parameter is used to specify a combination of + D-Bus annotations. + + + + + SD_BUS_VTABLE_DEPRECATED + + Mark this vtable entry as deprecated using the + org.freedesktop.DBus.Deprecated annotation in introspection data. If + specified for SD_BUS_VTABLE_START(), the annotation is applied to the + enclosing interface. + + + + SD_BUS_VTABLE_HIDDEN + + Make this vtable entry hidden. It will not be shown in introspection data. + If specified for SD_BUS_VTABLE_START(), all entries in the array are + hidden. + + + + SD_BUS_VTABLE_METHOD_NO_REPLY + + Mark this vtable entry as a method that will not return a reply using the + org.freedesktop.DBus.Method.NoReply annotation in introspection data. + + + + + SD_BUS_VTABLE_PROPERTY_CONST + SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE + SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION + + Those three flags correspond to different values of the + org.freedesktop.DBus.Property.EmitsChangedSignal annotation, which + specifies whether the + org.freedesktop.DBus.Properties.PropertiesChanged signal is emitted + whenever the property changes. SD_BUS_VTABLE_PROPERTY_CONST + corresponds to const and means that the property never changes during + the lifetime of the object it belongs to, so no signal needs to be emitted. + SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE corresponds to + true and means that the signal is emitted. + SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION corresponds to + invalidates and means that the signal is emitted, but the value is + not included in the signal. + + + + SD_BUS_VTABLE_PROPERTY_EXPLICIT + + Mark this vtable property entry as requiring explicit request to for the + value to be shown (generally because the value is large or slow to calculate). This entry + cannot be combined with SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE, and will + not be shown in property listings by default (e.g. busctl introspect). + This corresponds to the org.freedesktop.systemd1.Explicit annotation + in introspection data. + + + + SD_BUS_VTABLE_SENSITIVE + + Mark this vtable method entry as processing sensitive data. When set, + incoming method call messages and their outgoing reply messages are marked as sensitive using + sd_bus_message_sensitive3, + so that they are erased from memory when freed. + + + + SD_BUS_VTABLE_ABSOLUTE_OFFSET + + Mark this vtable method or property entry so that the user data pointer passed to + its associated handler functions is determined slightly differently: instead of adding the offset + parameter of the entry to the user data pointer specified during vtable registration, the offset is + passed directly, converted to a pointer, without taking the user data pointer specified during + vtable registration into account. + + + + SD_BUS_VTABLE_CAPABILITY(capability) + + Access to this vtable entry will be allowed if the calling process has the + capability capability, as described in + sd_bus_query_sender_privilege3. + If used for SD_BUS_VTABLE_START(), provides a default for all entries in the + array. If not specified, either for an individual entry or the whole array, + CAP_SYS_ADMIN is checked by default. See capabilities7 + for information about capabilities. + + Note that vtable entries may be marked as unprivileged and the whole bus may be marked as + trusted, see the discussion of SD_BUS_VTABLE_UNPRIVILEGED below. + + + + + SD_BUS_VTABLE_UNPRIVILEGED + + Mark this vtable entry as unprivileged. Access to privileged entries is limited to + users with appropriate capabilities as described above. In practice many vtable entries are marked + as unprivileged, and either are open to everyone, or the decision whether to allow access is taken + later, e.g. by delegating to polkit. + + The whole bus may be marked as trusted, in which case annotations at the entry level are + ignored, see + sd_bus_set_trusted3. + + + When not specified, the + org.freedesktop.systemd1.Privileged annotation with value + true will be shown in introspection data. + + Note that this page describes checks implemented in the D-Bus client. The D-Bus server has an + additional policy that may permit or deny connections, see + "CONFIGURATION FILE" in + dbus-daemon1. + + + + + + + + Examples + + + Create a simple listener on the bus + + + + This creates a simple client on the bus (the user bus, when run as normal user). We may + use the D-Bus org.freedesktop.DBus.Introspectable.Introspect call to + acquire the XML description of the interface: + + + + + + + Return Value + + On success, sd_bus_add_object_vtable() and + sd_bus_add_fallback_vtable() return a non-negative integer. On + failure, they return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + One of the required parameters is NULL or invalid. A + reserved D-Bus interface was passed as the interface parameter. + + + + + -ENOPKG + + The bus cannot be resolved. + + + + -ECHILD + + The bus was created in a different process. + + + + -ENOMEM + + Memory allocation failed. + + + + -EPROTOTYPE + + sd_bus_add_object_vtable() and + sd_bus_add_fallback_vtable() have been both called for the same bus + object path, which is not allowed. + + + + -EEXIST + + This vtable has already been registered for this + interface and path. + + + + + + + + + + See Also + + + sd-bus3, + busctl1, + sd_bus_emit_properties_changed3, + sd_bus_emit_object_added3 + + + diff --git a/man/sd_bus_add_object_manager.xml b/man/sd_bus_add_object_manager.xml new file mode 100644 index 0000000..df2704a --- /dev/null +++ b/man/sd_bus_add_object_manager.xml @@ -0,0 +1,118 @@ + + + + + + + + sd_bus_add_object_manager + systemd + + + + sd_bus_add_object_manager + 3 + + + + sd_bus_add_object_manager + + Add a D-Bus object manager for a D-Bus object sub-tree + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_add_object_manager + sd_bus *bus + sd_bus_slot **slot + const char *path + + + + + + Description + + sd_bus_add_object_manager() installs a handler for the given path + that implements the GetManagedObjects() method of the + org.freedesktop.DBus.ObjectManager interface. See + + org.freedesktop.DBus.ObjectManager for more information. + + To implement the InterfacesAdded and + InterfacesRemoved signals of the + org.freedesktop.DBus.ObjectManager interface, call + sd_bus_emit_interfaces_added3 and + sd_bus_emit_interfaces_removed3 + whenever interfaces are added or removed from the sub-tree, respectively. + + When sd_bus_add_object_manager() succeeds, a slot is created + internally. If the output parameter slot is NULL, + a "floating" slot object is created, see + sd_bus_slot_set_floating3. + Otherwise, a pointer to the slot object is returned. In that case, the reference to the slot + object should be dropped when the object manager is not needed anymore, see + sd_bus_slot_unref3. + + + + + Return Value + + On success, sd_bus_add_object_manager() returns a non-negative + integer. On failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + One of the required parameters is NULL or + path is not a valid object path. + + + + + -ENOPKG + + The bus cannot be resolved. + + + + -ECHILD + + The bus was created in a different process. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + sd-bus3, + busctl1, + sd_bus_add_object_vtable3, + sd_bus_emit_interfaces_added3, + sd_bus_slot_unref3 + + + diff --git a/man/sd_bus_attach_event.xml b/man/sd_bus_attach_event.xml new file mode 100644 index 0000000..bb34d4a --- /dev/null +++ b/man/sd_bus_attach_event.xml @@ -0,0 +1,119 @@ + + + + + + + + sd_bus_attach_event + systemd + + + + sd_bus_attach_event + 3 + + + + sd_bus_attach_event + sd_bus_detach_event + sd_bus_get_event + + Attach a bus connection object to an event loop + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_attach_event + sd_bus *bus + sd_event *e + int priority + + + + int sd_bus_detach_event + sd_bus *bus + + + + sd_event *sd_bus_get_event + sd_bus *bus + + + + + + Description + + sd_bus_attach_event() attaches the specified bus connection object to an + sd-event3 event loop object at + the specified priority (see + sd_event_source_set_priority3 + for details on event loop priorities). When a bus connection object is attached to an event loop incoming messages + will be automatically read and processed, and outgoing messages written, whenever the event loop is run. When the + event loop is about to terminate, the bus connection is automatically flushed and closed (see + sd_bus_set_close_on_exit3 for + details on this). By default bus connection objects are not attached to any event loop. When a bus connection + object is attached to one it is not necessary to invoke + sd_bus_wait3 or + sd_bus_process3 as this + functionality is handled automatically by the event loop. + + sd_bus_detach_event() detaches a bus object from its event loop. + + The sd_bus_get_event() returns the event loop object the specified bus object is + currently attached to, or NULL if it is currently not attached to any. + + Note that sd_bus_attach_event() is only one of three supported ways to implement I/O + event handling for bus connections. Alternatively use + sd_bus_get_fd3 for hooking up a + bus connection object with external or manual event loops. Or use + sd_bus_wait3 as a simple + synchronous, blocking I/O waiting call. + + + + Return Value + + On success, sd_bus_attach_event() and sd_bus_detach_event() return + 0 or a positive integer. On failure, they return a negative errno-style error code. + + sd_bus_get_event() returns an event loop object or NULL. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection has been created in a different process. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd-event3, + sd_event_source_set_priority3, + sd_bus_set_close_on_exit3, + sd_bus_wait3, + sd_bus_get_fd3 + + + + diff --git a/man/sd_bus_call.xml b/man/sd_bus_call.xml new file mode 100644 index 0000000..1f7dfc2 --- /dev/null +++ b/man/sd_bus_call.xml @@ -0,0 +1,200 @@ + + + + + + + + sd_bus_call + systemd + + + + sd_bus_call + 3 + + + + sd_bus_call + sd_bus_call_async + + Invoke a D-Bus method call + + + + + #include <systemd/sd-bus.h> + + + + + int sd_bus_call + sd_bus *bus + sd_bus_message *m + uint64_t usec + sd_bus_error *ret_error + sd_bus_message **reply + + + + int sd_bus_call_async + sd_bus *bus + sd_bus_slot **slot + sd_bus_message *m + sd_bus_message_handler_t callback + void *userdata + uint64_t usec + + + + + + Description + + sd_bus_call() takes a complete bus message object and calls the + corresponding D-Bus method. On success, the response is stored in reply. + usec indicates the timeout in microseconds. If + ret_error is not NULL and + sd_bus_call() fails (either because of an internal error or because it + received a D-Bus error reply), ret_error is initialized to an instance of + sd_bus_error describing the error. + + sd_bus_call_async() is like sd_bus_call() but works + asynchronously. The callback indicates the function to call when the response + arrives. The userdata pointer will be passed to the callback function, and may be + chosen freely by the caller. If slot is not NULL and + sd_bus_call_async() succeeds, slot is set to a slot object + which can be used to cancel the method call at a later time using + sd_bus_slot_unref3. + If slot is NULL, the lifetime of the method call is bound to + the lifetime of the bus object itself, and it cannot be cancelled independently. See + sd_bus_slot_set_floating3 + for details. callback is called when a reply arrives with the reply, + userdata and an sd_bus_error output parameter as its + arguments. Unlike sd_bus_call(), the sd_bus_error output + parameter passed to the callback will be empty. To determine whether the method call succeeded, use + sd_bus_message_is_method_error3 + on the reply message passed to the callback instead. If the callback returns zero and the + sd_bus_error output parameter is still empty when the callback finishes, other + handlers registered with functions such as + sd_bus_add_filter3 or + sd_bus_add_match3 are + given a chance to process the message. If the callback returns a non-zero value or the + sd_bus_error output parameter is not empty when the callback finishes, no + further processing of the message is done. Generally, you want to return zero from the callback to give + other registered handlers a chance to process the reply as well. (Note that the + sd_bus_error parameter is an output parameter of the callback function, not an + input parameter; it can be used to propagate errors from the callback handler, it will not receive any + error that was received as method reply.) + + The message m passed to the callback is only borrowed, that is, the callback should + not call sd_bus_message_unref3 + on it. If the callback wants to hold on to the message beyond the lifetime of the callback, it needs to call + sd_bus_message_ref3 to create a + new reference. + + If usec is zero, the default D-Bus method call timeout is used. See + sd_bus_get_method_call_timeout3. + + + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code. + + + Errors + + When sd_bus_call() internally receives a D-Bus error reply, it will set + ret_error if it is not NULL, and will return a negative + value mapped from the error reply, see + sd_bus_error_get_errno3. + + + Returned errors may indicate the following problems: + + + + -EINVAL + + The input parameter m is NULL. + + + The input parameter m is not a D-Bus method call. + To create a new D-Bus method call, use + sd_bus_message_new_method_call3. + + + The input parameter m has the + BUS_MESSAGE_NO_REPLY_EXPECTED flag set. + + The input parameter error is + non-NULL but was not set to SD_BUS_ERROR_NULL. + + + + + -ECHILD + + The bus connection was allocated in a parent process and is being reused + in a child process after fork(). + + + + -ENOTCONN + + The input parameter bus is + NULL or the bus is not connected. + + + + -ECONNRESET + + The bus connection was closed while waiting for the response. + + + + + -ETIMEDOUT + + A response was not received within the given timeout. + + + + -ELOOP + + The message m is addressed to its own client. + + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_call_method3, + sd_bus_call_method_async3, + sd_bus_message_new_method_call3, + sd_bus_message_append3, + sd_bus_error3 + + + + diff --git a/man/sd_bus_call_method.xml b/man/sd_bus_call_method.xml new file mode 100644 index 0000000..7b52555 --- /dev/null +++ b/man/sd_bus_call_method.xml @@ -0,0 +1,156 @@ + + + + + + + + sd_bus_call_method + systemd + + + + sd_bus_call_method + 3 + + + + sd_bus_call_method + sd_bus_call_methodv + sd_bus_call_method_async + sd_bus_call_method_asyncv + + Initialize a bus message object and invoke the corresponding D-Bus method call + + + + + + #include <systemd/sd-bus.h> + + + + + int sd_bus_call_method + sd_bus *bus + const char *destination + const char *path + const char *interface + const char *member + sd_bus_error *ret_error + sd_bus_message **reply + const char *types + ... + + + + int sd_bus_call_methodv + sd_bus *bus + const char *destination + const char *path + const char *interface + const char *member + sd_bus_error *ret_error + sd_bus_message **reply + const char *types + va_list ap + + + + int sd_bus_call_method_async + sd_bus *bus + sd_bus_slot **slot + const char *destination + const char *path + const char *interface + const char *member + sd_bus_message_handler_t callback + void *userdata + const char *types + ... + + + + int sd_bus_call_method_asyncv + sd_bus *bus + sd_bus_slot **slot + const char *destination + const char *path + const char *interface + const char *member + sd_bus_message_handler_t callback + void *userdata + const char *types + va_list ap + + + + + + Description + + sd_bus_call_method() is a convenience function for initializing a + bus message object and calling the corresponding D-Bus method. It combines the + sd_bus_message_new_method_call3, + sd_bus_message_append3 and + sd_bus_call3 + functions into a single function call. + + sd_bus_call_method_async() is a convenience function for initializing + a bus message object and calling the corresponding D-Bus method asynchronously. It combines the + sd_bus_message_new_method_call3, + sd_bus_message_append3 and + sd_bus_call_async3 + functions into a single function call. + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code. + + + Errors + + See the man pages of + sd_bus_message_new_method_call3, + sd_bus_message_append3, + sd_bus_call3 and + sd_bus_call_async3 + for a list of possible errors. + + + + + + + Examples + + + Make a call to a D-Bus method that takes a single parameter + + + This defines a minimally useful program that will open a connection to the bus, call a method, + wait for the reply, and finally extract and print the answer. It does error handling and proper + memory management. + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_new_method_call3, + sd_bus_message_append3, + sd_bus_call3, + sd_bus_set_property3, + sd_bus_emit_signal3 + + + + diff --git a/man/sd_bus_can_send.xml b/man/sd_bus_can_send.xml new file mode 100644 index 0000000..632d9bc --- /dev/null +++ b/man/sd_bus_can_send.xml @@ -0,0 +1,93 @@ + + + + + + + + sd_bus_can_send + systemd + + + + sd_bus_can_send + 3 + + + + sd_bus_can_send + + Check which types can be sent over a bus object + + + + + #include <systemd/sd-bus.h> + + + void sd_bus_can_send + sd_bus *bus + char type + + + + + + Description + + sd_bus_can_send() is mostly used for checking if file descriptor + passing is available on the given bus. type can be any of the + SD_BUS_TYPE constants. + + + + Return Value + + On failure, sd_bus_can_send() returns a negative errno-style error + code. If values of the given type can be sent over the given bus, it returns a positive integer. + Otherwise, it returns zero. + + + Errors + + Returned errors may indicate the following problems: + + + + -ENOPKG + + The bus object bus could not be resolved. + + + + + -ENOTCONN + + The input parameter bus is + NULL or the bus is not connected. + + + + -ECHILD + + The bus object bus was created in a different + process. + + + + + + + + + See Also + + + systemd1, + sd-bus3 + + + + diff --git a/man/sd_bus_close.xml b/man/sd_bus_close.xml new file mode 100644 index 0000000..95427bd --- /dev/null +++ b/man/sd_bus_close.xml @@ -0,0 +1,119 @@ + + + + + + + + sd_bus_close + systemd + + + + sd_bus_close + 3 + + + + sd_bus_close + sd_bus_flush + sd_bus_default_flush_close + + Close and flush a bus connection + + + + + #include <systemd/sd-bus.h> + + + void sd_bus_close + sd_bus *bus + + + + int sd_bus_flush + sd_bus *bus + + + + void sd_bus_default_flush_close + void + + + + + + Description + + sd_bus_close() disconnects the specified bus connection. When this + call is invoked and the specified bus object refers to an active connection it is immediately + terminated. No further messages may be sent or received on it. Any messages queued in the bus + object (both incoming and outgoing) are released. If invoked on NULL bus + object or when the bus connection is already closed this function executes no operation. This + call does not free or unreference the bus object itself. Use + sd_bus_unref3 + for that. + + sd_bus_flush() synchronously writes out all outgoing queued message + on a bus connection if there are any. This function call may block if the peer is not processing + bus messages quickly. + + Before a program exits it is usually a good idea to flush any pending messages with + sd_bus_flush() and then close connections with + sd_bus_close() to ensure that no unwritten messages are lost, no further + messages may be queued and all incoming but unprocessed messages are released. After both + operations have been done, it is a good idea to also drop any remaining references to the bus + object so that it may be freed. Since these three operations are frequently done together a + helper call + sd_bus_flush_close_unref3 + is provided that combines them into one. + + sd_bus_default_flush_close() is similar to + sd_bus_flush_close_unref(), but does not take a bus pointer argument and + instead iterates over any of the "default" buses opened by + sd_bus_default3, + sd_bus_default_user3, + sd_bus_default_system3, + and similar calls. sd_bus_default_flush_close() is particularly useful to + clean up any buses opened using those calls before the program exits. + + + + Return Value + + On success, sd_bus_flush() returns a non-negative integer. On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection has been created in a different process. + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_unref3, + sd_bus_set_close_on_exit3 + + + + diff --git a/man/sd_bus_creds_get_pid.xml b/man/sd_bus_creds_get_pid.xml new file mode 100644 index 0000000..56cfa4e --- /dev/null +++ b/man/sd_bus_creds_get_pid.xml @@ -0,0 +1,526 @@ + + + + + + + + sd_bus_creds_get_pid + systemd + + + + sd_bus_creds_get_pid + 3 + + + + sd_bus_creds_get_pid + sd_bus_creds_get_ppid + sd_bus_creds_get_tid + sd_bus_creds_get_uid + sd_bus_creds_get_euid + sd_bus_creds_get_suid + sd_bus_creds_get_fsuid + sd_bus_creds_get_gid + sd_bus_creds_get_egid + sd_bus_creds_get_sgid + sd_bus_creds_get_fsgid + sd_bus_creds_get_supplementary_gids + sd_bus_creds_get_comm + sd_bus_creds_get_tid_comm + sd_bus_creds_get_exe + sd_bus_creds_get_cmdline + sd_bus_creds_get_cgroup + sd_bus_creds_get_unit + sd_bus_creds_get_slice + sd_bus_creds_get_user_unit + sd_bus_creds_get_user_slice + sd_bus_creds_get_session + sd_bus_creds_get_owner_uid + sd_bus_creds_has_effective_cap + sd_bus_creds_has_permitted_cap + sd_bus_creds_has_inheritable_cap + sd_bus_creds_has_bounding_cap + sd_bus_creds_get_selinux_context + sd_bus_creds_get_audit_session_id + sd_bus_creds_get_audit_login_uid + sd_bus_creds_get_tty + sd_bus_creds_get_unique_name + sd_bus_creds_get_well_known_names + sd_bus_creds_get_description + + Retrieve fields from a credentials object + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_creds_get_pid + sd_bus_creds *c + pid_t *pid + + + + int sd_bus_creds_get_ppid + sd_bus_creds *c + pid_t *ppid + + + + int sd_bus_creds_get_tid + sd_bus_creds *c + pid_t *tid + + + + int sd_bus_creds_get_uid + sd_bus_creds *c + uid_t *uid + + + + int sd_bus_creds_get_euid + sd_bus_creds *c + uid_t *uid + + + + int sd_bus_creds_get_suid + sd_bus_creds *c + uid_t *uid + + + + int sd_bus_creds_get_fsuid + sd_bus_creds *c + uid_t *uid + + + + int sd_bus_creds_get_gid + sd_bus_creds *c + gid_t *gid + + + + int sd_bus_creds_get_egid + sd_bus_creds *c + gid_t *gid + + + + int sd_bus_creds_get_sgid + sd_bus_creds *c + gid_t *gid + + + + int sd_bus_creds_get_fsgid + sd_bus_creds *c + gid_t *gid + + + + int sd_bus_creds_get_supplementary_gids + sd_bus_creds *c + const gid_t **gids + + + + int sd_bus_creds_get_comm + sd_bus_creds *c + const char **comm + + + + int sd_bus_creds_get_tid_comm + sd_bus_creds *c + const char **comm + + + + int sd_bus_creds_get_exe + sd_bus_creds *c + const char **exe + + + + int sd_bus_creds_get_cmdline + sd_bus_creds *c + char ***cmdline + + + + int sd_bus_creds_get_cgroup + sd_bus_creds *c + const char **cgroup + + + + int sd_bus_creds_get_unit + sd_bus_creds *c + const char **unit + + + + int sd_bus_creds_get_slice + sd_bus_creds *c + const char **slice + + + + int sd_bus_creds_get_user_unit + sd_bus_creds *c + const char **unit + + + + int sd_bus_creds_get_user_slice + sd_bus_creds *c + const char **slice + + + + int sd_bus_creds_get_session + sd_bus_creds *c + const char **slice + + + + int sd_bus_creds_get_owner_uid + sd_bus_creds *c + uid_t *uid + + + + int sd_bus_creds_has_effective_cap + sd_bus_creds *c + int capability + + + + int sd_bus_creds_has_permitted_cap + sd_bus_creds *c + int capability + + + + int sd_bus_creds_has_inheritable_cap + sd_bus_creds *c + int capability + + + + int sd_bus_creds_has_bounding_cap + sd_bus_creds *c + int capability + + + + int sd_bus_creds_get_selinux_context + sd_bus_creds *c + const char **context + + + + int sd_bus_creds_get_audit_session_id + sd_bus_creds *c + uint32_t *sessionid + + + + int sd_bus_creds_get_audit_login_uid + sd_bus_creds *c + uid_t *loginuid + + + + int sd_bus_creds_get_tty + sd_bus_creds *c + const char **tty + + + + int sd_bus_creds_get_unique_name + sd_bus_creds *c + const char **name + + + + int sd_bus_creds_get_well_known_names + sd_bus_creds *c + char ***name + + + + int sd_bus_creds_get_description + sd_bus_creds *c + const char **name + + + + + + + Description + + These functions return credential information from an + sd_bus_creds object. Credential objects may + be created with + sd_bus_creds_new_from_pid3, + in which case they describe the credentials of the process + identified by the specified PID, with + sd_bus_get_name_creds3, + in which case they describe the credentials of a bus peer + identified by the specified bus name, with + sd_bus_get_owner_creds3, + in which case they describe the credentials of the creator of a + bus, or with + sd_bus_message_get_creds3, + in which case they describe the credentials of the sender of the + message. + + Not all credential fields are part of every + sd_bus_creds object. Use + sd_bus_creds_get_mask3 + to determine the mask of fields available. + + sd_bus_creds_get_pid() will retrieve + the PID (process identifier). Similarly, + sd_bus_creds_get_ppid() will retrieve the + parent PID. Note that PID 1 has no parent process, in which case + -ENXIO is returned. + + sd_bus_creds_get_tid() will retrieve the + TID (thread identifier). + + sd_bus_creds_get_uid() will retrieve + the numeric UID (user identifier). Similarly, + sd_bus_creds_get_euid() returns the effective + UID, sd_bus_creds_get_suid() the saved UID + and sd_bus_creds_get_fsuid() the file system + UID. + + sd_bus_creds_get_gid() will retrieve the + numeric GID (group identifier). Similarly, + sd_bus_creds_get_egid() returns the effective + GID, sd_bus_creds_get_sgid() the saved GID + and sd_bus_creds_get_fsgid() the file system + GID. + + sd_bus_creds_get_supplementary_gids() + will retrieve the supplementary GIDs list. + + sd_bus_creds_get_comm() will retrieve the + comm field (truncated name of the executable, as stored in + /proc/pid/comm). + + + sd_bus_creds_get_tid_comm() will retrieve + the comm field of the thread (as stored in + /proc/pid/task/tid/comm). + + + sd_bus_creds_get_exe() will retrieve the path to the program executable (as + stored in the /proc/pid/exe link, but with the + (deleted) suffix removed). Note that kernel threads do not have an executable path, in which + case -ENXIO is returned. Note that this property should not be used for more than explanatory + information, in particular it should not be used for security-relevant decisions. That's because the + executable might have been replaced or removed by the time the value can be processed. Moreover, the + kernel exports this information in an ambiguous way (i.e. a deleted executable cannot be safely + distinguished from one whose name suffix is (deleted)). + + sd_bus_creds_get_cmdline() will + retrieve an array of command line arguments (as stored in + /proc/pid/cmdline). Note + that kernel threads do not have a command line, in which case + -ENXIO is returned. + + sd_bus_creds_get_cgroup() will retrieve the control group path. See Control Groups v2. + + + sd_bus_creds_get_unit() will retrieve + the systemd unit name (in the system instance of systemd) that the + process is a part of. See + systemd.unit5. For + processes that are not part of a unit, returns -ENXIO. + + + sd_bus_creds_get_user_unit() will + retrieve the systemd unit name (in the user instance of systemd) + that the process is a part of. See + systemd.unit5. For + processes that are not part of a user unit, returns -ENXIO. + + + sd_bus_creds_get_slice() will retrieve + the systemd slice (a unit in the system instance of systemd) that + the process is a part of. See + systemd.slice5. Similarly, + sd_bus_creds_get_user_slice() retrieves the + systemd slice of the process, in the user instance of systemd. + + + sd_bus_creds_get_session() will + retrieve the identifier of the login session that the process is + a part of. Please note the login session may be limited to a stub + process or two. User processes may instead be started from their + systemd user manager, e.g. GUI applications started using DBus + activation, as well as service processes which are shared between + multiple logins of the same user. For processes that are not part + of a session, returns -ENXIO. + + sd_bus_creds_get_owner_uid() will + retrieve the numeric UID (user identifier) of the user who owns + the user unit or login session that the process is a part of. See + systemd-logind.service8. + For processes that are not part of a user unit or session, returns + -ENXIO. + + + sd_bus_creds_has_effective_cap() will check whether the capability specified by + capability was set in the effective capabilities mask. A positive return value means that it + was set, zero means that it was not set, and a negative return value indicates an error. See capabilities7 and the + AmbientCapabilities= and CapabilityBoundingSet= settings in + systemd.exec5. + + + sd_bus_creds_has_permitted_cap() is + similar to sd_bus_creds_has_effective_cap(), + but will check the permitted capabilities mask. + + sd_bus_creds_has_inheritable_cap() is + similar to sd_bus_creds_has_effective_cap(), + but will check the inheritable capabilities mask. + + sd_bus_creds_has_bounding_cap() is + similar to sd_bus_creds_has_effective_cap(), + but will check the bounding capabilities mask. + + sd_bus_creds_get_selinux_context() will + retrieve the SELinux security context (label) of the process. + + sd_bus_creds_get_audit_session_id() + will retrieve the audit session identifier of the process. Returns + -ENXIO for processes that are not part of an audit session. + + sd_bus_creds_get_audit_login_uid() will + retrieve the audit user login identifier (the identifier of the + user who is "responsible" for the session). Returns -ENXIO for + processes that are not part of an audit session. + + sd_bus_creds_get_tty() will retrieve + the controlling TTY, without the prefixing "/dev/". Returns -ENXIO + for processes that have no controlling TTY. + + sd_bus_creds_get_unique_name() will + retrieve the D-Bus unique name. See The + D-Bus specification. + + sd_bus_creds_get_well_known_names() will + retrieve the set of D-Bus well-known names. See The + D-Bus specification. + + sd_bus_creds_get_description() will + retrieve a descriptive name of the bus connection of the + peer. This name is useful to discern multiple bus connections by + the same peer, and may be altered by the peer with the + sd_bus_set_description3 + call. + + All functions that take a const + char** parameter will store the answer there as an + address of a NUL-terminated string. It will be valid as long as + c remains valid, and should not be freed or + modified by the caller. + + All functions that take a char*** + parameter will store the answer there as an address of an array + of strings. Each individual string is NUL-terminated, and the + array is NULL-terminated as a whole. It will be valid as long as + c remains valid, and should not be freed or + modified by the caller. + + + + Return Value + + On success, these calls return 0 or a positive integer. On + failure, these calls return a negative errno-style error code. + + + + Errors + + Returned errors may indicate the following problems: + + + + -ENODATA + + The given field is not available in the credentials object + c. + + + + + -ENXIO + + The given field is not specified for the described process or peer. This will be + returned by sd_bus_creds_get_unit(), + sd_bus_creds_get_slice(), sd_bus_creds_get_user_unit(), + sd_bus_creds_get_user_slice(), and + sd_bus_creds_get_session() if the process is not part of a systemd system + unit, systemd user unit, systemd slice, or logind session. It will be returned by + sd_bus_creds_get_owner_uid() if the process is not part of a systemd user unit + or logind session. It will also be returned by sd_bus_creds_get_exe() and + sd_bus_creds_get_cmdline() for kernel threads (since these are not started + from an executable binary, nor have a command line), and by + sd_bus_creds_get_audit_session_id() and + sd_bus_creds_get_audit_login_uid() when the process is not part of an audit + session, and sd_bus_creds_get_tty() if the process has no controlling + TTY. + + + + -EINVAL + + Specified pointer parameter is NULL. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_creds_new_from_pid2, + fork2, + execve2, + credentials7, + free3, + proc5, + systemd.journal-fields7 + + + + diff --git a/man/sd_bus_creds_new_from_pid.xml b/man/sd_bus_creds_new_from_pid.xml new file mode 100644 index 0000000..ea3acc4 --- /dev/null +++ b/man/sd_bus_creds_new_from_pid.xml @@ -0,0 +1,315 @@ + + + + + + + + sd_bus_creds_new_from_pid + systemd + + + + sd_bus_creds_new_from_pid + 3 + + + + sd_bus_creds_new_from_pid + sd_bus_creds_get_mask + sd_bus_creds_get_augmented_mask + sd_bus_creds_ref + sd_bus_creds_unref + sd_bus_creds_unrefp + + Retrieve credentials object for the specified PID + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_creds_new_from_pid + pid_t pid + uint64_t creds_mask + sd_bus_creds **ret + + + + uint64_t sd_bus_creds_get_mask + sd_bus_creds *c + + + + uint64_t sd_bus_creds_get_augmented_mask + sd_bus_creds *c + + + + sd_bus_creds *sd_bus_creds_ref + sd_bus_creds *c + + + + sd_bus_creds *sd_bus_creds_unref + sd_bus_creds *c + + + + void sd_bus_creds_unrefp + sd_bus_creds **c + + + + + SD_BUS_CREDS_PID, + SD_BUS_CREDS_PPID, + SD_BUS_CREDS_TID, + SD_BUS_CREDS_UID, + SD_BUS_CREDS_EUID, + SD_BUS_CREDS_SUID, + SD_BUS_CREDS_FSUID, + SD_BUS_CREDS_GID, + SD_BUS_CREDS_EGID, + SD_BUS_CREDS_SGID, + SD_BUS_CREDS_FSGID, + SD_BUS_CREDS_SUPPLEMENTARY_GIDS, + SD_BUS_CREDS_COMM, + SD_BUS_CREDS_TID_COMM, + SD_BUS_CREDS_EXE, + SD_BUS_CREDS_CMDLINE, + SD_BUS_CREDS_CGROUP, + SD_BUS_CREDS_UNIT, + SD_BUS_CREDS_SLICE, + SD_BUS_CREDS_USER_UNIT, + SD_BUS_CREDS_USER_SLICE, + SD_BUS_CREDS_SESSION, + SD_BUS_CREDS_OWNER_UID, + SD_BUS_CREDS_EFFECTIVE_CAPS, + SD_BUS_CREDS_PERMITTED_CAPS, + SD_BUS_CREDS_INHERITABLE_CAPS, + SD_BUS_CREDS_BOUNDING_CAPS, + SD_BUS_CREDS_SELINUX_CONTEXT, + SD_BUS_CREDS_AUDIT_SESSION_ID, + SD_BUS_CREDS_AUDIT_LOGIN_UID, + SD_BUS_CREDS_TTY, + SD_BUS_CREDS_UNIQUE_NAME, + SD_BUS_CREDS_WELL_KNOWN_NAMES, + SD_BUS_CREDS_DESCRIPTION, + SD_BUS_CREDS_AUGMENT, + _SD_BUS_CREDS_ALL + + + + + Description + + sd_bus_creds_new_from_pid() creates a + new credentials object and fills it with information about the + process pid. The pointer to this object + will be stored in the ret pointer. Note that + credential objects may also be created and retrieved via + sd_bus_get_name_creds3, + sd_bus_get_owner_creds3 + and + sd_bus_message_get_creds3. + + The information that will be stored is determined by + creds_mask. It may contain a subset of ORed + constants SD_BUS_CREDS_PID, + SD_BUS_CREDS_PPID, + SD_BUS_CREDS_TID, + SD_BUS_CREDS_UID, + SD_BUS_CREDS_EUID, + SD_BUS_CREDS_SUID, + SD_BUS_CREDS_FSUID, + SD_BUS_CREDS_GID, + SD_BUS_CREDS_EGID, + SD_BUS_CREDS_SGID, + SD_BUS_CREDS_FSGID, + SD_BUS_CREDS_SUPPLEMENTARY_GIDS, + SD_BUS_CREDS_COMM, + SD_BUS_CREDS_TID_COMM, + SD_BUS_CREDS_EXE, + SD_BUS_CREDS_CMDLINE, + SD_BUS_CREDS_CGROUP, + SD_BUS_CREDS_UNIT, + SD_BUS_CREDS_SLICE, + SD_BUS_CREDS_USER_UNIT, + SD_BUS_CREDS_USER_SLICE, + SD_BUS_CREDS_SESSION, + SD_BUS_CREDS_OWNER_UID, + SD_BUS_CREDS_EFFECTIVE_CAPS, + SD_BUS_CREDS_PERMITTED_CAPS, + SD_BUS_CREDS_INHERITABLE_CAPS, + SD_BUS_CREDS_BOUNDING_CAPS, + SD_BUS_CREDS_SELINUX_CONTEXT, + SD_BUS_CREDS_AUDIT_SESSION_ID, + SD_BUS_CREDS_AUDIT_LOGIN_UID, + SD_BUS_CREDS_TTY, + SD_BUS_CREDS_UNIQUE_NAME, + SD_BUS_CREDS_WELL_KNOWN_NAMES, and + SD_BUS_CREDS_DESCRIPTION. Use the special + value _SD_BUS_CREDS_ALL to request all + supported fields. The SD_BUS_CREDS_AUGMENT + constant may not be ORed into the mask for invocations of + sd_bus_creds_new_from_pid(). + + Fields can be retrieved from the credentials object using + sd_bus_creds_get_pid3 + and other functions which correspond directly to the constants + listed above. + + A mask of fields which were actually successfully retrieved + can be retrieved with + sd_bus_creds_get_mask(). If the credentials + object was created with + sd_bus_creds_new_from_pid(), this will be a + subset of fields requested in creds_mask. + + + Similar to sd_bus_creds_get_mask(), the + function sd_bus_creds_get_augmented_mask() + returns a bitmask of field constants. The mask indicates which + credential fields have been retrieved in a non-atomic fashion. For + credential objects created via + sd_bus_creds_new_from_pid(), this mask will be + identical to the mask returned by + sd_bus_creds_get_mask(). However, for + credential objects retrieved via + sd_bus_get_name_creds(), this mask will be set + for the credential fields that could not be determined atomically + at peer connection time, and which were later added by reading + augmenting credential data from + /proc/. Similarly, for credential objects + retrieved via sd_bus_get_owner_creds(), the + mask is set for the fields that could not be determined atomically + at bus creation time, but have been augmented. Similarly, for + credential objects retrieved via + sd_bus_message_get_creds(), the mask is set + for the fields that could not be determined atomically at message + sending time, but have been augmented. The mask returned by + sd_bus_creds_get_augmented_mask() is always a + subset of (or identical to) the mask returned by + sd_bus_creds_get_mask() for the same + object. The latter call hence returns all credential fields + available in the credential object, the former then marks the + subset of those that have been augmented. Note that augmented + fields are unsuitable for authorization decisions, as they may be + retrieved at different times, thus being subject to races. Hence, + augmented fields should be used exclusively for informational + purposes. + + + sd_bus_creds_ref() creates a new + reference to the credentials object c. This + object will not be destroyed until + sd_bus_creds_unref() has been called as many + times plus once more. Once the reference count has dropped to zero, + c cannot be used anymore, so further + calls to sd_bus_creds_ref(c) or + sd_bus_creds_unref(c) are illegal. + + sd_bus_creds_unref() destroys a reference + to c. + + sd_bus_creds_unrefp() is similar to + sd_bus_creds_unref() but takes a pointer to a + pointer to an sd_bus_creds object. This call is useful in + conjunction with GCC's and LLVM's Clean-up + Variable Attribute. Note that this function is defined as + inline function. + + sd_bus_creds_ref(), + sd_bus_creds_unref() and + sd_bus_creds_unrefp() execute no operation if + the passed in bus credentials object is + NULL. + + + + + Return Value + + On success, sd_bus_creds_new_from_pid() + returns 0 or a positive integer. On failure, it returns a negative + errno-style error code. + + sd_bus_creds_get_mask() returns the + mask of successfully acquired fields. + + sd_bus_creds_get_augmented_mask() + returns the mask of fields that have been augmented from data in + /proc/, and are thus not suitable for + authorization decisions. + + sd_bus_creds_ref() always returns the + argument. + + sd_bus_creds_unref() always returns + NULL. + + + + Reference ownership + + Function sd_bus_creds_new_from_pid() + creates a new object and the caller owns the sole reference. When + not needed anymore, this reference should be destroyed with + sd_bus_creds_unref3. + + + + Errors + + Returned errors may indicate the following problems: + + + + + -ESRCH + + Specified pid could not be found. + + + + -EINVAL + + Specified parameter is invalid (NULL in case of output + parameters). + + + + -ENOMEM + + Memory allocation failed. + + + + -EOPNOTSUPP + + One of the requested fields is unknown to the local system. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_creds_get_pid3, + sd_bus_get_name_creds3, + sd_bus_get_owner_creds3, + sd_bus_message_get_creds3 + + + + diff --git a/man/sd_bus_default.xml b/man/sd_bus_default.xml new file mode 100644 index 0000000..cee0748 --- /dev/null +++ b/man/sd_bus_default.xml @@ -0,0 +1,349 @@ + + + + + + + + sd_bus_default + systemd + + + + sd_bus_default + 3 + + + + sd_bus_default + sd_bus_default_user + sd_bus_default_system + + sd_bus_open + sd_bus_open_with_description + sd_bus_open_user + sd_bus_open_user_with_description + sd_bus_open_user_machine + sd_bus_open_system + sd_bus_open_system_with_description + sd_bus_open_system_remote + sd_bus_open_system_machine + + Acquire a connection to a system or user bus + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_default + sd_bus **bus + + + + int sd_bus_default_user + sd_bus **bus + + + + int sd_bus_default_system + sd_bus **bus + + + + int sd_bus_open + sd_bus **bus + + + + int sd_bus_open_with_description + sd_bus **bus + const char *description + + + + int sd_bus_open_user + sd_bus **bus + + + + int sd_bus_open_user_with_description + sd_bus **bus + const char *description + + + + int sd_bus_open_user_machine + sd_bus **bus + const char *machine + + + + int sd_bus_open_system + sd_bus **bus + + + + int sd_bus_open_system_with_description + sd_bus **bus + const char *description + + + + int sd_bus_open_system_remote + sd_bus **bus + const char *host + + + + int sd_bus_open_system_machine + sd_bus **bus + const char *machine + + + + + + + Description + + sd_bus_default() acquires a bus + connection object to the user bus when invoked from within a user + slice (any session under user-*.slice, e.g.: + user@1000.service), or to the system bus + otherwise. The connection object is associated with the calling + thread. Each time the function is invoked from the same thread, + the same object is returned, but its reference count is increased + by one, as long as at least one reference is kept. When the last + reference to the connection is dropped (using the + sd_bus_unref3 + call), the connection is terminated. Note that the connection is + not automatically terminated when the associated thread ends. It + is important to drop the last reference to the bus connection + explicitly before the thread ends, as otherwise, the connection will + leak. Also, queued but unread or unwritten messages keep the + bus referenced, see below. + + sd_bus_default_user() returns a user + bus connection object associated with the calling thread. + sd_bus_default_system() is similar, but + connects to the system bus. Note that + sd_bus_default() is identical to these two + calls, depending on the execution context. + + sd_bus_open() creates a new, + independent bus connection to the user bus when invoked in user + context, or the system bus + otherwise. sd_bus_open_user() is similar, but + connects only to the user bus. + sd_bus_open_system() does the same, but + connects to the system bus. In contrast to + sd_bus_default(), + sd_bus_default_user(), and + sd_bus_default_system(), these calls return + new, independent connection objects that are not associated with + the invoking thread and are not shared between multiple + invocations. It is recommended to share connections per thread to + efficiently make use the available resources. Thus, it is + recommended to use sd_bus_default(), + sd_bus_default_user() and + sd_bus_default_system() to connect to the + user or system buses. + + sd_bus_open_with_description(), + sd_bus_open_user_with_description(), and + sd_bus_open_system_with_description() are similar to + sd_bus_open(), sd_bus_open_user(), and + sd_bus_open_system(), but allow a description string to be set, see + sd_bus_set_description3. + description may be NULL, in which case this function + is equivalent to sd_bus_open(). This description string is used in log + messages about the bus object, and including a "name" for the bus makes them easier to + understand. Some messages are emitted during bus initialization, hence using this function is + preferable to setting the description later with + sd_bus_open_with_description(). The argument is copied internally and will + not be referenced after the function returns. + + If the $DBUS_SESSION_BUS_ADDRESS environment + variable is set + (cf. environ7), + it will be used as the address of the user bus. This variable can + contain multiple addresses separated by ;. If + this variable is not set, a suitable default for the default user + D-Bus instance will be used. + + If the $DBUS_SYSTEM_BUS_ADDRESS + environment variable is set, it will be used as the address of the + system bus. This variable uses the same syntax as + $DBUS_SESSION_BUS_ADDRESS. If this variable is + not set, a suitable default for the default system D-Bus instance + will be used. + + sd_bus_open_system_remote() connects to the system bus on + the specified host using + ssh1. + host consists of an optional user name followed by the + @ symbol, and the hostname, optionally followed by a + : and a port, optionally followed by a + / and a machine name. If the machine name is given, a connection + is created to the system bus in the specified container on the remote machine, and + otherwise a connection to the system bus on the specified host is created. + + Note that entering a container is a privileged operation, and will likely only + work for the root user on the remote machine. + + sd_bus_open_system_machine() connects to the system bus in the specified + machine, where machine is the name of a local container, + possibly prefixed by a user name and a separating @. If the container name is + specified as the special string .host the connection is made to the local system. This + is useful to connect to the local system bus as specific user, e.g. foobar@.host to + connect to the local system bus as local user foobar. If the @ + syntax is used either the left-hand side or the right-hand side may be omitted (but not both) in which + case the local user name or .host is implied. If the @ syntax is + not used the connection is always made as root user. See + sd_bus_set_address3 + for a description of the address syntax, and + machinectl1 for more + information about the "machine" concept. Note that connections into local containers are only available + to privileged processes at this time. + + sd_bus_open_user_machine() is similar to + sd_bus_open_system_machine(), but connects to the user bus of the root user, or if + the @ syntax is used, of the specified user. + + These calls allocate a bus connection object and initiate + the connection to a well-known bus of some form. An alternative to + using these high-level calls is to create an unconnected bus + object with + sd_bus_new3 + and to connect it with + sd_bus_start3. + + + + + + Reference ownership + The functions sd_bus_open(), + sd_bus_open_user(), + sd_bus_open_user_machine(), + sd_bus_open_system(), + sd_bus_open_system_remote(), and + sd_bus_open_system_machine() return a new + connection object and the caller owns the sole reference. When not + needed anymore, this reference should be destroyed with + sd_bus_unref3. + + + The functions sd_bus_default(), + sd_bus_default_user() and + sd_bus_default_system() do not necessarily + create a new object, but increase the connection reference of an + existing connection object by one. Use + sd_bus_unref3 + to drop the reference. + + Queued but unwritten/unread messages keep a reference to their bus connection object. For this reason, even + if an application dropped all references to a bus connection, it might not get destroyed right away. Until all + incoming queued messages are read, and until all outgoing unwritten messages are written, the bus object will stay + alive. sd_bus_flush() may be used to write all outgoing queued messages so they drop their + references. To flush the unread incoming messages, use sd_bus_close(), which will also close + the bus connection. When using the default bus logic, it is a good idea to first invoke + sd_bus_flush() followed by sd_bus_close() when a thread or process + terminates, and thus its bus connection object should be freed. + + Normally, slot objects (as created by + sd_bus_add_match3 and similar + calls) keep a reference to their bus connection object, too. Thus, as long as a bus slot object remains referenced + its bus object will remain allocated too. Optionally, bus slot objects may be placed in "floating" mode. When in + floating mode the life cycle of the bus slot object is bound to the bus object, i.e. when the bus object is freed + the bus slot object is automatically unreferenced too. The floating state of a slot object may be controlled + explicitly with + sd_bus_slot_set_floating3, + though usually floating bus slot objects are created by passing NULL as the + slot parameter of sd_bus_add_match() and related calls, thus indicating + that the caller is not directly interested in referencing and managing the bus slot object. + + The life cycle of the default bus connection should be the + responsibility of the code that creates/owns the thread the + default bus connection object is associated with. Library code + should neither call sd_bus_flush() nor + sd_bus_close() on default bus objects unless + it does so in its own private, self-allocated thread. Library code + should not use the default bus object in other threads unless it + is clear that the program using it will life cycle the bus + connection object and flush and close it before exiting from the + thread. In libraries where it is not clear that the calling + program will life cycle the bus connection object, it is hence + recommended to use sd_bus_open_system() + instead of sd_bus_default_system() and + related calls. + + + + Return Value + + On success, these calls return 0 or a positive + integer. On failure, these calls return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The specified parameters are invalid. + + + + -ENOMEDIUM + + The requested bus type is not available because of invalid environment (for example + the user session bus is not available because $XDG_RUNTIME_DIR is not set). + + + + + -ENOMEM + + Memory allocation failed. + + + + -ESOCKTNOSUPPORT + + The protocol version required to connect to the selected bus is not + supported. + + + + In addition, other connection-related errors may be returned. See + sd_bus_send3. + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_new3, + sd_bus_ref3, + sd_bus_unref3, + sd_bus_close3, + ssh1, + systemd-machined.service8, + machinectl1 + + + + diff --git a/man/sd_bus_emit_signal.xml b/man/sd_bus_emit_signal.xml new file mode 100644 index 0000000..08d5be4 --- /dev/null +++ b/man/sd_bus_emit_signal.xml @@ -0,0 +1,243 @@ + + + + + + + + sd_bus_emit_signal + systemd + + + + sd_bus_emit_signal + 3 + + + + sd_bus_emit_signal + sd_bus_emit_signalv + sd_bus_emit_interfaces_added + sd_bus_emit_interfaces_added_strv + sd_bus_emit_interfaces_removed + sd_bus_emit_interfaces_removed_strv + sd_bus_emit_properties_changed + sd_bus_emit_properties_changed_strv + sd_bus_emit_object_added + sd_bus_emit_object_removed + + Convenience functions for emitting (standard) D-Bus signals + + + + + #include <systemd/sd-bus-vtable.h> + + + int sd_bus_emit_signal + sd_bus *bus + const char *path + const char *interface + const char *member + const char *types + ... + + + + int sd_bus_emit_signalv + sd_bus *bus + const char *path + const char *interface + const char *member + const char *types + va_list ap + + + + int sd_bus_emit_interfaces_added + sd_bus *bus + const char *path + const char *interface + ... + + + + int sd_bus_emit_interfaces_added_strv + sd_bus *bus + const char *path + const char **interfaces + + + + int sd_bus_emit_interfaces_removed + sd_bus *bus + const char *path + const char *interface + ... + + + + int sd_bus_emit_interfaces_removed_strv + sd_bus *bus + const char *path + const char **interfaces + + + + int sd_bus_emit_properties_changed + sd_bus *bus + const char *path + const char *interface + const char *name + ... + + + + int sd_bus_emit_properties_changed_strv + sd_bus *bus + const char *path + const char *interface + const char **names + + + + int sd_bus_emit_object_added + sd_bus *bus + const char *path + + + + int sd_bus_emit_object_removed + sd_bus *bus + const char *path + + + + + + Description + + sd_bus_emit_signal() is a convenience function for initializing a + bus message object and emitting the corresponding D-Bus signal. It combines the + sd_bus_message_new_signal3, + sd_bus_message_append3 and + sd_bus_send3 + functions into a single function call. sd_bus_emit_signalv() is + equivalent to sd_bus_message_append(), except that it is called with a + va_list instead of a variable number of arguments. + + sd_bus_emit_interfaces_added() and + sd_bus_emit_interfaces_removed() are used to implement the + InterfacesAdded and InterfacesRemoved signals of the + org.freedesktop.DBus.ObjectManager interface. They take a path whose + interfaces have been modified as an argument and a variable list of interfaces that have been + added or removed, respectively. The final argument passed to + sd_bus_emit_interfaces_added() and + sd_bus_emit_interfaces_removed() must be + NULL. This allows both functions to safely determine the number of passed + interface arguments. sd_bus_emit_interfaces_added_strv() and + sd_bus_emit_interfaces_removed_strv() are identical to their respective + counterparts but both take the list of interfaces as a single argument instead of a variable + number of arguments. + + sd_bus_emit_properties_changed() is used to implement the + PropertiesChanged signal of the + org.freedesktop.DBus.Properties interface. It takes an object path, + interface and a variable list of property names as its arguments. The final argument passed to + sd_bus_emit_properties_changed() must be + NULL. This allows it to safely determine the number of passed property + names. sd_bus_emit_properties_changed_strv() is identical to + sd_bus_emit_properties_changed() but takes the list of property names as a + single argument instead of a variable number of arguments. + + sd_bus_emit_object_added() and + sd_bus_emit_object_removed() are convenience functions for emitting the + InterfacesAdded or InterfacesRemoved signals for all + interfaces registered on a specific object path, respectively. This includes any parent fallback + vtables if they are not overridden by a more applicable child vtable. It also includes all the + standard D-Bus interfaces implemented by sd-bus itself on any registered object. + + Note that sd_bus_emit_interfaces_added(), + sd_bus_emit_interfaces_removed(), + sd_bus_emit_object_added() and + sd_bus_emit_object_removed() require an object manager to have been + registered on the given object path or one of its parent object paths using + sd_bus_add_object_manager3. + + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + One of the required parameters is NULL or invalid. A + reserved D-Bus interface was passed as the interface parameter. + + + + + -ENOPKG + + The bus cannot be resolved. + + + + -ECHILD + + The bus was created in a different process. + + + + -ENOMEM + + Memory allocation failed. + + + + -ESRCH + + One of sd_bus_emit_interfaces_added(), + sd_bus_emit_interfaces_removed(), + sd_bus_emit_object_added() or + sd_bus_emit_object_removed() was called on an object without an + object manager registered on its own object path or one of its parent object paths. + + + + + See the man pages of + sd_bus_message_new_signal3, + sd_bus_message_append3 and + sd_bus_send3 + for more possible errors. + + + + + + + See Also + + + sd-bus3, + busctl1, + sd_bus_message_new_signal3, + sd_bus_message_append3, + sd_bus_send3, + sd_bus_call_method3 + + + diff --git a/man/sd_bus_enqueue_for_read.xml b/man/sd_bus_enqueue_for_read.xml new file mode 100644 index 0000000..9bdf498 --- /dev/null +++ b/man/sd_bus_enqueue_for_read.xml @@ -0,0 +1,88 @@ + + + + + + + + sd_bus_enqueue_for_read + systemd + + + + sd_bus_enqueue_for_read + 3 + + + + sd_bus_enqueue_for_read + + Re-enqueue a bus message on a bus connection, for reading + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_enqueue_for_read + sd_bus *bus + sd_bus_message *message + + + + + + + Description + + sd_bus_enqueue_for_read() may be used to re-enqueue an incoming bus message on + the local read queue, so that it is processed and dispatched locally again, similarly to how an incoming + message from the peer is processed. Takes a bus connection object and the message to enqueue. A reference + is taken of the message and the caller's reference thus remains in possession of the caller. The message + is enqueued at the end of the queue, thus will be dispatched after all other already queued messages are + dispatched. + + This call is primarily useful for dealing with incoming method calls that may be processed only + after an additional asynchronous operation completes. One example are PolicyKit authorization requests + that are determined to be necessary to authorize a newly incoming method call: when the PolicyKit response + is received the original method call may be re-enqueued to process it again, this time with the + authorization result known. + + + + Return Value + + On success, this function return 0 or a positive integer. On failure, it returns a negative errno-style + error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection has been created in a different process. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_send3, + + + + diff --git a/man/sd_bus_error-example.c b/man/sd_bus_error-example.c new file mode 100644 index 0000000..9b162eb --- /dev/null +++ b/man/sd_bus_error-example.c @@ -0,0 +1,18 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include +#include + +int writer_with_negative_errno_return(int fd, sd_bus_error *error) { + const char *message = "Hello, World!\n"; + + ssize_t n = write(fd, message, strlen(message)); + if (n >= 0) + return n; /* On success, return the number of bytes written, possibly 0. */ + + /* On error, initialize the error structure, and also propagate the errno + * value that write(2) set for us. */ + return sd_bus_error_set_errnof(error, errno, "Failed to write to fd %i: %m", fd); +} diff --git a/man/sd_bus_error.xml b/man/sd_bus_error.xml new file mode 100644 index 0000000..b2f62f2 --- /dev/null +++ b/man/sd_bus_error.xml @@ -0,0 +1,408 @@ + + + + + + + + sd_bus_error + systemd + + + + sd_bus_error + 3 + + + + sd_bus_error + SD_BUS_ERROR_MAKE_CONST + SD_BUS_ERROR_NULL + sd_bus_error_free + sd_bus_error_set + sd_bus_error_setf + sd_bus_error_setfv + sd_bus_error_set_const + sd_bus_error_set_errno + sd_bus_error_set_errnof + sd_bus_error_set_errnofv + sd_bus_error_get_errno + sd_bus_error_copy + sd_bus_error_move + sd_bus_error_is_set + sd_bus_error_has_name + sd_bus_error_has_names_sentinel + sd_bus_error_has_names + + sd-bus error handling + + + + + #include <systemd/sd-bus.h> + + typedef struct { + const char *name; + const char *message; + … +} sd_bus_error; + + + SD_BUS_ERROR_MAKE_CONST(name, message) + + + SD_BUS_ERROR_NULL + + + + void sd_bus_error_free + sd_bus_error *e + + + + int sd_bus_error_set + sd_bus_error *e + const char *name + const char *message + + + + int sd_bus_error_setf + sd_bus_error *e + const char *name + const char *format + … + + + + int sd_bus_error_setfv + sd_bus_error *e + const char *name + const char *format + va_list ap + + + + int sd_bus_error_set_const + sd_bus_error *e + const char *name + const char *message + + + + int sd_bus_error_set_errno + sd_bus_error *e + int error + + + + int sd_bus_error_set_errnof + sd_bus_error *e + int error + const char *format + … + + + + int sd_bus_error_set_errnofv + sd_bus_error *e + int error + const char *format + va_list ap + + + + int sd_bus_error_get_errno + const sd_bus_error *e + + + + int sd_bus_error_copy + sd_bus_error *dst + const sd_bus_error *e + + + + int sd_bus_error_move + sd_bus_error *dst + sd_bus_error *e + + + + int sd_bus_error_is_set + const sd_bus_error *e + + + + int sd_bus_error_has_name + const sd_bus_error *e + const char *name + + + + int sd_bus_error_has_names_sentinel + const sd_bus_error *e + ... + + + + #define sd_bus_error_has_names(e, ...) sd_bus_error_has_names_sentinel(e, ..., NULL) + + + + + + + Description + + The sd_bus_error structure carries information about a D-Bus error + condition, or lack thereof. The functions described below may be used to set and query fields in this + structure. + + The name field contains a short identifier of an error. It + should follow the rules for error names described in the D-Bus specification, subsection Valid + Names. A number of common, standardized error names are described in + sd-bus-errors3, but + additional domain-specific errors may be defined by applications. + + The message field usually contains a human-readable string + describing the details, but might be NULL. + + An unset sd_bus_error structure should have both fields initialized to + NULL, and signifies lack of an error, i.e. success. Assign + SD_BUS_ERROR_NULL to the structure in order to initialize both fields to + NULL. When no longer necessary, resources held by the + sd_bus_error structure should be destroyed with + sd_bus_error_free(). + + sd_bus_error_set() sets an error structure to the specified name and message + strings. The strings will be copied into internal, newly allocated memory. It is essential to free the + contents again when they are not required anymore (see above). Do not use this call on error structures + that have already been set. If you intend to reuse an error structure, free the old data stored in it + with sd_bus_error_free() first. + + sd_bus_error_set() will return an errno-like value (see + errno3) + determined from the specified error name name. If name is + NULL, it is assumed that no error occurred, and 0 is returned. + If name is nonnull, a negative value is always returned. If + e is NULL, no error structure is initialized, but + name is still converted into an errno-style value. + + Various well-known D-Bus errors are converted to well-known errno counterparts, + and the other ones to -EIO. See + sd-bus-errors3 for a + list of well-known error names. Additional error mappings may be defined with + sd_bus_error_add_map3. + + + sd_bus_error_set() is designed to be conveniently used in a + return statement. If message is NULL, no + message is set. This call can fail if no memory may be allocated for the name and message strings, in + which case an SD_BUS_ERROR_NO_MEMORY error will be set instead and + -ENOMEM returned. + + sd_bus_error_setf() and sd_bus_error_setfv() are similar + to sd_bus_error_set(), but take a printf3 format + string and corresponding arguments to generate the message field. + sd_bus_error_setf() uses variadic arguments, and + sd_bus_error_setfv() accepts the arguments as a + va_arg3 + parameter list. + + sd_bus_error_set_const() is similar to + sd_bus_error_set(), but the string parameters are not copied internally, and must + hence remain constant and valid for the lifetime of e. Use this call to avoid + memory allocations when setting error structures. Since this call does not allocate memory, it will not + fail with an out-of-memory condition as sd_bus_error_set() may, as described + above. Alternatively, the SD_BUS_ERROR_MAKE_CONST() macro may be used to generate a + literal, constant bus error structure on-the-fly. + + sd_bus_error_set_errno() will immediately return 0 if the + specified error parameter error is 0. Otherwise, it will set + name from an errno-like value that is converted to a D-Bus + error. strerror_r3 will + be used to set message. Well-known D-Bus error names will be used for + name if applicable, otherwise a name in the System.Error. + namespace will be generated. The sign of the specified error number is ignored and the absolute value is + used implicitly. If the specified error error is non-zero, the call always returns + a negative value, for convenient usage in return statements. This call might fail + due to lack of memory, in which case an SD_BUS_ERROR_NO_MEMORY error is set instead, + and -ENOMEM is returned. + + sd_bus_error_set_errnof() and sd_bus_error_set_errnof() + are similar to sd_bus_error_set_errno(), but in addition to + error, take a printf3 format + string and corresponding arguments. The message field will be generated from + format and the arguments. + sd_bus_error_set_errnof() uses variadic arguments, and + sd_bus_error_set_errnofv() accepts the arguments as a + va_arg3 + parameter list. + + sd_bus_error_get_errno() converts the name field of + an error structure to an errno-like (positive) value using the same rules as + sd_bus_error_set(). If e is NULL, + 0 will be returned. + + sd_bus_error_copy() will initialize dst using the + values in e, if e has been set with an error value before. + Otherwise, it will return immediately. If the strings in e were set using + sd_bus_error_set_const(), they will be shared. Otherwise, they will be + copied. Before this call, dst must be unset, i.e. either freshly initialized with + NULL or reset using sd_bus_error_free(). + + sd_bus_error_copy() generally returns 0 or a negative + errno-like value based on the input parameter e: + 0 if it was unset and a negative integer if it was set to some error, similarly to + sd_bus_error_set(). It may however also return an error generated internally, for + example -ENOMEM if a memory allocation fails. + + sd_bus_error_move() is similar to sd_bus_error_copy(), + but will move any error information from e into dst, + resetting the former. This function cannot fail, as no new memory is allocated. Note that if + e is not set, dst is initialized to + SD_BUS_ERROR_NULL. Moreover, if dst is + NULL no operation is executed on it and resources held by e + are freed and reset. Returns a converted errno-like, non-positive error value. + + sd_bus_error_is_set() will return a + non-zero value if e is + non-NULL and an error has been set, + false otherwise. + + sd_bus_error_has_name() will return a + non-zero value if e is + non-NULL and an error with the same + name has been set, + false otherwise. + + sd_bus_error_has_names_sentinel() is similar to + sd_bus_error_has_name(), but takes multiple names to check against. The list must be + terminated with NULL. sd_bus_error_has_names() + is a macro wrapper around sd_bus_error_has_names_sentinel() that adds the + NULL sentinel automatically. + + sd_bus_error_free() will destroy + resources held by e. The parameter itself + will not be deallocated, and must be free3d + by the caller if necessary. The function may also be called safely + on unset errors (error structures with both fields set to NULL), + in which case it performs no operation. This call will reset the + error structure after freeing the data, so that all fields are set + to NULL. The structure may be reused afterwards. + + + + Reference ownership + + sd_bus_error is not reference-counted. Users should destroy resources held + by it by calling sd_bus_error_free(). Usually, error structures are allocated on the + stack or passed in as function parameters, but they may also be allocated dynamically, in which case it + is the duty of the caller to free3 the memory + held by the structure itself after freeing its contents with + sd_bus_error_free(). + + + + Return Value + + The functions sd_bus_error_set(), sd_bus_error_setf(), + and sd_bus_error_set_const() always return 0 when the specified + error value is NULL, and a negative errno-like value corresponding to the + name parameter otherwise. The functions + sd_bus_error_set_errno(), sd_bus_error_set_errnof() and + sd_bus_error_set_errnofv(), return 0 when the specified error + value is 0, and a negative errno-like value corresponding to the + error parameter otherwise. If an error occurs internally, one of the negative + error values listed below will be returned. This allows those functions to be conveniently used in a + return statement, see the example below. + + sd_bus_error_get_errno() returns + false when e is + NULL, and a positive errno value mapped from + e->name otherwise. + + sd_bus_error_copy() and sd_bus_error_move() return a + negative error value converted from the source error, and zero if the error has not been set. This + allows those functions to be conveniently used in a return statement, see the + example below. + + sd_bus_error_is_set() returns a + non-zero value when e and the + name field are + non-NULL, zero otherwise. + + sd_bus_error_has_name(), sd_bus_error_has_names(), and + sd_bus_error_has_names_sentinel() return a non-zero value when e is + non-NULL and the name field is equal to one of the given + names, zero otherwise. + + + Errors + + Return value may indicate the following problems in the invocation of the function itself: + + + + -EINVAL + + Error was already set in the sd_bus_error structure when + one the error-setting functions was called. + + + + -ENOMEM + + Memory allocation failed. + + + + On success, sd_bus_error_set(), sd_bus_error_setf(), + sd_bus_error_set_const(), sd_bus_error_set_errno(), + sd_bus_error_set_errnof(), sd_bus_error_set_errnofv(), + sd_bus_error_copy(), and sd_bus_error_move() will return a + negative converted errno-style value, or 0 if the error + parameter is NULL or unset. D-Bus errors are converted to the integral + errno-style value, and the mapping mechanism is extensible, see the discussion + above. This effectively means that almost any negative errno-style value can be + returned. + + + + + Examples + + + Using the negative return value to propagate an error + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd-bus-errors3, + sd_bus_error_add_map3, + errno3, + strerror_r3 + + + + diff --git a/man/sd_bus_error_add_map.xml b/man/sd_bus_error_add_map.xml new file mode 100644 index 0000000..7c914b0 --- /dev/null +++ b/man/sd_bus_error_add_map.xml @@ -0,0 +1,134 @@ + + + + + + + + sd_bus_error_add_map + systemd + + + + sd_bus_error_add_map + 3 + + + + sd_bus_error_add_map + sd_bus_error_map + SD_BUS_ERROR_MAP + SD_BUS_ERROR_END + + Additional sd-dbus error mappings + + + + + #include <systemd/sd-bus.h> + + typedef struct { + const char *name; + int code; + … +} sd_bus_error_map; + + SD_BUS_ERROR_MAP(name, code) + + SD_BUS_ERROR_MAP_END + + + int sd_bus_error_add_map + const sd_bus_error_map *map + + + + + + Description + + The sd_bus_error_add_map() call may be + used to register additional mappings for converting D-Bus errors + to Linux errno-style errors. The mappings + defined with this call are consulted by calls such as + sd_bus_error_set3 + or + sd_bus_error_get_errno3. By + default, a number of generic, standardized mappings are known, as + documented in + sd-bus-errors3. Use + this call to add further, application-specific mappings. + + The function takes a pointer to an array of + sd_bus_error_map structures. A reference + to the specified array is added to the lookup tables for error + mappings. Note that the structure is not copied, and that it is hence + essential that the array stays available and constant during the + entire remaining runtime of the process. + + The mapping array should be put together with a series of + SD_BUS_ERROR_MAP() macro invocations that + take a literal name string and a (positive) + errno-style error number. The last entry of the + array should be an invocation of the + SD_BUS_ERROR_MAP_END macro. The array should not be + put together without use of these two macros. + + Note that the call is idempotent: it is safe to invoke it + multiple times with the parameter, which will only add the passed + mapping array once. + + Note that the memory allocated by this call is not intended + to be freed during the lifetime of the process. It should not be + freed explicitly. + + + + Return Value + + sd_bus_error_add_map() returns a + positive value when the new array was added to the lookup + tables. It returns zero when the same array was already added + before. On error, a negative errno-style error + code is returned. See below for known error codes. + + + Errors + + Returned errors may indicate the following problems: + + + + + -EINVAL + + The specified mapping array is invalid. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_error3, + sd-bus-errors3, + errno3, + strerror_r3 + + + + diff --git a/man/sd_bus_get_current_handler.xml b/man/sd_bus_get_current_handler.xml new file mode 100644 index 0000000..c3756b8 --- /dev/null +++ b/man/sd_bus_get_current_handler.xml @@ -0,0 +1,86 @@ + + + + + + + + sd_bus_get_current_handler + systemd + + + + sd_bus_get_current_handler + 3 + + + + sd_bus_get_current_handler + sd_bus_get_current_message + sd_bus_get_current_slot + sd_bus_get_current_userdata + + Query information of the callback a bus object is currently running + + + + + #include <systemd/sd-bus.h> + + + + + sd_bus_message_handler_t sd_bus_get_current_handler + sd_bus *bus + + + + sd_bus_message* sd_bus_get_current_message + sd_bus *bus + + + + sd_bus_slot* sd_bus_get_current_slot + sd_bus *bus + + + + void* sd_bus_get_current_userdata + sd_bus *bus + + + + + + Description + + Whenever sd-bus is about to invoke a user-supplied callback function, it stores the + current callback, D-Bus message, slot and userdata pointer and allows these to be queried via + sd_bus_get_current_handler(), + sd_bus_get_current_message(), + sd_bus_get_current_slot() and + sd_bus_get_current_userdata(), respectively. If bus + cannot be resolved or if execution does not reside in a user-supplied callback of + bus, these functions return NULL. + + + + Return Value + + On success, these functions return the requested object. On failure, they return + NULL. + + + + + + See Also + + + systemd1, + sd-bus3 + + + + diff --git a/man/sd_bus_get_fd.xml b/man/sd_bus_get_fd.xml new file mode 100644 index 0000000..a8a1615 --- /dev/null +++ b/man/sd_bus_get_fd.xml @@ -0,0 +1,177 @@ + + + + + + + + + sd_bus_get_fd + systemd + + + + sd_bus_get_fd + 3 + + + + sd_bus_get_fd + sd_bus_get_events + sd_bus_get_timeout + + Get the file descriptor, I/O events and timeout to wait for from a message bus + object + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_get_fd + sd_bus *bus + + + + int sd_bus_get_events + sd_bus *bus + + + + int sd_bus_get_timeout + sd_bus *bus + uint64_t *timeout_usec + + + + + + Description + + sd_bus_get_fd() returns the file descriptor used to communicate from + a message bus object. This descriptor can be used with + poll3 + or a similar function to wait for I/O events on the specified bus connection object. If the bus + object was configured with the sd_bus_set_fd() function, then the + input_fd file descriptor used in that call is returned. + + sd_bus_get_events() returns the I/O events to wait for, suitable for + passing to poll() or a similar call. Returns a combination of + POLLIN, POLLOUT, … events, or negative on error. + + + sd_bus_get_timeout() returns the timeout in µs to pass to + poll() or a similar call when waiting for events on the specified bus + connection. The returned timeout may be zero, in which case a subsequent I/O polling call + should be invoked in non-blocking mode. The returned timeout may be + UINT64_MAX in which case the I/O polling call may block indefinitely, + without any applied timeout. Note that the returned timeout should be considered only a + maximum sleeping time. It is permissible (and even expected) that shorter timeouts are used by + the calling program, in case other event sources are polled in the same event loop. Note that + the returned time-value is absolute, based of CLOCK_MONOTONIC and specified + in microseconds. When converting this value in order to pass it as third argument to + poll() (which expects relative milliseconds), care should be taken to convert + to a relative time and use a division that rounds up to ensure the I/O polling operation + doesn't sleep for shorter than necessary, which might result in unintended busy looping + (alternatively, use + ppoll2 + instead of plain poll(), which understands timeouts with nano-second + granularity). + + These three functions are useful to hook up a bus connection object with an external or + manual event loop involving poll() or a similar I/O polling call. Before + each invocation of the I/O polling call, all three functions should be invoked: the file + descriptor returned by sd_bus_get_fd() should be polled for the events + indicated by sd_bus_get_events(), and the I/O call should block for that up + to the timeout returned by sd_bus_get_timeout(). After each I/O polling + call the bus connection needs to process incoming or outgoing data, by invoking + sd_bus_process3. + + + Note that these functions are only one of three supported ways to implement I/O event + handling for bus connections. Alternatively use + sd_bus_attach_event3 + to attach a bus connection to an + sd-event3 + event loop. Or use + sd_bus_wait3 + as a simple synchronous, blocking I/O waiting call. + + + + Return Value + + On success, sd_bus_get_fd() returns the file descriptor used for + communication. On failure, it returns a negative errno-style error code. + + On success, sd_bus_get_events() returns the I/O event mask to use for + I/O event watching. On failure, it returns a negative errno-style error code. + + On success, sd_bus_get_timeout() returns a non-negative integer. On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + An invalid bus object was passed. + + + + -ECHILD + + The bus connection was allocated in a parent process and is being reused + in a child process after fork(). + + + + -ENOTCONN + + The bus connection has been terminated. + + + + -EPERM + + Two distinct file descriptors were passed for input and output using + sd_bus_set_fd(), which sd_bus_get_fd() cannot + return. + + + + -ENOPKG + + The bus cannot be resolved. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_process3, + sd_bus_attach_event3, + sd_bus_wait3, + sd_bus_set_fd3, + poll3 + + + + diff --git a/man/sd_bus_get_n_queued_read.xml b/man/sd_bus_get_n_queued_read.xml new file mode 100644 index 0000000..c9978d8 --- /dev/null +++ b/man/sd_bus_get_n_queued_read.xml @@ -0,0 +1,100 @@ + + + + + + + + sd_bus_get_fd + systemd + + + + sd_bus_get_n_queued_read + 3 + + + + sd_bus_get_n_queued_read + sd_bus_get_n_queued_write + + Get the number of pending bus messages in the read and write queues of a bus connection object + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_get_n_queued_read + sd_bus *bus + uint64_t *ret + + + + int sd_bus_get_n_queued_write + sd_bus *bus + uint64_t *ret + + + + + + Description + + + sd_bus_get_n_queued_read() may be used to query the number of bus messages in the read queue + of a bus connection object. The read queue contains all messages read from the transport medium (e.g. network + socket) but not yet processed locally. The function expects two arguments: the bus object to query, and a pointer + to a 64bit counter variable to write the current queue size to. Use sd_bus_process() in + order to process queued messages, i.e. to reduce the size of the read queue (as well as, in fact, the write + queue, see below). + + + + Similarly, sd_bus_get_n_queued_write() may be used to query the number of currently pending + bus messages in the write queue of a bus connection object. The write queue contains all messages enqueued into + the connection with a call such as sd_bus_send() but not yet written to the transport + medium. The expected arguments are similar to sd_bus_get_n_queued_read(). Here too, use + sd_bus_process() to reduce the size of the write queue. Alternatively, use + sd_bus_flush() to synchronously write out any pending bus messages until the write queue is + empty. + + + + + Return Value + + On success, these functions return 0 or a positive integer. On failure, they return a negative errno-style + error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection was created in a different process. + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_process3, + sd_bus_send3, + sd_bus_flush3 + + + + diff --git a/man/sd_bus_get_name_creds.xml b/man/sd_bus_get_name_creds.xml new file mode 100644 index 0000000..6f0541d --- /dev/null +++ b/man/sd_bus_get_name_creds.xml @@ -0,0 +1,121 @@ + + + + + + + + sd_bus_get_name_creds + systemd + + + + sd_bus_get_name_creds + 3 + + + + sd_bus_get_name_creds + sd_bus_get_owner_creds + + Query bus client credentials + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_get_name_creds + sd_bus *bus + const char *name + uint64_t mask + sd_bus_creds **creds + + + + int sd_bus_get_owner_creds + sd_bus *bus + uint64_t mask + sd_bus_creds **creds + + + + + + Description + + sd_bus_get_name_creds() queries the credentials of the bus client + identified by name. The mask parameter is a combo of + SD_BUS_CREDS_* flags that indicate which credential info the caller is + interested in. See + sd_bus_creds_new_from_pid3 + for a list of possible flags. On success, creds contains a new + sd_bus_creds instance with the requested information. Ownership of this instance + belongs to the caller and it should be freed once no longer needed by calling + sd_bus_creds_unref3. + + + sd_bus_get_owner_creds() queries the credentials of the creator of the given + bus. The mask and creds parameters behave the same as in + sd_bus_get_name_creds(). + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + An argument is invalid. + + + + -ENOPKG + + The bus cannot be resolved. + + + + -EPERM + + The bus has already been started. + + + + -ECHILD + + The bus was created in a different process. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_creds_unref3 + + + diff --git a/man/sd_bus_get_name_machine_id.xml b/man/sd_bus_get_name_machine_id.xml new file mode 100644 index 0000000..8249485 --- /dev/null +++ b/man/sd_bus_get_name_machine_id.xml @@ -0,0 +1,98 @@ + + + + + + + + sd_bus_get_name_machine_id + systemd + + + + sd_bus_get_name_machine_id + 3 + + + + sd_bus_get_name_machine_id + + Retrieve a bus client's machine identity + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_get_name_machine_id + sd_bus *bus + const char *name + sd_id128_t *machine + + + + + + Description + + sd_bus_get_name_machine_id() retrieves the D-Bus machine identity of the + machine that the bus client identified by name is running on. Internally, it calls + the GetMachineId method of the org.freedesktop.DBus.Peer + interface. The D-Bus machine identity is a 128-bit UUID. On Linux systems running systemd, this + corresponds to the contents of /etc/machine-id. On success, the machine identity is + stored in machine. + + + + Return Value + + On success, this function returns a non-negative integer. On failure, it returns a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + An argument is invalid. + + + + -ENOPKG + + The bus cannot be resolved. + + + + -ECHILD + + The bus was created in a different process. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3 + + + + diff --git a/man/sd_bus_interface_name_is_valid.xml b/man/sd_bus_interface_name_is_valid.xml new file mode 100644 index 0000000..81a3fad --- /dev/null +++ b/man/sd_bus_interface_name_is_valid.xml @@ -0,0 +1,98 @@ + + + + + + + sd_bus_interface_name_is_valid + systemd + + + + sd_bus_interface_name_is_valid + 3 + + + + sd_bus_interface_name_is_valid + sd_bus_service_name_is_valid + sd_bus_member_name_is_valid + sd_bus_object_path_is_valid + + Check if a string is a valid bus name or object path + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_interface_name_is_valid + const char* p + + + + int sd_bus_service_name_is_valid + const char* p + + + + int sd_bus_member_name_is_valid + const char* p + + + + int sd_bus_object_path_is_valid + const char* p + + + + + + Description + + sd_bus_interface_name_is_valid() checks if a given string + p is a syntactically valid bus interface name. Similarly, + sd_bus_service_name_is_valid() checks if the argument is a valid bus service name, + sd_bus_member_name_is_valid() checks if the argument is a valid bus interface member + name, and sd_bus_object_path_is_valid() checks if the argument is a valid bus object + path. Those functions generally check that only allowed characters are used and that the length of the + string is within limits. + + + + Return Value + + Those functions return 1 if the argument is a valid interface / service / member name or object + path, and 0 if it is not. If the argument is NULL, an error is returned. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The p parameter is + NULL. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_call_method3 + + + + diff --git a/man/sd_bus_is_open.xml b/man/sd_bus_is_open.xml new file mode 100644 index 0000000..621ed27 --- /dev/null +++ b/man/sd_bus_is_open.xml @@ -0,0 +1,106 @@ + + + + + + + + sd_bus_is_open + systemd + + + + sd_bus_is_open + 3 + + + + sd_bus_is_open + sd_bus_is_ready + + Check whether the bus connection is open or ready + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_is_open + sd_bus *bus + + + + int sd_bus_is_ready + sd_bus *bus + + + + + + + Description + + sd_bus_is_open() checks whether the specified bus connection is open, i.e. in the + process of being established, already established or in the process of being torn down. It returns zero when the + connection has not been started yet + (i.e. sd_bus_start3 or some + equivalent call has not been invoked yet), or is fully terminated again (for example after + sd_bus_close3), it returns + positive otherwise. + + sd_bus_is_ready() checks whether the specified connection is fully established, + i.e. completed the connection and authentication phases of the protocol and received the + Hello() method call response, and is not in the process of being torn down again. It returns + zero outside of this state, and positive otherwise. Effectively, this function returns positive while regular + messages can be sent or received on the connection. + + The bus argument may be NULL, zero is also returned in + that case. + + To be notified when the connection is fully established, use + sd_bus_set_connected_signal3 and + install a match for the Connected() signal on the + org.freedesktop.DBus.Local interface. To be notified when the connection is torn down again, + install a match for the Disconnected() signal on the + org.freedesktop.DBus.Local interface. + + + + Return Value + + Those functions return 0 if the bus is not in the given state, and a positive + integer when it is. On failure, a negative errno-style error code is returned. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection has been created in a different process. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_start3, + sd_bus_close3, + sd_bus_set_connected_signal3 + + + + diff --git a/man/sd_bus_list_names.xml b/man/sd_bus_list_names.xml new file mode 100644 index 0000000..d8f7e60 --- /dev/null +++ b/man/sd_bus_list_names.xml @@ -0,0 +1,110 @@ + + + + + + + + sd_bus_list_names + systemd + + + + sd_bus_list_names + 3 + + + + sd_bus_list_names + + Retrieve information about registered names on a bus + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_list_names + sd_bus *bus + char ***acquired + char ***activatable + + + + + + Description + + sd_bus_list_names() retrieves information about the registered names on a bus. + If acquired is not NULL, this function calls + + org.freedesktop.DBus.ListNames to retrieve the list of currently-owned names on the bus. If + acquired is not NULL, the function calls + + org.freedesktop.DBus.ListActivableNames to retrieve the list of all names on the bus that can be + activated. Note that ownership of the arrays returned by sd_bus_list_names() in + acquired and activatable is transferred to the caller and + hence, the caller is responsible for freeing these arrays and their contents. + + + + Return Value + + On success, sd_bus_list_names() returns a non-negative integer. On failure, + it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + bus or both acquired and + activatable were NULL. + + + + + -ENOPKG + + The bus cannot be resolved. + + + + -ECHILD + + The bus was created in a different process. + + + + -ENOMEM + + Memory allocation failed. + + + + -ENOTCONN + + The bus is not connected. + + + + + + + + + See Also + + + systemd1, + sd-bus3 + + + diff --git a/man/sd_bus_message_append.xml b/man/sd_bus_message_append.xml new file mode 100644 index 0000000..98667ad --- /dev/null +++ b/man/sd_bus_message_append.xml @@ -0,0 +1,239 @@ + + + + + + + + sd_bus_message_append + systemd + + + + sd_bus_message_append + 3 + + + + sd_bus_message_append + sd_bus_message_appendv + + Attach fields to a D-Bus message based on a type string + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_append + sd_bus_message *m + const char *types + … + + + + int sd_bus_message_appendv + sd_bus_message *m + const char *types + va_list ap + + + + + + + Description + + The sd_bus_message_append() function appends a sequence of fields to + the D-Bus message object m. The type string types + describes the types of the field arguments that follow. For each type specified in the type + string, one or more arguments need to be specified, in the same order as declared in the type + string. + + The type string is composed of the elements shown in the table below. It contains zero or + more single "complete types". Each complete type may be one of the basic types or a fully + described container type. A container type may be a structure with the contained types, a + variant, an array with its element type, or a dictionary entry with the contained types. The + type string is NUL-terminated. + + In case of a basic type, one argument of the corresponding type is expected. + + A structure is denoted by a sequence of complete types between ( and + ). This sequence cannot be empty — it must contain at least one type. + Arguments corresponding to this nested sequence follow the same rules as if they were not + nested. + + A variant is denoted by v. Corresponding arguments must begin with a + type string denoting a complete type, and following that, arguments corresponding to the + specified type. + + An array is denoted by a followed by a complete type. Corresponding + arguments must begin with the number of entries in the array, followed by the entries + themselves, matching the element type of the array. + + A dictionary is an array of dictionary entries, denoted by a followed + by a pair of complete types between { and }. The first of + those types must be a basic type. Corresponding arguments must begin with the number of + dictionary entries, followed by a pair of values for each entry matching the element type of the + dictionary entries. + + sd_bus_message_appendv() is equivalent to + sd_bus_message_append(), except that it is called with a + va_list instead of a variable number of arguments. This function does not + call the va_end() macro. Because it invokes the + va_arg() macro, the value of ap is undefined after + the call. + + For further details on the D-Bus type system, please consult the + D-Bus Specification. + + + + Item type specifiers + + + + + + + + + + a + SD_BUS_TYPE_ARRAY + array + determined by array type and size + int, followed by array contents + + + + v + SD_BUS_TYPE_VARIANT + variant + determined by the type argument + signature string, followed by variant contents + + + + ( + SD_BUS_TYPE_STRUCT_BEGIN + array start + determined by the nested types + structure contents + + + ) + SD_BUS_TYPE_STRUCT_END + array end + + + + { + SD_BUS_TYPE_DICT_ENTRY_BEGIN + dictionary entry start + determined by the nested types + dictionary contents + + + } + SD_BUS_TYPE_DICT_ENTRY_END + dictionary entry end + + + +
+ + For types s and g (unicode string or signature), the pointer + may be NULL, which is equivalent to an empty string. For h (UNIX + file descriptor), the descriptor is duplicated by this call and the passed descriptor stays in possession + of the caller. See + sd_bus_message_append_basic3 + for the precise interpretation of those and other types. + + + + Types String Grammar + + types ::= complete_type* +complete_type ::= basic_type | variant | structure | array | dictionary +basic_type ::= "y" | "n" | "q" | "u" | "i" | "x" | "t" | "d" | + "b" | "h" | + "s" | "o" | "g" +variant ::= "v" +structure ::= "(" complete_type+ ")" +array ::= "a" complete_type +dictionary ::= "a" "{" basic_type complete_type "}" + + + + + Examples + + Append a single basic type (the string a string): + + + sd_bus_message *m; +… +sd_bus_message_append(m, "s", "a string"); + + Append all types of integers: + + uint8_t y = 1; +int16_t n = 2; +uint16_t q = 3; +int32_t i = 4; +uint32_t u = 5; +int32_t x = 6; +uint32_t t = 7; +double d = 8.0; +sd_bus_message_append(m, "ynqiuxtd", y, n, q, i, u, x, t, d); + + Append a structure composed of a string and a D-Bus path: + + sd_bus_message_append(m, "(so)", "a string", "/a/path"); + + + Append an array of UNIX file descriptors: + + sd_bus_message_append(m, "ah", 3, STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO); + + + Append a variant, with the real type "g" (signature), + and value "sdbusisgood": + + sd_bus_message_append(m, "v", "g", "sdbusisgood"); + + Append a dictionary containing the mapping {1=>"a", 2=>"b", 3=>""}: + + + sd_bus_message_append(m, "a{is}", 3, 1, "a", 2, "b", 3, NULL); + + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code. + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_append_basic3, + sd_bus_message_append_array3, + sd_bus_message_open_container3 + + + + diff --git a/man/sd_bus_message_append_array.xml b/man/sd_bus_message_append_array.xml new file mode 100644 index 0000000..da72b78 --- /dev/null +++ b/man/sd_bus_message_append_array.xml @@ -0,0 +1,179 @@ + + + + + + + + sd_bus_message_append_array + systemd + + + + sd_bus_message_append_array + 3 + + + + sd_bus_message_append_array + sd_bus_message_append_array_memfd + sd_bus_message_append_array_iovec + sd_bus_message_append_array_space + + Append an array of fields to a D-Bus + message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_append_array + sd_bus_message *m + char type + void *ptr + size_t size + + + + int sd_bus_message_append_array_memfd + sd_bus_message *m + char type + int memfd + uint64_t offset + uint64_t size + + + + int sd_bus_message_append_array_iovec + sd_bus_message *m + char type + const struct iovec *iov + unsigned n + + + + int sd_bus_message_append_array_space + sd_bus_message *m + char type + size_t size + void **ptr + + + + + + Description + + The sd_bus_message_append_array() + function appends an array to a D-Bus message + m. A container will be opened, the array + contents appended, and the container closed. The parameter + type determines how the pointer + p is interpreted. + type must be one of the "trivial" types + y, n, q, + i, u, x, + t, d (but not + b), as defined by the Basic + Types section of the D-Bus specification, and listed in + sd_bus_message_append_basic3. + Pointer p must point to an array of size + size bytes containing items of the + respective type. Size size must be a + multiple of the size of the type type. As a + special case, p may be + NULL, if size is 0. + The memory pointed to by p is copied into + the memory area containing the message and stays in possession of + the caller. The caller may hence freely change the data after this + call without affecting the message the array was appended + to. + + The sd_bus_message_append_array_memfd() + function appends an array of a trivial type to message + m, similar to + sd_bus_message_append_array(). The contents + of the memory file descriptor memfd + starting at the specified offset and of the specified size is + used as the contents of the array. The offset and size must be a + multiple of the size of the type + type. However, as a special exception, if + the offset is specified as zero and the size specified as + UINT64_MAX the full memory file descriptor contents is used. The + memory file descriptor is sealed by this call if it has not been + sealed yet, and cannot be modified after this call. See + memfd_create2 + for details about memory file descriptors. Appending arrays with + memory file descriptors enables efficient zero-copy data transfer, + as the memory file descriptor may be passed as-is to the + destination, without copying the memory in it to the destination + process. Not all protocol transports support passing memory file + descriptors between participants, in which case this call will + automatically fall back to copying. Also, as memory file + descriptor passing is inefficient for smaller amounts of data, + copying might still be enforced even where memory file descriptor + passing is supported. + + The sd_bus_message_append_array_iovec() + function appends an array of a trivial type to the message + m, similar to + sd_bus_message_append_array(). Contents of + the I/O vector array iov are used as the + contents of the array. The total size of + iov payload (the sum of + iov_len fields) must be a multiple of + the size of the type type. The + iov argument must point to + n I/O vector structures. Each structure may + have the iov_base field set, in which + case the memory pointed to will be copied into the message, or + unset (set to zero), in which case a block of zeros of length + iov_len bytes will be inserted. The + memory pointed at by iov may be changed + after this call. + + The sd_bus_message_append_array_space() + function appends space for an array of a trivial type to message + m. It behaves the same as + sd_bus_message_append_array(), but instead of + copying items to the message, it returns a pointer to the + destination area to the caller in pointer + p. The caller should subsequently write the + array contents to this memory. Modifications to the memory + pointed to should only occur until the next operation on the bus + message is invoked. Most importantly, the memory should not be + altered anymore when another field has been added to the message + or the message has been sealed. + + + + Return Value + + On success, these calls return 0 or a positive integer. On failure, they return a negative + errno-style error code. + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_append3, + sd_bus_message_append_basic3, + memfd_create2, + The D-Bus specification + + + + diff --git a/man/sd_bus_message_append_basic.xml b/man/sd_bus_message_append_basic.xml new file mode 100644 index 0000000..3509095 --- /dev/null +++ b/man/sd_bus_message_append_basic.xml @@ -0,0 +1,261 @@ + + + + + + + + sd_bus_message_append_basic + systemd + + + + sd_bus_message_append_basic + 3 + + + + sd_bus_message_append_basic + + Attach a single field to a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_append_basic + sd_bus_message *m + char type + const void *p + + + + + + Description + + sd_bus_message_append_basic() appends a + single field to the message m. The + parameter type determines how the pointer + p is interpreted. + type must be one of the basic types as + defined by the Basic + Types section of the D-Bus specification, and listed in + the table below. + + + + Item type specifiers + + + + + + + + + + Specifier + Constant + Description + Size + Expected C Type + + + + + y + SD_BUS_TYPE_BYTE + unsigned integer + 1 byte + uint8_t + + + + b + SD_BUS_TYPE_BOOLEAN + boolean + 4 bytes + int + + + + n + SD_BUS_TYPE_INT16 + signed integer + 2 bytes + int16_t + + + + q + SD_BUS_TYPE_UINT16 + unsigned integer + 2 bytes + uint16_t + + + + i + SD_BUS_TYPE_INT32 + signed integer + 4 bytes + int32_t + + + + u + SD_BUS_TYPE_UINT32 + unsigned integer + 4 bytes + uint32_t + + + + x + SD_BUS_TYPE_INT64 + signed integer + 8 bytes + int64_t + + + + t + SD_BUS_TYPE_UINT64 + unsigned integer + 8 bytes + uint64_t + + + + d + SD_BUS_TYPE_DOUBLE + floating-point + 8 bytes + double + + + + s + SD_BUS_TYPE_STRING + Unicode string + variable + char[] + + + + o + SD_BUS_TYPE_OBJECT_PATH + object path + variable + char[] + + + + g + SD_BUS_TYPE_SIGNATURE + signature + variable + char[] + + + + h + SD_BUS_TYPE_UNIX_FD + UNIX file descriptor + 4 bytes + int + + + +
+ + The value of the parameter is copied into a memory area held + by the message object, stays in the possession of the caller and + may hence be freely changed after this call without affecting the + bus message it has been added to. If type + is h (UNIX file descriptor), the descriptor is + duplicated by this call and the passed descriptor stays in + possession of the caller. + + For types s, o, and + g, the parameter p is + interpreted as a pointer to a NUL-terminated + character sequence. As a special case, a NULL + pointer is interpreted as an empty string. The string should be + valid Unicode string encoded as UTF-8. In case of the two latter + types, the additional requirements for a D-Bus object path or + type signature should be satisfied. Those requirements should be + verified by the recipient of the message. + + + + + Return Value + + On success, this call returns 0 or a positive integer. On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -EINVAL + + Specified parameter is invalid. + + + + + -EPERM + + Message has been sealed. + + + + + -ESTALE + + Message is in invalid state. + + + + + -ENXIO + + Message cannot be appended to. + + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_read_basic3, + sd_bus_message_append3, + The D-Bus specification + + + + diff --git a/man/sd_bus_message_append_string_memfd.xml b/man/sd_bus_message_append_string_memfd.xml new file mode 100644 index 0000000..5a4db0d --- /dev/null +++ b/man/sd_bus_message_append_string_memfd.xml @@ -0,0 +1,119 @@ + + + + + + + + sd_bus_message_append_string_memfd + systemd + + + + sd_bus_message_append_string_memfd + 3 + + + + sd_bus_message_append_string_memfd + sd_bus_message_append_string_iovec + sd_bus_message_append_string_space + + Attach a string to a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_append_string_memfd + sd_bus_message *m + int memfd + + + + int sd_bus_message_append_string_iovec + sd_bus_message *m + const struct iovec *iov + unsigned n + + + + int sd_bus_message_append_string_space + sd_bus_message *m + size_t size + char **s + + + + + + Description + + The functions + sd_bus_message_append_string_memfd() and + sd_bus_message_append_string_iovec() can be + used to append a single string (item of type s) + to message m. + + In case of + sd_bus_message_append_string_memfd(), the + contents of memfd are the string. They must + satisfy the same constraints as described for the + s type in + sd_bus_message_append_basic3. + + In case of + sd_bus_message_append_string_iovec(), the + payload of iov is the string. It must + satisfy the same constraints as described for the + s type in + sd_bus_message_append_basic3. + + The iov argument must point to + n struct iovec + structures. Each structure may have the + iov_base field set, in which case the + memory pointed to will be copied into the message, or unset, in + which case a block of spaces (ASCII 32) of length + iov_len will be inserted. The + memory pointed at by iov may be changed + after this call. + + The + sd_bus_message_append_string_space() function appends + space for a string to message m. It behaves + similar to sd_bus_message_append_basic() with + type s, but instead of copying a string into + the message, it returns a pointer to the destination area to + the caller in pointer p. Space for the string + of length size plus the terminating + NUL is allocated. + + + + Return Value + + On success, those calls return 0 or a positive integer. On failure, they return a negative + errno-style error code. + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_append_basic3, + The D-Bus specification + + + + diff --git a/man/sd_bus_message_append_strv.xml b/man/sd_bus_message_append_strv.xml new file mode 100644 index 0000000..8bf78dd --- /dev/null +++ b/man/sd_bus_message_append_strv.xml @@ -0,0 +1,81 @@ + + + + + + + + sd_bus_message_append_strv + systemd + + + + sd_bus_message_append_strv + 3 + + + + sd_bus_message_append_strv + + Attach an array of strings to a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_append_strv + sd_bus_message *m + char **l + + + + + + Description + + The sd_bus_message_append() function can be + used to append an array of strings to message + m. The parameter l + shall point to a NULL-terminated array of pointers + to NUL-terminated strings. Each string must + satisfy the same constraints as described for the + s type in + sd_bus_message_append_basic3. + + + The memory pointed at by p and the + contents of the strings themselves are copied into the memory area + containing the message and may be changed after this call. Note + that the signature of l parameter is to be + treated as const char *const *, and the contents + will not be modified. + + + + Return Value + + On success, this call returns 0 or a positive integer. On failure, a negative errno-style error + code is returned. + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_append3, + sd_bus_message_append_array3, + The D-Bus specification + + + + diff --git a/man/sd_bus_message_at_end.xml b/man/sd_bus_message_at_end.xml new file mode 100644 index 0000000..9cff48a --- /dev/null +++ b/man/sd_bus_message_at_end.xml @@ -0,0 +1,86 @@ + + + + + + + sd_bus_message_at_end + systemd + + + + sd_bus_message_at_end + 3 + + + + sd_bus_message_at_end + + Check if a message has been fully read + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_at_end + sd_bus_message *m + int complete + + + + + + Description + + sd_bus_message_at_end() returns whether all data from the currently opened + container in m or all data from all containers in m has + been read. If complete is zero, this function returns whether all data from the + currently opened container has been read. If complete is non-zero, this function + returns whether all data from all containers in m has been read. + + + + Return Value + + If all data from all containers or the current container (depending on the value of + complete) has been read, sd_bus_message_at_end() returns a + positive integer. If there is still data left to be read, it returns zero. On failure, it returns a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The m parameter is NULL. + + + + + -EPERM + + The message is not sealed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_read3 + + + diff --git a/man/sd_bus_message_copy.xml b/man/sd_bus_message_copy.xml new file mode 100644 index 0000000..278bc35 --- /dev/null +++ b/man/sd_bus_message_copy.xml @@ -0,0 +1,111 @@ + + + + + + + + sd_bus_message_copy + systemd + + + + sd_bus_message_copy + 3 + + + + sd_bus_message_copy + + Copy the contents of one message to another + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_copy + sd_bus_message *m + sd_bus_message *source + int all + + + + + + Description + + sd_bus_message_copy() copies the contents from + message source to m. If + all is false, a single complete type is copied + (basic or container). If all is true, the contents + are copied until the end of the currently open container or the end + of source. + + + + Return Value + + On success, this call returns true if anything was copied, and false if + there was nothing to copy. On failure, it returns a negative errno-style error + code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -EINVAL + + source or m are + NULL. + + + + -EPERM + + Message m has been sealed or source + has not been sealed. + + + + -ESTALE + + Destination message is in invalid state. + + + + + -ENXIO + + Destination message cannot be appended to. + + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_append3 + + + + diff --git a/man/sd_bus_message_dump.xml b/man/sd_bus_message_dump.xml new file mode 100644 index 0000000..83a4a4e --- /dev/null +++ b/man/sd_bus_message_dump.xml @@ -0,0 +1,108 @@ + + + + + + + + sd_bus_message_dump + systemd + + + + sd_bus_message_dump + 3 + + + + sd_bus_message_dump + + Produce a string representation of a message for debugging purposes + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_dump + sd_bus_message *m + FILE *f + uint64_t flags + + + + + SD_BUS_MESSAGE_DUMP_WITH_HEADER, + SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY + + + + + Description + + The sd_bus_message_dump() function writes a textual representation of the + message m to the stream f. If f is + NULL, standard output (stdio) will be used. This function is + intended to be used for debugging purposes, and the output is neither stable nor designed to be machine + readable. + + The flags parameter may be used to modify the output. With + SD_BUS_MESSAGE_DUMP_WITH_HEADER, a header that specifies the message type and flags + and some additional metadata is printed. When SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY is + not passed, the contents of the whole message are printed. When it is passed, + only the current container in printed. + + Note that this function moves the read pointer of the message. It may be necessary to reset the + position afterwards, for example with + sd_bus_message_rewind3. + + + + + Examples + + Output for a signal message (with SD_BUS_MESSAGE_DUMP_WITH_HEADER): + +‣ Type=signal Endian=l Flags=1 Version=1 Cookie=22 + Path=/value/a Interface=org.freedesktop.DBus.Properties Member=PropertiesChanged + MESSAGE "sa{sv}as" { + STRING "org.freedesktop.systemd.ValueTest"; + ARRAY "{sv}" { + DICT_ENTRY "sv" { + STRING "Value"; + VARIANT "s" { + STRING "object 0x1e, path /value/a"; + }; + }; + }; + ARRAY "s" { + STRING "Value2"; + STRING "AnExplicitProperty"; + }; + }; + + + + + + Return Value + + On success, this function returns 0 or a positive integer. On failure, it returns a negative + errno-style error code. No error codes are currently defined. + + + + + + See Also + + + systemd1, + sd-bus3 + + + + diff --git a/man/sd_bus_message_get_cookie.xml b/man/sd_bus_message_get_cookie.xml new file mode 100644 index 0000000..148bda5 --- /dev/null +++ b/man/sd_bus_message_get_cookie.xml @@ -0,0 +1,107 @@ + + + + + + + + sd_bus_message_get_cookie + systemd + + + + sd_bus_message_get_cookie + 3 + + + + sd_bus_message_get_cookie + sd_bus_message_get_reply_cookie + Returns the transaction cookie of a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_get_cookie + sd_bus_message *message + uint64_t *cookie + + + + int sd_bus_message_get_reply_cookie + sd_bus_message *message + uint64_t *cookie + + + + + + Description + + sd_bus_message_get_cookie() returns the + transaction cookie of a message. The cookie uniquely identifies a + message within each bus peer, but is not globally unique. It is + assigned when a message is sent. + + sd_bus_message_get_reply_cookie() + returns the transaction cookie of the message the specified + message is a response to. When a reply message is generated for a + method call message, its cookie is copied over into this field. + Note that while every message that is transferred is identified by + a cookie, only response messages carry a reply cookie + field. + + Both functions take a message object as first parameter and + a place to store the 64-bit cookie in. + + + + Return Value + + On success, these calls return 0 or a positive integer. On failure, they return a negative + errno-style error code. + + On success, the cookie/reply cookie is returned in the specified 64-bit unsigned integer + variable. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + A specified parameter is invalid. + + + + -ENODATA + + No cookie has been assigned to this message. This either indicates that the + message has not been sent yet and hence has no cookie assigned, or that the message is not a method + response message and hence carries a reply cookie field. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_new3 + + + + diff --git a/man/sd_bus_message_get_monotonic_usec.xml b/man/sd_bus_message_get_monotonic_usec.xml new file mode 100644 index 0000000..605e2b4 --- /dev/null +++ b/man/sd_bus_message_get_monotonic_usec.xml @@ -0,0 +1,141 @@ + + + + + + + + sd_bus_message_get_monotonic_usec + systemd + + + + sd_bus_message_get_monotonic_usec + 3 + + + + sd_bus_message_get_monotonic_usec + sd_bus_message_get_realtime_usec + sd_bus_message_get_seqnum + Retrieve the sender timestamps and sequence number of a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_get_monotonic_usec + sd_bus_message *message + uint64_t *usec + + + + int sd_bus_message_get_realtime_usec + sd_bus_message *message + uint64_t *usec + + + + int sd_bus_message_get_seqnum + sd_bus_message *message + uint64_t *seqnum + + + + + + Description + + sd_bus_message_get_monotonic_usec() + returns the monotonic timestamp of the time the message was sent. + This value is in microseconds since the + CLOCK_MONOTONIC epoch, see + clock_gettime2 + for details. + + Similarly, + sd_bus_message_get_realtime_usec() returns + the realtime (wallclock) timestamp of the time the message was + sent. This value is in microseconds since Jan 1st, 1970, i.e. in + the CLOCK_REALTIME clock. + + sd_bus_message_get_seqnum() returns the + kernel-assigned sequence number of the message. The kernel assigns + a global, monotonically increasing sequence number to all messages + transmitted on the local system, at the time the message was sent. + This sequence number is useful for determining message send order, + even across different buses of the local system. The sequence + number combined with the boot ID of the system (as returned by + sd_id128_get_boot3) + is a suitable globally unique identifier for bus messages. + + Note that the sending order and receiving order of messages + might differ, in particular for broadcast messages. This means + that the sequence number and the timestamps of messages a client + reads are not necessarily monotonically increasing. + + These timestamps and the sequence number are attached to + each message by the kernel and cannot be manipulated by the + sender. + + Note that these timestamps are only available on some bus + transports, and only after support for them has been negotiated + with the + sd_bus_negotiate_timestamp3 + call. + + + + Return Value + + On success, these calls return 0 or a positive integer. On + failure, these calls return a negative errno-style error + code. + + On success, the timestamp or sequence number is returned in + the specified 64-bit unsigned integer variable. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + A specified parameter is invalid. + + + + -ENODATA + + No timestamp or sequence number information is attached to the passed message. This + error is returned if the underlying transport does not support timestamping or assigning of + sequence numbers, or if this feature has not been negotiated with + sd_bus_negotiate_timestamp3. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_new3, + sd_bus_negotiate_timestamp3, + clock_gettime2, + sd_id128_get_boot3 + + + + diff --git a/man/sd_bus_message_get_signature.xml b/man/sd_bus_message_get_signature.xml new file mode 100644 index 0000000..203145b --- /dev/null +++ b/man/sd_bus_message_get_signature.xml @@ -0,0 +1,111 @@ + + + + + + + sd_bus_message_get_signature + systemd + + + + sd_bus_message_get_signature + 3 + + + + sd_bus_message_get_signature + sd_bus_message_is_empty + sd_bus_message_has_signature + + Query bus message signature + + + + + #include <systemd/sd-bus.h> + + + const char* sd_bus_message_get_signature + sd_bus_message *message + int complete + + + + int sd_bus_message_is_empty + sd_bus_message *message + + + + int sd_bus_message_has_signature + sd_bus_message *message + const char *signature + + + + + + + Description + + sd_bus_message_get_signature() returns the signature of message + message. If complete is true, the signature of the + whole message is returned, and just the signature of the currently open container otherwise. + + + sd_bus_message_is_empty() returns true if the message is empty, + i.e. when its signature is empty. + + sd_bus_message_has_signature() returns true if the signature of the + message message matches given signature. Parameter + signature may be NULL, this is treated the same as + an empty string, which is equivalent to calling sd_bus_message_is_empty(). + + + + + Return Value + + On success, sd_bus_message_get_signature() returns + the signature, and NULL on error. + + The other functions return 0 or a positive integer on success. On failure, they return a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The message parameter is NULL. + + + + + NULL + + The message parameter is NULL. + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_new3 + + + + diff --git a/man/sd_bus_message_get_type.xml b/man/sd_bus_message_get_type.xml new file mode 100644 index 0000000..dd86316 --- /dev/null +++ b/man/sd_bus_message_get_type.xml @@ -0,0 +1,167 @@ + + + + + + + + sd_bus_message_get_type + systemd + + + + sd_bus_message_get_type + 3 + + + + sd_bus_message_get_type + sd_bus_message_get_error + sd_bus_message_get_errno + sd_bus_message_get_creds + sd_bus_message_is_signal + sd_bus_message_is_method_call + sd_bus_message_is_method_error + + Query bus message addressing/credentials metadata + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_get_type + sd_bus_message *m + uint8_t *type + + + + sd_bus_error* sd_bus_message_get_error + sd_bus_message *m + + + + int sd_bus_message_get_errno + sd_bus_message *m + + + + sd_bus_creds* sd_bus_message_get_creds + sd_bus_message *m + + + + int sd_bus_message_is_signal + sd_bus_message *m + const char *interface + const char *member + + + + int sd_bus_message_is_method_call + sd_bus_message *m + const char *interface + const char *member + + + + int sd_bus_message_is_method_error + sd_bus_message *m + const char *name + + + + + + + Description + + sd_bus_message_get_type() returns the type of a message in the output + parameter type, one of SD_BUS_MESSAGE_METHOD_CALL, + SD_BUS_MESSAGE_METHOD_RETURN, SD_BUS_MESSAGE_METHOD_ERROR, + SD_BUS_MESSAGE_SIGNAL. This type is either specified as a parameter when the message + is created using + sd_bus_message_new3, + or is set automatically when the message is created using + sd_bus_message_new_signal3, + sd_bus_message_new_method_call3, + sd_bus_message_new_method_error3 + and similar functions. + + sd_bus_message_get_error() returns the error stored in the message + m, if there is any. Otherwise, it returns NULL. + sd_bus_message_get_errno() returns the error stored in the message + m as a positive errno-style value, if there is any. Otherwise, it returns zero. + Errors are mapped to errno values according to the default and any additional registered error mappings. + See sd-bus-errors3 and + sd_bus_error_add_map3. + + + sd_bus_message_get_creds() returns the message credentials attached to the + message m. If no credentials are attached to the message, it returns + NULL. Ownership of the credentials instance is not transferred to the caller and + hence should not be freed. + + sd_bus_message_is_signal() checks if message m is a + signal message. If interface is non-null, it also checks if the message has the + same interface set. If member is non-null, it also checks if the message has the + same member set. Also see + sd_bus_message_new_signal3. + It returns true when all checks pass. + + sd_bus_message_is_method_call() checks if message m + is a method call message. If interface is non-null, it also checks if the message + has the same interface set. If member is non-null, it also checks if the message + has the same member set. Also see + sd_bus_message_new_method_call3. + It returns true when all checks pass. + + sd_bus_message_is_method_error() checks if message m + is an error reply message. If name is non-null, it also checks if the message has + the same error identifier set. Also see + sd_bus_message_new_method_error3. + It returns true when all checks pass. + + + + Return Value + + On success, these functions (except sd_bus_message_get_error() and + sd_bus_message_get_creds()) return a non-negative integer. On failure, they return a + negative errno-style error code. sd_bus_message_get_errno() always returns a + non-negative integer, even on failure. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The message parameter m or an output parameter is + NULL. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_new3, + sd_bus_message_set_destination3, + sd-bus-errors3, + sd_bus_error_add_map3 + + + + diff --git a/man/sd_bus_message_new.xml b/man/sd_bus_message_new.xml new file mode 100644 index 0000000..c56df61 --- /dev/null +++ b/man/sd_bus_message_new.xml @@ -0,0 +1,188 @@ + + + + + + + sd_bus_message_new + systemd + + + + sd_bus_message_new + 3 + + + + sd_bus_message_new + sd_bus_message_ref + sd_bus_message_unref + sd_bus_message_unrefp + SD_BUS_MESSAGE_METHOD_CALL + SD_BUS_MESSAGE_METHOD_RETURN + SD_BUS_MESSAGE_METHOD_ERROR + SD_BUS_MESSAGE_SIGNAL + sd_bus_message_get_bus + + Create a new bus message object and create or destroy references to it + + + + + #include <systemd/sd-bus.h> + + enum { + SD_BUS_MESSAGE_METHOD_CALL, + SD_BUS_MESSAGE_METHOD_RETURN, + SD_BUS_MESSAGE_METHOD_ERROR, + SD_BUS_MESSAGE_SIGNAL, +}; + + + int sd_bus_message_new + sd_bus *bus + sd_bus_message **m + uint8_t type + + + + sd_bus_message *sd_bus_message_ref + sd_bus_message *m + + + + sd_bus_message *sd_bus_message_unref + sd_bus_message *m + + + + void sd_bus_message_unrefp + sd_bus_message **mp + + + + sd_bus *sd_bus_message_get_bus + sd_bus_message *m + + + + + + Description + + sd_bus_message_new() creates a new bus message object attached to the + bus bus and returns it in the output parameter m. + This object is reference-counted, and will be destroyed when all references are gone. Initially, + the caller of this function owns the sole reference to the message object. Note that the message + object holds a reference to the bus object, so the bus object will not be destroyed as long as + the message exists. + + Note: this is a low-level call. In most cases functions like + sd_bus_message_new_method_call3, + sd_bus_message_new_method_error3, + sd_bus_message_new_method_return3, + and sd_bus_message_new_signal3 + that create a message of a certain type and initialize various fields are easier to use. + + The type parameter specifies the type of the message. It must be + one of SD_BUS_MESSAGE_METHOD_CALL — a method call, + SD_BUS_MESSAGE_METHOD_RETURN — a method call reply, + SD_BUS_MESSAGE_METHOD_ERROR — an error reply to a method call, + SD_BUS_MESSAGE_SIGNAL — a broadcast message with no reply. + + + The flag to allow interactive authorization is initialized based on the current value set + in the bus object, see + sd_bus_set_allow_interactive_authorization3. + This may be changed using + sd_bus_message_set_allow_interactive_authorization3. + + + sd_bus_message_ref() increases the internal reference counter of + m by one. + + sd_bus_message_unref() decreases the internal reference counter of + m by one. Once the reference count has dropped to zero, message object is + destroyed and cannot be used anymore, so further calls to sd_bus_message_ref() or + sd_bus_message_unref() are illegal. + + sd_bus_message_unrefp() is similar to + sd_bus_message_unref() but takes a pointer to a + pointer to an sd_bus_message object. This call is useful in + conjunction with GCC's and LLVM's Clean-up + Variable Attribute. See + sd_bus_new3 + for an example how to use the cleanup attribute. + + sd_bus_message_ref() and sd_bus_message_unref() + execute no operation if the passed in bus message object address is + NULL. sd_bus_message_unrefp() will first dereference + its argument, which must not be NULL, and will execute no operation if + that is NULL. + + + sd_bus_message_get_bus() returns the bus object that message + m is attached to. + + + + Return Value + + On success, sd_bus_message_new() returns 0 or a positive integer. On + failure, it returns a negative errno-style error code. + + sd_bus_message_ref() always returns the argument. + + + sd_bus_message_unref() always returns + NULL. + + sd_bus_message_get_bus() always returns the bus object. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + Specified type is invalid. + + + + -ENOTCONN + + The bus parameter bus is NULL or + the bus is not connected. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_new3, + sd_bus_message_new_method_call3, + sd_bus_message_new_method_error3, + sd_bus_message_new_method_return3, + sd_bus_message_new_signal3 + + + + diff --git a/man/sd_bus_message_new_method_call.xml b/man/sd_bus_message_new_method_call.xml new file mode 100644 index 0000000..f6278e3 --- /dev/null +++ b/man/sd_bus_message_new_method_call.xml @@ -0,0 +1,172 @@ + + + + + + + + sd_bus_message_new_method_call + systemd + + + + sd_bus_message_new_method_call + 3 + + + + sd_bus_message_new_method_call + sd_bus_message_new_method_return + + Create a method call message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_new_method_call + sd_bus *bus + sd_bus_message **m + const char *destination + const char *path + const char *interface + const char *member + + + + int sd_bus_message_new_method_return + sd_bus_message *call + sd_bus_message **m + + + + + + Description + + The sd_bus_message_new_method_call() function creates a new bus + message object that encapsulates a D-Bus method call, and returns it in the + m output parameter. The call will be made on the destination + destination, path path, on the interface + interface, member member. + + Briefly, the destination is a dot-separated name that identifies a + service connected to the bus. The path is a slash-separated identifier of + an object within the destination that resembles a file system path. The meaning of this path is + defined by the destination. The interface is a dot-separated name that + resembles a Java interface name that identifies a group of methods and signals supported by the + object identified by path. Methods and signals are collectively called + members and are identified by a simple name composed of ASCII letters, + numbers, and underscores. See the D-Bus Tutorial for an + in-depth explanation. + + The destination parameter may be NULL. The + interface parameter may be NULL, if the destination + has only a single member with the given name and there is no ambiguity if the interface name is + omitted. + + Note that this is a low level interface. See + sd_bus_call_method3 + for a more convenient way of calling D-Bus methods. + + The sd_bus_message_new_method_return() function creates a new bus + message object that is a reply to the method call call and returns it in + the m output parameter. The call parameter must be + a method call message. The sender of call is used as the destination. + + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The output parameter m is + NULL. + + The destination parameter is non-null and is not a valid D-Bus + service name (org.somewhere.Something), the path + parameter is not a valid D-Bus path (/an/object/path), the + interface parameter is non-null and is not a valid D-Bus interface + name (an.interface.name), or the member parameter + is not a valid D-Bus member (Name). + + The call parameter is not a method call object. + + + + + -ENOTCONN + + The bus parameter bus is NULL or + the bus is not connected. + + + + -ENOMEM + + Memory allocation failed. + + + + -EPERM + + + The call parameter is not sealed. + + + + + -EOPNOTSUPP + + + The call message does not have a cookie. + + + + + + + + + + Examples + + + Make a call to a D-Bus method that takes a single parameter + + + This defines a minimally useful program that will open a connection to the bus, create a + message object, send it, wait for the reply, and finally extract and print the answer. It does + error handling and proper memory management. + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_call3, + sd_bus_call_method3, + sd_bus_path_encode3 + + + + diff --git a/man/sd_bus_message_new_method_error.xml b/man/sd_bus_message_new_method_error.xml new file mode 100644 index 0000000..92c4ac6 --- /dev/null +++ b/man/sd_bus_message_new_method_error.xml @@ -0,0 +1,187 @@ + + + + + + + + sd_bus_message_new_method_error + systemd + + + + sd_bus_message_new_method_error + 3 + + + + sd_bus_message_new_method_error + sd_bus_message_new_method_errorf + sd_bus_message_new_method_errno + sd_bus_message_new_method_errnof + + Create an error reply for a method call + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_new_method_error + sd_bus_message *call + sd_bus_message **m + const sd_bus_error *e + + + + int sd_bus_message_new_method_errorf + sd_bus_message *call + sd_bus_message **m + const char *name + const char *format + … + + + + int sd_bus_message_new_method_errno + sd_bus_message *call + sd_bus_message **m + int error + const sd_bus_error *p + + + + int sd_bus_message_new_method_errnof + sd_bus_message *call + sd_bus_message **m + int error + const char *format + … + + + + + + Description + + The sd_bus_message_new_method_error() function creates + a new bus message object that is an error reply to the + call message, and returns it in the + m output parameter. The error information from error + e is appended: the name field of + e is used as the error identifier in the reply header (for + example an error name such as + org.freedesktop.DBus.Error.NotSupported or the equivalent + symbolic SD_BUS_ERROR_NOT_SUPPORTED), and the + message field is set as the human readable error message + string if present. The error e must have the + name field set, see + sd_bus_error_is_set3. + + + The sd_bus_message_new_method_errorf() function + creates an error reply similarly to + sd_bus_message_new_method_error(), but instead of a ready + error structure, it takes an error identifier string name, + plus a printf3 + format string format and corresponding arguments. An error + reply is sent with the error identifier name and the + formatted string as the message. name and + format must not be NULL. + + + The sd_bus_message_new_method_errno() function creates + an error reply similarly to + sd_bus_message_new_method_error(), but in addition to the + error structure p, it takes an + errno3 + error value in parameter error. If the error + p is set (see + sd_bus_error_is_set3), + it is used in the reply. Otherwise, error is translated to + an error identifier and used to create a new error structure using + sd_bus_error_set_errno3 + and that is used in the reply. (If error is zero, no error + is actually set, and an error reply with no information is created.) + + The sd_bus_message_new_method_errnof() function + creates an error reply similarly to + sd_bus_message_new_method_error(). It takes an + errno3 + error value in parameter error, plus a printf3 + format string format and corresponding arguments. + %m may be used in the format string to refer to the error + string corresponding to the specified errno code. The error message is initialized + using the error identifier generated from error and the + formatted string. (If error is zero, no error is actually + set, and an error reply with no information is created.) + + + + Return Value + + These functions return 0 if the error reply was successfully created, and a + negative errno-style error code otherwise. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The call message call or the output + parameter m are NULL. + + Message call is not a method call + message. + + The error e parameter to + sd_bus_message_new_method_error() is not set, see + sd_bus_error_is_set3. + + + + + + -EPERM + + Message call has been sealed. + + + + + -ENOTCONN + + The bus to which message call is + attached is not connected. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3 + + + + diff --git a/man/sd_bus_message_new_signal.xml b/man/sd_bus_message_new_signal.xml new file mode 100644 index 0000000..17862de --- /dev/null +++ b/man/sd_bus_message_new_signal.xml @@ -0,0 +1,121 @@ + + + + + + + + sd_bus_message_new_signal + systemd + + + + sd_bus_message_new_signal + 3 + + + + sd_bus_message_new_signal + + Create a signal message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_new_signal + sd_bus *bus + sd_bus_message **m + const char *path + const char *interface + const char *member + + + + + + Description + + The sd_bus_message_new_signal() function creates a new bus message + object that encapsulates a D-Bus signal, and returns it in the m output + parameter. The signal will be sent to path path, on the interface + interface, member member. When this message is + sent, no reply is expected. See + sd_bus_message_new_method_call1 + for a short description of the meaning of the path, + interface, and member parameters. + + + + + Return Value + + This function returns 0 if the message object was successfully created, and a negative + errno-style error code otherwise. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The output parameter m is + NULL. + + The path parameter is not a valid D-Bus path + (/an/object/path), the interface parameter is not + a valid D-Bus interface name (an.interface.name), or the + member parameter is not a valid D-Bus member + (Name). + + + + -ENOTCONN + + The bus parameter bus is NULL or + the bus is not connected. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + Examples + + + Send a simple signal + + + + This function in systemd sources is used to emit the + UnitFilesChanged signal when the unit files have been changed. + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_emit_signal3 + + + + diff --git a/man/sd_bus_message_open_container.xml b/man/sd_bus_message_open_container.xml new file mode 100644 index 0000000..89c75f0 --- /dev/null +++ b/man/sd_bus_message_open_container.xml @@ -0,0 +1,183 @@ + + + + + + + + sd_bus_message_open_container + systemd + + + + sd_bus_message_open_container + 3 + + + + sd_bus_message_open_container + sd_bus_message_close_container + sd_bus_message_enter_container + sd_bus_message_exit_container + + Create and move between containers in D-Bus messages + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_open_container + sd_bus_message *m + char type + const char *contents + + + + int sd_bus_message_close_container + sd_bus_message *m + + + + int sd_bus_message_enter_container + sd_bus_message *m + char type + const char *contents + + + + int sd_bus_message_exit_container + sd_bus_message *m + + + + + + Description + + sd_bus_message_open_container() appends a new container to the message + m. After opening a new container, it can be filled with content using + sd_bus_message_append3 + and similar functions. Containers behave like a stack. To nest containers inside each other, call + sd_bus_message_open_container() multiple times without calling + sd_bus_message_close_container() in between. Each container will be nested inside the + previous container. type represents the container type and should be one of + r, a, v or e as described in + sd_bus_message_append3. + Instead of literals, the corresponding constants SD_BUS_TYPE_STRUCT, + SD_BUS_TYPE_ARRAY, SD_BUS_TYPE_VARIANT or + SD_BUS_TYPE_DICT_ENTRY can also be used. contents describes + the type of the container's elements and should be a D-Bus type string following the rules described in + sd_bus_message_append3. + + + sd_bus_message_close_container() closes the last container opened with + sd_bus_message_open_container(). On success, the write pointer of the message + m is positioned after the closed container in its parent container or in + m itself if there is no parent container. + + sd_bus_message_enter_container() enters the next container of the message + m for reading. It behaves mostly the same as + sd_bus_message_open_container(). Entering a container allows reading its contents + with + sd_bus_message_read3 + and similar functions. type and contents are the same as in + sd_bus_message_open_container(). + + sd_bus_message_exit_container() exits the scope of the last container entered + with sd_bus_message_enter_container(). It behaves mostly the same as + sd_bus_message_close_container(). Note that + sd_bus_message_exit_container() may only be called after iterating through all + members of the container, i.e. reading or skipping them. Use + sd_bus_message_skip3 + to skip over felds of a container in order to be able to exit the container with + sd_bus_message_exit_container() without reading all members. + + + + Return Value + + On success, these functions return a non-negative integer. + sd_bus_message_open_container() and sd_bus_message_close_container() + return 0. + sd_bus_message_enter_container() returns 1 if it successfully opened a new container, and 0 if + that was not possible because the end of the currently open container or message was reached. + sd_bus_message_exit_container() returns 1 on success. + On failure, all of these functions return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + m or contents are + NULL or type is invalid. + + + + -EPERM + + The message m is already sealed. + + + + -ESTALE + + The message m is in an invalid state. + + + + -ENOMEM + + Memory allocation failed. + + + + -EBUSY + + sd_bus_message_exit_container() was called but there are + unread members left in the container. + + + + + + + + + Examples + + + Append an array of strings to a message + + + + + + Read an array of strings from a message + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_append3, + sd_bus_message_read3, + sd_bus_message_skip3, + The D-Bus specification + + + + diff --git a/man/sd_bus_message_read.xml b/man/sd_bus_message_read.xml new file mode 100644 index 0000000..aa325f3 --- /dev/null +++ b/man/sd_bus_message_read.xml @@ -0,0 +1,275 @@ + + + + + + + + sd_bus_message_read + systemd + + + + sd_bus_message_read + 3 + + + + sd_bus_message_read + sd_bus_message_readv + sd_bus_message_peek_type + + Read a sequence of values from a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_read + sd_bus_message *m + const char *types + ... + + + + int sd_bus_message_readv + sd_bus_message *m + const char *types + va_list ap + + + + int sd_bus_message_peek_type + sd_bus_message *m + char *type + const char **contents + + + + + + Description + + sd_bus_message_read() reads a sequence of fields from the D-Bus message object + m and advances the read position in the message. The type string + types describes the types of items expected in the message and the field arguments + that follow. The type string may be NULL or empty, in which case nothing is read. + + + The type string is composed of the elements described in + sd_bus_message_append3, + i.e. basic and container types. It must contain zero or more single "complete types". The type string is + NUL-terminated. + + For each type specified in the type string, one or more arguments need to be specified after the + types parameter, in the same order. The arguments must be pointers to appropriate + types (a pointer to int8_t for a y in the type string, a pointer to + int32_t for an i, a pointer to const char* for an + s, ...) which are set based on the values in the message. As an exception, in case of + array and variant types, the first argument is an "input" argument that further specifies how the message + should be read. See the table below for a complete list of allowed arguments and their types. Note that, + if the basic type is a pointer (e.g., const char * in the case of a string), the argument is + a pointer to a pointer, and also the pointer value that is written is only borrowed and the contents must + be copied if they are to be used after the end of the message's lifetime. If the type is + h (UNIX file descriptor), the descriptor is not duplicated by this call and the + returned descriptor remains in possession of the message object, and needs to be duplicated by the caller + in order to keep an open reference to it after the message object is freed. + + Each argument may also be NULL, in which case the value is read and ignored. + + + + Item type specifiers + + + + + + + + + + Specifier + Constant + Description + Type of the first argument + Types of the subsequent arguments, if any + + + + + + + + a + SD_BUS_TYPE_ARRAY + array + int, which specifies the expected length n of the array + n sets of arguments appropriate for the array element type + + + + v + SD_BUS_TYPE_VARIANT + variant + signature string + arguments appropriate for the types specified by the signature + + + + ( + SD_BUS_TYPE_STRUCT_BEGIN + array start + arguments appropriate for the structure elements + + + ) + SD_BUS_TYPE_STRUCT_END + array end + + + + { + SD_BUS_TYPE_DICT_ENTRY_BEGIN + dictionary entry start + arguments appropriate for the first type in the pair + arguments appropriate for the second type in the pair + + + } + SD_BUS_TYPE_DICT_ENTRY_END + dictionary entry end + + + +
+ + If objects of the specified types are not present at the current position in the message, an error + is returned. + + The sd_bus_message_readv() is equivalent to the + sd_bus_message_read(), except that it is called with a va_list + instead of a variable number of arguments. This function does not call the va_end() + macro. Because it invokes the va_arg() macro, the value of ap + is undefined after the call. + + sd_bus_message_peek_type() determines the type of the next element in + m to be read by sd_bus_message_read() or similar functions. + On success, the type is stored in type, if it is not NULL. + If the type is a container type, the type of its elements is stored in contents, + if it is not NULL. If this function successfully determines the type of the next + element in m, it returns a positive integer. If there are no more elements to be + read, it returns zero. + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + + + -EBUSY + + When reading from a container, this error will be returned if unread elements + are left in the container. + + + + + + + + + Examples + + Read a single basic type (a 64-bit integer): + + + sd_bus_message *m; +int64_t x; + +sd_bus_message_read(m, "x", &x); + + Read a boolean value: + + sd_bus_message *m; +int x; /* Do not use C99 'bool' type here, it's typically smaller + in memory and would cause memory corruption */ + +sd_bus_message_read(m, "b", &x); + + Read all types of integers: + + uint8_t y; +int16_t n; +uint16_t q; +int32_t i; +uint32_t u; +int32_t x; +uint32_t t; +double d; + +sd_bus_message_read(m, "ynqiuxtd", &y, &n, &q, &i, &u, &x, &t, &d); + + Read a structure composed of a string and a D-Bus path: + + const char *s, *p; + +sd_bus_message_read(m, "(so)", &s, &p); + + + Read a variant, with the real type "gt" (signature, unsigned integer): + + + const char *s; +uint64_t *v; + +sd_bus_message_read(m, "v", "gt", &s, &v); + + Read a dictionary containing three pairs of type {integer=>string}: + + + int i, j, k; +const char *s, *t, *u; + +sd_bus_message_read(m, "a{is}", 3, &i, &s, &j, &t, &k, &u); + + + Read a single file descriptor, and duplicate it in order to keep it open after the message is + freed. + + sd_bus_message *m; +int fd, fd_copy; + +sd_bus_message_read(m, "h", &fd); +fd_copy = fcntl(fd, FD_DUPFD_CLOEXEC, 3); + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_read_basic3, + sd_bus_message_skip3, + sd_bus_message_append3, + sd_bus_message_enter_container3 + + + + diff --git a/man/sd_bus_message_read_array.xml b/man/sd_bus_message_read_array.xml new file mode 100644 index 0000000..daff909 --- /dev/null +++ b/man/sd_bus_message_read_array.xml @@ -0,0 +1,116 @@ + + + + + + + + sd_bus_message_read_array + systemd + + + + sd_bus_message_read_array + 3 + + + + sd_bus_message_read_array + + Access an array of elements in a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_read_array + sd_bus_message *m + char type + const void **ptr + size_t *size + + + + + + Description + + sd_bus_message_read_array() provides access to an array elements in the + bus message m. The "read pointer" in the message must be right before an array of type + type. As a special case, type may be + NUL, in which case any trivial type is acceptable. A pointer to the array data is returned + in the parameter ptr and the size of array data (in bytes) is returned in the + parameter size. If the returned size parameter is 0, a + valid non-null pointer will be returned as ptr, but it may not be + dereferenced. The data is aligned as appropriate for the data type. The data is part of the message — it + may not be modified and is valid only as long as the message is referenced. After this function returns, + the "read pointer" points at the next element after the array. + + Note that this function only supports arrays of trivial types, i.e. arrays of booleans, the various + integer types, as well as floating point numbers. In particular it may not be used for arrays of strings, + structures or similar. + + + + Return Value + + + On success and when an array was read, sd_bus_message_read_array() returns an + integer greater than zero. If invoked while inside a container element (such as an array, e.g. when + operating on an array of arrays) and the final element of the outer container has been read already and + the read pointer is thus behind the last element of the outer container this call returns 0 (and the + returned pointer will be NULL and the size will be 0). On failure, it returns a + negative errno-style error code. + + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + Specified type is invalid or not a trivial type (see above), or the message + parameter or one of the output parameters are NULL. + + + + -EOPNOTSUPP + + The byte order in the message is different than native byte + order. + + + + -EPERM + + The message is not sealed. + + + + -EBADMSG + + The message cannot be parsed. + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_read3, + sd_bus_message_read_strv3 + + + + diff --git a/man/sd_bus_message_read_basic.xml b/man/sd_bus_message_read_basic.xml new file mode 100644 index 0000000..5595143 --- /dev/null +++ b/man/sd_bus_message_read_basic.xml @@ -0,0 +1,237 @@ + + + + + + + + + sd_bus_message_read_basic + systemd + + + + sd_bus_message_read_basic + 3 + + + + sd_bus_message_read_basic + + Read a basic type from a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_read_basic + sd_bus_message *m + char type + void *p + + + + + + Description + + + sd_bus_message_read_basic() reads a basic type from a + message and advances the read position in the message. The set of basic + types and their ascii codes passed in type are + described in the D-Bus + Specification. + + + + If p is not NULL, it should contain a pointer to an + appropriate object. For example, if type is 'y', the object + passed in p should have type uint8_t *. If + type is 's', the object passed in p + should have type const char **. Note that, if the basic type is a pointer (e.g., + const char * in the case of a string), the pointer is only borrowed and the contents must + be copied if they are to be used after the end of the message's lifetime. Similarly, during the + lifetime of such a pointer, the message must not be modified. If type is + 'h' (UNIX file descriptor), the descriptor is not duplicated by this call and the + returned descriptor remains in possession of the message object, and needs to be duplicated by the + caller in order to keep an open reference to it after the message object is freed (for example by + calling fcntl(fd, FD_DUPFD_CLOEXEC, 3)). See the table below for a complete list of + allowed types. + + + + Item type specifiers + + + + + + + + + Specifier + Constant + Description + Expected C Type + + + + + y + SD_BUS_TYPE_BYTE + 8bit unsigned integer + uint8_t * + + + + b + SD_BUS_TYPE_BOOLEAN + boolean + int * (NB: not bool *) + + + + n + SD_BUS_TYPE_INT16 + 16bit signed integer + int16_t * + + + + q + SD_BUS_TYPE_UINT16 + 16bit unsigned integer + uint16_t * + + + + i + SD_BUS_TYPE_INT32 + 32bit signed integer + int32_t * + + + + u + SD_BUS_TYPE_UINT32 + 32bit unsigned integer + uint32_t * + + + + x + SD_BUS_TYPE_INT64 + 64bit signed integer + int64_t * + + + + t + SD_BUS_TYPE_UINT64 + 64bit unsigned integer + uint64_t * + + + + d + SD_BUS_TYPE_DOUBLE + IEEE 754 double precision floating-point + double * + + + + s + SD_BUS_TYPE_STRING + UTF-8 string + const char ** + + + + o + SD_BUS_TYPE_OBJECT_PATH + D-Bus object path string + const char ** + + + + g + SD_BUS_TYPE_SIGNATURE + D-Bus signature string + const char ** + + + + h + SD_BUS_TYPE_UNIX_FD + UNIX file descriptor + int * + + + +
+ + + If there is no object of the specified type at the current position in the + message, an error is returned. + + + + + Return Value + + + On success, sd_bus_message_read_basic() returns a positive integer. + If the end of the currently opened array has been reached, it returns 0. + On failure, it returns a negative errno-style error code. + + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + Specified type string is invalid or the message parameter is + NULL. + + + + -ENXIO + + The message does not contain the specified type at current position. + + + + + -EBADMSG + + The message cannot be parsed. + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_append_basic3, + sd_bus_message_skip3, + sd_bus_message_read3 + + + + diff --git a/man/sd_bus_message_read_strv.xml b/man/sd_bus_message_read_strv.xml new file mode 100644 index 0000000..6f46c18 --- /dev/null +++ b/man/sd_bus_message_read_strv.xml @@ -0,0 +1,113 @@ + + + + + + + + sd_bus_message_read_strv + systemd + + + + sd_bus_message_read_strv + 3 + + + + sd_bus_message_read_strv + sd_bus_message_read_strv_extend + + Access an array of strings in a message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_read_strv + sd_bus_message *m + char ***l + + + + int sd_bus_message_read_strv_extend + sd_bus_message *m + char ***l + + + + + + Description + + sd_bus_message_read_strv() reads an array of string-like items from the + message m. The "read pointer" in the message must be right before an array of + strings (D-Bus type as), object paths (D-Bus type ao), or + signatures (D-Bus type ag). On success, a pointer to a + NULL-terminated array of strings (strv) is returned in the output parameter + l. Note that ownership of this array is transferred to the caller. Hence, the + caller is responsible for freeing this array and its contents. + + sd_bus_message_read_strv_extend() is similar, but the second parameter is an + input-output parameter. If *l is NULL, if behaves identically + to sd_bus_message_read_strv(). Otherwise, *l must point to a + strv, which will be reallocated and extended with additional strings. This function is particularly + useful when combining multiple lists of strings in a message or messages into a single array of strings. + + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + m or l are NULL. + + + + + -EPERM + + The message is not sealed. + + + + -EBADMSG + + The message cannot be parsed. + + + + -ENXIO + + The message "read pointer" is not right before an array of the appropriate type. + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_read3 + + + + diff --git a/man/sd_bus_message_rewind.xml b/man/sd_bus_message_rewind.xml new file mode 100644 index 0000000..5640d28 --- /dev/null +++ b/man/sd_bus_message_rewind.xml @@ -0,0 +1,88 @@ + + + + + + + + sd_bus_message_rewind + systemd + + + + sd_bus_message_rewind + 3 + + + + sd_bus_message_rewind + + Return to beginning of message or current container + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_rewind + sd_bus_message *m + int complete + + + + + + Description + + sd_bus_message_rewind() moves the "read pointer" in the message + m to either the beginning of the message (if + complete is true) or to the beginning of the currently open container. If + no container is open, complete has no effect. + + + + Return Value + + + On success, this function returns 0 or a positive integer. The value is zero if the current + container or whole message in case no container is open is empty, and positive otherwise. On + failure, it returns a negative errno-style error code. + + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The m parameter is NULL. + + + + -EPERM + + The message m has not been sealed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_read3 + + + + diff --git a/man/sd_bus_message_seal.xml b/man/sd_bus_message_seal.xml new file mode 100644 index 0000000..53d3a21 --- /dev/null +++ b/man/sd_bus_message_seal.xml @@ -0,0 +1,106 @@ + + + + + + + + sd_bus_message_seal + systemd + + + + sd_bus_message_seal + 3 + + + + sd_bus_message_seal + + Prepare a D-Bus message for transmission + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_seal + sd_bus_message *m + uint64_t cookie + uint64_t timeout_usec + + + + + + Description + + sd_bus_message_seal() finishes the message m + and prepares it for transmission using + sd_bus_send3. + cookie specifies the identifier used to match the message reply to its + corresponding request. timeout_usec specifies the maximum time in + microseconds to wait for a reply to arrive. + + Note that in most scenarios, it's not necessary to call this function directly. + sd_bus_call3, + sd_bus_call_async3 and + sd_bus_send3 + will seal any given messages if they have not been sealed yet. + + + + Return Value + + On success, this function returns a non-negative integer. On failure, it returns a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The m parameter is NULL. + + + + + -EBADMSG + + The D-Bus message m has open containers. + + + + + -ENOMSG + + The D-Bus message m is a reply but its type + signature does not match the return type signature of its corresponding member in the + object vtable. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_call3, + sd_bus_call_async3, + sd_bus_send3 + + + + diff --git a/man/sd_bus_message_sensitive.xml b/man/sd_bus_message_sensitive.xml new file mode 100644 index 0000000..f953965 --- /dev/null +++ b/man/sd_bus_message_sensitive.xml @@ -0,0 +1,85 @@ + + + + + + + + sd_bus_message_sensitive + systemd + + + + sd_bus_message_sensitive + 3 + + + + sd_bus_message_sensitive + + Mark a message object as containing sensitive data + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_sensitive + sd_bus_message *message + + + + + + Description + + sd_bus_message_sensitive() marks an allocated bus message as containing + sensitive data. This ensures that the message data is carefully removed from memory (specifically, + overwritten with zero bytes) when released. It is recommended to mark all incoming and outgoing messages + like this that contain security credentials and similar data that should be dealt with carefully. Note + that it is not possible to unmark messages like this, it's a one way operation. If a message is already + marked sensitive and then marked sensitive a second time the message remains marked so and no further + operation is executed. + + As a safety precaution all messages that are created as reply to messages that are marked sensitive + are also implicitly marked so. + + + + Return Value + + On success, this functions return 0 or a positive integer. On failure, it returns a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The message parameter is + NULL. + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_new_method_call3 + + + + diff --git a/man/sd_bus_message_set_destination.xml b/man/sd_bus_message_set_destination.xml new file mode 100644 index 0000000..6308b5e --- /dev/null +++ b/man/sd_bus_message_set_destination.xml @@ -0,0 +1,151 @@ + + + + + + sd_bus_message_set_destination + systemd + + + + sd_bus_message_set_destination + 3 + + + + sd_bus_message_set_destination + sd_bus_message_get_destination + sd_bus_message_get_path + sd_bus_message_get_interface + sd_bus_message_get_member + sd_bus_message_set_sender + sd_bus_message_get_sender + + Set and query bus message addressing information + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_set_destination + sd_bus_message *message + const char *destination + + + + const char* sd_bus_message_get_destination + sd_bus_message *message + + + + const char* sd_bus_message_get_path + sd_bus_message *message + + + + const char* sd_bus_message_get_interface + sd_bus_message *message + + + + const char* sd_bus_message_get_member + sd_bus_message *message + + + + int sd_bus_message_set_sender + sd_bus_message *message + const char *sender + + + + const char* sd_bus_message_get_sender + sd_bus_message *message + + + + + + Description + + sd_bus_message_set_destination() sets the destination service name + for the specified bus message object. The specified name must be a valid unique or well-known + service name. + + sd_bus_message_get_destination(), + sd_bus_message_get_path(), + sd_bus_message_get_interface(), and + sd_bus_message_get_member() return the destination, path, interface, and + member fields from message header. The return value will be + NULL is message is NULL or the + message is of a type that doesn't use those fields or the message doesn't have them set. See + sd_bus_message_new_method_call3 and + sd_bus_message_set_destination3 + for more discussion of those values. + + sd_bus_message_set_sender() sets the sender service name for the specified bus message + object. The specified name must be a valid unique or well-known service name. This function is useful only for + messages to send on direct connections as for connections to bus brokers the broker will fill in the destination + field anyway, and the sender field set by original sender is ignored. + + sd_bus_message_get_sender() returns the sender field from + message. + + When a string is returned, it is a pointer to internal storage, and may not be modified or + freed. It is only valid as long as the message remains referenced and + this field hasn't been changed by a different call. + + + + Return Value + + On success, these calls return 0 or a positive integer. On failure, these calls return a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The message parameter or the output parameter are + NULL. + + + + -EPERM + + For sd_bus_message_set_destination() and + sd_bus_message_set_sender(), the message is already sealed. + + + + + -EEXIST + + The message already has a destination or sender field set. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_new3, + sd_bus_set_sender3 + + + + diff --git a/man/sd_bus_message_set_expect_reply.xml b/man/sd_bus_message_set_expect_reply.xml new file mode 100644 index 0000000..dccb99a --- /dev/null +++ b/man/sd_bus_message_set_expect_reply.xml @@ -0,0 +1,147 @@ + + + + + + + + sd_bus_message_set_expect_reply + systemd + + + + sd_bus_message_set_expect_reply + 3 + + + + sd_bus_message_set_expect_reply + sd_bus_message_get_expect_reply + sd_bus_message_set_auto_start + sd_bus_message_get_auto_start + sd_bus_message_set_allow_interactive_authorization + sd_bus_message_get_allow_interactive_authorization + + Set and query bus message metadata + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_set_expect_reply + sd_bus_message *message + int b + + + + int sd_bus_message_get_expect_reply + sd_bus_message *message + + + + int sd_bus_message_set_auto_start + sd_bus_message *message + int b + + + + int sd_bus_message_get_auto_start + sd_bus_message *message + + + + int sd_bus_message_set_allow_interactive_authorization + sd_bus_message *message + int b + + + + int sd_bus_message_get_allow_interactive_authorization + sd_bus_message *message + + + + + + Description + + sd_bus_message_set_expect_reply() sets or clears the + NO_REPLY_EXPECTED flag on the message m. This flag matters + only for method call messages and is used to specify that no method return or error reply is expected. + It is ignored for other types. Thus, for a method call message, calling + sd_bus_message_set_expect_reply(…, 0) sets the flag and suppresses the + reply. + + sd_bus_message_get_expect_reply() checks if the + NO_REPLY_EXPECTED flag is set on the message m. It will + return positive if it is not set, and zero if it is. + + sd_bus_message_set_auto_start() sets or clears the + NO_AUTO_START flag on the message m. When the flag is set, + the bus must not launch an owner for the destination name in response to this message. Calling + sd_bus_message_set_auto_start(…, 0) sets the flag. + + sd_bus_message_get_auto_start() checks if the + NO_AUTO_START flag is set on the message m. It will return + positive if it is not set, and zero if it is. + + sd_bus_message_set_allow_interactive_authorization() sets or clears the + ALLOW_INTERACTIVE_AUTHORIZATION flag on the message m. + Setting this flag informs the receiver that the caller is prepared to wait for interactive authorization + via polkit or a similar framework. Note that setting this flag does not guarantee that the receiver will + actually perform interactive authorization. Also, make sure to set a suitable message timeout when using + this flag since interactive authorization could potentially take a long time as it depends on user input. + If b is non-zero, the flag is set. + + sd_bus_message_get_allow_interactive_authorization() checks if the + ALLOW_INTERACTIVE_AUTHORIZATION flag is set on the message m. + It will return a positive integer if the flag is set. Otherwise, it returns zero. + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The message parameter is NULL. + + + + + -EPERM + + + The message message is sealed when trying to set a flag. + + The message message has wrong type. + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_set_description3 + + + diff --git a/man/sd_bus_message_skip.xml b/man/sd_bus_message_skip.xml new file mode 100644 index 0000000..7a227c4 --- /dev/null +++ b/man/sd_bus_message_skip.xml @@ -0,0 +1,108 @@ + + + + + + + sd_bus_message_skip + systemd + + + + sd_bus_message_skip + 3 + + + + sd_bus_message_skip + + Skip elements in a bus message + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_skip + sd_bus_message *m + const char* types + + + + + + Description + + sd_bus_message_skip() is somewhat similar to + sd_bus_message_read3, + but instead of reading the contents of the message, it only moves the "read pointer". Subsequent + read operations will read the elements that are after the elements that were skipped. + + The types argument has the same meaning as in + sd_bus_message_read(). It may also be NULL, to skip a + single element of any type. + + + + Return Value + + On success, sd_bus_message_skip() returns 0 or a positive integer. On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The m parameter is + NULL. + + + + -EBADMSG + + The message cannot be parsed. + + + + -EPERM + + The message is not sealed. + + + + -ENXIO + + The message end has been reached and the requested elements cannot be read. + + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_read3, + sd_bus_message_read_basic3 + + + + diff --git a/man/sd_bus_message_verify_type.xml b/man/sd_bus_message_verify_type.xml new file mode 100644 index 0000000..9f3a347 --- /dev/null +++ b/man/sd_bus_message_verify_type.xml @@ -0,0 +1,99 @@ + + + + + + + sd_bus_message_verify_type + systemd + + + + sd_bus_message_verify_type + 3 + + + + sd_bus_message_verify_type + + Check if the message has specified type at the current location + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_message_verify_type + sd_bus_message *m + char type + const char* contents + + + + + + Description + + sd_bus_message_verify_type() checks if the complete type at the + current location in the message m matches the specified + type and contents. If non-zero, parameter + type must be one of the types specified in + sd_bus_message_append1. + If non-null, parameter contents must be a valid sequence of complete + types. If both type and contents are specified + type must be a container type. + + If type is specified, the type in the message must match. If + contents is specified, the type in the message must be a container type + with this signature. + + + + Return Value + + On success, this call returns true if the type matches and zero if not (the message + m contains different data or the end of the message has been reached). On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -EINVAL + + m or both type and + contents are NULL. + + Arguments do not satisfy other constraints listed above. + + + + + -EPERM + + Message m is not sealed. + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_append3 + + + + diff --git a/man/sd_bus_negotiate_fds.xml b/man/sd_bus_negotiate_fds.xml new file mode 100644 index 0000000..a4893b6 --- /dev/null +++ b/man/sd_bus_negotiate_fds.xml @@ -0,0 +1,163 @@ + + + + + + + + sd_bus_negotiate_fds + systemd + + + + sd_bus_negotiate_fds + 3 + + + + sd_bus_negotiate_fds + sd_bus_negotiate_timestamp + sd_bus_negotiate_creds + sd_bus_get_creds_mask + + Control feature negotiation on bus connections + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_negotiate_fds + sd_bus *bus + int b + + + + int sd_bus_negotiate_timestamp + sd_bus *bus + int b + + + + int sd_bus_negotiate_creds + sd_bus *bus + int b + uint64_t mask + + + + int sd_bus_get_creds_mask + sd_bus *bus + uint64_t *mask + + + + + + Description + + sd_bus_negotiate_fds() controls whether file descriptor passing shall be + negotiated for the specified bus connection. It takes a bus object and a boolean, which, when true, + enables file descriptor passing, and, when false, disables it. Note that not all transports and servers + support file descriptor passing. In particular, networked transports generally do not support file + descriptor passing. To find out whether file descriptor passing is available after negotiation, use + sd_bus_can_send3 + and pass SD_BUS_TYPE_UNIX_FD. Note that file descriptor passing is always enabled + for both sending and receiving or for neither, but never only in one direction. By default, file + descriptor passing is negotiated for all connections. + + sd_bus_negotiate_timestamp() controls whether implicit sender timestamps shall + be attached automatically to all incoming messages. Takes a bus object and a boolean, which, when true, + enables timestamping, and, when false, disables it. Use + sd_bus_message_get_monotonic_usec3, + sd_bus_message_get_realtime_usec3, + sd_bus_message_get_seqnum3 + to query the timestamps of incoming messages. If negotiation is disabled or not supported, these calls + will fail with -ENODATA. Note that currently no transports support timestamping of + messages. By default, message timestamping is not negotiated for connections. + + sd_bus_negotiate_creds() controls whether and which implicit sender + credentials shall be attached automatically to all incoming messages. Takes a bus object and a boolean + indicating whether to enable or disable the credential parts encoded in the bit mask value argument. Note + that not all transports support attaching sender credentials to messages, or do not support all types of + sender credential parameters, or might suppress them under certain circumstances for individual messages. + Specifically, dbus1 only supports SD_BUS_CREDS_UNIQUE_NAME. The sender credentials + are suitable for authorization decisions. By default, only + SD_BUS_CREDS_WELL_KNOWN_NAMES and SD_BUS_CREDS_UNIQUE_NAME are + enabled. In fact, these two credential fields are always sent along and cannot be turned off. + + sd_bus_get_creds_mask() returns the set of sender credentials that was + negotiated to be attached to all incoming messages in mask. This value is an + upper boundary only. Hence, always make sure to explicitly check which credentials are attached to a + specific message before using it. + + The sd_bus_negotiate_fds() function may be called only before the connection + has been started with + sd_bus_start3. Both + sd_bus_negotiate_timestamp() and sd_bus_negotiate_creds() may + also be called after a connection has been set up. Note that, when operating on a connection that is + shared between multiple components of the same program (for example via + sd_bus_default3), it + is highly recommended to only enable additional per message metadata fields, but never disable them + again, in order not to disable functionality needed by other components. + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EPERM + + The bus connection has already been started. + + + + -EINVAL + + An argument is invalid. + + + + -ENOPKG + + The bus cannot be resolved. + + + + -ECHILD + + The bus was created in a different process. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_start3, + sd_bus_can_send3, + sd_bus_message_get_monotonic_usec3, + sd_bus_message_get_realtime_usec3, + sd_bus_message_get_seqnum3, + sd_bus_message_get_creds3 + + + + diff --git a/man/sd_bus_new.xml b/man/sd_bus_new.xml new file mode 100644 index 0000000..b451061 --- /dev/null +++ b/man/sd_bus_new.xml @@ -0,0 +1,199 @@ + + + + + + + + sd_bus_new + systemd + + + + sd_bus_new + 3 + + + + sd_bus_new + sd_bus_ref + sd_bus_unref + sd_bus_unrefp + sd_bus_close_unref + sd_bus_close_unrefp + sd_bus_flush_close_unref + sd_bus_flush_close_unrefp + + Create a new bus object and create or destroy references to it + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_new + sd_bus **bus + + + + sd_bus *sd_bus_ref + sd_bus *bus + + + + sd_bus *sd_bus_unref + sd_bus *bus + + + + sd_bus *sd_bus_close_unref + sd_bus *bus + + + + sd_bus *sd_bus_flush_close_unref + sd_bus *bus + + + + void sd_bus_unrefp + sd_bus **busp + + + + void sd_bus_close_unrefp + sd_bus **busp + + + + void sd_bus_flush_close_unrefp + sd_bus **busp + + + + + + Description + + sd_bus_new() creates a new bus + object. This object is reference-counted, and will be destroyed + when all references are gone. Initially, the caller of this + function owns the sole reference and the bus object will not be + connected to any bus. To connect it to a bus, make sure + to set an address with + sd_bus_set_address3 + or a related call, and then start the connection with + sd_bus_start3. + + In most cases, it is better to use + sd_bus_default_user3, + sd_bus_default_system3 + or related calls instead of the more low-level sd_bus_new() and + sd_bus_start(). The higher-level functions not only allocate a bus object but also + start the connection to a well-known bus in a single function call. + + sd_bus_ref() increases the reference + counter of bus by one. + + sd_bus_unref() decreases the reference + counter of bus by one. Once the reference + count has dropped to zero, bus is destroyed + and cannot be used anymore, so further calls to + sd_bus_ref() or + sd_bus_unref() are illegal. + + sd_bus_unrefp() is similar to + sd_bus_unref() but takes a pointer to a + pointer to an sd_bus object. This call is useful in + conjunction with GCC's and LLVM's Clean-up + Variable Attribute. Note that this function is defined as an + inline function. Use a declaration like the following, in order to + allocate a bus object that is freed automatically as the code + block is left: + + { + __attribute__((cleanup(sd_bus_unrefp))) sd_bus *bus = NULL; + int r; + … + r = sd_bus_default(&bus); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to allocate bus: %m\n"); + } + … +} + + sd_bus_ref() and sd_bus_unref() execute no operation if + the argument is NULL. sd_bus_unrefp() will first dereference + its argument, which must not be NULL, and will execute no operation if + that is NULL. + + sd_bus_close_unref() is similar to sd_bus_unref(), but + first executes + sd_bus_close3, + ensuring that the connection is terminated before the reference to the connection is dropped and possibly + the object freed. + + sd_bus_flush_close_unref() is similar to sd_bus_unref(), + but first executes + sd_bus_flush3 as well + as sd_bus_close3, + ensuring that any pending messages are synchronously flushed out before the reference to the connection + is dropped and possibly the object freed. This call is particularly useful immediately before exiting + from a program as it ensures that any pending outgoing messages are written out, and unprocessed but + queued incoming messages released before the connection is terminated and released. + + sd_bus_close_unrefp() is similar to + sd_bus_close_unref(), but may be used in GCC's and LLVM's Clean-up Variable + Attribute, see above. Similarly, sd_bus_flush_close_unrefp() is similar to + sd_bus_flush_close_unref(). + + + + Return Value + + On success, sd_bus_new() returns 0 or a + positive integer. On failure, it returns a negative errno-style + error code. + + sd_bus_ref() always returns the argument. + + + sd_bus_unref() and sd_bus_flush_close_unref() always return + NULL. + + + Errors + + Returned errors may indicate the following problems: + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_default_user3, + sd_bus_default_system3, + sd_bus_open_user3, + sd_bus_open_system3, + sd_bus_close3 + + + + diff --git a/man/sd_bus_path_encode.xml b/man/sd_bus_path_encode.xml new file mode 100644 index 0000000..5cdb1d7 --- /dev/null +++ b/man/sd_bus_path_encode.xml @@ -0,0 +1,153 @@ + + + + + + + + sd_bus_path_encode + systemd + + + + sd_bus_path_encode + 3 + + + + sd_bus_path_encode + sd_bus_path_encode_many + sd_bus_path_decode + sd_bus_path_decode_many + + Convert an external identifier into an object path and back + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_path_encode + const char *prefix + const char *external_id + char **ret_path + + + + int sd_bus_path_encode_many + char **out + const char *path_template + … + + + + int sd_bus_path_decode + const char *path + const char *prefix + char **ret_external_id + + + + int sd_bus_path_decode_many + const char *path + const char *path_template + … + + + + + + Description + + sd_bus_path_encode() and + sd_bus_path_decode() convert external + identifier strings into object paths and back. These functions are + useful to map application-specific string identifiers of any kind + into bus object paths in a simple, reversible and safe way. + + sd_bus_path_encode() takes a bus path + prefix and an external identifier string as arguments, plus a + place to store the returned bus path string. The bus path prefix + must be a valid bus path, starting with a slash + /, and not ending in one. The external + identifier string may be in any format, may be the empty string, + and has no restrictions on the charset — however, it must + always be NUL-terminated. The returned string + will be the concatenation of the bus path prefix plus an escaped + version of the external identifier string. This operation may be + reversed with sd_bus_path_decode(). It is + recommended to only use external identifiers that generally + require little escaping to be turned into valid bus path + identifiers (for example, by sticking to a 7-bit ASCII character + set), in order to ensure the resulting bus path is still short and + easily processed. + + sd_bus_path_decode() reverses the + operation of sd_bus_path_encode() and thus + regenerates an external identifier string from a bus path. It + takes a bus path and a prefix string, plus a place to store the + returned external identifier string. If the bus path does not + start with the specified prefix, 0 is returned and the returned + string is set to NULL. Otherwise, the + string following the prefix is unescaped and returned in the + external identifier string. + + The escaping used will replace all characters which are + invalid in a bus object path by _, followed by a + hexadecimal value. As a special case, the empty string will be + replaced by a lone _. + + sd_bus_path_encode_many() works like + its counterpart sd_bus_path_encode(), but + takes a path template as argument and encodes multiple labels + according to its embedded directives. For each + % character found in the template, the caller + must provide a string via varargs, which will be encoded and + embedded at the position of the % character. + Any other character in the template is copied verbatim into the + encoded path. + + sd_bus_path_decode_many() does the + reverse of sd_bus_path_encode_many(). It + decodes the passed object path according to the given + path template. For each % character in the + template, the caller must provide an output storage + (char **) via varargs. The decoded label + will be stored there. Each % character will + only match the current label. It will never match across labels. + Furthermore, only a single directive is allowed per label. + If NULL is passed as output storage, the + label is verified but not returned to the caller. + + + + Return Value + + On success, sd_bus_path_encode() + returns positive or 0, and a valid bus path in the return + argument. On success, sd_bus_path_decode() + returns a positive value if the prefixed matched, or 0 if it + did not. If the prefix matched, the external identifier is returned + in the return parameter. If it did not match, NULL is returned in + the return parameter. On failure, a negative errno-style error + number is returned by either function. The returned strings must + be + free3'd + by the caller. + + + + + + See Also + + + systemd1, + sd-bus3, + free3 + + + + diff --git a/man/sd_bus_process.xml b/man/sd_bus_process.xml new file mode 100644 index 0000000..193c16c --- /dev/null +++ b/man/sd_bus_process.xml @@ -0,0 +1,133 @@ + + + + + + + + + sd_bus_process + systemd + + + + sd_bus_process + 3 + + + + sd_bus_process + + Drive the connection + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_process + sd_bus *bus + sd_bus_message **ret + + + + + + Description + + sd_bus_process() drives the connection between the client and the message bus. That is, + it handles connecting, authentication, and message processing. When invoked pending I/O work is executed, and + queued incoming messages are dispatched to registered callbacks. Each time it is invoked a single operation is + executed. It returns zero when no operations were pending and positive if a message was processed. When zero is + returned the caller should synchronously poll for I/O events before calling into + sd_bus_process() again. For that either use the simple, synchronous + sd_bus_wait3 call, or hook up + the bus connection object to an external or manual event loop using + sd_bus_get_fd3. + + + sd_bus_process() processes at most one incoming message per call. If the parameter + ret is not NULL and the call processed a message, + *ret is set to this message. The caller owns a reference to this message and should call + sd_bus_message_unref3 when the + message is no longer needed. If ret is not NULL, progress was made, but no message was + processed, *ret is set to NULL. + + If the bus object is connected to an + sd-event3 event loop (with + sd_bus_attach_event3), it is not + necessary to call sd_bus_process() directly as it is invoked automatically when + necessary. + + + + Return Value + + If progress was made, a positive integer is returned. If no progress was made, 0 is returned. If an + error occurs, a negative errno-style error code is returned. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + An invalid bus object was passed. + + + + -ECHILD + + The bus connection was allocated in a parent process and is being reused in a child + process after fork(). + + + + -ENOTCONN + + The bus connection has been terminated already. + + + + -ECONNRESET + + The bus connection has been terminated just now. + + + + -EBUSY + + This function is already being called, i.e. sd_bus_process() + has been called from a callback function that itself was called by + sd_bus_process(). + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_wait3, + sd_bus_get_fd3, + sd_bus_message_unref3, + sd-event3, + sd_bus_attach_event3 + + + + diff --git a/man/sd_bus_query_sender_creds.xml b/man/sd_bus_query_sender_creds.xml new file mode 100644 index 0000000..47cc336 --- /dev/null +++ b/man/sd_bus_query_sender_creds.xml @@ -0,0 +1,134 @@ + + + + + + + + sd_bus_query_sender_creds + systemd + + + + sd_bus_query_sender_creds + 3 + + + + sd_bus_query_sender_creds + sd_bus_query_sender_privilege + + Query bus message sender credentials/privileges + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_query_sender_creds + sd_bus_message *m + uint64_t mask + sd_bus_creds **creds + + + + sd_bus_error* sd_bus_query_sender_privilege + sd_bus_message *m + int capability + + + + + + Description + + sd_bus_query_sender_creds() returns the credentials of the message + m. The mask parameter is a combo of + SD_BUS_CREDS_* flags that indicate which credential info the caller is + interested in. See + sd_bus_creds_new_from_pid3 + for a list of possible flags. First, this message checks if the requested credentials are attached to the + message itself. If not, but the message contains the pid of the sender and the caller specified the + SD_BUS_CREDS_AUGMENT flag, this function tries to figure out + the missing credentials via other means (starting from the pid). If the pid isn't available but the + message has a sender, this function calls + sd_bus_get_name_creds3 + to get the requested credentials. If the message has no sender (when a direct connection is used), this + function calls + sd_bus_get_owner_creds3 + to get the requested credentials. On success, the requested credentials are stored in + creds. Ownership of the credentials object in creds is + transferred to the caller and should be freed by calling + sd_bus_creds_unref3. + + + sd_bus_query_sender_privilege() checks if the message m + has the requested privileges. If capability is a non-negative integer, this + function checks if the message has the capability with the same value. See + capabilities7 + for a list of capabilities. If capability is a negative integer, this function + returns whether the sender of the message runs as the same user as the receiver of the message, or if the + sender of the message runs as root and the receiver of the message does not run as root. On success and + if the message has the requested privileges, this function returns a positive integer. If the message + does not have the requested privileges, this function returns zero. + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The message m or an output parameter is + NULL. + + + + -ENOTCONN + + The bus of m is not connected. + + + + -ECHILD + + The bus of m was created in a different process. + + + + + -EPERM + + The message m is not sealed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_creds_new_from_pid3, + sd_bus_get_name_creds3, + sd_bus_get_owner_creds3, + sd_bus_creds_unref3, + capabilities7 + + + diff --git a/man/sd_bus_reply_method_error.xml b/man/sd_bus_reply_method_error.xml new file mode 100644 index 0000000..c9553a0 --- /dev/null +++ b/man/sd_bus_reply_method_error.xml @@ -0,0 +1,176 @@ + + + + + + + + sd_bus_reply_method_error + systemd + + + + sd_bus_reply_method_error + 3 + + + + sd_bus_reply_method_error + sd_bus_reply_method_errorf + sd_bus_reply_method_errorfv + sd_bus_reply_method_errno + sd_bus_reply_method_errnof + sd_bus_reply_method_errnofv + + Reply with an error to a D-Bus method call + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_reply_method_error + sd_bus_message *call + const sd_bus_error *e + + + + int sd_bus_reply_method_errorf + sd_bus_message *call + const char *name + const char *format + ... + + + + int sd_bus_reply_method_errorfv + sd_bus_message *call + const char *name + const char *format + va_list ap + + + + int sd_bus_reply_method_errno + sd_bus_message *call + int error + const sd_bus_error *p + + + + int sd_bus_reply_method_errnof + sd_bus_message *call + int error + const char *format + ... + + + + int sd_bus_reply_method_errnofv + sd_bus_message *call + int error + const char *format + va_list ap + + + + + + Description + + The sd_bus_reply_method_error() function sends an error reply to the + call message. The error structure e specifies the + error to send, and is used as described in + sd_bus_message_new_method_error3. + If no reply is expected to call, this function succeeds without sending a + reply. + + The sd_bus_reply_method_errorf() is to + sd_bus_reply_method_error() what + sd_bus_message_new_method_errorf() is to + sd_bus_message_new_method_error(). + + The sd_bus_reply_method_errno() is to + sd_bus_reply_method_error() what + sd_bus_message_new_method_errno() is to + sd_bus_message_new_method_error(). + + The sd_bus_reply_method_errnof() is to + sd_bus_reply_method_error() what + sd_bus_message_new_method_errnof() is to + sd_bus_message_new_method_error(). + + + + Return Value + + This function returns a non-negative integer if the error reply was successfully sent or + if call does not expect a reply. On failure, it returns a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The input parameter call is + NULL. + + Message call is not a method call message. + + Message call is not attached to a bus. + + The error parameter e to + sd_bus_reply_method_error() is not set, see + sd_bus_error_is_set3. + + + + + + -EPERM + + Message call has been sealed. + + + + + -ENOTCONN + + The bus to which message call is attached is not + connected. + + + + -ENOMEM + + Memory allocation failed. + + + + In addition, any error returned by + sd_bus_send1 + may be returned. + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_new_method_error3 + + + + diff --git a/man/sd_bus_reply_method_return.xml b/man/sd_bus_reply_method_return.xml new file mode 100644 index 0000000..b9003e8 --- /dev/null +++ b/man/sd_bus_reply_method_return.xml @@ -0,0 +1,123 @@ + + + + + + + + sd_bus_reply_method_return + systemd + + + + sd_bus_reply_method_return + 3 + + + + sd_bus_reply_method_return + sd_bus_reply_method_returnv + + Reply to a D-Bus method call + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_reply_method_return + sd_bus_message *call + const char *types + ... + + + + int sd_bus_reply_method_returnv + sd_bus_message *call + const char *types + va_list ap + + + + + + Description + + sd_bus_reply_method_return() sends a reply to the + call message. The type string types and the + arguments that follow it must adhere to the format described in + sd_bus_message_append3. + If no reply is expected to call, this function succeeds without sending a + reply. + + + + Return Value + + On success, this function returns a non-negative integer. On failure, it returns a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The input parameter call is + NULL. + + Message call is not a method call message. + + + Message call is not attached to a bus. + + Message m is not a method reply message. + + + + + -EPERM + + Message call has been sealed. + + + + + -ENOTCONN + + The bus to which message call is attached is not + connected. + + + + -ENOMEM + + Memory allocation failed. + + + + In addition, any error returned by + sd_bus_send1 + may be returned. + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_new_method_return3 + + + + diff --git a/man/sd_bus_request_name.xml b/man/sd_bus_request_name.xml new file mode 100644 index 0000000..28fda40 --- /dev/null +++ b/man/sd_bus_request_name.xml @@ -0,0 +1,210 @@ + + + + + + + + sd_bus_request_name + systemd + + + + sd_bus_request_name + 3 + + + + sd_bus_request_name + sd_bus_request_name_async + sd_bus_release_name + sd_bus_release_name_async + Request or release a well-known service name on a bus + + + + + #include <systemd/sd-bus.h> + + + + + int sd_bus_request_name + sd_bus *bus + const char *name + uint64_t flags + + + + int sd_bus_request_name_async + sd_bus *bus + sd_bus_slot **slot + const char *name + uint64_t flags + sd_bus_message_handler_t callback + void *userdata + + + + int sd_bus_release_name + sd_bus *bus + const char *name + + + + int sd_bus_release_name_async + sd_bus *bus + sd_bus_slot **slot + const char *name + sd_bus_message_handler_t callback + void *userdata + + + + + + Description + + sd_bus_request_name() requests a well-known service name on a bus. It takes a + bus connection, a valid bus name, and a flags parameter. The flags parameter is a combination of zero or + more of the following flags: + + + + SD_BUS_NAME_ALLOW_REPLACEMENT + + After acquiring the name successfully, permit other peers to take over the name when they try + to acquire it with the SD_BUS_NAME_REPLACE_EXISTING flag set. If + SD_BUS_NAME_ALLOW_REPLACEMENT is not set on the original request, such a request by other + peers will be denied. + + + + SD_BUS_NAME_REPLACE_EXISTING + + Take over the name if it was already acquired by another peer, and that other peer + has permitted takeover by setting SD_BUS_NAME_ALLOW_REPLACEMENT while acquiring + it. + + + + SD_BUS_NAME_QUEUE + + Queue the acquisition of the name when the name is already taken. + + + + sd_bus_request_name() operates in a synchronous fashion: a message requesting the name + is sent to the bus broker, and the call waits until the broker responds. + + sd_bus_request_name_async() is an asynchronous version of + sd_bus_request_name(). Instead of waiting for the request to complete, the request message is + enqueued. The specified callback will be called when the broker's response is received. If + the parameter is specified as NULL a default implementation is used instead which will + terminate the connection when the name cannot be acquired. The function returns a slot object in its + slot parameter — if it is passed as non-NULL — which may be used as a + reference to the name request operation. Use + sd_bus_slot_unref3 to destroy + this reference. Note that destroying the reference will not unregister the name, but simply ensure the specified + callback is no longer called. + + sd_bus_release_name() releases an acquired well-known name. It takes a bus connection + and a valid bus name as parameters. This function operates synchronously, sending a release request message to the + bus broker and waiting for it to reply. + + sd_bus_release_name_async() is an asynchronous version of + sd_bus_release_name(). The specified callback function is called when + the name has been released successfully. If specified as NULL a generic implementation is used + that ignores the result of the operation. As above, the slot (if + non-NULL) is set to an object that may be used to reference the operation. + + These functions are supported only on bus connections, i.e. connections to a bus broker and not on direct + connections. + + + + Return Value + + On success, these calls return 0 or a positive integer. On failure, these calls return a negative errno-style + error code. + + If SD_BUS_NAME_QUEUE is specified, sd_bus_request_name() will return + 0 when the name is already taken by another peer and the client has been added to the queue for the name. In that + case, the caller can subscribe to NameOwnerChanged signals to be notified when the name is + successfully acquired. sd_bus_request_name() returns > 0 when the name has immediately + been acquired successfully. + + + Errors + + Returned errors may indicate the following problems: + + + + -EALREADY + + The caller already is the owner of the specified name. + + + + -EEXIST + + The name has already been acquired by a different peer, and SD_BUS_NAME_REPLACE_EXISTING was + not specified or the other peer did not specify SD_BUS_NAME_ALLOW_REPLACEMENT while acquiring the + name. + + + + -ESRCH + + It was attempted to release a name that is currently not registered on the + bus. + + + + -EADDRINUSE + + It was attempted to release a name that is owned by a different peer on the + bus. + + + + -EINVAL + + A specified parameter is invalid. This is also generated when the requested name is + a special service name reserved by the D-Bus specification, or when the operation is requested on a + connection that does not refer to a bus. + + + + -ENOTCONN + + The bus connection has been disconnected. + + + + -ECHILD + + The bus connection has been created in a different process than the current + one. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_new3, + sd_bus_slot_unref3 + + + + diff --git a/man/sd_bus_send.xml b/man/sd_bus_send.xml new file mode 100644 index 0000000..315ad07 --- /dev/null +++ b/man/sd_bus_send.xml @@ -0,0 +1,168 @@ + + + + + + + + sd_bus_send + systemd + + + + sd_bus_send + 3 + + + + sd_bus_send + sd_bus_send_to + sd_bus_message_send + + Queue a D-Bus message for transfer + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_send + sd_bus *bus + sd_bus_message *m + uint64_t *cookie + + + + int sd_bus_send_to + sd_bus *bus + sd_bus_message *m + const char *destination + uint64_t *cookie + + + + int sd_bus_message_send + sd_bus_message *m + + + + + + Description + + sd_bus_send() queues the bus message object m for + transfer. If bus is NULL, the bus that + m is attached to is used. bus only needs to be set when the + message is sent to a different bus than the one it's attached to, for example when forwarding messages. + If the output parameter cookie is not NULL, it is set to the + message identifier. This value can later be used to match incoming replies to their corresponding + messages. If cookie is set to NULL and the message is not + sealed, sd_bus_send() assumes the message m doesn't expect a + reply and adds the necessary headers to indicate this. + + Note that in most scenarios, sd_bus_send() should not be called + directly. Instead, use higher level functions such as + sd_bus_call_method3 and + sd_bus_reply_method_return3 + which call sd_bus_send() internally. + + sd_bus_send_to() is a shorthand for sending a message to a specific + destination. It's main use case is to simplify sending unicast signal messages (signals that only have a + single receiver). It's behavior is similar to calling + sd_bus_message_set_destination3 + followed by calling sd_bus_send(). + + sd_bus_send()/sd_bus_send_to() will write the message + directly to the underlying transport (e.g. kernel socket buffer) if possible. If the connection is not + set up fully yet the message is queued locally. If the transport buffers are congested any unwritten + message data is queued locally, too. If the connection has been closed or is currently being closed the + call fails. + sd_bus_process3 should + be invoked to write out any queued message data to the transport. + + sd_bus_message_send() is the same as sd_bus_send() but + without the first and last argument. sd_bus_message_send(m) is equivalent to + sd_bus_send(sd_bus_message_get_bus(m), m, NULL). + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The input parameter m is NULL. + + + + + -EOPNOTSUPP + + The bus connection does not support sending file descriptors. + + + + + -ECHILD + + The bus connection was allocated in a parent process and is being reused in a child + process after fork(). + + + + -ENOBUFS + + The bus connection's write queue is full. + + + + -ENOTCONN + + The input parameter bus is + NULL or the bus is not connected. + + + + -ECONNRESET + + The bus connection was closed while waiting for the response. + + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_call_method3, + sd_bus_message_set_destination3, + sd_bus_reply_method_return3, + sd_bus_process3 + + + + diff --git a/man/sd_bus_set_address.xml b/man/sd_bus_set_address.xml new file mode 100644 index 0000000..21742bd --- /dev/null +++ b/man/sd_bus_set_address.xml @@ -0,0 +1,188 @@ + + + + + + + + sd_bus_set_address + systemd + + + + sd_bus_set_address + 3 + + + + sd_bus_set_address + sd_bus_get_address + sd_bus_set_exec + + Set or query the address of the bus connection + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_address + sd_bus *bus + const char *address + + + + int sd_bus_get_address + sd_bus *bus + const char **address + + + + int sd_bus_set_exec + sd_bus *bus + const char *path + char *const *argv + + + + + + Description + + sd_bus_set_address() configures a list of addresses of bus brokers to try to + connect to from a subsequent + sd_bus_start3 call. + The argument is a ;-separated list of addresses to try. Each item must be one of the + following: + + + + + A unix socket address specified as + unix:guid=guid,path=path or + unix:guid=guid,abstract=path. + Exactly one of the path= and abstract= keys must be present, + while guid= is optional. + + + + A TCP socket address specified as + tcp:[guid=guid,][host=host][,port=port][,family=family]. + One or both of the host= and port= keys must be present, while + the rest is optional. family may be either or + . + + + + An executable to spawn specified as + unixexec:guid=guid,path=path,argv1=argument,argv2=argument,.... + The path= key must be present, while guid= is optional. + + + + A machine (container) to connect to specified as + x-machine-unix:guid=guid,machine=machine,pid=pid. + Exactly one of the machine= and pid= keys must be present, + while guid= is optional. machine is the name of a local + container. See + machinectl1 for + more information about the "machine" concept. machine=.host may be used to specify + the host machine. A connection to the standard system bus socket inside of the specified machine will + be created. + + + + In all cases, parameter guid is an identifier of the remote peer, in the + syntax accepted by + sd_id128_from_string3. + If specified, the identifier returned by the peer after the connection is established will be checked and + the connection will be rejected in case of a mismatch. + + Note that the addresses passed to sd_bus_set_address() may not be verified + immediately. If they are invalid, an error may be returned e.g. from a subsequent call to + sd_bus_start3. + + + sd_bus_get_address() returns any previously set addresses. In addition to + being explicitly set by sd_bus_set_address(), the address will also be set + automatically by + sd_bus_open3 and + similar calls, based on environment variables or built-in defaults. + + sd_bus_set_exec() is a shorthand function for setting a + unixexec address that spawns the given executable with the given arguments. + If argv is NULL, the given executable is spawned + without any extra arguments. + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The input parameters bus or address are NULL. + + + + + -ENOPKG + + The bus object bus could not be resolved. + + + + + -EPERM + + The input parameter bus is in a wrong state + (sd_bus_set_address() may only be called once on a newly-created bus object). + + + + + -ECHILD + + The bus object bus was created in a different + process. + + + + + -ENODATA + + The bus object bus has no address configured. + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_new3, + sd_bus_start3, + systemd-machined.service8, + machinectl1 + + + + diff --git a/man/sd_bus_set_close_on_exit.xml b/man/sd_bus_set_close_on_exit.xml new file mode 100644 index 0000000..cf3bbae --- /dev/null +++ b/man/sd_bus_set_close_on_exit.xml @@ -0,0 +1,108 @@ + + + + + + + + sd_bus_set_close_on_exit + systemd + + + + sd_bus_set_close_on_exit + 3 + + + + sd_bus_set_close_on_exit + sd_bus_get_close_on_exit + + Control whether to close the bus connection during the event loop exit phase + + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_close_on_exit + sd_bus *bus + int b + + + + int sd_bus_get_close_on_exit + sd_bus *bus + + + + + + + Description + + sd_bus_set_close_on_exit() may be used to enable or disable whether + the bus connection is automatically flushed (as in + sd_bus_flush3) + and closed (as in + sd_bus_close3) + during the exit phase of the event loop. This logic only applies to bus connections that are + attached to an + sd-event3 + event loop, see + sd_bus_attach_event3. + By default this mechanism is enabled and makes sure that any pending messages that have not been + written to the bus connection are written out when the event loop is shutting down. In some + cases this behaviour is not desirable, for example when the bus connection shall remain usable + until after the event loop exited. If b is true, the feature is enabled + (which is the default), otherwise disabled. + + sd_bus_get_close_on_exit() may be used to query the current setting + of this feature. It returns zero when the feature is disabled, and positive if enabled. + + + + Return Value + + On success, sd_bus_set_close_on_exit() returns a non-negative + integer. On failure, it returns a negative errno-style error code. + + sd_bus_get_close_on_exit() returns 0 if the feature is currently + disabled or a positive integer if it is enabled. On failure, it returns a negative errno-style + error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection was created in a different process. + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_flush3, + sd_bus_attach_event3, + sd-event3, + sd_event_add_exit3 + + + diff --git a/man/sd_bus_set_connected_signal.xml b/man/sd_bus_set_connected_signal.xml new file mode 100644 index 0000000..b2dfcf0 --- /dev/null +++ b/man/sd_bus_set_connected_signal.xml @@ -0,0 +1,109 @@ + + + + + + + + sd_bus_set_connected_signal + systemd + + + + sd_bus_set_connected_signal + 3 + + + + sd_bus_set_connected_signal + sd_bus_get_connected_signal + + Control emission of local connection establishment signal on bus connections + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_connected_signal + sd_bus *bus + int b + + + + int sd_bus_get_connected_signal + sd_bus *bus + + + + + + + Description + + sd_bus_set_connected_signal() may be used to control whether a local, synthetic + Connected() signal message shall be generated and enqueued for dispatching when the connection + is fully established. If the b parameter is zero the message is not generated (the default), + otherwise it is generated. + + sd_bus_get_connected_signal() may be used to query whether this feature is enabled. It + returns zero if not, positive otherwise. + + The Connected() signal message is generated from the + org.freedesktop.DBus.Local service and interface, and + /org/freedesktop/DBus/Local object path. Use + sd_bus_match_signal_async3 to + match on this signal. + + This message is particularly useful on slow transports where connections take a long time to be + established. This is especially the case when + sd_bus_set_watch_bind3 is + used. The signal is generated when the + sd_bus_is_ready3 returns + positive for the first time. + + The Connected() signal corresponds with the Disconnected() signal + that is synthesized locally when the connection is terminated. The latter is generated unconditionally however, + unlike the former which needs to be enabled explicitly before it is generated, with + sd_bus_set_connected_signal(). + + + + Return Value + + On success, these functions return 0 or a positive integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection has been created in a different process. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_match_signal_async3, + sd_bus_set_watch_bind3, + sd_bus_is_ready3 + + + + diff --git a/man/sd_bus_set_description.xml b/man/sd_bus_set_description.xml new file mode 100644 index 0000000..0c38c16 --- /dev/null +++ b/man/sd_bus_set_description.xml @@ -0,0 +1,249 @@ + + + + + + + + sd_bus_set_description + systemd + + + + sd_bus_set_description + 3 + + + + sd_bus_set_description + sd_bus_get_description + sd_bus_set_anonymous + sd_bus_is_anonymous + sd_bus_set_trusted + sd_bus_is_trusted + sd_bus_set_allow_interactive_authorization + sd_bus_get_allow_interactive_authorization + sd_bus_get_scope + sd_bus_get_tid + sd_bus_get_unique_name + + Set or query properties of a bus object + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_description + sd_bus *bus + const char *description + + + + int sd_bus_get_description + sd_bus *bus + const char **description + + + + int sd_bus_set_anonymous + sd_bus *bus + int b + + + + int sd_bus_is_anonymous + sd_bus *bus + + + + int sd_bus_set_trusted + sd_bus *bus + int b + + + + int sd_bus_is_trusted + sd_bus *bus + + + + int sd_bus_set_allow_interactive_authorization + sd_bus *bus + int b + + + + int sd_bus_get_allow_interactive_authorization + sd_bus *bus + + + + int sd_bus_get_scope + sd_bus *bus + const char **scope + + + + int sd_bus_get_tid + sd_bus *bus + pid_t *tid + + + + int sd_bus_get_unique_name + sd_bus *bus + const char **unique + + + + + + Description + + sd_bus_set_description() sets the description string that is used in + logging to the specified string. The string is copied internally and freed when the bus object + is deallocated. The description argument may be + NULL, in which case the description is unset. This function must be called + before the bus is started. + + sd_bus_get_description() returns a description string in + description. This string may have been previously set with + sd_bus_set_description() or + sd_bus_open_with_description3 + or similar. If not set this way, a default string like system or + user will be returned for the system or user buses, and + -ENXIO otherwise. + + sd_bus_set_anonymous() enables or disables "anonymous authentication", + i.e. lack of authentication, of the bus peer. This function must be called before the bus is + started. See the + + Authentication Mechanisms section of the D-Bus specification for details. + + sd_bus_is_anonymous() returns true if the bus connection allows + anonymous authentication (in the sense described in previous paragraph). + + sd_bus_set_trusted() sets the "trusted" state on the + bus object. If true, all connections on the bus are trusted and access to + all privileged and unprivileged methods is granted. This function must be called before the bus + is started. + + sd_bus_is_trusted() returns true if the bus connection is trusted (in + the sense described in previous paragraph). + + sd_bus_set_allow_interactive_authorization() enables or disables + interactive authorization for method calls. If true, messages are marked with the + ALLOW_INTERACTIVE_AUTHORIZATION flag specified by the + D-Bus + specification, informing the receiving side that the caller is prepared to wait for interactive + authorization, which might take a considerable time to complete. If this flag is set, the user + may be queried for passwords or confirmation via + polkit or a similar + framework. + + sd_bus_get_allow_interactive_authorization() returns true if + interactive authorization is allowed and false if not. + + sd_bus_get_scope() stores the scope of the given bus object in + scope. The scope of the system bus is system. The + scope of a user session bus is user. If the given bus object is not the + system or a user session bus, sd_bus_get_scope() returns an error. + + sd_bus_get_tid() stores the kernel thread id of the thread associated + with the given bus object in tid. If bus is a + default bus object obtained by calling one of the functions of the + sd_bus_default3 + family of functions, it stores the thread id of the thread the bus object was created in. + Otherwise, if the bus object is attached to an event loop, it stores the thread id of the + thread the event loop object was created in. If bus is not a default bus + object and is not attached to an event loop, sd_bus_get_tid() returns an + error. + + sd_bus_get_unique_name() stores the unique name of the bus object on + the bus in unique. See + + The D-Bus specification for more information on bus names. Note that the caller does not + own the string stored in unique and should not free it. + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + An argument is invalid. + + + + -ENOPKG + + The bus cannot be resolved. + + + + -EPERM + + The bus has already been started. + + + + -ECHILD + + The bus was created in a different process. + + + + -ENOMEM + + Memory allocation failed. + + + + -ENODATA + + The bus object passed to sd_bus_get_scope() was not a + system or user session bus. + + + + -ENXIO + + The bus object passed to sd_bus_get_tid() was not a + default bus object and is not attached to an event loop. + + The bus object passed to sd_bus_get_description() did + not have a description. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_default_user3, + sd_bus_default_system3, + sd_bus_open_user3, + sd_bus_open_system3 + + + + diff --git a/man/sd_bus_set_exit_on_disconnect.xml b/man/sd_bus_set_exit_on_disconnect.xml new file mode 100644 index 0000000..a694aef --- /dev/null +++ b/man/sd_bus_set_exit_on_disconnect.xml @@ -0,0 +1,114 @@ + + + + + + + + sd_bus_set_exit_on_disconnect + systemd + + + + sd_bus_set_exit_on_disconnect + 3 + + + + sd_bus_set_exit_on_disconnect + sd_bus_get_exit_on_disconnect + + Control the exit behavior when the bus object disconnects + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_exit_on_disconnect + sd_bus *bus + int b + + + + int sd_bus_get_exit_on_disconnect + sd_bus *bus + + + + + + Description + + sd_bus_set_exit_on_disconnect() may be used to configure the exit + behavior when the given bus object disconnects. If b is zero, no special + logic is executed when the bus object disconnects. If b is non-zero, the + behavior on disconnect depends on whether the bus object is attached to an event loop or not. If + the bus object is attached to an event loop (see + sd_bus_attach_event3), + the event loop is closed when the bus object disconnects (as if calling + sd_event_exit3). + Otherwise, + exit3 + is called. The exit code passed to sd_event_exit() and + exit() is EXIT_FAILURE. If the bus object has already + disconnected when enabling the exit behavior, the exit behavior is executed immediately. By + default, the exit behavior is disabled. + + sd_bus_get_exit_on_disconnect() returns whether the exit on + disconnect behavior is enabled for the given bus object. + + + + Return Value + + On success, sd_bus_set_exit_on_disconnect() returns a non-negative + integer. On failure, it returns a negative errno-style error code. + + sd_bus_get_exit_on_disconnect() returns a positive integer if the + exit on disconnect behavior is enabled. Otherwise, it returns zero. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + A required parameter was NULL. + + + + -ENOPKG + + The bus object could not be resolved. + + + + -ECHILD + + The bus connection was created in a different process. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_attach_event3, + sd-event3, + sd_event_exit3 + + + diff --git a/man/sd_bus_set_fd.xml b/man/sd_bus_set_fd.xml new file mode 100644 index 0000000..a79458a --- /dev/null +++ b/man/sd_bus_set_fd.xml @@ -0,0 +1,120 @@ + + + + + + + + + sd_bus_set_fd + systemd + + + + sd_bus_set_fd + 3 + + + + sd_bus_set_fd + + Set the file descriptors to use for bus communication + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_fd + sd_bus *bus + int input_fd + int output_fd + + + + + + Description + + sd_bus_set_fd() sets the file descriptors used to communicate by a bus + connection object. Both input_fd and output_fd must be + valid file descriptors, referring to stream-based file objects (e.g. a stream socket, a pair of pipes or + FIFOs, or even a TTY device). input_fd must be readable, and + output_fd must be writable. The same file descriptor may be used (and typically is + used) as both the input and the output file descriptor. This function must be called before the bus + connection is started via + sd_bus_start3. + + The bus connection object will take possession of the passed file descriptors and will close them + automatically when it is freed. Use + sd_bus_set_close_on_exit3 + to turn off this behaviour. + + + + Return Value + + On success, sd_bus_set_fd() returns a non-negative integer. On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + An invalid bus object was passed. + + + + -ECHILD + + The bus connection was allocated in a parent process and is being reused + in a child process after fork(). + + + + -EBADF + + An invalid file descriptor was passed to + sd_bus_set_fd(). + + + + -ENOPKG + + The bus cannot be resolved. + + + + -EPERM + + The bus connection has already been started. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_get_fd3, + sd_bus_start3 + + + + diff --git a/man/sd_bus_set_method_call_timeout.xml b/man/sd_bus_set_method_call_timeout.xml new file mode 100644 index 0000000..0db13e2 --- /dev/null +++ b/man/sd_bus_set_method_call_timeout.xml @@ -0,0 +1,103 @@ + + + + + + + + sd_bus_set_method_call_timeout + systemd + + + + sd_bus_set_method_call_timeout + 3 + + + + sd_bus_set_method_call_timeout + sd_bus_get_method_call_timeout + + Set or query the default D-Bus method call timeout of a bus object + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_method_call_timeout + sd_bus *bus + uint64_t usec + + + + int sd_bus_get_method_call_timeout + sd_bus *bus + uint64_t *ret + + + + + + Description + + sd_bus_set_method_call_timeout() sets the default D-Bus method call + timeout of bus to usec microseconds. + + sd_bus_get_method_call_timeout() queries the default D-Bus method + call timeout of bus. If no method call timeout was set using + sd_bus_set_method_call_timeout(), the timeout is read from the + $SYSTEMD_BUS_TIMEOUT environment variable. If this environment variable is + unset or does not contain a valid timeout, the implementation falls back to a predefined method + call timeout of 25 seconds. Note that $SYSTEMD_BUS_TIMEOUT is read once and + cached so callers should not rely on being able to change the default method call timeout at + runtime by changing the value of $SYSTEMD_BUS_TIMEOUT. Instead, call + sd_bus_set_method_call_timeout() to change the default method call timeout. + + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The parameters bus or ret + are NULL. + + + + -ENOPKG + + Bus object bus could not be resolved. + + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_call3 + + + + diff --git a/man/sd_bus_set_property.xml b/man/sd_bus_set_property.xml new file mode 100644 index 0000000..d6a410e --- /dev/null +++ b/man/sd_bus_set_property.xml @@ -0,0 +1,173 @@ + + + + + + + + sd_bus_set_property + systemd + + + + sd_bus_set_property + 3 + + + + sd_bus_set_property + sd_bus_set_propertyv + sd_bus_get_property + sd_bus_get_property_trivial + sd_bus_get_property_string + sd_bus_get_property_strv + + Set or query D-Bus service properties + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_property + sd_bus *bus + const char *destination + const char *path + const char *interface + const char *member + sd_bus_error *ret_error + const char *type + ... + + + + int sd_bus_set_propertyv + sd_bus *bus + const char *destination + const char *path + const char *interface + const char *member + sd_bus_error *ret_error + const char *type + va_list ap + + + + int sd_bus_get_property + sd_bus *bus + const char *destination + const char *path + const char *interface + const char *member + sd_bus_error *ret_error + sd_bus_message **reply + const char *type + + + + int sd_bus_get_property_trivial + sd_bus *bus + const char *destination + const char *path + const char *interface + const char *member + sd_bus_error *ret_error + char type + void *ret_ptr + + + + int sd_bus_get_property_string + sd_bus *bus + const char *destination + const char *path + const char *interface + const char *member + sd_bus_error *ret_error + char **ret + + + + int sd_bus_get_property_strv + sd_bus *bus + const char *destination + const char *path + const char *interface + const char *member + sd_bus_error *ret_error + char ***ret + + + + + + Description + + These functions set or query D-Bus properties. D-Bus properties are service fields exposed + via the org.freedesktop.DBus.Properties interface. Under the hood, these + functions call methods of the org.freedesktop.DBus.Properties interface and + as a result their semantics are similar to + sd_bus_call_method3. + + + sd_bus_set_property() sets a D-Bus property. If setting the property + fails or an internal error occurs, an error is returned and an extended description of the error + is optionally stored in ret_error if it is not NULL. + type and the arguments that follow it describe the new value of the + property and must follow the format described in + sd_bus_message_append3. + + + sd_bus_set_propertyv() is equivalent to + sd_bus_set_property(), except that it is called with a + va_list instead of a variable number of arguments. + + sd_bus_get_property() queries a D-Bus property. If retrieving the + property fails or an internal error occurs, an error is returned and an extended description of + the error is optionally stored in ret_error if it is not + NULL. On success, the property is stored in reply. + type describes the property type and must follow the format described in + sd_bus_message_append3. + + + sd_bus_get_property_trivial(), + sd_bus_get_property_string() and + sd_bus_get_property_strv() are shorthands for + sd_bus_get_property() that are used to query basic, string and string + vector properties respectively. The caller is responsible for freeing the string and string + vector results stored in ret by + sd_bus_get_property_string() and + sd_bus_get_property_strv(). + + + + Return Value + + On success, these functions return a non-negative integer. On failure, they return a + negative errno-style error code. + + + Errors + + See the + sd_bus_call_method3 + man page for a list of possible errors. + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_call_method3 + + + + diff --git a/man/sd_bus_set_sender.xml b/man/sd_bus_set_sender.xml new file mode 100644 index 0000000..c6e07ac --- /dev/null +++ b/man/sd_bus_set_sender.xml @@ -0,0 +1,103 @@ + + + + + + + + sd_bus_set_sender + systemd + + + + sd_bus_set_sender + 3 + + + + sd_bus_set_sender + sd_bus_get_sender + + Configure default sender for outgoing messages + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_sender + sd_bus *bus + const char* name + + + + int sd_bus_get_sender + sd_bus *bus + const char** name + + + + + + + Description + + sd_bus_set_sender() configures the default sender service name to use for outgoing + messages. The service name specified in the name parameter is set on all outgoing messages + that are sent on the connection and have no sender set yet, for example through + sd_bus_message_set_sender3. Note + that this function is only supported on direct connections, i.e. not on connections to a bus broker as the broker + will fill in the sender service name automatically anyway. By default no sender name is configured, and hence + messages are sent without sender field set. If the name parameter is specified as + NULL the default sender service name is cleared, returning to the default state if a default + sender service name was set before. If passed as non-NULL the specified name must be a valid + unique or well-known service name. + + sd_bus_get_sender() may be used to query the current default service name for outgoing + messages. + + + + Return Value + + On success, these functions return 0 or a positive integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection has been created in a different process. + + + + -EPERM + + The specified bus connection object is a not a direct but a brokered + connection. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_message_set_sender3 + + + + diff --git a/man/sd_bus_set_server.xml b/man/sd_bus_set_server.xml new file mode 100644 index 0000000..e2cd74d --- /dev/null +++ b/man/sd_bus_set_server.xml @@ -0,0 +1,193 @@ + + + + + + + + sd_bus_set_server + systemd + + + + sd_bus_set_server + 3 + + + + sd_bus_set_server + sd_bus_is_server + sd_bus_get_bus_id + sd_bus_set_bus_client + sd_bus_is_bus_client + sd_bus_set_monitor + sd_bus_is_monitor + + Configure connection mode for a bus object + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_server + sd_bus *bus + int b + sd_id128_t id + + + + int sd_bus_is_server + sd_bus *bus + + + + int sd_bus_get_bus_id + sd_bus *bus + sd_id128_t *id + + + + int sd_bus_set_bus_client + sd_bus *bus + int b + + + + int sd_bus_is_bus_client + sd_bus *bus + + + + int sd_bus_set_monitor + sd_bus *bus + int b + + + + int sd_bus_is_monitor + sd_bus *bus + + + + + + Description + + sd_bus_set_server() configures the bus object as a server for direct D-Bus + connections. b enables/disables the server mode. If zero, the server mode is + disabled. Otherwise, the server mode is enabled. Configuring a bus object as a server is required to + allow establishing direct connections between two peers without going via the D-Bus daemon. + id must contain a 128-bit integer id for the server. If clients add a guid field + to their D-Bus address string, the server id must match this guid or the D-Bus authentication handshake + will fail. If no specific id is defined for the server, + sd_id128_randomize3 + can be used to generate a random id instead. + + sd_bus_is_server() returns whether the server mode is enabled for the given + bus object. + + sd_bus_get_bus_id() stores the D-Bus server id configured using + sd_bus_set_server() (for server bus objects) or received during D-Bus authentication + (for client bus objects) in id. + + sd_bus_set_bus_client() configures the bus object as a D-Bus daemon client. + b enables/disables the client mode. If zero, the client mode is disabled and the + bus object should connect directly to a D-Bus server. Otherwise, the client mode is enabled and the bus + object should connect to a D-Bus daemon. When connecting to an existing bus using any of the functions in + the sd_bus_open3 + family of functions or any of the functions in the + sd_bus_default3 family + of functions, the bus object is automatically configured as a bus client. However, when connecting to a + D-Bus daemon by calling + sd_bus_set_address3 + followed by + sd_bus_start3, the bus + object should be manually configured as a bus client using sd_bus_set_bus_client(). + By default, a bus object is not configured as a D-Bus daemon client. + + sd_bus_is_bus_client() returns whether the client mode is enabled/disabled for + the given bus object. + + sd_bus_set_monitor() configures the bus object as a D-Bus monitor object. + b enables/disables the monitor mode. If zero, the monitor mode is disabled. If + non-zero, the monitor mode is enabled. When the monitor mode is enabled, no messages may be sent via the + bus object and it may not expose any objects on the bus. To start monitoring messages, call the + org.freedesktop.DBus.Monitoring.BecomeMonitor method of the D-Bus daemon and pass + a list of matches indicating which messages to intercept. See + + The D-Bus specification for more information. + + sd_bus_is_monitor() returns whether the monitor mode is enabled/disabled for + the given bus object. + + + + + Return Value + + On success, sd_bus_set_server(), + sd_bus_get_bus_id(), sd_bus_set_bus_client() and + sd_bus_set_monitor() return a non-negative integer. On failure, they return a + negative errno-style error code. + + sd_bus_is_server(), sd_bus_is_bus_client() and + sd_bus_is_monitor() return a positive integer when the server or client mode is + enabled, respectively. Otherwise, they return zero. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection has been created in a different process. + + + + -EPERM + + The bus connection has already been started. + + + + -ENOPKG + + The bus cannot be resolved. + + + + -EINVAL + + A required parameter was NULL or + b was zero and id did not equal + SD_ID128_NULL. + + + + -ENOTCONN + + The bus is not connected. + + + + + + + + + See Also + + + systemd1, + sd-bus3 + + + + diff --git a/man/sd_bus_set_watch_bind.xml b/man/sd_bus_set_watch_bind.xml new file mode 100644 index 0000000..20f6f53 --- /dev/null +++ b/man/sd_bus_set_watch_bind.xml @@ -0,0 +1,118 @@ + + + + + + + + sd_bus_set_watch_bind + systemd + + + + sd_bus_set_watch_bind + 3 + + + + sd_bus_set_watch_bind + sd_bus_get_watch_bind + + Control socket binding watching on bus connections + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_set_watch_bind + sd_bus *bus + int b + + + + int sd_bus_get_watch_bind + sd_bus *bus + + + + + + + Description + + sd_bus_set_watch_bind() may be used to enable or disable client-side watching of server + socket binding for a bus connection object. If the b is true, the feature is enabled, + otherwise disabled (which is the default). When enabled, and the selected bus address refers to an + AF_UNIX socket in the file system which does not exist while the connection attempt is made an + inotify7 watch is installed on + it, waiting for the socket to appear. As soon as the socket appears the connection is made. This functionality is + useful in particular in early-boot programs that need to run before the system bus is available, but want to + connect to it the instant it may be connected to. + + sd_bus_get_watch_bind() may be used to query the current setting of this feature. It + returns zero when the feature is disabled, and positive if enabled. + + Note that no timeout is applied while we wait for the socket to appear. This means that any + synchronous remote operation (such as + sd_bus_call3, + sd_bus_add_match3 or + sd_bus_request_name3), + that is used on a connection with this feature enabled that hasn't been established yet, might block + forever if the socket is never created. However, asynchronous remote operations (such as + sd_bus_send3, + sd_bus_call_async3, + sd_bus_add_match_async3) + do not block in this case, and safely enqueue the requested operations to be dispatched the instant the + connection is set up. + + Use sd_bus_is_ready3 to + determine whether the connection is fully established, i.e. whether the peer socket has been bound, connected to + and authenticated. Use + sd_bus_set_connected_signal3 to + be notified when the connection is fully established. + + + + + Return Value + + On success, these functions return 0 or a positive integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ECHILD + + The bus connection has been created in a different process. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + inotify7, + sd_bus_call3, + sd_bus_add_match3, + sd_bus_request_name3, + sd_bus_is_ready3, + sd_bus_set_connected_signal3 + + + + diff --git a/man/sd_bus_slot_get_bus.xml b/man/sd_bus_slot_get_bus.xml new file mode 100644 index 0000000..48400ad --- /dev/null +++ b/man/sd_bus_slot_get_bus.xml @@ -0,0 +1,90 @@ + + + + + + + sd_bus_slot_get_bus + systemd + + + + sd_bus_slot_get_bus + 3 + + + + sd_bus_slot_get_bus + sd_bus_slot_get_current_handler + sd_bus_slot_get_current_message + sd_bus_slot_get_current_userdata + + Query information attached to a bus slot object + + + + + #include <systemd/sd-bus.h> + + + + + sd_bus *sd_bus_slot_get_bus + sd_bus_slot *slot + + + + sd_bus_message_handler_t sd_bus_slot_get_current_handler + + sd_bus_slot *slot + + + + sd_bus_message *sd_bus_slot_get_current_message + sd_bus_slot *slot + + + + void *sd_bus_slot_get_current_userdata + sd_bus_slot *slot + + + + + + Description + + sd_bus_slot_get_bus() returns the bus object that message + slot is attached to. + + sd_bus_slot_get_current_handler(), + sd_bus_slot_get_current_message() and + sd_bus_slot_get_current_userdata() return the current handler, message and + userdata respectively of the bus slot is attached to if we're currently + executing the callback associated with slot. + + + + Return Value + + sd_bus_slot_get_bus() always returns the bus object. + + On success, sd_bus_slot_get_current_handler(), + sd_bus_slot_get_current_message() and + sd_bus_slot_get_current_userdata() return the requested object. On failure, + they return NULL. + + + + + + See Also + + + systemd1, + sd-bus3, + + + + diff --git a/man/sd_bus_slot_ref.xml b/man/sd_bus_slot_ref.xml new file mode 100644 index 0000000..8ada3cb --- /dev/null +++ b/man/sd_bus_slot_ref.xml @@ -0,0 +1,94 @@ + + + + + + + sd_bus_slot_ref + systemd + + + + sd_bus_slot_ref + 3 + + + + sd_bus_slot_ref + sd_bus_slot_unref + sd_bus_slot_unrefp + + Create and destroy references to a bus slot object + + + + + #include <systemd/sd-bus.h> + + + sd_bus_slot *sd_bus_slot_ref + sd_bus_slot *slot + + + + sd_bus_slot *sd_bus_slot_unref + sd_bus_slot *slot + + + + void sd_bus_slot_unrefp + sd_bus_slot **slotp + + + + + + Description + + sd_bus_slot_ref() increases the internal reference counter of + slot by one. + + sd_bus_slot_unref() decreases the internal reference counter of + slot by one. Once the reference count has dropped to zero, slot object is + destroyed and cannot be used anymore, so further calls to sd_bus_slot_ref() + or sd_bus_slot_unref() are illegal. + + sd_bus_slot_unrefp() is similar to + sd_bus_slot_unref() but takes a pointer to a pointer to an + sd_bus_slot object. This call is useful in conjunction with GCC's and LLVM's Clean-up Variable + Attribute. See + sd_bus_new3 + for an example how to use the cleanup attribute. + + sd_bus_slot_ref() and sd_bus_slot_unref() + execute no operation if the passed in bus object address is + NULL. sd_bus_slot_unrefp() will first dereference + its argument, which must not be NULL, and will execute no operation if + that is NULL. + + + + Return Value + + sd_bus_slot_ref() always returns the argument. + + sd_bus_slot_unref() always returns NULL. + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_new3, + sd_bus_message_new3, + sd_bus_call_method_async3 + + + + diff --git a/man/sd_bus_slot_set_description.xml b/man/sd_bus_slot_set_description.xml new file mode 100644 index 0000000..4a8df0c --- /dev/null +++ b/man/sd_bus_slot_set_description.xml @@ -0,0 +1,105 @@ + + + + + + + sd_bus_slot_set_description + systemd + + + + sd_bus_slot_set_description + 3 + + + + sd_bus_slot_set_description + sd_bus_slot_get_description + + Set or query the description of bus slot objects + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_slot_set_description + sd_bus_slot* slot + const char *description + + + + int sd_bus_slot_get_description + sd_bus_slot* bus + const char **description + + + + + + Description + + sd_bus_slot_set_description() sets the description string + that is used in logging to the specified string. The string is copied internally + and freed when the bus slot object is deallocated. The + description argument may be NULL, in + which case the description is unset. + + sd_bus_slot_get_description() returns a description string in + description. If the string is not set, e.g. with + sd_bus_slot_set_description(), and the slot is a bus match callback slot, + the match string will be returned. Otherwise, -ENXIO is returned. + + + + + Return Value + + On success, these functions return 0 or a positive integer. On failure, + they return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + An required argument is NULL. + + + + -ENXIO + + The bus slot object has no description. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + + See Also + + + systemd1, + sd-bus3 + sd_bus_slot_ref3, + sd_bus_slot_set_userdata3 + + + + diff --git a/man/sd_bus_slot_set_destroy_callback.xml b/man/sd_bus_slot_set_destroy_callback.xml new file mode 100644 index 0000000..4de77d2 --- /dev/null +++ b/man/sd_bus_slot_set_destroy_callback.xml @@ -0,0 +1,130 @@ + + + + + + + + sd_bus_slot_set_destroy_callback + systemd + + + + sd_bus_slot_set_destroy_callback + 3 + + + + sd_bus_slot_set_destroy_callback + sd_bus_slot_get_destroy_callback + sd_bus_track_set_destroy_callback + sd_bus_track_get_destroy_callback + sd_bus_destroy_t + + Define the callback function for resource cleanup + + + + + #include <systemd/sd-bus.h> + + + typedef int (*sd_bus_destroy_t) + void *userdata + + + + int sd_bus_slot_set_destroy_callback + sd_bus_slot *slot + sd_bus_destroy_t callback + + + + int sd_bus_slot_get_destroy_callback + sd_bus_slot *slot + sd_bus_destroy_t *callback + + + + int sd_bus_track_set_destroy_callback + sd_bus_track *track + sd_bus_destroy_t callback + + + + int sd_bus_track_get_destroy_callback + sd_bus_track *track + sd_bus_destroy_t *callback + + + + + + Description + + sd_bus_slot_set_destroy_callback() sets callback as the callback + function to be called right before the bus slot object slot is deallocated. The + userdata pointer from the slot object will be passed as the userdata + parameter. This pointer can be set by an argument to the constructor functions, see + sd_bus_add_match3, or directly, + see sd_bus_slot_set_userdata3. + This callback function is called even if userdata is NULL. Note that + this callback is invoked at a time where the bus slot object itself is already invalidated, and executing + operations or taking new references to the bus slot object is not permissible. + + sd_bus_slot_get_destroy_callback() returns the current callback + for slot in the callback parameter. + + sd_bus_track_set_destroy_callback() and + sd_bus_track_get_destroy_callback() provide equivalent functionality for the + userdata pointer associated with bus peer tracking objects. For details about bus peer + tracking objects, see + sd_bus_track_new3. + + + + Return Value + + On success, sd_bus_slot_set_destroy_callback() and + sd_bus_track_set_destroy_callback() return 0 or a positive integer. On failure, they + return a negative errno-style error code. + + sd_bus_slot_get_destroy_callback() and + sd_bus_track_get_destroy_callback() return positive if the destroy callback function + is set, 0 if not. On failure, they return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The slot or track parameter is + NULL. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_slot_set_floating3, + sd_bus_add_match3, + sd_bus_track_new3, + sd_bus_slot_set_userdata3, + sd_bus_track_set_userdata3 + + + + diff --git a/man/sd_bus_slot_set_floating.xml b/man/sd_bus_slot_set_floating.xml new file mode 100644 index 0000000..dd3a950 --- /dev/null +++ b/man/sd_bus_slot_set_floating.xml @@ -0,0 +1,117 @@ + + + + + + + + sd_bus_slot_set_floating + systemd + + + + sd_bus_slot_set_floating + 3 + + + + sd_bus_slot_set_floating + sd_bus_slot_get_floating + + Control whether a bus slot object is "floating" + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_slot_set_floating + sd_bus_slot *slot + int b + + + + int sd_bus_slot_get_floating + sd_bus_slot *slot + + + + + + + Description + + sd_bus_slot_set_floating() controls whether the specified bus slot object + slot shall be "floating" or not. A floating bus slot object's lifetime is bound to the + lifetime of the bus object it is associated with, meaning that it remains allocated as long as the bus object + itself and is freed automatically when the bus object is freed. Regular (i.e. non-floating) bus slot objects keep + the bus referenced, hence the bus object remains allocated at least as long as there remains at least one + referenced bus slot object around. The floating state hence controls the direction of referencing between the bus + object and the bus slot objects: if floating the bus pins the bus slot, and otherwise the bus slot pins the bus + objects. Use sd_bus_slot_set_floating() to switch between both modes: if the + b parameter is zero, the slot object is considered floating, otherwise it is made a regular + (non-floating) slot object. + + Bus slot objects may be allocated with calls such as + sd_bus_add_match3. If the + slot of these functions is non-NULL the slot object will be of the + regular kind (i.e. non-floating), otherwise it will be created floating. With + sd_bus_slot_set_floating() a bus slot object allocated as regular can be converted into a + floating object and back. This is particularly useful for creating a bus slot object, then changing parameters of + it, and then turning it into a floating object, whose lifecycle is managed by the bus object. + + sd_bus_slot_get_floating() returns the current floating state of the specified bus slot + object. It returns negative on error, zero if the bus slot object is a regular (non-floating) object and positive + otherwise. + + + + Return Value + + On success, these functions return 0 or a positive integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The slot parameter is NULL. + + + + -ECHILD + + The bus connection has been created in a different process. + + + + -ESTALE + + The bus object the specified bus slot object is associated with has already been + freed, and hence no change in the floating state can be made anymore. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_slot_set_destroy_callback3, + sd_bus_add_match3 + + + + diff --git a/man/sd_bus_slot_set_userdata.xml b/man/sd_bus_slot_set_userdata.xml new file mode 100644 index 0000000..9fa5f3a --- /dev/null +++ b/man/sd_bus_slot_set_userdata.xml @@ -0,0 +1,88 @@ + + + + + + + + sd_bus_slot_set_userdata + systemd + + + + sd_bus_slot_set_userdata + 3 + + + + sd_bus_slot_set_userdata + sd_bus_slot_get_userdata + + Set and query the value in the "userdata" field + + + + + #include <systemd/sd-bus.h> + + + void* sd_bus_slot_set_userdata + sd_bus_slot* slot + void* userdata + + + + void* sd_bus_slot_get_userdata + sd_bus_slot* slot + + + + + + + Description + + The userdata pointer allows data to be passed between the point where a callback is + registered, for example when a filter is added using + sd_bus_add_filter3 + or an asynchronous function call is made using + sd_bus_call_async3, + and the point where the callback is called, without having any global state. The pointer has + type void* and is not used by the sd-bus functions in any way, except to pass to + the callback function. + + Usually, the userdata field is set when the slot object is initially + registered. sd_bus_slot_set_userdata() may be used to change it later for + the bus slot object slot. Previous value of the field is returned. The + argument and returned value may be NULL. It will be passed as the + userdata argument to the callback function attached to the slot. + + sd_bus_slot_set_userdata() gets the value of the userdata field in + the bus slot object slot. + + + + Return Value + + On success, these functions return the value of the userdata field before the function + call. If the slot object is NULL, + NULL will be returned to signify an error, but this is not distinguishable + from the userdata field value being NULL. + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_slot_set_destroy_callback3, + sd_bus_add_match3, + sd_bus_slot_get_current_userdata3 + + + + diff --git a/man/sd_bus_start.xml b/man/sd_bus_start.xml new file mode 100644 index 0000000..68fe3e0 --- /dev/null +++ b/man/sd_bus_start.xml @@ -0,0 +1,124 @@ + + + + + + + + sd_bus_start + systemd + + + + sd_bus_start + 3 + + + + sd_bus_start + + Initiate a bus connection to the D-bus broker daemon + + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_start + sd_bus *bus + + + + + + Description + + sd_bus_start() connects an existing bus connection object to the D-Bus + broker daemon, usually + dbus-daemon1 + or + dbus-broker1. + The mechanism to use for the connection must be configured before the call to + sd_bus_start(), using one of + sd_bus_set_address3, + sd_bus_set_fd3, or + sd_bus_set_exec3. + sd_bus_start() will open the connection socket or spawn the executable as + needed, and asynchronously start a org.freedesktop.DBus.Hello() call. The + answer to the Hello call will be processed later from + sd_bus_process3. If + opening of the connection or queuing of the asynchronous call fail, the connection will be closed with + sd_bus_close3. + + In most cases, it is better to use + sd_bus_default_user3, + sd_bus_default_system3 + or related calls instead of the more low-level sd_bus_new() and + sd_bus_start(). The higher-level functions not only allocate a bus object but also + start the connection to a well-known bus in a single function call. + + + + Return Value + + On success, this function returns a non-negative integer. On failure, it returns a negative + errno-style error code. + + + Errors + + + + -EINVAL + + The input parameter bus is NULL. + + + + + -ENOPKG + + Bus object bus could not be resolved. + + + + + -EPERM + + The input parameter bus is in a wrong state + (sd_bus_start() may only be called once on a newly-created bus object). + + + + + -ECHILD + + The bus object bus was created in a different + process. + + + + + In addition, other connection-related errors may be returned. See + sd_bus_send3. + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_default3, + sd_bus_call_async3 + + + + diff --git a/man/sd_bus_track_add_name.xml b/man/sd_bus_track_add_name.xml new file mode 100644 index 0000000..ae90e44 --- /dev/null +++ b/man/sd_bus_track_add_name.xml @@ -0,0 +1,228 @@ + + + + + + + + sd_bus_track_add_name + systemd + + + + sd_bus_track_add_name + 3 + + + + sd_bus_track_add_name + sd_bus_track_add_sender + sd_bus_track_remove_name + sd_bus_track_remove_sender + sd_bus_track_count + sd_bus_track_count_sender + sd_bus_track_count_name + sd_bus_track_contains + sd_bus_track_first + sd_bus_track_next + + Add, remove and retrieve bus peers tracked in a bus peer tracking object + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_track_add_name + sd_bus_track* t + const char* name + + + + int sd_bus_track_add_sender + sd_bus_track* t + sd_bus_message* message + + + + int sd_bus_track_remove_name + sd_bus_track* t + const char* name + + + + int sd_bus_track_remove_sender + sd_bus_track* t + sd_bus_message* message + + + + unsigned sd_bus_track_count + sd_bus_track* t + + + + int sd_bus_track_count_name + sd_bus_track* t + const char* name + + + + int sd_bus_track_count_sender + sd_bus_track* t + sd_bus_message* message + + + + int sd_bus_track_contains + sd_bus_track* t + const char* name + + + + const char* sd_bus_track_first + sd_bus_track* t + + + + const char* sd_bus_track_next + sd_bus_track* t + + + + + + + Description + + sd_bus_track_add_name() adds a peer to track to a bus peer tracking object. The first + argument should refer to a bus peer tracking object created with + sd_bus_track_new3, the second + name should refer to a D-Bus peer name to track, either in unique or well-known service format. If the name is not + tracked yet it will be added to the list of names to track. If it already is being tracked and non-recursive mode + is enabled, no operation is executed by this call. If recursive mode is enabled a per-name counter is increased by + one each time this call is invoked, and sd_bus_track_remove_name() has to be called as many + times as sd_bus_track_add_name() was invoked before in order to stop tracking of the name. Use + sd_bus_track_set_recursive3 to + switch from the default non-recursive mode to recursive mode, or back. Note that the specified name is tracked as + it is, well-known names are not resolved to unique names by this call. Note that multiple bus peer tracking objects + may track the same name. + + sd_bus_track_remove_name() undoes the effect of + sd_bus_track_add_name() and removes a bus peer name from the list of peers to watch. Depending + on whether non-recursive or recursive mode is enabled for the bus peer tracking object this call will either remove + the name fully from the tracking object, or will simply decrement the per-name counter by one, removing the name + only when the counter reaches zero (see above). Note that a bus peer disconnecting from the bus will implicitly + remove its names fully from the bus peer tracking object, regardless of the current per-name counter. + + sd_bus_track_add_sender() and sd_bus_track_remove_sender() are + similar to sd_bus_track_add_name() and sd_bus_track_remove_name() but + take a bus message as argument. The sender of this bus message is determined and added to/removed from the bus peer + tracking object. As messages always originate from unique names, and never from well-known names this means that + this call will effectively only add unique names to the bus peer tracking object. + + sd_bus_track_count() returns the number of names currently being tracked by the + specified bus peer tracking object. Note that this function always returns the actual number of names tracked, and + hence if sd_bus_track_add_name() has been invoked multiple times for the same name it is only + counted as one, regardless if recursive mode is used or not. + + sd_bus_track_count_name() returns the current per-name counter for the specified + name. If non-recursive mode is used this returns either 1 or 0, depending on whether the specified name has been + added to the tracking object before, or not. If recursive mode has been enabled, values larger than 1 may be + returned too, in case sd_bus_track_add_name() has been called multiple times for the same + name. + + sd_bus_track_count_sender() is similar to + sd_bus_track_count_name(), but takes a bus message object and returns the per-name counter + matching the sender of the message. + + sd_bus_track_contains() may be used to determine whether the specified name has been + added at least once to the specified bus peer tracking object. + + sd_bus_track_first() and sd_bus_track_next() may be used to + enumerate all names currently being tracked by the passed bus peer tracking + object. sd_bus_track_first() returns the first entry in the object, and resets an internally + maintained read index. Each subsequent invocation of sd_bus_track_next() returns the next name + contained in the bus object. If the end is reached NULL is returned. If no names have been + added to the object yet sd_bus_track_first() will return NULL + immediately. The order in which names are returned is undefined; in particular which name is considered the first + returned is not defined. If recursive mode is enabled and the same name has been added multiple times to the bus + peer tracking object it is only returned once by this enumeration. If new names are added to or existing names + removed from the bus peer tracking object while it is being enumerated the enumeration ends on the next invocation + of sd_bus_track_next() as NULL is returned. + + + + Return Value + + On success, sd_bus_track_add_name() and sd_bus_track_add_sender() + return 0 if the specified name has already been added to the bus peer tracking object before and positive if it + hasn't. On failure, they return a negative errno-style error code. + + sd_bus_track_remove_name() and sd_bus_track_remove_sender() return + positive if the specified name was previously tracked by the bus peer tracking object and has now been removed. In + non-recursive mode, 0 is returned if the specified name was not being tracked yet. In recursive mode + -EUNATCH is returned in this case. On failure, they return a negative errno-style error + code. + + sd_bus_track_count() returns the number of names currently being tracked, or 0 on + failure. + + sd_bus_track_count_name() and sd_bus_track_count_sender() return + the current per-name counter for the specified name or the sender of the specified message. Zero is returned for + names that are not being tracked yet, a positive value for names added at least once. Larger values than 1 are only + returned in recursive mode. On failure, a negative errno-style error code is returned. + + sd_bus_track_contains() returns the passed name if it exists in the bus peer tracking + object. On failure, and if the name has not been added yet NULL is returned. + + sd_bus_track_first() and sd_bus_track_next() return the first/next + name contained in the bus peer tracking object, and NULL if the end of the enumeration is + reached and on error. + + + Errors + + Returned errors may indicate the following problems: + + + + + -EUNATCH + + sd_bus_track_remove_name() or + sd_bus_track_remove_sender() have been invoked for a name not previously added + to the bus peer object. + + + + -EINVAL + + Specified parameter is invalid. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_track_new3 + + + + diff --git a/man/sd_bus_track_new.xml b/man/sd_bus_track_new.xml new file mode 100644 index 0000000..2147ad1 --- /dev/null +++ b/man/sd_bus_track_new.xml @@ -0,0 +1,231 @@ + + + + + + + + sd_bus_track_new + systemd + + + + sd_bus_track_new + 3 + + + + sd_bus_track_new + sd_bus_track_ref + sd_bus_track_unref + sd_bus_track_unrefp + sd_bus_track_set_recursive + sd_bus_track_get_recursive + sd_bus_track_get_bus + sd_bus_track_get_userdata + sd_bus_track_set_userdata + + Track bus peers + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_track_new + sd_bus* bus + sd_bus_track** ret + sd_bus_track_handler_t handler + void* userdata + + + + sd_bus_track *sd_bus_track_ref + sd_bus_track *t + + + + sd_bus_track *sd_bus_track_unref + sd_bus_track *t + + + + void sd_bus_track_unrefp + sd_bus_track **t + + + + int sd_bus_track_get_recursive + sd_bus_track *t + + + + int sd_bus_track_set_recursive + sd_bus_track *t + int b + + + + sd_bus* sd_bus_track_get_bus + sd_bus_track *t + + + + void* sd_bus_track_get_userdata + sd_bus_track *t + + + + void* sd_bus_track_set_userdata + sd_bus_track *t + void *userdata + + + + + + + Description + + sd_bus_track_new() creates a new bus peer tracking object. The object is allocated for + the specified bus, and returned in the *ret parameter. After use, the object should be freed + again by dropping the acquired reference with sd_bus_track_unref() (see below). A bus peer + tracking object may be used to keep track of peers on a specific IPC bus, for cases where peers are making use of + one or more local objects, in order to control the lifecycle of the local objects and ensure they stay around as + long as the peers needing them are around, and unreferenced (and possibly destroyed) as soon as all relevant peers + have vanished. Each bus peer tracking object may be used to track zero, one or more peers add a time. References to + specific bus peers are added via + sd_bus_track_add_name3 or + sd_bus_track_add_sender(). They may be dropped again via + sd_bus_track_remove_name() and + sd_bus_track_remove_sender(). Alternatively, references on peers are removed automatically + when they disconnect from the bus. If non-NULL the handler may specify + a function that is invoked whenever the last reference is dropped, regardless whether the reference is dropped + explicitly via sd_bus_track_remove_name() or implicitly because the peer disconnected from the + bus. The final argument userdata may be used to attach a generic user data pointer to the + object. This pointer is passed to the handler callback when it is invoked. + + sd_bus_track_ref() creates a new reference to a bus peer tracking object. This object + will not be destroyed until sd_bus_track_unref() has been called as many times plus once + more. Once the reference count has dropped to zero, the specified object cannot be used anymore, further calls to + sd_bus_track_ref() or sd_bus_track_unref() on the same object are + illegal. + + sd_bus_track_unref() destroys a reference to a bus peer tracking object. + + sd_bus_track_unrefp() is similar to sd_bus_track_unref() but takes + a pointer to a pointer to an sd_bus_track object. This call is useful in conjunction with GCC's and + LLVM's Clean-up Variable + Attribute. Note that this function is defined as inline function. + + sd_bus_track_ref(), sd_bus_track_unref() and + sd_bus_track_unrefp() execute no operation if the passed in bus peer tracking object is + NULL. + + Bus peer tracking objects may exist in two modes: by default they operate in non-recursive mode, but may + optionally be switched into recursive mode. If operating in the default non-recursive mode a peer is either tracked + or not tracked. In this mode invoking sd_bus_track_add_name() multiple times in a row for the + same peer is fully equivalent to calling it just once, as the call adds the peer to the set of tracked peers if + necessary, and executes no operation if the peer is already being tracked. A single invocation of + sd_bus_track_remove_name() removes the reference on the peer again, regardless how many times + sd_bus_track_add_name() was called before. If operating in recursive mode, the number of times + sd_bus_track_add_name() is invoked for the same peer name is counted and + sd_bus_track_remove_name() must be called the same number of times before the peer is not + tracked anymore, with the exception when the tracked peer vanishes from the bus, in which case the count is + irrelevant and the tracking of the specific peer is immediately + removed. sd_bus_track_get_recursive() may be used to determine whether the bus peer tracking + object is operating in recursive mode. sd_bus_track_set_recursive() may be used to enable or + disable recursive mode. By default a bus peer tracking object operates in non-recursive mode, and + sd_bus_track_get_recursive() for a newly allocated object hence returns a value equal to + zero. Use sd_bus_track_set_recursive() to enable recursive mode, right after allocation. It + takes a boolean argument to enable or disable recursive mode. Note that tracking objects for which + sd_bus_track_add_name() was already invoked at least once (and which hence track already one + or more peers) may not be switched from recursive to non-recursive mode anymore. + + sd_bus_track_get_bus() returns the bus object the bus peer tracking object belongs + to. It returns the bus object initially passed to sd_bus_track_new() when the object was + allocated. + + sd_bus_track_get_userdata() returns the generic user data pointer set on the bus peer + tracking object at the time of creation using sd_bus_track_new() or at a later time, using + sd_bus_track_set_userdata(). + + + + Return Value + + On success, sd_bus_track_new() and sd_bus_track_set_recursive() + return 0 or a positive integer. On failure, they return a negative errno-style error code. + + sd_bus_track_ref() always returns the argument. + + sd_bus_track_unref() always returns NULL. + + sd_bus_track_get_recursive() returns 0 if non-recursive mode is selected (default), and + greater than 0 if recursive mode is selected. On failure a negative errno-style error code is returned. + + sd_bus_track_get_bus() returns the bus object associated to the bus peer tracking + object. + + sd_bus_track_get_userdata() returns the generic user data pointer associated with the + bus peer tracking object. sd_bus_track_set_userdata() returns the previous user data pointer + set. + + + + + Reference ownership + + The sd_bus_track_new() function creates a new object and the caller owns the sole + reference. When not needed anymore, this reference should be destroyed with + sd_bus_track_unref(). + + + + Errors + + Returned errors may indicate the following problems: + + + + + -EBUSY + + Bus peers have already been added to the bus peer tracking object and + sd_bus_track_set_recursive() was called to change tracking mode. + + + + + -EINVAL + + Specified parameter is invalid + (NULL in case of output + parameters). + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + + See Also + + + systemd1, + sd-bus3 + sd_bus_track_add_name3 + + + + diff --git a/man/sd_bus_wait.xml b/man/sd_bus_wait.xml new file mode 100644 index 0000000..5858be1 --- /dev/null +++ b/man/sd_bus_wait.xml @@ -0,0 +1,113 @@ + + + + + + + + + sd_bus_wait + systemd + + + + sd_bus_wait + 3 + + + + sd_bus_wait + + Wait for I/O on a bus connection + + + + + #include <systemd/sd-bus.h> + + + int sd_bus_wait + sd_bus *bus + uint64_t timeout_usec + + + + + + Description + + sd_bus_wait() synchronously waits for I/O on the specified bus connection object. This + function is supposed to be called whenever + sd_bus_process3 returns zero, + indicating that no work is pending on the connection. Internally, this call invokes ppoll2, to wait for I/O on + the bus connection. If the timeout_sec parameter is specified, the call will block at most + for the specified amount of time in µs. Pass UINT64_MAX to permit it to sleep + indefinitely. + + After each invocation of sd_bus_wait() the sd_bus_process() call + should be invoked in order to process any now pending I/O work. + + Note that sd_bus_wait() is suitable only for simple programs as it does not permit + waiting for other I/O events. For more complex programs either connect the bus connection object to an external + event loop using sd_bus_get_fd3 + or to an sd-event3 event loop + using + sd_bus_attach_event3. + + + + Return Value + + If any I/O was seen, a positive value is returned, zero otherwise. If an error occurs, a negative + errno-style error code is returned. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + An invalid bus object was passed. + + + + -ECHILD + + The bus connection was allocated in a parent process and is being reused in a child + process after fork(). + + + + -ENOTCONN + + The bus connection has been terminated already. + + + + + + + + + See Also + + + systemd1, + sd-bus3, + sd_bus_process3, + sd_bus_get_fd3, + sd-event3, + sd_bus_attach_event3 + + + + diff --git a/man/sd_device_get_syspath.xml b/man/sd_device_get_syspath.xml new file mode 100644 index 0000000..54cb87a --- /dev/null +++ b/man/sd_device_get_syspath.xml @@ -0,0 +1,200 @@ + + + + + + + + sd_device_get_syspath + systemd + + + + sd_device_get_syspath + 3 + + + + sd_device_get_syspath + sd_device_get_devpath + sd_device_get_sysname + sd_device_get_sysnum + sd_device_get_subsystem + sd_device_get_devtype + sd_device_get_devname + sd_device_get_devnum + sd_device_get_ifindex + sd_device_get_driver + sd_device_get_diskseq + + Returns various fields of device objects + + + + + #include <systemd/sd-device.h> + + + int sd_device_get_syspath + sd_device *device + const char **ret + + + + int sd_device_get_devpath + sd_device *device + const char **ret + + + + int sd_device_get_sysname + sd_device *device + const char **ret + + + + int sd_device_get_sysnum + sd_device *device + const char **ret + + + + int sd_device_get_subsystem + sd_device *device + const char **ret + + + + int sd_device_get_devtype + sd_device *device + const char **ret + + + + int sd_device_get_devname + sd_device *device + const char **ret + + + + int sd_device_get_devnum + sd_device *device + dev_t *ret + + + + int sd_device_get_ifindex + sd_device *device + int *ret + + + + int sd_device_get_driver + sd_device *device + const char **ret + + + + int sd_device_get_diskseq + sd_device *device + uint64_t *ret + + + + + + + Description + + sd_device_get_syspath() returns the sysfs path of the specified device record, + including the /sys prefix. Example: /sys/devices/virtual/tty/tty7 + + sd_device_get_devpath() returns the sysfs path of the specified device record, + excluding the /sys prefix. Example: /devices/virtual/tty/tty7 + + sd_device_get_sysname() returns the sysfs name of the specified device record, + i.e. the last component of the sysfs path. Example: tty7 for the device + /sys/devices/virtual/tty/tty7 + + sd_device_get_sysnum() returns the sysfs device number of the specified device + record, i.e. the numeric suffix of the last component of the sysfs path. Example: 7 + for the device /sys/devices/virtual/tty/tty7 + + sd_device_get_subsystem() returns the kernel subsystem of the specified device + record. This is a short string fitting into a filename, and thus does not contain a slash and cannot be + empty. Example: tty, block or net. + + sd_device_get_devtype() returns the device type of the specified device + record, if the subsystem manages multiple types of devices. Example: for devices of the + block subsystem this can be disk or partition + + + sd_device_get_devname() returns the device node path of the specified device + record if the device has a device node. Example: for /sys/devices/virtual/tty/tty7 + the string /dev/tty7 is typically returned. + + sd_device_get_devnum() returns the device node major/minor + (i.e. dev_t) of the specified device record if the device has a device node (i.e. the one + returned by sd_device_get_devname()). For devices belonging to the + block subsystem this refers to a block device node, in all other cases to a character + device node. Example: for the /sys/devices/virtual/tty/tty7 device this typically + returns the device number with major/minor 4:7. + + sd_device_get_ifindex() returns the network interface index of the specified + device record, if the device encapsulates a network interface device, i.e. belongs to the + net subsystem. Example: the lo interface typically has interface + index 1. + + sd_device_get_driver() returns the kernel driver name attached to the + device. Note that the driver field is set on the devices consumed by the driver, not on the device + created by it. Example: a PCI device /sys/bus/pci/devices/0000:00:1f.6 might be + attached to a driver e1000e. + + sd_device_get_diskseq() returns the kernel disk sequence number of the block + device. This number monotonically increases whenever a backing medium of a block device changes without + the device name changing, and is relevant for block devices encapsulating devices with changing media + (e.g. floppy or CD-ROM), or loopback block devices. Only defined for block devices, i.e. those of + subsystem block. + + + + Return Value + + On success, these calls return 0 or a positive integer. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + A specified parameter is invalid. + + + + -ENOENT + + The requested field is not present in the device record. + + + + + + + + + + See Also + + + systemd1 + + + + diff --git a/man/sd_device_ref.xml b/man/sd_device_ref.xml new file mode 100644 index 0000000..2b8512a --- /dev/null +++ b/man/sd_device_ref.xml @@ -0,0 +1,85 @@ + + + + + + + sd_device_ref + systemd + + + + sd_device_ref + 3 + + + + sd_device_ref + sd_device_unref + sd_device_unrefp + + Create or destroy references to a device object + + + + + #include <systemd/sd-device.h> + + + sd_device* sd_device_ref + sd_device *device + + + + sd_device* sd_device_unref + sd_device *device + + + + void sd_device_unrefp + sd_device **device + + + + sd_device_ref() increases the internal reference counter of + device by one. + + sd_device_unref() decreases the internal reference counter of + device by one. Once the reference count has dropped to zero, + device is destroyed and cannot be used anymore, so further calls to + sd_device_ref() or sd_device_unref() are illegal. + + sd_device_unrefp() is similar to sd_device_unref() but + takes a pointer to a pointer to an sd_device object. This call is useful in conjunction with + GCC's and LLVM's Clean-up + Variable Attribute. Note that this function is defined as an inline function. Use a declaration + like the following, in order to allocate a device object that is freed automatically as the code block is + left: + + { + __attribute__((cleanup(sd_device_unrefp))) sd_device *device = NULL; + int r; + … + r = sd_device_new_from_syspath(&device, "…"); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to allocate device: %m\n"); + } + … +} + + sd_device_ref() and sd_device_unref() execute no + operation if the argument is NULL. sd_device_unrefp() will + first dereference its argument, which must not be NULL, and will execute no + operation if that is NULL. + + + + Return Value + + sd_device_ref() always returns the argument, and + sd_device_unref() always returns NULL. + + + diff --git a/man/sd_event_add_child.xml b/man/sd_event_add_child.xml new file mode 100644 index 0000000..fec754d --- /dev/null +++ b/man/sd_event_add_child.xml @@ -0,0 +1,352 @@ + + + + + + + + sd_event_add_child + systemd + + + + sd_event_add_child + 3 + + + + sd_event_add_child + sd_event_add_child_pidfd + sd_event_source_get_child_pid + sd_event_source_get_child_pidfd + sd_event_source_get_child_pidfd_own + sd_event_source_set_child_pidfd_own + sd_event_source_get_child_process_own + sd_event_source_set_child_process_own + sd_event_source_send_child_signal + sd_event_child_handler_t + + Add a child process state change event source to an event loop + + + + + #include <systemd/sd-event.h> + + typedef struct sd_event_source sd_event_source; + + + typedef int (*sd_event_child_handler_t) + sd_event_source *s + const siginfo_t *si + void *userdata + + + + int sd_event_add_child + sd_event *event + sd_event_source **source + pid_t pid + int options + sd_event_child_handler_t handler + void *userdata + + + + int sd_event_add_child_pidfd + sd_event *event + sd_event_source **source + int pidfd + int options + sd_event_child_handler_t handler + void *userdata + + + + int sd_event_source_get_child_pid + sd_event_source *source + pid_t *pid + + + + int sd_event_source_get_child_pidfd + sd_event_source *source + + + + int sd_event_source_get_child_pidfd_own + sd_event_source *source + + + + int sd_event_source_set_child_pidfd_own + sd_event_source *source + int own + + + + int sd_event_source_get_child_process_own + sd_event_source *source + + + + int sd_event_source_set_child_process_own + sd_event_source *source + int own + + + + int sd_event_source_send_child_signal + sd_event_source *source + int sig + const siginfo_t *info + unsigned flags + + + + + + + Description + + sd_event_add_child() adds a new child process state change event source to an + event loop. The event loop object is specified in the event parameter, the event + source object is returned in the source parameter. The pid + parameter specifies the PID of the process to watch, which must be a direct child process of the invoking + process. The options parameter determines which state changes will be watched for. + It must contain an OR-ed mask of WEXITED (watch for the child process terminating), + WSTOPPED (watch for the child process being stopped by a signal), and + WCONTINUED (watch for the child process being resumed by a signal). See + waitid2 + for further information. + + The handler must be a function to call when the process changes state or + NULL. The handler function will be passed the userdata + pointer, which may be chosen freely by the caller. The handler also receives a pointer to a + siginfo_t structure containing information about the child process event. The + handler may return negative to signal an error (see below), other return values are ignored. If + handler is NULL, a default handler that calls + sd_event_exit3 will be + used. + + Only a single handler may be installed for a specific child process. The handler is enabled for a + single event (SD_EVENT_ONESHOT), but this may be changed with + sd_event_source_set_enabled3. + If the handler function returns a negative error code, it will either be disabled after the invocation, + even if the SD_EVENT_ON mode was requested before, or it will cause the loop to + terminate, see + sd_event_source_set_exit_on_failure3. + + + To destroy an event source object use + sd_event_source_unref3, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even when there's still a + reference to it kept, consider setting the event source to + SD_EVENT_OFF with + sd_event_source_set_enabled3. + + The SIGCHLD signal must be blocked in all threads before this function is + called (using sigprocmask2 or + pthread_sigmask3). + + If the second parameter of sd_event_add_child() is passed as + NULL no reference to the event source object is returned. In this case the event + source is considered "floating", and will be destroyed implicitly when the event loop itself is + destroyed. + + Note that the handler function is + invoked at a time where the child process is not reaped yet (and + thus still is exposed as a zombie process by the kernel). However, + the child will be reaped automatically after the function + returns. Child processes for which no child process state change + event sources are installed will not be reaped by the event loop + implementation. + + If the handler parameter to sd_event_add_child() is + NULL, and the event source fires, this will be considered a request to exit the + event loop. In this case, the userdata parameter, cast to an integer, is passed as + the exit code parameter to + sd_event_exit3. + + If both a child process state change event source and a + SIGCHLD signal event source is installed in + the same event loop, the configured event source priorities decide + which event source is dispatched first. If the signal handler is + processed first, it should leave the child processes for which + child process state change event sources are installed unreaped. + + sd_event_add_child_pidfd() is similar to + sd_event_add_child() but takes a file descriptor referencing the process ("pidfd") + instead of the numeric PID. A suitable file descriptor may be acquired via pidfd_open2 and + related calls. The passed file descriptor is not closed when the event source is freed again, unless + sd_event_source_set_child_pidfd_own() is used to turn this behaviour on. Note that + regardless which of sd_event_add_child() and + sd_event_add_child_pidfd() is used for allocating an event source, the watched + process has to be a direct child process of the invoking process. Also in both cases + SIGCHLD has to be blocked in the invoking process. + + sd_event_source_get_child_pid() + retrieves the configured PID of a child process state change event + source created previously with + sd_event_add_child(). It takes the event + source object as the source parameter and a + pointer to a pid_t variable to return the process ID + in. + + + sd_event_source_get_child_pidfd() retrieves the file descriptor referencing + the watched process ("pidfd") if this functionality is available. On kernels that support the concept the + event loop will make use of pidfds to watch child processes, regardless if the individual event sources + are allocated via sd_event_add_child() or + sd_event_add_child_pidfd(). If the latter call was used to allocate the event + source, this function returns the file descriptor used for allocation. On kernels that do not support the + pidfd concept this function will fail with EOPNOTSUPP. This call takes the event + source object as the source parameter and returns the numeric file descriptor. + + + sd_event_source_get_child_pidfd_own() may be used to query whether the pidfd + the event source encapsulates shall be closed when the event source is freed. This function returns zero + if the pidfd shall be left open, and positive if it shall be closed automatically. By default this + setting defaults to on if the event source was allocated via sd_event_add_child() + and off if it was allocated via sd_event_add_child_pidfd(). The + sd_event_source_set_child_pidfd_own() function may be used to change the setting and + takes a boolean parameter with the new setting. + + sd_event_source_get_child_process_own() may be used to query whether the + process the event source watches shall be killed (with SIGKILL) and reaped when the + event source is freed. This function returns zero if the process shell be left running, and positive if + it shall be killed and reaped automatically. By default this setting defaults to off. The + sd_event_source_set_child_process_own() function may be used to change the setting + and takes a boolean parameter with the new setting. Note that currently if the calling process is + terminated abnormally the watched process might survive even thought the event source ceases to + exist. This behaviour might change eventually. + + sd_event_source_send_child_signal() may be used to send a UNIX signal to the + watched process. If the pidfd concept is supported in the kernel, this is implemented via pidfd_send_signal2 + and otherwise via rt_sigqueueinfo2 + (or via kill2 in case + info is NULL). The specified parameters match those of these + underlying system calls, except that the info is never modified (and is thus + declared constant). Like for the underlying system calls, the flags parameter + currently must be zero. + + + + Return Value + + On success, these functions return 0 or a positive + integer. On failure, they return a negative errno-style error + code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ENOMEM + + Not enough memory to allocate an object. + + + + -EINVAL + + An invalid argument has been passed. This includes + specifying an empty mask in options or a mask + which contains values different than a combination of + WEXITED, WSTOPPED, and + WCONTINUED. + + + + + + -EBUSY + + A handler is already installed for this child process, or + SIGCHLD is not blocked. + + + + + -ESTALE + + The event loop is already terminated. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + + -EDOM + + The passed event source is not a child process event source. + + + + -EOPNOTSUPP + + A pidfd was requested but the kernel does not support this concept. + + + + + + + + + + Example + + + Exit loop when the child terminates + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_now3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_enabled3, + sd_event_source_set_priority3, + sd_event_source_set_userdata3, + sd_event_source_set_description3, + sd_event_source_set_floating3, + waitid2, + sigprocmask2, + pthread_sigmask3, + pidfd_open2, + pidfd_send_signal2, + rt_sigqueueinfo2, + kill2 + + + + diff --git a/man/sd_event_add_defer.xml b/man/sd_event_add_defer.xml new file mode 100644 index 0000000..e56e16a --- /dev/null +++ b/man/sd_event_add_defer.xml @@ -0,0 +1,202 @@ + + + + + + + + sd_event_add_defer + systemd + + + + sd_event_add_defer + 3 + + + + sd_event_add_defer + sd_event_add_post + sd_event_add_exit + sd_event_handler_t + + Add static event sources to an event loop + + + + + #include <systemd/sd-event.h> + + typedef struct sd_event_source sd_event_source; + + + typedef int (*sd_event_handler_t) + sd_event_source *s + void *userdata + + + + int sd_event_add_defer + sd_event *event + sd_event_source **source + sd_event_handler_t handler + void *userdata + + + + int sd_event_add_post + sd_event *event + sd_event_source **source + sd_event_handler_t handler + void *userdata + + + + int sd_event_add_exit + sd_event *event + sd_event_source **source + sd_event_handler_t handler + void *userdata + + + + + + + Description + + These three functions add new static event sources to an event loop. The event loop object is + specified in the event parameter, the event source object is returned in the + source parameter. The event sources are enabled statically and will "fire" when + the event loop is run and the conditions described below are met. + + The handler is a function to call or NULL. The handler + function will be passed the userdata pointer, which may be chosen freely by the + caller. The handler may return negative to signal an error (see below), other return values are + ignored. If handler is NULL, a default handler that calls + sd_event_exit3 will be + used. + + sd_event_add_defer() adds a new event + source that will be dispatched instantly, before the event loop + goes to sleep again and waits for new events. By default, the + handler will be called once + (SD_EVENT_ONESHOT). Note that if the event + source is set to SD_EVENT_ON the event loop + will never go to sleep again, but continuously call the handler, + possibly interleaved with other event sources. + + sd_event_add_post() adds a new event + source that is run before the event loop will sleep and wait + for new events, but only after at least one other non-post event + source was dispatched. By default, the source is enabled + permanently (SD_EVENT_ON). Note that this + event source type will still allow the event loop to go to sleep + again, even if set to SD_EVENT_ON, as long as + no other event source is ever triggered. + + sd_event_add_exit() adds a new event + source that will be dispatched when the event loop is terminated + with sd_event_exit3. + + The + sd_event_source_set_enabled3 + function may be used to enable the event source permanently + (SD_EVENT_ON) or to make it fire just once + (SD_EVENT_ONESHOT). + + If the handler function returns a negative error code, it will either be disabled after the + invocation, even if the SD_EVENT_ON mode was requested before, or it will cause the + loop to terminate, see + sd_event_source_set_exit_on_failure3. + + + To destroy an event source object use + sd_event_source_unref3, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even when there's still a + reference to it kept, consider setting the event source to + SD_EVENT_OFF with + sd_event_source_set_enabled3. + + If the second parameter of these functions is passed as NULL no reference to + the event source object is returned. In this case the event source is considered "floating", and will be + destroyed implicitly when the event loop itself is destroyed. + + If the handler parameter to sd_event_add_defer() or + sd_event_add_post() is NULL, and the event source fires, this + will be considered a request to exit the event loop. In this case, the userdata + parameter, cast to an integer, is passed as the exit code parameter to + sd_event_exit3. Similar + functionality is not available for sd_event_add_exit(), as these types of event + sources are only dispatched when exiting anyway. + + + + Return Value + + On success, these functions return 0 or a positive + integer. On failure, they return a negative errno-style error + code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ENOMEM + + Not enough memory to allocate an object. + + + + -EINVAL + + An invalid argument has been passed. + + + + -ESTALE + + The event loop is already terminated. + + + + -ECHILD + + The event loop has been created in a different process. + + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_now3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_source_set_enabled3, + sd_event_source_set_priority3, + sd_event_source_set_userdata3, + sd_event_source_set_description3, + sd_event_source_set_floating3, + sd_event_exit3 + + + + diff --git a/man/sd_event_add_inotify.xml b/man/sd_event_add_inotify.xml new file mode 100644 index 0000000..c7af7bd --- /dev/null +++ b/man/sd_event_add_inotify.xml @@ -0,0 +1,234 @@ + + + + + + + + sd_event_add_inotify + systemd + + + + sd_event_add_inotify + 3 + + + + sd_event_add_inotify + sd_event_add_inotify_fd + sd_event_source_get_inotify_mask + sd_event_inotify_handler_t + + Add an "inotify" file system inode event source to an event loop + + + + + #include <systemd/sd-event.h> + + typedef struct sd_event_source sd_event_source; + + + typedef int (*sd_event_inotify_handler_t) + sd_event_source *s + const struct inotify_event *event + void *userdata + + + + int sd_event_add_inotify + sd_event *event + sd_event_source **source + const char *path + uint32_t mask + sd_event_inotify_handler_t handler + void *userdata + + + + int sd_event_add_inotify_fd + sd_event *event + sd_event_source **source + int fd + uint32_t mask + sd_event_inotify_handler_t handler + void *userdata + + + + int sd_event_source_get_inotify_mask + sd_event_source *source + uint32_t *mask + + + + + + + Description + + sd_event_add_inotify() adds a new inotify7 file + system inode event source to an event loop. The event loop object is specified in the + event parameter, the event source object is returned in the + source parameter. The path parameter specifies the path of + the file system inode to watch. The mask parameter specifies which types of inode + events to watch specifically. It must contain an OR-ed combination of IN_ACCESS, + IN_ATTRIB, IN_CLOSE_WRITE, … flags. See inotify7 for + further information. + + The handler must reference a function to call when the inode changes or + NULL. The handler function will be passed the userdata pointer, + which may be chosen freely by the caller. The handler also receives a pointer to a struct + inotify_event structure containing information about the inode event. The handler may return + negative to signal an error (see below), other return values are ignored. If + handler is NULL, a default handler that calls + sd_event_exit3 will be + used. + + sd_event_add_inotify_fd() is identical to + sd_event_add_inotify(), except that it takes a file descriptor to an inode (possibly + an O_PATH one, but any other will do too) instead of a path in the file system. + + + If multiple event sources are installed for the same inode the backing inotify watch descriptor is + automatically shared. The mask parameter may contain any flag defined by the inotify API, with the exception of + IN_MASK_ADD. + + The handler is enabled continuously (SD_EVENT_ON), but this may be changed with + sd_event_source_set_enabled3. + Alternatively, the IN_ONESHOT mask flag may be used to request + SD_EVENT_ONESHOT mode. If the handler function returns a negative error code, it + will be disabled after the invocation, even if the SD_EVENT_ON mode was requested + before. + + As a special limitation the priority of inotify event sources may only be altered (see + sd_event_source_set_priority3) + in the time between creation of the event source object with sd_event_add_inotify() and the + beginning of the next event loop iteration. Attempts of changing the priority any later will be refused. Consider + freeing and allocating a new inotify event source to change the priority at that point. + + To destroy an event source object use + sd_event_source_unref3, but note + that the event source is only removed from the event loop when all references to the event source are dropped. To + make sure an event source does not fire anymore, even when there's still a reference to it kept, consider disabling + it with + sd_event_source_set_enabled3. + + If the second parameter of sd_event_add_inotify() is passed as + NULL no reference to the event source object is returned. In this case the event + source is considered "floating", and will be destroyed implicitly when the event loop itself is + destroyed. + + If the handler parameter to sd_event_add_inotify() is + NULL, and the event source fires, this will be considered a request to exit the + event loop. In this case, the userdata parameter, cast to an integer, is passed as + the exit code parameter to + sd_event_exit3. + + sd_event_source_get_inotify_mask() retrieves the configured inotify watch mask of an + event source created previously with sd_event_add_inotify(). It takes the event source object + as the source parameter and a pointer to a uint32_t variable to return the mask + in. + + + + Return Value + + On success, these functions return 0 or a positive integer. On failure, they return a negative errno-style + error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ENOMEM + + Not enough memory to allocate an object. + + + + -EINVAL + + An invalid argument has been passed. This includes specifying a mask with + IN_MASK_ADD set. + + + + -ESTALE + + The event loop is already terminated. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + + -EDOM + + The passed event source is not an inotify process event source. + + + + -EBADF + + The passed file descriptor is not valid. + + + + -ENOSYS + + sd_event_add_inotify_fd() was called without + /proc/ mounted. + + + + + + + + Examples + + + A simple program that uses inotify to monitor one or two directories + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_now3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_defer3, + sd_event_add_child3, + sd_event_source_set_enabled3, + sd_event_source_set_priority3, + sd_event_source_set_userdata3, + sd_event_source_set_description3, + sd_event_source_set_floating3, + waitid2 + + + + diff --git a/man/sd_event_add_io.xml b/man/sd_event_add_io.xml new file mode 100644 index 0000000..383a58a --- /dev/null +++ b/man/sd_event_add_io.xml @@ -0,0 +1,311 @@ + + + + + + + + sd_event_add_io + systemd + + + + sd_event_add_io + 3 + + + + sd_event_add_io + sd_event_source_get_io_events + sd_event_source_set_io_events + sd_event_source_get_io_revents + sd_event_source_get_io_fd + sd_event_source_set_io_fd + sd_event_source_get_io_fd_own + sd_event_source_set_io_fd_own + sd_event_source + sd_event_io_handler_t + + Add an I/O event source to an event loop + + + + + #include <systemd/sd-event.h> + + typedef struct sd_event_source sd_event_source; + + + typedef int (*sd_event_io_handler_t) + sd_event_source *s + int fd + uint32_t revents + void *userdata + + + + int sd_event_add_io + sd_event *event + sd_event_source **source + int fd + uint32_t events + sd_event_io_handler_t handler + void *userdata + + + + int sd_event_source_get_io_events + sd_event_source *source + uint32_t *events + + + + int sd_event_source_set_io_events + sd_event_source *source + uint32_t events + + + + int sd_event_source_get_io_revents + sd_event_source *source + uint32_t *revents + + + + int sd_event_source_get_io_fd + sd_event_source *source + + + + int sd_event_source_set_io_fd + sd_event_source *source + int fd + + + + int sd_event_source_get_io_fd_own + sd_event_source *source + + + + int sd_event_source_set_io_fd_own + sd_event_source *source + int b + + + + + + + Description + + sd_event_add_io() adds a new I/O event + source to an event loop. The event loop object is specified in the + event parameter, the event source object is + returned in the source parameter. The + fd parameter takes the UNIX file descriptor + to watch, which may refer to a socket, a FIFO, a message queue, a + serial connection, a character device, or any other file descriptor + compatible with Linux + epoll7. The + events parameter takes a bit mask of events + to watch for, a combination of the following event flags: + EPOLLIN, EPOLLOUT, + EPOLLRDHUP, EPOLLPRI, + and EPOLLET, see + epoll_ctl2 + for details. + + The handler is a function to call when the event source is triggered or + NULL. The userdata pointer will be passed to the handler + function, and may be chosen freely by the caller. The handler will also be passed the file descriptor the + event was seen on, as well as the actual event flags. It's generally a subset of the events watched, + however may additionally include EPOLLERR and EPOLLHUP. The + handler may return negative to signal an error (see below), other return values are ignored. If + handler is NULL, a default handler that calls + sd_event_exit3 will be + used. + + By default, an event source will stay enabled continuously (SD_EVENT_ON), but + this may be changed with + sd_event_source_set_enabled3. + If the handler function returns a negative error code, it will either be disabled after the invocation, + even if the SD_EVENT_ON mode was requested before, or it will cause the loop to + terminate, see + sd_event_source_set_exit_on_failure3. + Note that an event source set to SD_EVENT_ON will fire continuously unless data is + read from or written to the file descriptor to reset the mask of events seen. + + Setting the I/O event mask to watch for to 0 does not mean + that the event source won't be triggered anymore, as + EPOLLHUP and EPOLLERR + may be triggered even with a zero event mask. To temporarily + disable an I/O event source use + sd_event_source_set_enabled3 + with SD_EVENT_OFF instead. + + To destroy an event source object use + sd_event_source_unref3, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even if it is still referenced, + disable the event source using + sd_event_source_set_enabled3 + with SD_EVENT_OFF. + + If the second parameter of + sd_event_add_io() is + NULL no reference to the event source object + is returned. In this case the event source is considered + "floating", and will be destroyed implicitly when the event loop + itself is destroyed. + + If the handler to sd_event_add_io() is + NULL, and the event source fires, this will be considered a request to exit the + event loop. In this case, the userdata parameter, cast to an integer, is passed as + the exit code parameter to + sd_event_exit3. + + Note that this call does not take possession of the file descriptor passed in, ownership (and thus + the duty to close it when it is no longer needed) remains with the caller. However, with the + sd_event_source_set_io_fd_own() call (see below) the event source may optionally + take ownership of the file descriptor after the event source has been created. In that case the file + descriptor is closed automatically as soon as the event source is released. + + It is recommended to use + sd_event_add_io() only in conjunction with + file descriptors that have O_NONBLOCK set, to + ensure that all I/O operations from invoked handlers are properly + asynchronous and non-blocking. Using file descriptors without + O_NONBLOCK might result in unexpected + starvation of other event sources. See + fcntl2 + for details on enabling O_NONBLOCK mode. + + sd_event_source_get_io_events() retrieves + the configured mask of watched I/O events of an event source created + previously with sd_event_add_io(). It takes + the event source object and a pointer to a variable to store the + mask in. + + sd_event_source_set_io_events() + configures the mask of watched I/O events of an event source created + previously with sd_event_add_io(). It takes the + event source object and the new event mask. + + sd_event_source_get_io_revents() + retrieves the I/O event mask of currently seen but undispatched + events from an event source created previously with + sd_event_add_io(). It takes the event source + object and a pointer to a variable to store the event mask + in. When called from a handler function on the handler's event + source object this will return the same mask as passed to the + handler's revents parameter. This call is + primarily useful to check for undispatched events of an event + source from the handler of an unrelated (possibly higher priority) + event source. Note the relation between + sd_event_source_get_pending() and + sd_event_source_get_io_revents(): both + functions will report non-zero results when there's an event + pending for the event source, but the former applies to all event + source types, the latter only to I/O event sources. + + sd_event_source_get_io_fd() retrieves + the UNIX file descriptor of an event source created previously + with sd_event_add_io(). It takes the event + source object and returns the non-negative file descriptor + or a negative error number on error (see below). + + sd_event_source_set_io_fd() + changes the UNIX file descriptor of an I/O event source created + previously with sd_event_add_io(). It takes + the event source object and the new file descriptor. + + sd_event_source_set_io_fd_own() controls whether the file descriptor of the event source + shall be closed automatically when the event source is freed, i.e. whether it shall be considered 'owned' by the + event source object. By default it is not closed automatically, and the application has to do this on its own. The + b parameter is a boolean parameter: if zero, the file descriptor is not closed automatically + when the event source is freed, otherwise it is closed. + + sd_event_source_get_io_fd_own() may be used to query the current setting of the file + descriptor ownership boolean flag as set with sd_event_source_set_io_fd_own(). It returns + positive if the file descriptor is closed automatically when the event source is destroyed, zero if not, and + negative on error. + + + + Return Value + + On success, these functions return 0 or a positive + integer. On failure, they return a negative errno-style error + code. + + + Errors + + Returned values may indicate the following problems: + + + + -ENOMEM + + Not enough memory to allocate an object. + + + + -EINVAL + + An invalid argument has been passed. + + + + + -ESTALE + + The event loop is already terminated. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + -EDOM + + The passed event source is not an I/O event source. + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_now3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_enabled3, + sd_event_source_set_priority3, + sd_event_source_set_userdata3, + sd_event_source_set_description3, + sd_event_source_get_pending3, + sd_event_source_set_floating3, + epoll_ctl2, + epoll7 + + + + diff --git a/man/sd_event_add_signal.xml b/man/sd_event_add_signal.xml new file mode 100644 index 0000000..3e8536e --- /dev/null +++ b/man/sd_event_add_signal.xml @@ -0,0 +1,207 @@ + + + + + + + + sd_event_add_signal + systemd + + + + sd_event_add_signal + 3 + + + + sd_event_add_signal + sd_event_source_get_signal + sd_event_signal_handler_t + SD_EVENT_SIGNAL_PROCMASK + + Add a UNIX process signal event source to an event + loop + + + + + #include <systemd/sd-event.h> + + typedef struct sd_event_source sd_event_source; + + SD_EVENT_SIGNAL_PROCMASK + + + typedef int (*sd_event_signal_handler_t) + sd_event_source *s + const struct signalfd_siginfo *si + void *userdata + + + + int sd_event_add_signal + sd_event *event + sd_event_source **source + int signal + sd_event_signal_handler_t handler + void *userdata + + + + int sd_event_source_get_signal + sd_event_source *source + + + + + + Description + + sd_event_add_signal() adds a new UNIX process signal event source to an event + loop. The event loop object is specified in the event parameter, and the event + source object is returned in the source parameter. The + signal parameter specifies the numeric signal to be handled (see signal7). + + The handler parameter is a function to call when the signal is received or + NULL. The handler function will be passed the userdata + pointer, which may be chosen freely by the caller. The handler also receives a pointer to a + signalfd_siginfo structure containing information about the received signal. See + signalfd2 for + further information. The handler may return negative to signal an error (see below), other return values + are ignored. If handler is NULL, a default handler that calls + sd_event_exit3 will be + used. + + Only a single handler may be installed for a specific signal. The signal must be blocked in all + threads before this function is called (using sigprocmask2 or + pthread_sigmask3). For + convenience, if the special flag SD_EVENT_SIGNAL_PROCMASK is ORed into the specified + signal the signal will be automatically masked as necessary, for the calling thread. Note that this only + works reliably if the signal is already masked in all other threads of the process, or if there are no + other threads at the moment of invocation. + + By default, the event source is enabled permanently (SD_EVENT_ON), but this + may be changed with + sd_event_source_set_enabled3. + If the handler function returns a negative error code, it will either be disabled after the invocation, + even if the SD_EVENT_ON mode was requested before, or it will cause the loop to + terminate, see + sd_event_source_set_exit_on_failure3. + + + To destroy an event source object use + sd_event_source_unref3, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even if it is still referenced, + disable the event source using + sd_event_source_set_enabled3 + with SD_EVENT_OFF. + + If the second parameter of + sd_event_add_signal() is + NULL no reference to the event source object + is returned. In this case the event source is considered + "floating", and will be destroyed implicitly when the event loop + itself is destroyed. + + If the handler parameter to sd_event_add_signal() is + NULL, and the event source fires, this will be considered a request to exit the + event loop. In this case, the userdata parameter, cast to an integer, is passed as + the exit code parameter to + sd_event_exit3. + + sd_event_source_get_signal() returns + the configured signal number of an event source created previously + with sd_event_add_signal(). It takes the + event source object as the source + parameter. + + + + Return Value + + On success, these functions return 0 or a positive + integer. On failure, they return a negative errno-style error + code. + + + Errors + + Returned errors may indicate the following problems: + + + + -ENOMEM + + Not enough memory to allocate an object. + + + + -EINVAL + + An invalid argument has been passed. + + + + -EBUSY + + A handler is already installed for this + signal or the signal was not blocked previously. + + + + -ESTALE + + The event loop is already terminated. + + + + -ECHILD + + The event loop has been created in a different process. + + + + -EDOM + + The passed event source is not a signal event source. + + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_now3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_enabled3, + sd_event_source_set_description3, + sd_event_source_set_userdata3, + sd_event_source_set_floating3, + signal7, + signalfd2, + sigprocmask2, + pthread_sigmask3 + + + + diff --git a/man/sd_event_add_time.xml b/man/sd_event_add_time.xml new file mode 100644 index 0000000..19f112b --- /dev/null +++ b/man/sd_event_add_time.xml @@ -0,0 +1,326 @@ + + + + + + + + sd_event_add_time + systemd + + + + sd_event_add_time + 3 + + + + sd_event_add_time + sd_event_add_time_relative + sd_event_source_get_time + sd_event_source_set_time + sd_event_source_set_time_relative + sd_event_source_get_time_accuracy + sd_event_source_set_time_accuracy + sd_event_source_get_time_clock + sd_event_time_handler_t + + Add a timer event source to an event loop + + + + + #include <systemd/sd-event.h> + + typedef struct sd_event_source sd_event_source; + + + typedef int (*sd_event_time_handler_t) + sd_event_source *s + uint64_t usec + void *userdata + + + + int sd_event_add_time + sd_event *event + sd_event_source **source + clockid_t clock + uint64_t usec + uint64_t accuracy + sd_event_time_handler_t handler + void *userdata + + + + int sd_event_add_time_relative + sd_event *event + sd_event_source **source + clockid_t clock + uint64_t usec + uint64_t accuracy + sd_event_time_handler_t handler + void *userdata + + + + int sd_event_source_get_time + sd_event_source *source + uint64_t *usec + + + + int sd_event_source_set_time + sd_event_source *source + uint64_t usec + + + + int sd_event_source_set_time_relative + sd_event_source *source + uint64_t usec + + + + int sd_event_source_get_time_accuracy + sd_event_source *source + uint64_t *usec + + + + int sd_event_source_set_time_accuracy + sd_event_source *source + uint64_t usec + + + + int sd_event_source_get_time_clock + sd_event_source *source + clockid_t *clock + + + + + + + Description + + sd_event_add_time() adds a new timer event source to an event loop. The event loop + object is specified in the event parameter, the event source object is returned in the + source parameter. The clock parameter takes a clock identifier, one + of CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_BOOTTIME, + CLOCK_REALTIME_ALARM, or CLOCK_BOOTTIME_ALARM. See + timerfd_create2 for details + regarding the various types of clocks. The usec parameter specifies the earliest time, in + microseconds (µs), relative to the clock's epoch, when the timer shall be triggered. If a time already in the past + is specified (including 0), this timer source "fires" immediately and is ready to be + dispatched. If the parameter is specified as UINT64_MAX the timer event will never elapse, + which may be used as an alternative to explicitly disabling a timer event source with + sd_event_source_set_enabled3. The + accuracy parameter specifies an additional accuracy value in µs specifying how much the + timer event may be delayed. Use 0 to select the default accuracy (250ms). Use 1µs for maximum + accuracy. Consider specifying 60000000µs (1min) or larger for long-running events that may be delayed + substantially. Picking higher accuracy values allows the system to coalesce timer events more aggressively, + improving power efficiency. + + The handler is a function to call when the timer elapses or + NULL. The userdata pointer will be passed to the handler + function, and may be chosen freely by the caller. The configured trigger time is also passed to the + handler, even if the call actually happens slightly later, subject to the specified accuracy value, the + kernel timer slack (see + prctl2), and + additional scheduling latencies. To query the actual time the handler was called use + sd_event_now3. The + handler may return negative to signal an error (see below), other return values are ignored. If + handler is NULL, a default handler that calls + sd_event_exit3 will be + used. + + By default, the timer will elapse once (SD_EVENT_ONESHOT), but this may be + changed with + sd_event_source_set_enabled3. + If the handler function returns a negative error code, it will either be disabled after the invocation, + even if the SD_EVENT_ON mode was requested before, or it will cause the loop to + terminate, see + sd_event_source_set_exit_on_failure3. + Note that a timer event set to SD_EVENT_ON will fire continuously unless its + configured time is updated using sd_event_source_set_time(). + + sd_event_add_time_relative() is like sd_event_add_time(), + but takes a relative time specification. It's relative to the current time of the event loop iteration, + as returned by + sd_event_now3. + + To destroy an event source object use + sd_event_source_unref3, + but note that the event source is only removed from the event loop + when all references to the event source are dropped. To make sure + an event source does not fire anymore, even if it is still referenced, + disable the event source using + sd_event_source_set_enabled3 + with SD_EVENT_OFF. + + If the second parameter of + sd_event_add_time() is + NULL no reference to the event source object + is returned. In this case the event source is considered + "floating", and will be destroyed implicitly when the event loop + itself is destroyed. + + If the handler parameter to sd_event_add_time() is + NULL, and the event source fires, this will be considered a request to exit the + event loop. In this case, the userdata parameter, cast to an integer, is passed as + the exit code parameter to + sd_event_exit3. + + Use CLOCK_BOOTTIME_ALARM and + CLOCK_REALTIME_ALARM to define event sources + that may wake up the system from suspend. + + In order to set up relative timers (that is, relative to the + current time), retrieve the current time via + sd_event_now3, + add the desired timespan to it, and use the result as + the usec parameter to + sd_event_add_time(). + + In order to set up repetitive timers (that is, timers that + are triggered in regular intervals), set up the timer normally, + for the first invocation. Each time the event handler is invoked, + update the timer's trigger time with + sd_event_source_set_time3 for the next timer + iteration, and reenable the timer using + sd_event_source_set_enabled(). To calculate + the next point in time to pass to + sd_event_source_set_time(), either use as + base the usec parameter passed to the timer + callback, or the timestamp returned by + sd_event_now(). In the former case timer + events will be regular, while in the latter case the scheduling + latency will keep accumulating on the timer. + + sd_event_source_get_time() retrieves the configured time value of an event + source created previously with sd_event_add_time() or + sd_event_add_time_relative(). It takes the event source object and a pointer to a + variable to store the time in, relative to the selected clock's epoch, in µs. The returned value is + relative to the epoch, even if the event source was created with a relative time via + sd_event_add_time_relative(). + + sd_event_source_set_time() changes the time of an event source created + previously with sd_event_add_time() or + sd_event_add_time_relative(). It takes the event source object and a time relative + to the selected clock's epoch, in µs. + + sd_event_source_set_time_relative() is similar to + sd_event_source_set_time(), but takes a time relative to the current time of the + event loop iteration, as returned by sd_event_now(). + + sd_event_source_get_time_accuracy() + retrieves the configured accuracy value of an event source + created previously with sd_event_add_time(). It + takes the event source object and a pointer to a variable to store + the accuracy in. The accuracy is specified in µs. + + sd_event_source_set_time_accuracy() + changes the configured accuracy of a timer event source created + previously with sd_event_add_time(). It takes + the event source object and accuracy, in µs. + + sd_event_source_get_time_clock() + retrieves the configured clock of an event source created + previously with sd_event_add_time(). It takes + the event source object and a pointer to a variable to store the + clock identifier in. + + + + Return Value + + On success, these functions return 0 or a positive + integer. On failure, they return a negative errno-style error + code. + + + Errors + + Returned values may indicate the following problems: + + + + -ENOMEM + + Not enough memory to allocate an object. + + + + -EINVAL + + An invalid argument has been passed. + + + + + -ESTALE + + The event loop is already terminated. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + + -EOPNOTSUPP + + The selected clock is not supported by the event loop implementation. + + + + + -EDOM + + The passed event source is not a timer event source. + + + + -EOVERFLOW + + The passed relative time is outside of the allowed range for time values (i.e. the + specified value added to the current time is outside the 64 bit unsigned integer range). + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_now3, + sd_event_add_io3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_enabled3, + sd_event_source_set_priority3, + sd_event_source_set_userdata3, + sd_event_source_set_description3, + sd_event_source_set_floating3, + clock_gettime2, + timerfd_create2, + prctl2 + + + + diff --git a/man/sd_event_exit.xml b/man/sd_event_exit.xml new file mode 100644 index 0000000..e13cbe1 --- /dev/null +++ b/man/sd_event_exit.xml @@ -0,0 +1,150 @@ + + + + + + + + sd_event_exit + systemd + + + + sd_event_exit + 3 + + + + sd_event_exit + sd_event_get_exit_code + + Ask the event loop to exit + + + + + #include <systemd/sd-event.h> + + + int sd_event_exit + sd_event *event + int code + + + + int sd_event_get_exit_code + sd_event *event + int *code + + + + + + + Description + + sd_event_exit() requests the event loop + specified in the event event loop object to + exit. The code parameter may be any integer + value and is returned as-is by + sd_event_loop3 + after the last event loop iteration. It may also be queried + using sd_event_get_exit_code(), see + below. + + When exiting is requested the event loop will stop listening + for and dispatching regular event sources. Instead it will proceed + with executing only event sources registered with + sd_event_add_exit3 + in the order defined by their priority. After all exit event + sources have been dispatched the event loop is terminated. + + If sd_event_exit() is invoked a second + time while the event loop is still processing exit event sources, + the exit code stored in the event loop object is updated, but + otherwise no further operation is executed. + + sd_event_get_exit_code() may be used to + query the exit code passed into + sd_event_exit() earlier. + + While the full positive and negative integer ranges may be used + for the exit code, care should be taken not pick exit codes that + conflict with regular exit codes returned by + sd_event_loop(), if these exit codes shall be + distinguishable. + + Note that for most event source types passing the callback pointer as NULL in + the respective constructor call (i.e. in + sd_event_add_time3, + sd_event_add_signal3, + …) has the effect of sd_event_exit() being invoked once the event source triggers, + with the specified userdata pointer cast to an integer as the exit code parameter. This is useful to + automatically terminate an event loop after some condition, such as a time-out or reception of + SIGTERM or similar. See the documentation for the respective constructor call for + details. + + + + Return Value + + On success, sd_event_exit() and sd_event_get_exit_code() + return 0 or a positive integer. On failure, they return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -EINVAL + + The event loop object or error code pointer are invalid. + + + + + -ECHILD + + The event loop was created in a different process. + + + + -ESTALE + + The event loop has exited already and all exit handlers are already processed. + + + + + -ENODATA + + The event loop has not been requested to exit yet. + + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_add_exit3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_io3, + sd_event_add_defer3, + sd_event_add_inotify3 + + + + diff --git a/man/sd_event_get_fd.xml b/man/sd_event_get_fd.xml new file mode 100644 index 0000000..a3b11e4 --- /dev/null +++ b/man/sd_event_get_fd.xml @@ -0,0 +1,111 @@ + + + + + + + + sd_event_get_fd + systemd + + + + sd_event_get_fd + 3 + + + + sd_event_get_fd + + Obtain a file descriptor to poll for event loop events + + + + + #include <systemd/sd-event.h> + + + int sd_event_get_fd + sd_event *event + + + + + + + Description + + sd_event_get_fd() returns the file + descriptor that an event loop object returned by the + sd_event_new3 + function uses to wait for events. This file descriptor may itself + be polled for + POLLIN/EPOLLIN + events. This makes it possible to embed an + sd-event3 + event loop into another, possibly foreign, event loop. + + The returned file descriptor refers to an epoll7 + object. It is recommended not to alter it by invoking + epoll_ctl2 + on it, in order to avoid interference with the event loop's inner + logic and assumptions. + + + + Return Value + + On success, sd_event_get_fd() returns a non-negative file descriptor. On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + event is not a valid pointer to an + sd_event structure. + + + + -ECHILD + + The event loop has been created in a different process. + + + + + + + + Examples + + + Integration in the GLib event loop + + + + + + + + + See Also + + + sd-event3, + sd_event_new3, + sd_event_wait3, + epoll_ctl2, + epoll7 + + + + diff --git a/man/sd_event_new.xml b/man/sd_event_new.xml new file mode 100644 index 0000000..8a105a7 --- /dev/null +++ b/man/sd_event_new.xml @@ -0,0 +1,218 @@ + + + + + + + + sd_event_new + systemd + + + + sd_event_new + 3 + + + + sd_event_new + sd_event_default + sd_event_ref + sd_event_unref + sd_event_unrefp + sd_event_get_tid + sd_event + + Acquire and release an event loop object + + + + + #include <systemd/sd-event.h> + + typedef struct sd_event sd_event; + + + int sd_event_new + sd_event **event + + + + int sd_event_default + sd_event **event + + + + sd_event *sd_event_ref + sd_event *event + + + + sd_event *sd_event_unref + sd_event *event + + + + void sd_event_unrefp + sd_event **event + + + + int sd_event_get_tid + sd_event *event + pid_t *tid + + + + + + + Description + + sd_event_new() allocates a new event + loop object. The event loop object is returned in the + event parameter. After use, drop + the returned reference with + sd_event_unref(). When the last reference is + dropped, the object is freed. + + sd_event_default() acquires a reference + to the default event loop object of the calling thread, possibly + allocating a new object if no default event loop object has been + allocated yet for the thread. After use, drop the returned + reference with sd_event_unref(). When the + last reference is dropped, the event loop is freed. If this + function is called while the object returned from a previous call + from the same thread is still referenced, the same object is + returned again, but the reference is increased by one. It is + recommended to use this call instead of + sd_event_new() in order to share event loop + objects between various components that are dispatched in the same + thread. All threads have exactly either zero or one default event loop + objects associated, but never more. + + After allocating an event loop object, add event sources to + it with + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_add_post3 or + sd_event_add_exit3, + and then execute the event loop using + sd_event_loop3. + + sd_event_ref() increases the reference + count of the specified event loop object by one. + + sd_event_unref() decreases the + reference count of the specified event loop object by one. If + the count hits zero, the object is freed. Note that it + is freed regardless of whether it is the default event loop object for a + thread or not. This means that allocating an event loop with + sd_event_default(), then releasing it, and + then acquiring a new one with + sd_event_default() will result in two + distinct objects. Note that, in order to free an event loop object, + all remaining event sources of the event loop also need to be + freed as each keeps a reference to it. + + sd_event_unrefp() is similar to + sd_event_unref() but takes a pointer to a + pointer to an sd_event object. This call is useful in + conjunction with GCC's and LLVM's Clean-up + Variable Attribute. Note that this function is defined as + inline function. Use a declaration like the following, + in order to allocate an event loop object that is freed + automatically as the code block is left: + + { + __attribute__((cleanup(sd_event_unrefp))) sd_event *event = NULL; + int r; + … + r = sd_event_default(&event); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to allocate event loop: %m\n"); + } + … +} + + sd_event_ref(), + sd_event_unref() and + sd_event_unrefp() execute no operation if the + passed in event loop object is NULL. + + sd_event_get_tid() retrieves the thread + identifier ("TID") of the thread the specified event loop object + is associated with. This call is only supported for event loops + allocated with sd_event_default(), and + returns the identifier for the thread the event loop is the + default event loop of. See gettid2 + for more information on thread identifiers. + + + + Return Value + + On success, sd_event_new(), sd_event_default() and + sd_event_get_tid() return 0 or a positive integer. On failure, they return a + negative errno-style error code. sd_event_ref() always returns a pointer to the + event loop object passed in. sd_event_unref() always returns + NULL. + + + Errors + + Returned errors may indicate the following problems: + + + + -ENOMEM + + Not enough memory to allocate the object. + + + + -EMFILE + + The maximum number of event loops has been allocated. + + + + + -ENXIO + + sd_event_get_tid() was invoked on an event loop object that + was not allocated with sd_event_default(). + + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_run3, + gettid2 + + + + diff --git a/man/sd_event_now.xml b/man/sd_event_now.xml new file mode 100644 index 0000000..789b9e0 --- /dev/null +++ b/man/sd_event_now.xml @@ -0,0 +1,114 @@ + + + + + + + + sd_event_now + systemd + + + + sd_event_now + 3 + + + + sd_event_now + + Retrieve current event loop iteration timestamp + + + + + #include <systemd/sd-event.h> + + + int sd_event_now + sd_event *event + clockid_t clock + uint64_t *usec + + + + + + + Description + + sd_event_now() returns the time when + the most recent event loop iteration began. A timestamp + is taken right after returning from the event sleep, and before + dispatching any event sources. The event + parameter specifies the event loop object to retrieve the timestamp + from. The clock parameter specifies the clock to + retrieve the timestamp for, and is one of + CLOCK_REALTIME (or equivalently + CLOCK_REALTIME_ALARM), + CLOCK_MONOTONIC, or + CLOCK_BOOTTIME (or equivalently + CLOCK_BOOTTIME_ALARM), see + clock_gettime2 + for more information on the various clocks. The retrieved + timestamp is stored in the usec parameter, + in µs since the clock's epoch. If this function is invoked before + the first event loop iteration, the current time is returned, as + reported by clock_gettime(). To distinguish + this case from a regular invocation the return value will be + positive, and zero when the returned timestamp refers to an actual + event loop iteration. + + + + Return Value + + If the first event loop iteration has not run yet sd_event_now() writes + current time to usec and returns a positive return value. Otherwise, it will + write the requested timestamp to usec and return 0. On failure, the call returns a + negative errno-style error code. + + + Errors + + Returned values may indicate the following problems: + + + + -EINVAL + + An invalid parameter was passed. + + + + + -EOPNOTSUPP + + Unsupported clock type. + + + + -ECHILD + + The event loop object was created in a different process. + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_add_time3, + clock_gettime2 + + + + diff --git a/man/sd_event_run.xml b/man/sd_event_run.xml new file mode 100644 index 0000000..81c51b7 --- /dev/null +++ b/man/sd_event_run.xml @@ -0,0 +1,164 @@ + + + + + + + + sd_event_run + systemd + + + + sd_event_run + 3 + + + + sd_event_run + sd_event_loop + + Run an event loop + + + + + #include <systemd/sd-event.h> + + + int sd_event_run + sd_event *event + uint64_t usec + + + + int sd_event_loop + sd_event *event + + + + + + Description + + sd_event_run() may be used to run a single + iteration of the event loop specified in the + event parameter. The function waits until an event to + process is available, and dispatches the registered handler for + it. The usec parameter specifies the + maximum time (in microseconds) to wait for an event. Use + (uint64_t) -1 to specify an infinite + timeout. + + sd_event_loop() invokes + sd_event_run() in a loop, thus implementing + the actual event loop. The call returns as soon as exiting was + requested using + sd_event_exit3. + + The event loop object event is + created with + sd_event_new3. + Events sources to wait for and their handlers may be registered + with + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_defer3, + sd_event_add_post3 + and + sd_event_add_exit3. + + + For low-level control of event loop execution, use + sd_event_prepare3, + sd_event_wait3 + and + sd_event_dispatch3 + which are wrapped by sd_event_run(). Along + with + sd_event_get_fd3, + these functions allow integration of an + sd-event3 + event loop into foreign event loop implementations. + + + + Return Value + + On failure, these functions return a negative errno-style + error code. sd_event_run() returns a + positive, non-zero integer if an event source was dispatched, and + zero when the specified timeout hit before an event source has + seen any event, and hence no event source was + dispatched. sd_event_loop() returns the exit + code specified when invoking + sd_event_exit(). + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The event parameter is invalid or + NULL. + + + + -EBUSY + + The event loop object is not in the right + state (see + sd_event_prepare3 + for an explanation of possible states). + + + + -ESTALE + + The event loop is already terminated. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + + + Other errors are possible, too. + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_exit3, + sd_event_get_fd3, + sd_event_wait3, + GLib Main Event Loop + + + + diff --git a/man/sd_event_set_signal_exit.xml b/man/sd_event_set_signal_exit.xml new file mode 100644 index 0000000..e5e675b --- /dev/null +++ b/man/sd_event_set_signal_exit.xml @@ -0,0 +1,101 @@ + + + + + + + + sd_event_set_signal_exit + systemd + + + + sd_event_set_signal_exit + 3 + + + + sd_event_set_signal_exit + + Automatically leave event loop on SIGINT and SIGTERM + + + + + #include <systemd/sd-event.h> + + + int sd_event_set_signal_exit + sd_event *event + int b + + + + + + + Description + + sd_event_set_signal_exit() may be used to ensure the event loop terminates + once a SIGINT or SIGTERM signal is received. It is a + convencience wrapper around invocations of + sd_event_add_signal3 + for both signals. The two signals are automatically added to the calling thread's signal mask (if a + program is multi-threaded care should be taken to either invoke this function before the first thread is + started or to manually block the two signals process-wide first). + + If the parameter b is specified as true, the event loop will terminate on + SIGINT and SIGTERM. If specified as false, it will no + longer. When this functionality is turned off the calling thread's signal mask is restored to match the + state before it was turned on, for the two signals. By default the two signals are not handled by the + event loop, and Linux' default signal handling for them is in effect. + + It's customary for UNIX programs to exit on either of these two signals, hence it's typically a + good idea to enable this functionality for the main event loop of a program. + + + + Return Value + + sd_event_set_signal_exit() returns a positive non-zero value when the setting + was successfully changed. It returns a zero when the specified setting was already in effect. On failure, + it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -ECHILD + + The event loop has been created in a different process. + + + + -EINVAL + + The passed event loop object was invalid. + + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_add_signal3 + + + + diff --git a/man/sd_event_set_watchdog.xml b/man/sd_event_set_watchdog.xml new file mode 100644 index 0000000..28d647c --- /dev/null +++ b/man/sd_event_set_watchdog.xml @@ -0,0 +1,145 @@ + + + + + + + + sd_event_set_watchdog + systemd + + + + sd_event_set_watchdog + 3 + + + + sd_event_set_watchdog + sd_event_get_watchdog + + Enable event loop watchdog support + + + + + #include <systemd/sd-event.h> + + + int sd_event_set_watchdog + sd_event *event + int b + + + + int sd_event_get_watchdog + sd_event *event + + + + + + + Description + + sd_event_set_watchdog() may be used to + enable or disable automatic watchdog notification support in the + event loop object specified in the event + parameter. Specifically, depending on the b + boolean argument this will make sure the event loop wakes up in + regular intervals and sends watchdog notification messages to the + service manager, if this was requested by the service + manager. Watchdog support is determined with + sd_watchdog_enabled3, + and watchdog messages are sent with + sd_notify3. See + the WatchdogSec= setting in + systemd.service5 + for details on how to enable watchdog support for a service and + the protocol used. The wake-up interval is chosen as half the + watchdog timeout declared by the service manager via the + $WATCHDOG_USEC environment variable. If the + service manager did not request watchdog notifications, or if the + process was not invoked by the service manager this call with a + true b parameter executes no + operation. Passing a false b parameter will + disable the automatic sending of watchdog notification messages if + it was enabled before. Newly allocated event loop objects have + this feature disabled. + + The first watchdog notification message is sent immediately + when sd_event_set_watchdog() is invoked with + a true b parameter. + + The watchdog logic is designed to allow the service manager + to automatically detect services that ceased processing of + incoming events, and thus appear "hung". Watchdog notifications + are sent out only at the beginning of each event loop + iteration. If an event source dispatch function blocks for an + excessively long time and does not return execution to the event + loop quickly, this might hence cause the notification message to + be delayed, and possibly result in abnormal program termination, + as configured in the service unit file. + + sd_event_get_watchdog() may be used to + determine whether watchdog support was previously requested by a + call to sd_event_set_watchdog() with a true + b parameter and successfully + enabled. + + + + Return Value + + On success, sd_event_set_watchdog() and + sd_event_get_watchdog() return a non-zero positive integer if the service manager + requested watchdog support and watchdog support was successfully enabled. They return zero if the service + manager did not request watchdog support, or if watchdog support was explicitly disabled with a false + b parameter. On failure, they return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -ECHILD + + The event loop has been created in a different process. + + + + -EINVAL + + The passed event loop object was invalid. + + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_new3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_watchdog_enabled3, + sd_notify3, + systemd.service5 + + + + diff --git a/man/sd_event_source_get_event.xml b/man/sd_event_source_get_event.xml new file mode 100644 index 0000000..a850583 --- /dev/null +++ b/man/sd_event_source_get_event.xml @@ -0,0 +1,74 @@ + + + + + + + + sd_event_source_get_event + systemd + + + + sd_event_source_get_event + 3 + + + + sd_event_source_get_event + + Retrieve the event loop of an event source + + + + + #include <systemd/sd-event.h> + + + sd_event* sd_event_source_get_event + sd_event_source *source + + + + + + + Description + + sd_event_source_get_event() may be used + to retrieve the event loop object the event source object specified + as source is associated with. The event + loop object is specified when creating an event source object with + calls such as + sd_event_add_io3 + or + sd_event_add_time3. + + + + Return Value + + On success, sd_event_source_get_event() + returns the associated event loop object. On failure, it returns + NULL. + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_userdata3 + + + + diff --git a/man/sd_event_source_get_pending.xml b/man/sd_event_source_get_pending.xml new file mode 100644 index 0000000..5906930 --- /dev/null +++ b/man/sd_event_source_get_pending.xml @@ -0,0 +1,137 @@ + + + + + + + + sd_event_source_get_pending + systemd + + + + sd_event_source_get_pending + 3 + + + + sd_event_source_get_pending + + Determine pending state of event sources + + + + + #include <systemd/sd-event.h> + + + int sd_event_source_get_pending + sd_event_source *source + + + + + + + Description + + sd_event_source_get_pending() may be + used to determine whether the event source object specified as + source has seen events but has not been + dispatched yet (and thus is marked "pending"). + + Event source objects initially are not marked pending, when + they are created with calls such as + sd_event_add_io3, + sd_event_add_time3, + with the exception of those created with + sd_event_add_defer3 + which are immediately marked pending, and + sd_event_add_exit3 + for which the "pending" concept is not defined. For details see + the respective manual pages. + + In each event loop iteration one event source of those + marked pending is dispatched, in the order defined by the event + source priority, as set with + sd_event_source_set_priority3. + + For I/O event sources, as created with + sd_event_add_io3, + the call + sd_event_source_get_io_revents3 + may be used to query the type of event pending in more + detail. + + + + + Return Value + + On success, sd_event_source_get_pending() returns an integer greater than zero + when the event source is marked pending, and zero when the event source is not marked pending. On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + source is not a valid pointer to an + sd_event_source object. + + + + -EDOM + + source refers to an event source object created with + sd_event_add_exit3. + + + + -ENOMEM + + Not enough memory. + + + + -ESTALE + + The event loop is already terminated. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + + + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_unref3 + + + + diff --git a/man/sd_event_source_set_description.xml b/man/sd_event_source_set_description.xml new file mode 100644 index 0000000..bea3e71 --- /dev/null +++ b/man/sd_event_source_set_description.xml @@ -0,0 +1,140 @@ + + + + + + + + sd_event_source_set_description + systemd + + + + sd_event_source_set_description + 3 + + + + sd_event_source_set_description + sd_event_source_get_description + + Set or retrieve descriptive names of event sources + + + + + #include <systemd/sd-event.h> + + + int sd_event_source_set_description + sd_event_source *source + const char *description + + + + int sd_event_source_get_description + sd_event_source *source + const char **description + + + + + + + Description + + sd_event_source_set_description() may + be used to set an arbitrary descriptive name for the event source + object specified as source. This name will + be used in debugging messages generated by + sd-event3 + for this event source, and may be queried using + sd_event_source_get_description() for + debugging purposes. The description parameter shall + point to a NUL-terminated string or be + NULL. In the latter case, the descriptive + name will be unset. The string is copied internally, hence the + description argument is not referenced + after the function returns. + + sd_event_source_get_description() may + be used to query the current descriptive name assigned to the + event source object source. It returns a + pointer to the current name in description, + stored in memory internal to the event source. The memory is + invalidated when the event source is destroyed or the descriptive + name is changed. + + Event source objects generally have no description set when + they are created, except for UNIX signal event sources created + with + sd_event_add_signal3, + whose descriptive name is initialized to the signal's C constant + name (e.g. SIGINT or + SIGTERM). + + + + Return Value + + On success, sd_event_source_set_description() and + sd_event_source_get_description() return a non-negative integer. On failure, they + return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + source is not a valid pointer to an + sd_event_source object or the description argument + for sd_event_source_get_description() is NULL. + + + + + -ENOMEM + + Not enough memory to copy the name. + + + + -ECHILD + + The event loop has been created in a different process. + + + + + -ENXIO + + No name was set for the event source. + + + + + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_userdata3 + + + + diff --git a/man/sd_event_source_set_destroy_callback.xml b/man/sd_event_source_set_destroy_callback.xml new file mode 100644 index 0000000..4e39f21 --- /dev/null +++ b/man/sd_event_source_set_destroy_callback.xml @@ -0,0 +1,112 @@ + + + + + + + + sd_event_source_set_destroy_callback + systemd + + + + sd_event_source_set_destroy_callback + 3 + + + + sd_event_source_set_destroy_callback + sd_event_source_get_destroy_callback + sd_event_destroy_t + + Define the callback function for resource cleanup + + + + + #include <systemd/sd-event.h> + + + typedef int (*sd_event_destroy_t) + void *userdata + + + + int sd_event_source_set_destroy_callback + sd_event_source *source + sd_event_destroy_t callback + + + + int sd_event_source_get_destroy_callback + sd_event_source *source + sd_event_destroy_t *callback + + + + + + + Description + + sd_event_source_set_destroy_callback() sets callback as the + callback function to be called right before the event source object source is + deallocated. The userdata pointer from the event source object will be passed as the + userdata parameter. This pointer can be set by an argument to the constructor functions, see + sd_event_add_io3, or directly, + see + sd_event_source_set_userdata3. + This callback function is called even if userdata is NULL. Note that + this callback is invoked at a time where the event source object itself is already invalidated, and executing + operations or taking new references to the event source object is not permissible. + + sd_event_source_get_destroy_callback() returns the current callback + for source in the callback parameter. + + + + Return Value + + On success, sd_event_source_set_destroy_callback() returns 0 or a positive + integer. On failure, it returns a negative errno-style error code. + + sd_event_source_get_destroy_callback() returns positive if the destroy + callback function is set, 0 if not. On failure, returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The source parameter is NULL. + + + + + + + + + + See Also + + + systemd1, + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_userdata3 + + + + diff --git a/man/sd_event_source_set_enabled.xml b/man/sd_event_source_set_enabled.xml new file mode 100644 index 0000000..5f13fc1 --- /dev/null +++ b/man/sd_event_source_set_enabled.xml @@ -0,0 +1,156 @@ + + + + + + + + sd_event_source_set_enabled + systemd + + + + sd_event_source_set_enabled + 3 + + + + sd_event_source_set_enabled + sd_event_source_get_enabled + SD_EVENT_ON + SD_EVENT_OFF + SD_EVENT_ONESHOT + + Enable or disable event sources + + + + + #include <systemd/sd-event.h> + + enum { + SD_EVENT_OFF = 0, + SD_EVENT_ON = 1, + SD_EVENT_ONESHOT = -1, +}; + + + int sd_event_source_set_enabled + sd_event_source *source + int enabled + + + + int sd_event_source_get_enabled + sd_event_source *source + int *enabled + + + + + + + Description + + sd_event_source_set_enabled() may be used to enable or disable the event + source object specified as source. The enabled parameter + takes one of SD_EVENT_ON (to enable), SD_EVENT_OFF (to disable) + or SD_EVENT_ONESHOT. If invoked with SD_EVENT_ONESHOT the event + source will be enabled but automatically reset to SD_EVENT_OFF after one dispatch. + For SD_EVENT_OFF, the event source source may be + NULL, in which case the function does nothing. Otherwise, + source must be a valid pointer to an sd_event_source + object. + + Event sources that are disabled will not result in event + loop wakeups and will not be dispatched, until they are enabled + again. + + sd_event_source_get_enabled() may be used to query whether the event source + object source is currently enabled or not. If both the + source and the output parameter enabled are + NULL, this function returns false. Otherwise, source must be + a valid pointer to an sd_event_source object. If the output parameter + enabled is not NULL, it is set to the enablement state (one + of SD_EVENT_ON, SD_EVENT_OFF, + SD_EVENT_ONESHOT). The function also returns true if the event source is not + disabled. + + Event source objects are enabled when they are first created + with calls such as + sd_event_add_io3, + sd_event_add_time3. However, + depending on the event source type they are enabled continuously + (SD_EVENT_ON) or only for a single invocation + of the event source handler + (SD_EVENT_ONESHOT). For details see the + respective manual pages. + + As event source objects stay active and may be dispatched as + long as there is at least one reference to them, in many cases it + is a good idea to combine a call to + sd_event_source_unref3 + with a prior call to + sd_event_source_set_enabled() with + SD_EVENT_OFF, to ensure the event source is + not dispatched again until all other remaining references are dropped. + + + + Return Value + + On success, sd_event_source_set_enabled() returns a non-negative + integer. sd_event_source_get_enabled() returns zero if the source is disabled + (SD_EVENT_OFF) and a positive integer otherwise. On failure, they return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + source is not a valid pointer to an + sd_event_source object. + + + + -ENOMEM + + Not enough memory. + + + + -ECHILD + + The event loop has been created in a different process. + + + + + + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_unref3, + sd_event_source_set_ratelimit3 + + + + diff --git a/man/sd_event_source_set_exit_on_failure.xml b/man/sd_event_source_set_exit_on_failure.xml new file mode 100644 index 0000000..6f839cd --- /dev/null +++ b/man/sd_event_source_set_exit_on_failure.xml @@ -0,0 +1,108 @@ + + + + + + + + sd_event_source_set_exit_on_failure + systemd + + + + sd_event_source_set_exit_on_failure + 3 + + + + sd_event_source_set_exit_on_failure + sd_event_source_get_exit_on_failure + + Set or retrieve the exit-on-failure feature of event sources + + + + + #include <systemd/sd-event.h> + + + int sd_event_source_set_exit_on_failure + sd_event_source *source + int b + + + + int sd_event_source_get_exit_on_failure + sd_event_source *source + + + + + + + Description + + sd_event_source_set_exit_on_failure() may be used to set/unset the + exit-on-failure flag of the event source object specified as source. The flag + defaults to off. If on and the callback function set for the event source returns a failure code (i.e. a + negative value) the event loop is exited too, using the callback return code as the exit code for + sd_event_exit3. If + off, the event source is disabled but the event loop continues to run. Setting this flag is useful for + "dominant" event sources that define the purpose and reason for the event loop, and whose failure hence + should propagate to the event loop itself — as opposed to "auxiliary" event sources whose failures should + remain local and affect the event source, but not propagate further. + + sd_event_source_get_exit_on_failure() may be used to query the flag currently + set for the event source object source. + + + + Return Value + + On success, sd_event_source_set_exit_on_failure() returns a non-negative + integer. sd_event_source_get_exit_on_failure() returns 0 if the flag is off, > 0 + if the flag is on. On failure, both return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + source is not a valid pointer to an + sd_event_source object. + + + + -EDOM + + The event source refers to an exit event source (as created with + sd_event_add_exit3), + for which this functionality is not supported. + + + + + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3 + + + + diff --git a/man/sd_event_source_set_floating.xml b/man/sd_event_source_set_floating.xml new file mode 100644 index 0000000..7f3ed86 --- /dev/null +++ b/man/sd_event_source_set_floating.xml @@ -0,0 +1,118 @@ + + + + + + + + sd_event_source_set_floating + systemd + + + + sd_event_source_set_floating + 3 + + + + sd_event_source_set_floating + sd_event_source_get_floating + + Set or retrieve 'floating' state of event sources + + + + + #include <systemd/sd-event.h> + + + int sd_event_source_set_floating + sd_event_source *source + int floating + + + + int sd_event_source_get_floating + sd_event_source *source + + + + + + + Description + + sd_event_source_set_floating() takes a boolean and sets the 'floating' state + of the specified event source object. This is used to change the direction of reference counts for the + object and the event loop it is associated with. In non-floating mode, the event source object holds a + reference to the event loop object, but not vice versa. The creator of the event source object must hold + a reference to it as long as the source should exist. In floating mode, the event loop holds a reference + to the source object, and will decrease the reference count when being freed. This means that a reference + to the event loop should be held to prevent both from being destroyed. + + Various calls that allocate event source objects (i.e. + sd_event_add_io3, + sd_event_add_time3 and + similar) will automatically set an event source object to 'floating' mode if the caller passed + NULL in the parameter used to return a reference to the event source object. + Nevertheless, it may be necessary to gain temporary access to the source object, for example to adjust + event source properties after allocation (e.g. its priority or description string). In those cases the + object may be created in non-floating mode, and the returned reference used to adjust the properties, and + the object marked as floating afterwards, and the reference in the caller dropped. + + sd_event_source_get_floating() may be used to query the current 'floating' + state of the event source object source. It returns zero if 'floating' mode is + off, positive if it is on. + + + + Return Value + + On success, sd_event_source_set_floating() and + sd_event_source_get_floating() return a non-negative integer. On failure, they + return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + source is not a valid pointer to an + sd_event_source object. + + + + -ECHILD + + The event loop has been created in a different process. + + + + + + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_description3, + sd_event_source_set_priority3 + + + + diff --git a/man/sd_event_source_set_prepare.xml b/man/sd_event_source_set_prepare.xml new file mode 100644 index 0000000..d52c55b --- /dev/null +++ b/man/sd_event_source_set_prepare.xml @@ -0,0 +1,142 @@ + + + + + + + + sd_event_source_set_prepare + systemd + + + + sd_event_source_set_prepare + 3 + + + + sd_event_source_set_prepare + + Set a preparation callback for event sources + + + + + #include <systemd/sd-event.h> + + + int sd_event_source_set_prepare + sd_event_source *source + sd_event_handler_t callback + + + + typedef int (*sd_event_handler_t) + sd_event_source *s + void *userdata + + + + + + + Description + + sd_event_source_set_prepare() may be + used to set a preparation callback for the event source object + specified as source. The callback function + specified as callback will be invoked + immediately before the event loop goes to sleep to wait for + incoming events. It is invoked with the user data pointer passed + when the event source was created. The event source will be disabled + if the callback function returns a negative error code. The callback + function may be used to reconfigure the precise events to wait for. + If the callback parameter is passed as NULL + the callback function is reset. + + Event source objects have no preparation callback associated + when they are first created with calls such as + sd_event_add_io3, + sd_event_add_time3. Preparation + callback functions are supported for all event source types with + the exception of those created with + sd_event_add_exit3. Preparation + callback functions are dispatched in the order indicated by the + event source's priority field, as set with + sd_event_source_set_priority3. Preparation + callbacks of disabled event sources (see + sd_event_source_set_enabled3) + are not invoked. + + + + Return Value + + On success, sd_event_source_set_prepare() returns a non-negative integer. On + failure, it returns a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + source is not a valid pointer to an + sd_event_source object. + + + + -ESTALE + + The event loop is already terminated. + + + + -ENOMEM + + Not enough memory. + + + + -ECHILD + + The event loop has been created in a different process. + + + + + -EDOM + + The specified event source has been created with + sd_event_add_exit3. + + + + + + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_enabled3, + sd_event_source_set_priority3, + sd_event_source_set_userdata3 + + + + diff --git a/man/sd_event_source_set_priority.xml b/man/sd_event_source_set_priority.xml new file mode 100644 index 0000000..2616c12 --- /dev/null +++ b/man/sd_event_source_set_priority.xml @@ -0,0 +1,166 @@ + + + + + + + + sd_event_source_set_priority + systemd + + + + sd_event_source_set_priority + 3 + + + + sd_event_source_set_priority + sd_event_source_get_priority + SD_EVENT_PRIORITY_IMPORTANT + SD_EVENT_PRIORITY_NORMAL + SD_EVENT_PRIORITY_IDLE + + Set or retrieve the priority of event sources + + + + + #include <systemd/sd-event.h> + + enum { + SD_EVENT_PRIORITY_IMPORTANT = -100, + SD_EVENT_PRIORITY_NORMAL = 0, + SD_EVENT_PRIORITY_IDLE = 100, +}; + + + int sd_event_source_set_priority + sd_event_source *source + int64_t priority + + + + int sd_event_source_get_priority + sd_event_source *source + int64_t *priority + + + + + + + Description + + sd_event_source_set_priority() may be + used to set the priority for the event source object specified as + source. The priority is specified as an + arbitrary signed 64bit integer. The priority is initialized to + SD_EVENT_PRIORITY_NORMAL (0) when the event + source is allocated with a call such as + sd_event_add_io3 + or + sd_event_add_time3, + and may be changed with this call. If multiple event sources have seen events at the same time, they are dispatched in the order indicated by the + event sources' priorities. Event sources with smaller priority + values are dispatched first. As well-known points of reference, + the constants SD_EVENT_PRIORITY_IMPORTANT + (-100), SD_EVENT_PRIORITY_NORMAL (0) and + SD_EVENT_PRIORITY_IDLE (100) may be used to + indicate event sources that shall be dispatched early, normally or + late. It is recommended to specify priorities based on these + definitions, and relative to them — however, the full 64bit + signed integer range is available for ordering event + sources. + + Priorities define the order in which event sources that have + seen events are dispatched. Care should be taken to ensure that + high-priority event sources (those with negative priority values + assigned) do not cause starvation of low-priority event sources + (those with positive priority values assigned). + + The order in which event sources with the same priority are + dispatched is undefined, but the event loop generally tries to + dispatch them in the order it learnt about events on them. As the + backing kernel primitives do not provide accurate information + about the order in which events occurred this is not necessarily + reliable. However, it is guaranteed that if events are seen on + multiple same-priority event sources at the same time, each one is + not dispatched again until all others have been dispatched + once. This behavior guarantees that within each priority + particular event sources do not starve or dominate the event + loop. + + The priority of event sources may be changed at any time of their lifetime, with the exception of inotify + event sources (i.e. those created with + sd_event_add_inotify3) whose + priority may only be changed in the time between their initial creation and the first subsequent event loop + iteration. + + sd_event_source_get_priority() may be + used to query the current priority assigned to the event source + object source. + + + + Return Value + + On success, sd_event_source_set_priority() and + sd_event_source_get_priority() return a non-negative integer. On failure, they + return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + source is not a valid pointer to an + sd_event_source object. + + + + -ENOMEM + + Not enough memory. + + + + -ESTALE + + The event loop is already terminated. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + + + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3 + + + + diff --git a/man/sd_event_source_set_ratelimit.xml b/man/sd_event_source_set_ratelimit.xml new file mode 100644 index 0000000..b8e6380 --- /dev/null +++ b/man/sd_event_source_set_ratelimit.xml @@ -0,0 +1,160 @@ + + + + + + + + sd_event_source_set_ratelimit + systemd + + + + sd_event_source_set_ratelimit + 3 + + + + sd_event_source_set_ratelimit + sd_event_source_get_ratelimit + sd_event_source_is_ratelimited + sd_event_source_set_ratelimit_expire_callback + + Configure rate limiting on event sources + + + + + #include <systemd/sd-event.h> + + + int sd_event_source_set_ratelimit + sd_event_source *source + uint64_t interval_usec + unsigned burst + + + + int sd_event_source_get_ratelimit + sd_event_source *source + uint64_t* ret_interval_usec + unsigned* ret_burst + + + + int sd_event_source_is_ratelimited + sd_event_source *source + + + + int sd_event_source_set_ratelimit_expire_callback + sd_event_source *source + sd_event_handler_tcallback + + + + + + + Description + + sd_event_source_set_ratelimit() may be used to enforce rate limiting on an + event source. When used an event source will be temporarily turned off when it fires more often then a + specified burst number within a specified time interval. This is useful as simple mechanism to avoid + event source starvation if high priority event sources fire very frequently. + + Pass the event source to operate on as first argument, a time interval in microseconds as second + argument and a maximum dispatch limit ("burst") as third parameter. Whenever the event source is + dispatched more often than the specified burst within the specified interval it is placed in a mode + similar to being disabled with + sd_event_source_set_enabled3 + and the SD_EVENT_OFF parameter. However it is disabled only temporarily – once the + specified interval is over regular operation resumes. It is again disabled temporarily once the specified rate + limiting is hit the next time. If either the interval or the burst value are specified as zero, rate + limiting is turned off. By default event sources do not have rate limiting enabled. Note that rate + limiting and disabling via sd_event_source_set_enabled() are independent of each + other, and an event source will only effect event loop wake-ups and is dispatched while it both is + enabled and rate limiting is not in effect. + + sd_event_source_get_ratelimit() may be used to query the current rate limiting + parameters set on the event source object source. The previously set interval and + burst vales are returned in the second and third argument. + + sd_event_source_is_ratelimited() may be used to query whether the event source + is currently affected by rate limiting, i.e. it has recently hit the rate limit and is currently + temporarily disabled due to that. + + sd_event_source_set_ratelimit_expire_callback may be used to set a callback + function that is invoked every time the event source leaves rate limited state. Note that function is + called in the same event loop iteration in which state transition occurred. + + Rate limiting is currently implemented for I/O, timer, signal, defer and inotify event + sources. + + + + Return Value + + On success, sd_event_source_set_ratelimit(), + sd_event_source_set_ratelimit_expire_callback and + sd_event_source_get_ratelimit() return a non-negative integer. On failure, they return + a negative errno-style error code. sd_event_source_is_ratelimited returns zero if rate + limiting is currently not in effect and greater than zero if it is in effect; it returns a negative + errno-style error code on failure. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + source is not a valid pointer to an + sd_event_source object. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + -EDOM + + It was attempted to use the rate limiting feature on an event source type that does + not support rate limiting. + + + + -ENOEXEC + + sd_event_source_get_ratelimit() was called on an event source + that doesn't have rate limiting configured. + + + + + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_enabled3 + + + + diff --git a/man/sd_event_source_set_userdata.xml b/man/sd_event_source_set_userdata.xml new file mode 100644 index 0000000..e8e5dc1 --- /dev/null +++ b/man/sd_event_source_set_userdata.xml @@ -0,0 +1,93 @@ + + + + + + + + sd_event_source_set_userdata + systemd + + + + sd_event_source_set_userdata + 3 + + + + sd_event_source_set_userdata + sd_event_source_get_userdata + + Set or retrieve user data pointer of event sources + + + + + #include <systemd/sd-event.h> + + + void* sd_event_source_set_userdata + sd_event_source *source + void *userdata + + + + void* sd_event_source_get_userdata + sd_event_source *source + + + + + + + Description + + sd_event_source_set_userdata() may be + used to set an arbitrary user data pointer for the event source + object specified as source. The user data + pointer is usually specified when creating an event source object + with calls such as + sd_event_add_io3 + or + sd_event_add_time3, + and may be updated with this call. The user data pointer is also + passed to all handler callback functions associated with the event + source. The userdata parameter specifies + the new user data pointer to set, the function returns the + previous user data pointer. Note that NULL is + a valid user data pointer. + + sd_event_source_get_userdata() may be + used to query the current user data pointer assigned to the event + source object source. + + + + Return Value + + On success, + sd_event_source_set_userdata() and + sd_event_source_get_userdata() return the + previously set user data pointer. On failure, they return + NULL. + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_description3 + + + + diff --git a/man/sd_event_source_unref.xml b/man/sd_event_source_unref.xml new file mode 100644 index 0000000..b626e4c --- /dev/null +++ b/man/sd_event_source_unref.xml @@ -0,0 +1,132 @@ + + + + + + + + sd_event_source_unref + systemd + + + + sd_event_source_unref + 3 + + + + sd_event_source_unref + sd_event_source_unrefp + sd_event_source_ref + sd_event_source_disable_unref + sd_event_source_disable_unrefp + + Increase or decrease event source reference counters + + + + + #include <systemd/sd-event.h> + + + sd_event_source* sd_event_source_unref + sd_event_source *source + + + + void sd_event_source_unrefp + sd_event_source **source + + + + sd_event_source* sd_event_source_ref + sd_event_source *source + + + + sd_event_source* sd_event_source_disable_unref + sd_event_source *source + + + + void sd_event_source_disable_unrefp + sd_event_source **source + + + + + + Description + + sd_event_source_unref() may be used to decrement by one the internal reference + counter of the event source object specified as source. The reference counter is + initially set to one, when the event source is created with calls such as + sd_event_add_io3 or + sd_event_add_time3. When + the reference counter reaches zero, the object is detached from the event loop object and destroyed. + + + sd_event_source_unrefp() is similar to + sd_event_source_unref() but takes a pointer to a + pointer to an sd_event_source object. This call is useful in + conjunction with GCC's and LLVM's Clean-up + Variable Attribute. Note that this function is defined as + inline function. + + sd_event_source_ref() may be used to increase by one the internal reference + counter of the event source object specified as source. + + sd_event_source_unref(), + sd_bus_creds_unrefp() and + sd_bus_creds_ref() execute no operation if + the passed event source object is + NULL. + + Note that event source objects stay alive and may be dispatched as long as they have a reference + counter greater than zero. In order to drop a reference of an event source and make sure the associated + event source handler function is not called anymore it is recommended to combine a call of + sd_event_source_unref() with a prior call to + sd_event_source_set_enabled() with SD_EVENT_OFF or call + sd_event_source_disable_unref(), see below. + + sd_event_source_disable_unref() combines a call to + sd_event_source_set_enabled() with SD_EVENT_OFF with + sd_event_source_unref(). This ensures that the source is disabled before the local + reference to it is lost. The source parameter is allowed to be + NULL. + + sd_event_source_disable_unrefp() is similar to + sd_event_source_unrefp(), but in addition disables the source first. This call is + useful in conjunction with GCC's and LLVM's + Clean-up Variable + Attribute. Note that this function is defined as inline function. + + + + Return Value + + sd_event_source_unref() and + sd_event_source_disable_unref() always return NULL. + sd_event_source_ref() always returns the event source object passed in. + + + + + + See Also + + + sd-event3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_source_set_enabled3 + + + + diff --git a/man/sd_event_wait.xml b/man/sd_event_wait.xml new file mode 100644 index 0000000..25e21b9 --- /dev/null +++ b/man/sd_event_wait.xml @@ -0,0 +1,324 @@ + + + + + + + + sd_event_wait + systemd + + + + sd_event_wait + 3 + + + + sd_event_wait + sd_event_prepare + sd_event_dispatch + sd_event_get_state + sd_event_get_iteration + SD_EVENT_INITIAL + SD_EVENT_PREPARING + SD_EVENT_ARMED + SD_EVENT_PENDING + SD_EVENT_RUNNING + SD_EVENT_EXITING + SD_EVENT_FINISHED + + Low-level event loop operations + + + + + #include <systemd/sd-event.h> + + enum { + SD_EVENT_INITIAL, + SD_EVENT_PREPARING, + SD_EVENT_ARMED, + SD_EVENT_PENDING, + SD_EVENT_RUNNING, + SD_EVENT_EXITING, + SD_EVENT_FINISHED, +}; + + + int sd_event_prepare + sd_event *event + + + + int sd_event_wait + sd_event *event + uint64_t usec + + + + int sd_event_dispatch + sd_event *event + + + + int sd_event_get_state + sd_event *event + + + + int sd_event_get_iteration + sd_event *event + uint64_t *ret + + + + + + + Description + + The low-level sd_event_prepare(), + sd_event_wait() and + sd_event_dispatch() functions may be used to + execute specific phases of an event loop. See + sd_event_run3 + and + sd_event_loop3 + for higher-level functions that execute individual but complete + iterations of an event loop or run it continuously. + + sd_event_prepare() checks for pending + events and arms necessary timers. If any events are ready to be + processed ("pending"), it returns a positive, non-zero value, and the caller + should process these events with + sd_event_dispatch(). + + sd_event_dispatch() dispatches the + highest priority event source that has a pending event. On + success, sd_event_dispatch() returns either + zero, which indicates that no further event sources may be + dispatched and exiting of the event loop was requested via + sd_event_exit3; + or a positive non-zero value, which means that an event source was + dispatched and the loop returned to its initial state, and the + caller should initiate the next event loop iteration by invoking + sd_event_prepare() again. + + In case sd_event_prepare() returned + zero, sd_event_wait() should be called to + wait for further events or a timeout. If any events are ready to + be processed, it returns a positive, non-zero value, and the + events should be dispatched with + sd_event_dispatch(). Otherwise, the event + loop returned to its initial state and the next event loop + iteration should be initiated by invoking + sd_event_prepare() again. + + sd_event_get_state() may be used to + determine the state the event loop is currently in. It returns one + of the states described below. + + sd_event_get_iteration() may be used to determine the current iteration of the event + loop. It returns an unsigned 64bit integer containing a counter that increases monotonically with each iteration of + the event loop, starting with 0. The counter is increased at the time of the + sd_event_prepare() invocation. + + All five functions take, as the first argument, the event loop object event that has + been created with sd_event_new(). The timeout for sd_event_wait() is + specified in usec in microseconds. (uint64_t) -1 may be used to + specify an infinite timeout. + + + + State Machine + + The event loop knows the following states, that may be + queried with sd_event_get_state(). + + + + SD_EVENT_INITIAL + + The initial state the event loop is in, + before each event loop iteration. Use + sd_event_prepare() to transition the + event loop into the SD_EVENT_ARMED or + SD_EVENT_PENDING states. + + + + SD_EVENT_PREPARING + + An event source is currently being prepared, + i.e. the preparation handler is currently being executed, as + set with + sd_event_source_set_prepare3. This + state is only seen in the event source preparation handler + that is invoked from the + sd_event_prepare() call and is + immediately followed by SD_EVENT_ARMED or + SD_EVENT_PENDING. + + + + SD_EVENT_ARMED + + sd_event_prepare() has + been called and no event sources were ready to be + dispatched. Use sd_event_wait() to wait + for new events, and transition into + SD_EVENT_PENDING or back into + SD_EVENT_INITIAL. + + + + SD_EVENT_PENDING + + sd_event_prepare() or + sd_event_wait() have been called and + there were event sources with events pending. Use + sd_event_dispatch() to dispatch the + highest priority event source and transition back to + SD_EVENT_INITIAL, or + SD_EVENT_FINISHED. + + + + SD_EVENT_RUNNING + + A regular event source is currently being + dispatched. This state is only seen in the event source + handler that is invoked from the + sd_event_dispatch() call, and is + immediately followed by SD_EVENT_INITIAL + or SD_EVENT_FINISHED as soon the event + source handler returns. Note that during dispatching of exit + event sources the SD_EVENT_EXITING state + is seen instead. + + + + SD_EVENT_EXITING + + Similar to + SD_EVENT_RUNNING but is the state in + effect while dispatching exit event sources. It is followed by + SD_EVENT_INITIAL or + SD_EVENT_FINISHED as soon as the event + handler returns. + + + + SD_EVENT_FINISHED + + The event loop has exited. All exit event + sources have run. If the event loop is in this state it serves + no purpose anymore, and should be freed. + + + + + A simplified flow chart of the states and the calls to + transition between them is shown below. Note that + SD_EVENT_PREPARING, + SD_EVENT_RUNNING and + SD_EVENT_EXITING are not shown here. + + + INITIAL -<---<---<---<---<---<---<---<---<---<---<---<---\ + | | + | ^ + | | + v ret == 0 | + sd_event_prepare() >--->--->--->--->- ARMED | + | | ^ + | ret > 0 | | + | | | + v v ret == 0 | + PENDING <---<---<---<---<---< sd_event_wait() >--->--->--+ + | ret > 0 ^ + | | + | | + v | + sd_event_dispatch() >--->--->--->--->--->--->--->--->--->--->/ + | ret > 0 + | ret == 0 + | + v + FINISHED + + + + + Return Value + + On success, these functions return 0 or a positive integer. On failure, they return a negative + errno-style error code. In case of sd_event_prepare() and + sd_event_wait(), a positive, non-zero return code indicates that events are ready to + be processed and zero indicates that no events are ready. In case of + sd_event_dispatch(), a positive, non-zero return code indicates that the event loop + returned to its initial state and zero indicates the event loop has + exited. sd_event_get_state() returns a positive or zero state on success. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + The event parameter is invalid or NULL. + + + + + -EBUSY + + The event loop object is not in the right state. + + + + -ESTALE + + The event loop is already terminated. + + + + + -ECHILD + + The event loop has been created in a different process. + + + + + + Other errors are possible, too. + + + + + + + See Also + + + systemd1, + sd_event_new3, + sd_event_add_io3, + sd_event_add_time3, + sd_event_add_signal3, + sd_event_add_child3, + sd_event_add_inotify3, + sd_event_add_defer3, + sd_event_run3, + sd_event_get_fd3, + sd_event_source_set_prepare3 + + + + diff --git a/man/sd_get_seats.xml b/man/sd_get_seats.xml new file mode 100644 index 0000000..818f968 --- /dev/null +++ b/man/sd_get_seats.xml @@ -0,0 +1,118 @@ + + + + + + + + sd_get_seats + systemd + + + + sd_get_seats + 3 + + + + sd_get_seats + sd_get_sessions + sd_get_uids + sd_get_machine_names + Determine available seats, sessions, logged in users and virtual machines/containers + + + + + #include <systemd/sd-login.h> + + + int sd_get_seats + char ***seats + + + + int sd_get_sessions + char ***sessions + + + + int sd_get_uids + uid_t **users + + + + int sd_get_machine_names + char ***machines + + + + + + + Description + + sd_get_seats() may be used to determine + all currently available local seats. Returns the number of seat + identifiers and if the input pointer is non-NULL, a + NULL-terminated array of seat identifiers + is stored at the address. + The returned array and all strings it references need to be freed + with the libc + free3 + call after use. Note that instead of an empty array + NULL may be returned and should be considered + equivalent to an empty array. + + Similarly, sd_get_sessions() may be + used to determine all current login sessions. + + Similarly, sd_get_uids() may be used to + determine all Unix users who currently have login sessions. + + Similarly, sd_get_machine_names() may + be used to determine all current virtual machines and containers + on the system. + + Note that the returned lists are not sorted and in an + undefined order. + + + + Return Value + + On success, sd_get_seats(), sd_get_sessions(), + sd_get_uids() and sd_get_machine_names() return the number of + entries in the arrays. On failure, these calls return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-login3, + sd_session_get_seat3 + + + + diff --git a/man/sd_hwdb_get.xml b/man/sd_hwdb_get.xml new file mode 100644 index 0000000..6a6594f --- /dev/null +++ b/man/sd_hwdb_get.xml @@ -0,0 +1,157 @@ + + + + + + + sd_hwdb_get + systemd + + + + sd_hwdb_get + 3 + + + + sd_hwdb_get + sd_hwdb_seek + sd_hwdb_enumerate + SD_HWDB_FOREACH_PROPERTY + + Seek to a location in hwdb or access entries + + + + + #include <systemd/sd-hwdb.h> + + + int sd_hwdb_get + sd_hwdb *hwdb + const char *modalias + const char *key + const char **value + + + + int sd_hwdb_seek + sd_hwdb *hwdb + const char *modalias + + + + int sd_hwdb_enumerate + sd_hwdb *hwdb + const char **key + const char **value + + + + SD_HWDB_FOREACH_PROPERTY + hwdb + modalias + key + value + + + + + + Description + + sd_hwdb_get() queries the hwdb object created earlier + with sd_hwdb_new3 for + entries matching the specified string modalias, and returns the value + corresponding to the key key. The value is returned as a + NUL-terminated string in value. It must not be modified by + the caller and is valid as long as a reference to hwdb is kept. When multiple + patterns in the database match modalias, the one with the highest priority is + used. See hwdb7 for + details. + + sd_hwdb_seek() selects entries matching the specified string + modalias. Subsequent queries with sd_hwdb_enumerate() will + access the key-value pairs for that string. + + sd_hwdb_enumerate() returns (in turn) all the key-value pairs defined for the + string used with sd_hwdb_seek(). Each pair is returned as + NUL-terminated strings in key and + value. The strings must not be modified by the caller and are valid as long as a + reference to hwdb is kept. When multiple patterns in the database match + modalias, the combination of all matching key-value pairs is used. See + hwdb7 for + details. + + The SD_HWDB_FOREACH_PROPERTY() macro combines + sd_hwdb_seek() and sd_hwdb_enumerate(). No error handling is + performed and iteration simply stops on error. See the example below. + + + + Return Value + + On success, sd_hwdb_get() and sd_hwdb_seek() return a + non-negative integer. On failure, they return a negative errno-style error code. + + sd_hwdb_enumerate() returns a positive integer if another key-value pair was found or zero if + all entries have already been enumerated. On failure, it returns a negative errno-style error code. + + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + A parameter is NULL. + + + + -ENOENT + + An entry for the specified modalias was not found. + + + + + -EAGAIN + + sd_hwdb_seek() was not called before + sd_hwdb_enumerate(). + + + + + + + + + Examples + + + Look up hwdb entries for a USB device + + + + The effect is similar to calling systemd-hwdb query usb:v046DpC534. + + + + + + See Also + + + systemd1, + systemd-udevd.service8, + sd-hwdb3, + systemd-hwdb8 + + + + diff --git a/man/sd_hwdb_new.xml b/man/sd_hwdb_new.xml new file mode 100644 index 0000000..0584add --- /dev/null +++ b/man/sd_hwdb_new.xml @@ -0,0 +1,131 @@ + + + + + + + sd_hwdb_new + systemd + + + + sd_hwdb_new + 3 + + + + sd_hwdb_new + sd_hwdb_new_from_path + sd_hwdb_ref + sd_hwdb_unref + + Create a new hwdb object and create or destroy references to it + + + + + #include <systemd/sd-hwdb.h> + + + int sd_hwdb_new + sd_hwdb **hwdb + + + + int sd_hwdb_new_from_path + const char *path + sd_hwdb **hwdb + + + + sd_hwdb* sd_hwdb_ref + sd_hwdb *hwdb + + + + sd_hwdb* sd_hwdb_unref + sd_hwdb *hwdb + + + + + + Description + + sd_hwdb_new() creates a new hwdb object to access the binary hwdb + database. Upon initialization, the file containing the binary representation of the hardware database is + located and opened. The new object is returned in hwdb. + + sd_hwdb_new_from_path() may be used to specify the path from which the binary + hardware database should be opened. + + The hwdb object is reference counted. sd_hwdb_ref() and + sd_hwdb_unref() may be used to get a new reference or destroy an existing reference + to an object. The caller must dispose of the reference acquired with sd_hwdb_new() + by calling sd_hwdb_unref() when done with the object. + + Use + sd_hwdb_seek3, + sd_hwdb_get3, and + sd_hwdb_enumerate3 to + access entries. + + + + Return Value + + On success, sd_hwdb_new() and sd_hwdb_new_from_path() + return a non-negative integer. On failure, a negative errno-style error code is returned. + + sd_hwdb_ref() always returns the argument. + + + sd_hwdb_unref() always returns NULL. + + + + Errors + + Returned errors may indicate the following problems: + + + + -ENOENT + + The binary hardware database file could not be located. See + systemd-hwdb8 + for more information. + + + + + -EINVAL + + The located binary hardware database file is in an incompatible format. + + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + systemd-udevd.service8, + sd-hwdb3, + systemd-hwdb3 + + + + diff --git a/man/sd_id128_get_machine.xml b/man/sd_id128_get_machine.xml new file mode 100644 index 0000000..35a3045 --- /dev/null +++ b/man/sd_id128_get_machine.xml @@ -0,0 +1,212 @@ + + + + + + + + sd_id128_get_machine + systemd + + + + sd_id128_get_machine + 3 + + + + sd_id128_get_machine + sd_id128_get_machine_app_specific + sd_id128_get_boot + sd_id128_get_boot_app_specific + sd_id128_get_invocation + Retrieve 128-bit IDs + + + + + #include <systemd/sd-id128.h> + + + int sd_id128_get_machine + sd_id128_t *ret + + + + int sd_id128_get_machine_app_specific + sd_id128_t app_id + sd_id128_t *ret + + + + int sd_id128_get_boot + sd_id128_t *ret + + + + int sd_id128_get_boot_app_specific + sd_id128_t app_id + sd_id128_t *ret + + + + int sd_id128_get_invocation + sd_id128_t *ret + + + + + + + Description + + sd_id128_get_machine() returns the machine ID of the executing host. This reads and + parses the machine-id5 + file. This function caches the machine ID internally to make retrieving the machine ID a cheap operation. This ID + may be used wherever a unique identifier for the local system is needed. However, it is recommended to use this ID + as-is only in trusted environments. In untrusted environments it is recommended to derive an application specific + ID from this machine ID, in an irreversible (cryptographically secure) way. To make this easy + sd_id128_get_machine_app_specific() is provided, see below. + + sd_id128_get_machine_app_specific() is similar to + sd_id128_get_machine(), but retrieves a machine ID that is specific to the application that is + identified by the indicated application ID. It is recommended to use this function instead of + sd_id128_get_machine() when passing an ID to untrusted environments, in order to make sure + that the original machine ID may not be determined externally. This way, the ID used by the application remains + stable on a given machine, but cannot be easily correlated with IDs used in other applications on the same + machine. The application-specific ID should be generated via a tool like systemd-id128 new, + and may be compiled into the application. This function will return the same application-specific ID for each + combination of machine ID and application ID. Internally, this function calculates HMAC-SHA256 of the application + ID, keyed by the machine ID. + + sd_id128_get_boot() returns the boot ID of the executing kernel. This reads and parses + the /proc/sys/kernel/random/boot_id file exposed by the kernel. It is randomly generated early + at boot and is unique for every running kernel instance. See random4 for more + information. This function also internally caches the returned ID to make this call a cheap operation. It is + recommended to use this ID as-is only in trusted environments. In untrusted environments it is recommended to + derive an application specific ID using sd_id128_get_boot_app_specific(), see below. + + sd_id128_get_boot_app_specific() is analogous to + sd_id128_get_machine_app_specific() but returns an ID that changes between boots. Some + machines may be used for a long time without rebooting, hence the boot ID may remain constant for a long time, and + has properties similar to the machine ID during that time. + + sd_id128_get_invocation() returns the invocation ID of the currently executed + service. In its current implementation, this reads and parses the $INVOCATION_ID environment + variable that the service manager sets when activating a service, see + systemd.exec5 for details. The + ID is cached internally. In future a different mechanism to determine the invocation ID may be added. + + Note that sd_id128_get_machine_app_specific(), + sd_id128_get_boot(), sd_id128_get_boot_app_specific(), and + sd_id128_get_invocation() always return UUID Variant 1 Version 4 compatible IDs. + sd_id128_get_machine() will also return a UUID Variant 1 Version 4 compatible ID on + new installations but might not on older. It is possible to convert the machine ID non-reversibly into a + UUID Variant 1 Version 4 compatible one. For more information, see + machine-id5. It is + hence guaranteed that these functions will never return the ID consisting of all zero or all one bits + (SD_ID128_NULL, SD_ID128_ALLF) — with the possible exception of + sd_id128_get_machine(), as mentioned. + + For more information about the sd_id128_t + type see + sd-id1283. + + + + Return Value + + Those calls return 0 on success (in which case ret is filled in), + or a negative errno-style error code. + + + Errors + Returned errors may indicate the following problems: + + + + -ENOENT + + Returned by sd_id128_get_machine(), + sd_id128_get_machine_app_specific(), and + sd_id128_get_boot_app_specific() when /etc/machine-id is + missing. + + + + -ENOMEDIUM + + Returned by sd_id128_get_machine(), + sd_id128_get_machine_app_specific(), and + sd_id128_get_boot_app_specific() when /etc/machine-id is + empty or all zeros. + + + + -ENXIO + + Returned by sd_id128_get_invocation() if no invocation ID is + set. + + + + -EIO + + Returned by any of the functions described here when the configured value has + invalid format. + + + + -EPERM + + Requested information could not be retrieved because of insufficient permissions. + + + + + + + + + + Examples + + + Application-specific machine ID + + First, generate the application ID: + $ systemd-id128 -p new +As string: +c273277323db454ea63bb96e79b53e97 + +As UUID: +c2732773-23db-454e-a63b-b96e79b53e97 + +As man:sd-id128(3) macro: +#define MESSAGE_XYZ SD_ID128_MAKE(c2,73,27,73,23,db,45,4e,a6,3b,b9,6e,79,b5,3e,97) +... + + + Then use the new identifier in an example application: + + + + + + + See Also + + + systemd1, + systemd-id1281, + sd-id1283, + machine-id5, + systemd.exec5, + sd_id128_randomize3, + random4 + + + + diff --git a/man/sd_id128_randomize.xml b/man/sd_id128_randomize.xml new file mode 100644 index 0000000..2df3547 --- /dev/null +++ b/man/sd_id128_randomize.xml @@ -0,0 +1,80 @@ + + + + + + + + sd_id128_randomize + systemd + + + + sd_id128_randomize + 3 + + + + sd_id128_randomize + Generate 128-bit IDs + + + + + #include <systemd/sd-id128.h> + + + int sd_id128_randomize + sd_id128_t *ret + + + + + + + Description + + sd_id128_randomize() generates a new randomized 128-bit ID and returns it in + ret. Every invocation returns a new randomly generated ID. This uses the + getrandom2 + kernel random number generator. + + Note that sd_id128_randomize() always returns a UUID Variant 1 Version 4 + compatible ID. It is hence guaranteed that this function will never return the ID consisting of all zero + or all one bits (SD_ID128_NULL, SD_ID128_ALLF). + + For more information about the sd_id128_t + type, see + sd-id1283. + + systemd-id1281's + new command may be used as a command line front-end for + sd_id128_randomize(). + + + + Return Value + + The call returns 0 on success (in which case + ret is filled in), or a negative + errno-style error code. + + + + + + See Also + + + systemd1, + sd-id1283, + machine-id5, + getrandom2, + random4, + sd_id128_get_machine3 + + + + diff --git a/man/sd_id128_to_string.xml b/man/sd_id128_to_string.xml new file mode 100644 index 0000000..e0338ba --- /dev/null +++ b/man/sd_id128_to_string.xml @@ -0,0 +1,122 @@ + + + + + + + + sd_id128_to_string + systemd + + + + sd_id128_to_string + 3 + + + + sd_id128_to_string + SD_ID128_TO_STRING + SD_ID128_STRING_MAX + sd_id128_to_uuid_string + SD_ID128_TO_UUID_STRING + SD_ID128_UUID_STRING_MAX + sd_id128_from_string + Format or parse 128-bit IDs as strings + + + + + #include <systemd/sd-id128.h> + + #define SD_ID128_STRING_MAX 33U + + #define SD_ID128_UUID_STRING_MAX 37U + + #define SD_ID128_TO_STRING(id) … + + #define SD_ID128_TO_UUID_STRING(id) … + + + char *sd_id128_to_string + sd_id128_t id, char s[static SD_ID128_STRING_MAX] + + + + char *sd_id128_uuid_string + sd_id128_t id, char s[static SD_ID128_UUID_STRING_MAX] + + + + int sd_id128_from_string + const char *s, sd_id128_t *ret + + + + + + + Description + + sd_id128_to_string() formats a 128-bit ID as a character string. It expects + the ID and a string array capable of storing 33 characters + (SD_ID128_STRING_MAX). The ID will be formatted as 32 lowercase hexadecimal digits + and be terminated by a NUL byte. + + SD_ID128_TO_STRING() is a macro that wraps + sd_id128_to_string() and passes an appropriately sized buffer as second argument, + allocated as C99 compound literal. Each use will thus implicitly acquire a suitable buffer on the stack + which remains valid until the end of the current code block. This is usually the simplest way to acquire + a string representation of a 128-bit ID in a buffer that is valid in the current code block. + + sd_id128_to_uuid_string() and SD_ID128_TO_UUID_STRING() + are similar to these two functions/macros, but format the 128bit values as RFC4122 UUIDs, i.e. a series + of 36 lowercase hexadeciaml digits and dashes, terminated by a NUL byte. + + sd_id128_from_string() implements the reverse operation: it takes a 33 + character string with 32 hexadecimal digits (either lowercase or uppercase, terminated by + NUL) and parses them back into a 128-bit ID returned in + ret. Alternatively, this call can also parse a 37-character string with a 128-bit + ID formatted as RFC UUID. If ret is passed as NULL the + function will validate the passed ID string, but not actually return it in parsed form. + + Note that when formatting and parsing 36 character UUIDs this is done strictly in Big Endian byte order, + i.e. according to RFC4122 Variant 1 rules, even + if the UUID encodes a different variant. This matches behaviour in various other Linux userspace + tools. It's probably wise to avoid UUIDs of other variant types. + + For more information about the sd_id128_t type see + sd-id1283. Note that + these calls operate the same way on all architectures, i.e. the results do not depend on + endianness. + + When formatting a 128-bit ID into a string, it is often easier to use a format string for + printf3. This + is easily done using the SD_ID128_FORMAT_STR and + SD_ID128_FORMAT_VAL() macros. For more information see + sd-id1283. + + + + Return Value + + sd_id128_to_string() always succeeds and returns a pointer to the string array + passed in. sd_id128_from_string() returns 0 on success, in which case + ret is filled in, or a negative errno-style error code. + + + + + + See Also + + + systemd1, + sd-id1283, + printf3 + + + + diff --git a/man/sd_is_fifo.xml b/man/sd_is_fifo.xml new file mode 100644 index 0000000..99f1524 --- /dev/null +++ b/man/sd_is_fifo.xml @@ -0,0 +1,201 @@ + + + + + + + + sd_is_fifo + systemd + + + + sd_is_fifo + 3 + + + + sd_is_fifo + sd_is_socket + sd_is_socket_inet + sd_is_socket_unix + sd_is_socket_sockaddr + sd_is_mq + sd_is_special + Check the type of a file descriptor + + + + + #include <systemd/sd-daemon.h> + + + int sd_is_fifo + int fd + const char *path + + + + int sd_is_socket + int fd + int family + int type + int listening + + + + int sd_is_socket_inet + int fd + int family + int type + int listening + uint16_t port + + + + int sd_is_socket_sockaddr + int fd + int type + const struct sockaddr *addr + unsigned addr_len + int listening + + + + int sd_is_socket_unix + int fd + int type + int listening + const char *path + size_t length + + + + int sd_is_mq + int fd + const char *path + + + + int sd_is_special + int fd + const char *path + + + + + + + Description + + sd_is_fifo() may be called to check + whether the specified file descriptor refers to a FIFO or pipe. If + the path parameter is not + NULL, it is checked whether the FIFO is bound + to the specified file system path. + + sd_is_socket() may be called to check + whether the specified file descriptor refers to a socket. If the + family parameter is not + AF_UNSPEC, it is checked whether the socket + is of the specified family (AF_UNIX, + AF_INET, …). If the type + parameter is not 0, it is checked whether the socket is of the + specified type (SOCK_STREAM, + SOCK_DGRAM, …). If the + listening parameter is positive, it is + checked whether the socket is in accepting mode, i.e. + listen() has been called for it. If + listening is 0, it is checked whether the + socket is not in this mode. If the parameter is negative, no such + check is made. The listening parameter + should only be used for stream sockets and should be set to a + negative value otherwise. + + sd_is_socket_inet() is similar to + sd_is_socket(), but optionally checks the + IPv4 or IPv6 port number the socket is bound to, unless + port is zero. For this call + family must be passed as either + AF_UNSPEC, AF_INET, or + AF_INET6. + + sd_is_socket_sockaddr() is similar to + sd_is_socket_inet(), but checks if the socket is bound to the + address specified by addr. The + family specified by addr must be + either AF_INET or AF_INET6 and + addr_len must be large enough for that family. If + addr specifies a non-zero port, it is also checked if the + socket is bound to this port. In addition, for IPv6, if addr + specifies non-zero sin6_flowinfo or + sin6_scope_id, it is checked if the socket has the same + values. + + sd_is_socket_unix() is similar to + sd_is_socket() but optionally checks the + AF_UNIX path the socket is bound to, unless + the path parameter is + NULL. For normal file system + AF_UNIX sockets, set the + length parameter to 0. For Linux abstract + namespace sockets, set the length to the + size of the address, including the initial 0 byte, and set the + path to the initial 0 byte of the socket + address. + + sd_is_mq() may be called to check + whether the specified file descriptor refers to a POSIX message + queue. If the path parameter is not + NULL, it is checked whether the message queue + is bound to the specified name. + + sd_is_special() may be called to check + whether the specified file descriptor refers to a special file. If + the path parameter is not + NULL, it is checked whether the file + descriptor is bound to the specified filename. Special files in + this context are character device nodes and files in + /proc/ or /sys/. + + + + Return Value + + On failure, these calls return a negative errno-style error + code. If the file descriptor is of the specified type and bound to + the specified address, a positive return value is returned, + otherwise zero. + + + + Notes + + + + Internally, these function use a combination of + fstat() and + getsockname() to check the file descriptor + type and where it is bound to. + + + + See Also + + systemd1, + sd-daemon3, + sd_listen_fds3, + systemd.service5, + systemd.socket5, + ip7, + ipv67, + unix7, + fifo7, + mq_overview7, + socket7. + + + + diff --git a/man/sd_journal_add_match.xml b/man/sd_journal_add_match.xml new file mode 100644 index 0000000..f7f5ee3 --- /dev/null +++ b/man/sd_journal_add_match.xml @@ -0,0 +1,177 @@ + + + + + + + + sd_journal_add_match + systemd + + + + sd_journal_add_match + 3 + + + + sd_journal_add_match + sd_journal_add_disjunction + sd_journal_add_conjunction + sd_journal_flush_matches + Add or remove entry matches + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_add_match + sd_journal *j + const void *data + size_t size + + + + int sd_journal_add_disjunction + sd_journal *j + + + + int sd_journal_add_conjunction + sd_journal *j + + + + void sd_journal_flush_matches + sd_journal *j + + + + + + Description + + sd_journal_add_match() adds a match by + which to filter the entries of the journal file. Matches applied + with this call will filter what can be iterated through and read + from the journal file via calls like + sd_journal_next3 + and + sd_journal_get_data3. + Parameter data must be of the form + FIELD=value, + where the FIELD part is a short uppercase string consisting only + of 0–9, A–Z and the underscore; it may not begin with two underscores or be the empty + string. The value part may be anything, including binary. Parameter + size specifies the number of bytes in data + (i.e. the length of FIELD, plus one, plus the length of + value). Parameter size may also be + specified as 0, in which case data + must be a NUL-terminated string, and the bytes before the terminating + zero are used as the match. + + If a match is applied, only entries with this field set + will be iterated. Multiple matches may be active at the same time: + If they apply to different fields, only entries with both fields + set like this will be iterated. If they apply to the same fields, + only entries where the field takes one of the specified values + will be iterated. Well known fields are documented in + systemd.journal-fields7. + Whenever a new match is added the current entry position is reset, + and + sd_journal_next3 + (or a similar call) needs to be called before entries can be read + again. + + sd_journal_add_disjunction() may be + used to insert a disjunction (i.e. logical OR) in the match list. + If this call is invoked, all previously added matches since the + last invocation of + sd_journal_add_disjunction() or + sd_journal_add_conjunction() are combined in + an OR with all matches added afterwards, until + sd_journal_add_disjunction() or + sd_journal_add_conjunction() is invoked again + to begin the next OR or AND term. + + sd_journal_add_conjunction() may be + used to insert a conjunction (i.e. logical AND) in the match list. + If this call is invoked, all previously added matches since the + last invocation of + sd_journal_add_conjunction() are combined in + an AND with all matches added afterwards, until + sd_journal_add_conjunction() is invoked again + to begin the next AND term. The combination of + sd_journal_add_match(), + sd_journal_add_disjunction() and + sd_journal_add_conjunction() may be used to + build complex search terms, even though full logical expressions + are not available. Note that + sd_journal_add_conjunction() operates one + level 'higher' than + sd_journal_add_disjunction(). It is hence + possible to build an expression of AND terms, consisting of OR + terms, consisting of AND terms, consisting of OR terms of matches + (the latter OR expression is implicitly created for matches with + the same field name, see above). + + sd_journal_flush_matches() may be used + to flush all matches, disjunction and conjunction terms again. + After this call all filtering is removed and all entries in the + journal will be iterated again. + + Note that filtering via matches only applies to the way the + journal is read, it has no effect on storage on disk. + + + + Return Value + + sd_journal_add_match(), + sd_journal_add_disjunction() and + sd_journal_add_conjunction() + return 0 on success or a negative errno-style error + code. sd_journal_flush_matches() + returns nothing. + + + + + + Examples + + The following example adds matches to a journal context + object to iterate only through messages generated by the Avahi + service at the four error log levels, plus all messages of the + message ID 03bb1dab98ab4ecfbf6fff2738bdd964 coming from any + service (this example lacks the necessary error checking): + + … +int add_matches(sd_journal *j) { + sd_journal_add_match(j, "_SYSTEMD_UNIT=avahi-daemon.service", 0); + sd_journal_add_match(j, "PRIORITY=0", 0); + sd_journal_add_match(j, "PRIORITY=1", 0); + sd_journal_add_match(j, "PRIORITY=2", 0); + sd_journal_add_match(j, "PRIORITY=3", 0); + sd_journal_add_disjunction(j); + sd_journal_add_match(j, "MESSAGE_ID=03bb1dab98ab4ecfbf6fff2738bdd964", 0); +} + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_data3, + systemd.journal-fields7 + + + + diff --git a/man/sd_journal_enumerate_fields.xml b/man/sd_journal_enumerate_fields.xml new file mode 100644 index 0000000..2d8055e --- /dev/null +++ b/man/sd_journal_enumerate_fields.xml @@ -0,0 +1,114 @@ + + + + + + + + sd_journal_enumerate_fields + systemd + + + + sd_journal_enumerate_fields + 3 + + + + sd_journal_enumerate_fields + sd_journal_restart_fields + SD_JOURNAL_FOREACH_FIELD + Read used field names from the journal + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_enumerate_fields + sd_journal *j + const char **field + + + + void sd_journal_restart_fields + sd_journal *j + + + + SD_JOURNAL_FOREACH_FIELD + sd_journal *j + const char *field + + + + + + + Description + + sd_journal_enumerate_fields() may be used to iterate through all field names used in the + opened journal files. On each invocation the next field name is returned. The order of the returned field names is + not defined. It takes two arguments: the journal context object, plus a pointer to a constant string pointer where + the field name is stored in. The returned data is in a read-only memory map and is only valid until the next + invocation of sd_journal_enumerate_fields(). Note that this call is subject to the data field + size threshold as controlled by sd_journal_set_data_threshold(). + + sd_journal_restart_fields() resets the field name enumeration index to the beginning of + the list. The next invocation of sd_journal_enumerate_fields() will return the first field + name again. + + The SD_JOURNAL_FOREACH_FIELD() macro may be used as a handy wrapper around + sd_journal_restart_fields() and sd_journal_enumerate_fields(). + + These functions currently are not influenced by matches set with sd_journal_add_match() + but this might change in a later version of this software. + + To retrieve the possible values a specific field can take use + sd_journal_query_unique3. + + + + Return Value + + sd_journal_enumerate_fields() returns a + positive integer if the next field name has been read, 0 when no + more field names are known, or a negative errno-style error code. + sd_journal_restart_fields() returns + nothing. + + + + Notes + + + + + + + + Examples + + Use the SD_JOURNAL_FOREACH_FIELD() macro to iterate through all field names in use in the + current journal. + + + + + + See Also + + + systemd1, + systemd.journal-fields7, + sd-journal3, + sd_journal_open3, + sd_journal_query_unique3, + sd_journal_get_data3, + sd_journal_add_match3 + + + + diff --git a/man/sd_journal_get_catalog.xml b/man/sd_journal_get_catalog.xml new file mode 100644 index 0000000..ad5992f --- /dev/null +++ b/man/sd_journal_get_catalog.xml @@ -0,0 +1,113 @@ + + + + + + + + sd_journal_get_catalog + systemd + + + + sd_journal_get_catalog + 3 + + + + sd_journal_get_catalog + sd_journal_get_catalog_for_message_id + Retrieve message catalog entry + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_get_catalog + sd_journal *j + char **ret + + + + int sd_journal_get_catalog_for_message_id + sd_id128_t id + char **ret + + + + + + + Description + + sd_journal_get_catalog() retrieves a + message catalog entry for the current journal entry. This will + look up an entry in the message catalog by using the + MESSAGE_ID= field of the current journal entry. + Before returning the entry all journal field names in the catalog + entry text enclosed in "@" will be replaced by the respective + field values of the current entry. If a field name referenced in + the message catalog entry does not exist, in the current journal + entry, the "@" will be removed, but the field name otherwise left + untouched. + + sd_journal_get_catalog_for_message_id() + works similar to sd_journal_get_catalog() but + the entry is looked up by the specified message ID (no open + journal context is necessary for this), and no field substitution + is performed. + + For more information about the journal message catalog + please refer to the Journal + Message Catalogs documentation page. + + + + Return Value + + sd_journal_get_catalog() and + sd_journal_get_catalog_for_message_id() + return 0 on success or a negative errno-style error code. If no + matching message catalog entry is found, -ENOENT is + returned. + + On successful return, ret points to a + new string, which must be freed with + free3. + + + + + Notes + + Function sd_journal_get_catalog() is thread-agnostic and only + a single specific thread may operate on a given object during its entire lifetime. It's safe to allocate multiple + independent objects and use each from a specific thread in parallel. However, it's not safe to allocate such an + object in one thread, and operate or free it from any other, even if locking is used to ensure these threads don't + operate on it at the very same time. + + Function sd_journal_get_catalog_for_message_id() is are thread-safe and may be called in + parallel from multiple threads. + + + + + + See Also + + + systemd1, + systemd.journal-fields7, + sd-journal3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_data3, + malloc3 + + + + diff --git a/man/sd_journal_get_cursor.xml b/man/sd_journal_get_cursor.xml new file mode 100644 index 0000000..acaba06 --- /dev/null +++ b/man/sd_journal_get_cursor.xml @@ -0,0 +1,114 @@ + + + + + + + + sd_journal_get_cursor + systemd + + + + sd_journal_get_cursor + 3 + + + + sd_journal_get_cursor + sd_journal_test_cursor + Get cursor string for or test cursor string against the current journal entry + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_get_cursor + sd_journal *j + char **cursor + + + + int sd_journal_test_cursor + sd_journal *j + const char *cursor + + + + + + + Description + + sd_journal_get_cursor() returns a + cursor string for the current journal entry. A cursor is a + serialization of the current journal position formatted as text. + The string only contains printable characters and can be passed + around in text form. The cursor identifies a journal entry + globally and in a stable way and may be used to later seek to it + via + sd_journal_seek_cursor3. + The cursor string should be considered opaque and not be parsed by + clients. Seeking to a cursor position without the specific entry + being available locally will seek to the next closest (in terms of + time) available entry. The call takes two arguments: a journal + context object and a pointer to a string pointer where the cursor + string will be placed. The string is allocated via libc + malloc3 + and should be freed after use with + free3. + + Note that sd_journal_get_cursor() will + not work before + sd_journal_next3 + (or related call) has been called at least once, in order to + position the read pointer at a valid entry. + + sd_journal_test_cursor() + may be used to check whether the current position in + the journal matches the specified cursor. This is + useful since cursor strings do not uniquely identify + an entry: the same entry might be referred to by + multiple different cursor strings, and hence string + comparing cursors is not possible. Use this call to + verify after an invocation of + sd_journal_seek_cursor3 + whether the entry being sought to was actually found + in the journal or the next closest entry was used + instead. + + + + Return Value + + sd_journal_get_cursor() returns 0 on + success or a negative errno-style error code. + sd_journal_test_cursor() returns positive if + the current entry matches the specified cursor, 0 if it does not + match the specified cursor or a negative errno-style error code on + failure. + + + + Notes + + + + + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_open3, + sd_journal_seek_cursor3 + + + + diff --git a/man/sd_journal_get_cutoff_realtime_usec.xml b/man/sd_journal_get_cutoff_realtime_usec.xml new file mode 100644 index 0000000..445130e --- /dev/null +++ b/man/sd_journal_get_cutoff_realtime_usec.xml @@ -0,0 +1,114 @@ + + + + + + + + sd_journal_get_cutoff_realtime_usec + systemd + + + + sd_journal_get_cutoff_realtime_usec + 3 + + + + sd_journal_get_cutoff_realtime_usec + sd_journal_get_cutoff_monotonic_usec + Read cut-off timestamps from the current journal entry + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_get_cutoff_realtime_usec + sd_journal *j + uint64_t *from + uint64_t *to + + + + int sd_journal_get_cutoff_monotonic_usec + sd_journal *j + sd_id128_t boot_id + uint64_t *from + uint64_t *to + + + + + + + Description + + sd_journal_get_cutoff_realtime_usec() + retrieves the realtime (wallclock) timestamps of the first and + last entries accessible in the journal. It takes three arguments: + the journal context object j and two + pointers from and to + pointing at 64-bit unsigned integers to store the timestamps in. + The timestamps are in microseconds since the epoch, i.e. + CLOCK_REALTIME. Either one of the two + timestamp arguments may be passed as NULL in + case the timestamp is not needed, but not both. + + sd_journal_get_cutoff_monotonic_usec() + retrieves the monotonic timestamps of the first and last entries + accessible in the journal. It takes three arguments: the journal + context object j, a 128-bit identifier for + the boot boot_id, and two pointers to + 64-bit unsigned integers to store the timestamps, + from and to. The + timestamps are in microseconds since boot-up of the specific boot, + i.e. CLOCK_MONOTONIC. Since the monotonic + clock begins new with every reboot it only defines a well-defined + point in time when used together with an identifier identifying + the boot, see + sd_id128_get_boot3 + for more information. The function will return the timestamps for + the boot identified by the passed boot ID. Either one of the two + timestamp arguments may be passed as NULL in + case the timestamp is not needed, but not both. + + + + Return Value + + sd_journal_get_cutoff_realtime_usec() + and sd_journal_get_cutoff_monotonic_usec() + return 1 on success, 0 if not suitable entries are in the journal + or a negative errno-style error code. + + Locations pointed to by parameters + from and to will be + set only if the return value is positive, and obviously, the + parameters are non-null. + + + + Notes + + + + + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_open3, + sd_journal_get_realtime_usec3, + sd_id128_get_boot3, + clock_gettime2 + + + + diff --git a/man/sd_journal_get_data.xml b/man/sd_journal_get_data.xml new file mode 100644 index 0000000..2955cd2 --- /dev/null +++ b/man/sd_journal_get_data.xml @@ -0,0 +1,276 @@ + + + + + + + + sd_journal_get_data + systemd + + + + sd_journal_get_data + 3 + + + + sd_journal_get_data + sd_journal_enumerate_data + sd_journal_enumerate_available_data + sd_journal_restart_data + SD_JOURNAL_FOREACH_DATA + sd_journal_set_data_threshold + sd_journal_get_data_threshold + Read data fields from the current journal entry + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_get_data + sd_journal *j + const char *field + const void **data + size_t *length + + + + int sd_journal_enumerate_data + sd_journal *j + const void **data + size_t *length + + + + int sd_journal_enumerate_available_data + sd_journal *j + const void **data + size_t *length + + + + void sd_journal_restart_data + sd_journal *j + + + + SD_JOURNAL_FOREACH_DATA + sd_journal *j + const void *data + size_t length + + + + int sd_journal_set_data_threshold + sd_journal *j + size_t sz + + + + int sd_journal_get_data_threshold + sd_journal *j + size_t *sz + + + + + + Description + + sd_journal_get_data() gets the data object associated with a specific field + from the current journal entry. It takes four arguments: the journal context object, a string with the + field name to request, plus a pair of pointers to pointer/size variables where the data object and its + size shall be stored in. The field name should be an entry field name. Well-known field names are listed in + systemd.journal-fields7, + but any field can be specified. The returned data is in a read-only memory map and is only valid until + the next invocation of sd_journal_get_data(), + sd_journal_enumerate_data(), + sd_journal_enumerate_available_data(), or when the read pointer is altered. Note + that the data returned will be prefixed with the field name and =. Also note that, by + default, data fields larger than 64K might get truncated to 64K. This threshold may be changed and turned + off with sd_journal_set_data_threshold() (see below). + + sd_journal_enumerate_data() may be used + to iterate through all fields of the current entry. On each + invocation the data for the next field is returned. The order of + these fields is not defined. The data returned is in the same + format as with sd_journal_get_data() and also + follows the same life-time semantics. + + sd_journal_enumerate_available_data() is similar to + sd_journal_enumerate_data(), but silently skips any fields which may be valid, but + are too large or not supported by current implementation. + + sd_journal_restart_data() resets the + data enumeration index to the beginning of the entry. The next + invocation of sd_journal_enumerate_data() + will return the first field of the entry again. + + Note that the SD_JOURNAL_FOREACH_DATA() macro may be used as a handy wrapper + around sd_journal_restart_data() and + sd_journal_enumerate_available_data(). + + Note that these functions will not work before + sd_journal_next3 + (or related call) has been called at least once, in order to + position the read pointer at a valid entry. + + sd_journal_set_data_threshold() may be + used to change the data field size threshold for data returned by + sd_journal_get_data(), + sd_journal_enumerate_data() and + sd_journal_enumerate_unique(). This threshold + is a hint only: it indicates that the client program is interested + only in the initial parts of the data fields, up to the threshold + in size — but the library might still return larger data objects. + That means applications should not rely exclusively on this + setting to limit the size of the data fields returned, but need to + apply an explicit size limit on the returned data as well. This + threshold defaults to 64K by default. To retrieve the complete + data fields this threshold should be turned off by setting it to + 0, so that the library always returns the complete data objects. + It is recommended to set this threshold as low as possible since + this relieves the library from having to decompress large + compressed data objects in full. + + sd_journal_get_data_threshold() returns + the currently configured data field size threshold. + + + + Return Value + + sd_journal_get_data() returns 0 on success or a negative errno-style error + code. sd_journal_enumerate_data() and + sd_journal_enumerate_available_data() return a positive integer if the next field + has been read, 0 when no more fields remain, or a negative errno-style error code. + sd_journal_restart_data() doesn't return anything. + sd_journal_set_data_threshold() and sd_journal_get_threshold() + return 0 on success or a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + -EINVAL + + One of the required parameters is NULL or invalid. + + + + + -ECHILD + + The journal object was created in a different process. + + + + -EADDRNOTAVAIL + + The read pointer is not positioned at a valid entry; + sd_journal_next3 + or a related call has not been called at least once. + + + + -ENOENT + + The current entry does not include the specified field. + + + + + -ENOMEM + + Memory allocation failed. + + + + -ENOBUFS + + A compressed entry is too large. + + + + -E2BIG + + The data field is too large for this computer architecture (e.g. above 4 GB on a + 32-bit architecture). + + + + -EPROTONOSUPPORT + + The journal is compressed with an unsupported method or the journal uses an + unsupported feature. + + + + -EBADMSG + + The journal is corrupted (possibly just the entry being iterated over). + + + + + -EIO + + An I/O error was reported by the kernel. + + + + + + + Notes + + + + + + + + Examples + + See + sd_journal_next3 + for a complete example how to use + sd_journal_get_data(). + + Use the + SD_JOURNAL_FOREACH_DATA() macro to + iterate through all fields of the current journal + entry: + + … +int print_fields(sd_journal *j) { + const void *data; + size_t length; + SD_JOURNAL_FOREACH_DATA(j, data, length) + printf("%.*s\n", (int) length, data); +} +… + + + + See Also + + + systemd1, + systemd.journal-fields7, + sd-journal3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_realtime_usec3, + sd_journal_query_unique3 + + + + diff --git a/man/sd_journal_get_fd.xml b/man/sd_journal_get_fd.xml new file mode 100644 index 0000000..6ca45c4 --- /dev/null +++ b/man/sd_journal_get_fd.xml @@ -0,0 +1,259 @@ + + + + + + + + sd_journal_get_fd + systemd + + + + sd_journal_get_fd + 3 + + + + sd_journal_get_fd + sd_journal_get_events + sd_journal_get_timeout + sd_journal_process + sd_journal_wait + sd_journal_reliable_fd + SD_JOURNAL_NOP + SD_JOURNAL_APPEND + SD_JOURNAL_INVALIDATE + Journal change notification + interface + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_get_fd + sd_journal *j + + + + int sd_journal_get_events + sd_journal *j + + + + int sd_journal_get_timeout + sd_journal *j + uint64_t *timeout_usec + + + + int sd_journal_process + sd_journal *j + + + + int sd_journal_wait + sd_journal *j + uint64_t timeout_usec + + + + int sd_journal_reliable_fd + sd_journal *j + + + + + + + Description + + sd_journal_get_fd() returns a file + descriptor that may be asynchronously polled in an external event + loop and is signaled as soon as the journal changes, because new + entries or files were added, rotation took place, or files have + been deleted, and similar. The file descriptor is suitable for + usage in + poll2. + Use sd_journal_get_events() for an events + mask to watch for. The call takes one argument: the journal + context object. Note that not all file systems are capable of + generating the necessary events for wakeups from this file + descriptor for changes to be noticed immediately. In particular + network files systems do not generate suitable file change events + in all cases. Cases like this can be detected with + sd_journal_reliable_fd(), below. + sd_journal_get_timeout() will ensure in these + cases that wake-ups happen frequently enough for changes to be + noticed, although with a certain latency. + + sd_journal_get_events() will return the + poll() mask to wait for. This function will + return a combination of POLLIN and + POLLOUT and similar to fill into the + .events field of struct + pollfd. + + sd_journal_get_timeout() will return a + timeout value for usage in poll(). This + returns a value in microseconds since the epoch of + CLOCK_MONOTONIC for timing out + poll() in timeout_usec. + See + clock_gettime2 + for details about CLOCK_MONOTONIC. If there + is no timeout to wait for, this will fill in (uint64_t) + -1 instead. Note that poll() takes + a relative timeout in milliseconds rather than an absolute timeout + in microseconds. To convert the absolute 'us' timeout into + relative 'ms', use code like the following: + + uint64_t t; +int msec; +sd_journal_get_timeout(m, &t); +if (t == (uint64_t) -1) + msec = -1; +else { + struct timespec ts; + uint64_t n; + clock_gettime(CLOCK_MONOTONIC, &ts); + n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000; + msec = t > n ? (int) ((t - n + 999) / 1000) : 0; +} + + The code above does not do any error checking for brevity's + sake. The calculated msec integer can be passed + directly as poll()'s timeout + parameter. + + After each poll() wake-up + sd_journal_process() needs to be called to + process events. This call will also indicate what kind of change + has been detected (see below; note that spurious wake-ups are + possible). + + A synchronous alternative for using + sd_journal_get_fd(), + sd_journal_get_events(), + sd_journal_get_timeout() and + sd_journal_process() is + sd_journal_wait(). It will synchronously wait + until the journal gets changed. The maximum time this call sleeps + may be controlled with the timeout_usec + parameter. Pass (uint64_t) -1 to wait + indefinitely. Internally this call simply combines + sd_journal_get_fd(), + sd_journal_get_events(), + sd_journal_get_timeout(), + poll() and + sd_journal_process() into one. + + sd_journal_reliable_fd() may be used to check whether the wake-up events from + the file descriptor returned by sd_journal_get_fd() are known to be quickly + triggered. On certain file systems where file change events from the OS are not available (such as NFS) + changes need to be polled for repeatedly, and hence are detected only with a considerable latency. This + call will return a positive value if the journal changes are detected quickly and zero when they need to + be polled for. Note that there is usually no need to invoke this function directly as + sd_journal_get_timeout() will request appropriate timeouts anyway. + + Note that all of the above change notification interfaces do not report changes + instantly. Latencies are introduced for multiple reasons: as mentioned certain storage backends require + time-based polling, in other cases wake-ups are optimized by coalescing events, and the OS introduces + additional IO/CPU scheduling latencies. + + + + Return Value + + sd_journal_get_fd() returns a valid + file descriptor on success or a negative errno-style error + code. + + sd_journal_get_events() returns a + combination of POLLIN, + POLLOUT and suchlike on success or a negative + errno-style error code. + + sd_journal_reliable_fd() returns a + positive integer if the file descriptor returned by + sd_journal_get_fd() will generate wake-ups + immediately for all journal changes. Returns 0 if there might be a + latency involved. + + sd_journal_process() and sd_journal_wait() return a negative + errno-style error code, or one of SD_JOURNAL_NOP, SD_JOURNAL_APPEND or + SD_JOURNAL_INVALIDATE on success: + + + If SD_JOURNAL_NOP is returned, the journal did not change since the last + invocation. + + If SD_JOURNAL_APPEND is returned, new entries have been appended to the end + of the journal. In this case it is sufficient to simply continue reading at the previous end location of the + journal, to read the newly added entries. + + If SD_JOURNAL_INVALIDATE, journal files were added to or removed from the + set of journal files watched (e.g. due to rotation or vacuuming), and thus entries might have appeared or + disappeared at arbitrary places in the log stream, possibly before or after the previous end of the log + stream. If SD_JOURNAL_INVALIDATE is returned, live-view UIs that want to reflect on screen + the precise state of the log data on disk should probably refresh their entire display (relative to the cursor of + the log entry on the top of the screen). Programs only interested in a strictly sequential stream of log data may + treat SD_JOURNAL_INVALIDATE the same way as SD_JOURNAL_APPEND, thus + ignoring any changes to the log view earlier than the old end of the log stream. + + + + + Signal safety + + In general, sd_journal_get_fd(), sd_journal_get_events(), and + sd_journal_get_timeout() are not "async signal safe" in the meaning of + signal-safety7. + Nevertheless, only the first call to any of those three functions performs unsafe operations, so subsequent calls + are safe. + + sd_journal_process() and sd_journal_wait() are not + safe. sd_journal_reliable_fd() is safe. + + + + Notes + + + + + + + + Examples + + Iterating through the journal, in a live view tracking all + changes: + + + + Waiting with poll() (this + example lacks all error checking for the sake of + simplicity): + + + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_open3, + sd_journal_next3, + poll2, + clock_gettime2 + + + + diff --git a/man/sd_journal_get_realtime_usec.xml b/man/sd_journal_get_realtime_usec.xml new file mode 100644 index 0000000..025b6a1 --- /dev/null +++ b/man/sd_journal_get_realtime_usec.xml @@ -0,0 +1,112 @@ + + + + + + + + sd_journal_get_realtime_usec + systemd + + + + sd_journal_get_realtime_usec + 3 + + + + sd_journal_get_realtime_usec + sd_journal_get_monotonic_usec + Read timestamps from the current journal entry + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_get_realtime_usec + sd_journal *j + uint64_t *usec + + + + int sd_journal_get_monotonic_usec + sd_journal *j + uint64_t *usec + sd_id128_t *boot_id + + + + + + + Description + + sd_journal_get_realtime_usec() gets the + realtime (wallclock) timestamp of the current journal entry. It + takes two arguments: the journal context object and a pointer to a + 64-bit unsigned integer to store the timestamp in. The timestamp + is in microseconds since the epoch, i.e. + CLOCK_REALTIME. + + sd_journal_get_monotonic_usec() gets + the monotonic timestamp of the current journal entry. It takes + three arguments: the journal context object, a pointer to a 64-bit + unsigned integer to store the timestamp in, as well as a 128-bit + ID buffer to store the boot ID of the monotonic timestamp. The + timestamp is in microseconds since boot-up of the specific boot, + i.e. CLOCK_MONOTONIC. Since the monotonic + clock begins new with every reboot, it only defines a well-defined + point in time when used together with an identifier identifying + the boot. See + sd_id128_get_boot3 + for more information. If the boot ID parameter is passed + NULL, the function will fail if the monotonic + timestamp of the current entry is not of the current system + boot. + + Note that these functions will not work before + sd_journal_next3 + (or related call) has been called at least + once, in order to position the read pointer at a valid entry. + + + + Return Value + + sd_journal_get_realtime_usec() and + sd_journal_get_monotonic_usec() returns 0 on + success or a negative errno-style error code. If the boot ID + parameter was passed NULL and the monotonic + timestamp of the current journal entry is not of the current + system boot, -ESTALE is returned by + sd_journal_get_monotonic_usec(). + + + + Notes + + + + + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_data3, + sd_id128_get_boot3, + clock_gettime2, + sd_journal_get_cutoff_realtime_usec3 + + + + diff --git a/man/sd_journal_get_usage.xml b/man/sd_journal_get_usage.xml new file mode 100644 index 0000000..e6fcd67 --- /dev/null +++ b/man/sd_journal_get_usage.xml @@ -0,0 +1,71 @@ + + + + + + + + sd_journal_get_usage + systemd + + + + sd_journal_get_usage + 3 + + + + sd_journal_get_usage + Journal disk usage + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_get_usage + sd_journal *j + uint64_t *bytes + + + + + + + Description + + sd_journal_get_usage() determines the + total disk space currently used by journal files (in bytes). If + SD_JOURNAL_LOCAL_ONLY was passed when opening + the journal, this value will only reflect the size of journal + files of the local host, otherwise of all hosts. + + + + Return Value + + sd_journal_get_usage() returns 0 on + success or a negative errno-style error code. + + + + Notes + + + + + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_open3, + + + + diff --git a/man/sd_journal_has_runtime_files.xml b/man/sd_journal_has_runtime_files.xml new file mode 100644 index 0000000..e452b49 --- /dev/null +++ b/man/sd_journal_has_runtime_files.xml @@ -0,0 +1,79 @@ + + + + + + + + + sd_journal_has_runtime_files + systemd + + + + sd_journal_has_runtime_files + 3 + + + + sd_journal_has_runtime_files + sd_journal_has_persistent_files + Query availability of runtime or persistent journal files + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_has_runtime_files + sd_journal *j + + + + int sd_journal_has_persistent_files + sd_journal *j + + + + + + + Description + + sd_journal_has_runtime_files() returns a positive value + if runtime journal files (present in /run/systemd/journal/) have been found. + Otherwise returns 0. + + sd_journal_has_persistent_files() returns a positive value + if persistent journal files (present in /var/log/journal/) have been found. + Otherwise returns 0. + + + + Return value + Both sd_journal_has_runtime_files() + and sd_journal_has_persistent_files() return -EINVAL + if their argument is NULL. + + + + + Notes + + + + + + + + See Also + + sd-journal3 + + + + diff --git a/man/sd_journal_next.xml b/man/sd_journal_next.xml new file mode 100644 index 0000000..628abb2 --- /dev/null +++ b/man/sd_journal_next.xml @@ -0,0 +1,148 @@ + + + + + + + + sd_journal_next + systemd + + + + sd_journal_next + 3 + + + + sd_journal_next + sd_journal_previous + sd_journal_next_skip + sd_journal_previous_skip + SD_JOURNAL_FOREACH + SD_JOURNAL_FOREACH_BACKWARDS + Advance or set back the read pointer in the journal + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_next + sd_journal *j + + + + int sd_journal_previous + sd_journal *j + + + + int sd_journal_next_skip + sd_journal *j + uint64_t skip + + + + int sd_journal_previous_skip + sd_journal *j + uint64_t skip + + + + SD_JOURNAL_FOREACH + sd_journal *j + + + + SD_JOURNAL_FOREACH_BACKWARDS + sd_journal *j + + + + + + Description + + sd_journal_next() advances the read + pointer into the journal by one entry. The only argument taken is + a journal context object as allocated via + sd_journal_open3. + After successful invocation the entry may be read with functions + such as + sd_journal_get_data3. + + Similarly, sd_journal_previous() sets + the read pointer back one entry. + + sd_journal_next_skip() and + sd_journal_previous_skip() advance/set back the read pointer by multiple + entries at once, as specified in the skip parameter. The skip + parameter must be less than or equal to 2147483647 (2³¹-1). + + The journal is strictly ordered by reception time, and hence + advancing to the next entry guarantees that the entry then + pointing to is later in time than then previous one, or has the + same timestamp. + + Note that + sd_journal_get_data3 + and related calls will fail unless + sd_journal_next() has been invoked at least + once in order to position the read pointer on a journal + entry. + + Note that the SD_JOURNAL_FOREACH() + macro may be used as a wrapper around + sd_journal_seek_head3 + and sd_journal_next() in order to make + iterating through the journal easier. See below for an example. + Similarly, SD_JOURNAL_FOREACH_BACKWARDS() may + be used for iterating the journal in reverse order. + + + + Return Value + + The four calls return the number of entries advanced/set + back on success or a negative errno-style error code. When the end + or beginning of the journal is reached, a number smaller than + requested is returned. More specifically, if + sd_journal_next() or + sd_journal_previous() reach the end/beginning + of the journal they will return 0, instead of 1 when they are + successful. This should be considered an EOF marker. + + + + Notes + + + + + + + + Examples + + Iterating through the journal: + + + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_open3, + sd_journal_get_data3, + sd_journal_get_realtime_usec3, + sd_journal_get_cursor3 + + + + diff --git a/man/sd_journal_open.xml b/man/sd_journal_open.xml new file mode 100644 index 0000000..8f62c96 --- /dev/null +++ b/man/sd_journal_open.xml @@ -0,0 +1,225 @@ + + + + + + + + sd_journal_open + systemd + + + + sd_journal_open + 3 + + + + sd_journal_open + sd_journal_open_directory + sd_journal_open_directory_fd + sd_journal_open_files + sd_journal_open_files_fd + sd_journal_open_namespace + sd_journal_close + sd_journal + SD_JOURNAL_LOCAL_ONLY + SD_JOURNAL_RUNTIME_ONLY + SD_JOURNAL_SYSTEM + SD_JOURNAL_CURRENT_USER + SD_JOURNAL_OS_ROOT + SD_JOURNAL_ALL_NAMESPACES + SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE + Open the system journal for reading + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_open + sd_journal **ret + int flags + + + + int sd_journal_open_namespace + sd_journal **ret + const char *namespace + int flags + + + + int sd_journal_open_directory + sd_journal **ret + const char *path + int flags + + + + int sd_journal_open_directory_fd + sd_journal **ret + int fd + int flags + + + + int sd_journal_open_files + sd_journal **ret + const char **paths + int flags + + + + int sd_journal_open_files_fd + sd_journal **ret + int fds[] + unsigned n_fds + int flags + + + + void sd_journal_close + sd_journal *j + + + + + + Description + + sd_journal_open() opens the log journal + for reading. It will find all journal files automatically and + interleave them automatically when reading. As first argument it + takes a pointer to a sd_journal pointer, which, + on success, will contain a journal context object. The second + argument is a flags field, which may consist of the following + flags ORed together: SD_JOURNAL_LOCAL_ONLY + makes sure only journal files generated on the local machine will + be opened. SD_JOURNAL_RUNTIME_ONLY makes sure + only volatile journal files will be opened, excluding those which + are stored on persistent storage. + SD_JOURNAL_SYSTEM will cause journal files of + system services and the kernel (in opposition to user session + processes) to be opened. + SD_JOURNAL_CURRENT_USER will cause journal + files of the current user to be opened. If neither + SD_JOURNAL_SYSTEM nor + SD_JOURNAL_CURRENT_USER are specified, all + journal file types will be opened. + + sd_journal_open_namespace() is similar to + sd_journal_open() but takes an additional namespace parameter + that specifies which journal namespace to operate on. If specified as NULL the call + is identical to sd_journal_open(). If non-NULL only data from + the namespace identified by the specified parameter is accessed. This call understands two additional + flags: if SD_JOURNAL_ALL_NAMESPACES is specified the + namespace parameter is ignored and all defined namespaces are accessed + simultaneously; if SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE the specified namespace and + the default namespace are accessed but no others (this flag has no effect when + namespace is passed as NULL). For details about journal + namespaces see + systemd-journald.service8. + + sd_journal_open_directory() is similar to sd_journal_open() but + takes an absolute directory path as argument. All journal files in this directory will be opened and interleaved + automatically. This call also takes a flags argument. The flags parameters accepted by this call are + SD_JOURNAL_OS_ROOT, SD_JOURNAL_SYSTEM, and + SD_JOURNAL_CURRENT_USER. If SD_JOURNAL_OS_ROOT is specified, journal + files are searched for below the usual /var/log/journal and + /run/log/journal relative to the specified path, instead of directly beneath it. + The other two flags limit which files are opened, the same as for sd_journal_open(). + + + sd_journal_open_directory_fd() is similar to + sd_journal_open_directory(), but takes a file descriptor referencing a directory in the file + system instead of an absolute file system path. + + sd_journal_open_files() is similar to sd_journal_open() but takes a + NULL-terminated list of file paths to open. All files will be opened and interleaved + automatically. This call also takes a flags argument, but it must be passed as 0 as no flags are currently + understood for this call. Please note that in the case of a live journal, this function is only useful for + debugging, because individual journal files can be rotated at any moment, and the opening of specific files is + inherently racy. + + sd_journal_open_files_fd() is similar to sd_journal_open_files() + but takes an array of open file descriptors that must reference journal files, instead of an array of file system + paths. Pass the array of file descriptors as second argument, and the number of array entries in the third. The + flags parameter must be passed as 0. + + sd_journal objects cannot be used in the + child after a fork. Functions which take a journal object as an + argument (sd_journal_next() and others) will + return -ECHILD after a fork. + + + sd_journal_close() will close the + journal context allocated with + sd_journal_open() or + sd_journal_open_directory() and free its + resources. + + When opening the journal only journal files accessible to + the calling user will be opened. If journal files are not + accessible to the caller, this will be silently ignored. + + See + sd_journal_next3 + for an example of how to iterate through the journal after opening + it with sd_journal_open(). + + A journal context object returned by + sd_journal_open() references a specific + journal entry as current entry, similar to a + file seek index in a classic file system file, but without + absolute positions. It may be altered with + sd_journal_next3 + and + sd_journal_seek_head3 + and related calls. The current entry position may be exported in + cursor strings, as accessible via + sd_journal_get_cursor3. + Cursor strings may be used to globally identify a specific journal + entry in a stable way and then later to seek to it (or if the + specific entry is not available locally, to its closest entry in + time) + sd_journal_seek_cursor3. + + Notification of journal changes is available via + sd_journal_get_fd() and related calls. + + + + Return Value + + The sd_journal_open(), + sd_journal_open_directory(), and + sd_journal_open_files() calls return 0 on + success or a negative errno-style error code. + sd_journal_close() returns nothing. + + + + Notes + + + + + + + + See Also + + + systemd1, + sd-journal3, + systemd-journald.service8, + sd_journal_next3, + sd_journal_get_data3 + + + + diff --git a/man/sd_journal_print.xml b/man/sd_journal_print.xml new file mode 100644 index 0000000..7778234 --- /dev/null +++ b/man/sd_journal_print.xml @@ -0,0 +1,276 @@ + + + + + + + + sd_journal_print + systemd + + + + sd_journal_print + 3 + + + + sd_journal_print + sd_journal_printv + sd_journal_send + sd_journal_sendv + sd_journal_perror + SD_JOURNAL_SUPPRESS_LOCATION + sd_journal_print_with_location + sd_journal_printv_with_location + sd_journal_send_with_location + sd_journal_sendv_with_location + sd_journal_perror_with_location + + Submit log entries to the journal + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_print + int priority + const char *format + … + + + + int sd_journal_printv + int priority + const char *format + va_list ap + + + + int sd_journal_send + const char *format + … + + + + int sd_journal_sendv + const struct iovec *iov + int n + + + + int sd_journal_perror + const char *message + + + + int sd_journal_print_with_location + int priority + const char *file + const char *line + const char *func + const char *format + … + + + + int sd_journal_printv_with_location + int priority + const char *file + const char *line + const char *func + const char *format + va_list ap + + + + int sd_journal_send_with_location + const char *file + const char *line + const char *func + const char *format + … + + + + int sd_journal_sendv_with_location + const char *file + const char *line + const char *func + const struct iovec *iov + int n + + + + int sd_journal_perror_with_location + const char *file + const char *line + const char *func + const char *message + + + + + + Description + + sd_journal_print() may be used to submit simple, plain text log entries to the system + journal. The first argument is a priority value. This is followed by a format string and its parameters, similar to + printf3 or + syslog3. + Note that currently the resulting message will be truncated to LINE_MAX - 8. + The priority value is one of LOG_EMERG, LOG_ALERT, + LOG_CRIT, LOG_ERR, LOG_WARNING, + LOG_NOTICE, LOG_INFO, LOG_DEBUG, as defined in + syslog.h, see syslog3 for details. It is + recommended to use this call to submit log messages in the application locale or system locale and in UTF-8 format, + but no such restrictions are enforced. Note that log messages written using this function are generally not + expected to end in a new-line character. However, as all trailing whitespace (including spaces, new-lines, + tabulators and carriage returns) are automatically stripped from the logged string, it is acceptable to specify one + (or more). Empty lines (after trailing whitespace removal) are suppressed. On non-empty lines, leading whitespace + (as well as inner whitespace) is left unmodified. + + sd_journal_printv() is similar to + sd_journal_print() but takes a variable + argument list encapsulated in an object of type + va_list (see + stdarg3 + for more information) instead of the format string. It is + otherwise equivalent in behavior. + + sd_journal_send() may be used to submit structured log entries to the system journal. It + takes a series of format strings, each immediately followed by their associated parameters, terminated by + NULL. The strings passed should be of the format VARIABLE=value. The + variable name must be in uppercase and consist only of characters, numbers and underscores, and may not begin with + an underscore. (All assignments that do not follow this syntax will be ignored.) The value can be of any size and + format. It is highly recommended to submit text strings formatted in the UTF-8 character encoding only, and submit + binary fields only when formatting in UTF-8 strings is not sensible. A number of well-known fields are defined, see + systemd.journal-fields7 for + details, but additional application defined fields may be used. A variable may be assigned more than one value per + entry. If this function is used, trailing whitespace is automatically removed from each formatted field. + + sd_journal_sendv() is similar to sd_journal_send() but takes an + array of struct iovec (as defined in uio.h, see readv3 for details) + instead of the format string. Each structure should reference one field of the entry to submit. The second argument + specifies the number of structures in the array. sd_journal_sendv() is particularly useful to + submit binary objects to the journal where that is necessary. Note that this function will not strip trailing + whitespace of the passed fields, but passes the specified data along unmodified. This is different from both + sd_journal_print() and sd_journal_send() described above, which are based + on format strings, and do strip trailing whitespace. + + sd_journal_perror() is a similar to + perror3 + and writes a message to the journal that consists of the passed + string, suffixed with ": " and a human-readable representation of + the current error code stored in + errno3. + If the message string is passed as NULL or + empty string, only the error string representation will be + written, prefixed with nothing. An additional journal field ERRNO= + is included in the entry containing the numeric error code + formatted as decimal string. The log priority used is + LOG_ERR (3). + + Note that sd_journal_send() is a + wrapper around sd_journal_sendv() to make it + easier to use when only text strings shall be submitted. Also, the + following two calls are mostly equivalent: + + sd_journal_print(LOG_INFO, "Hello World, this is PID %lu!", (unsigned long) getpid()); + +sd_journal_send("MESSAGE=Hello World, this is PID %lu!", (unsigned long) getpid(), + "PRIORITY=%i", LOG_INFO, + NULL); + + Note that these calls implicitly add fields for the source file, function name and code line where + invoked. This is implemented with macros. If this is not desired, it can be turned off by defining + SD_JOURNAL_SUPPRESS_LOCATION before including sd-journal.h. + + + sd_journal_print_with_location(), + sd_journal_printv_with_location(), sd_journal_send_with_location(), + sd_journal_sendv_with_location(), and + sd_journal_perror_with_location() are similar to their counterparts without + _with_location, but accept additional parameters to explicitly set the source file + name, function, and line. The arguments file and line must contain valid + journal entries including the variable name, e.g. CODE_FILE=src/foo.c and + CODE_LINE=666, while func must only contain the function name, i.e. the value + without CODE_FUNC=. These variants are primarily useful when writing custom wrappers, for + example in bindings for a different language. + + syslog3 + and sd_journal_print() may + largely be used interchangeably + functionality-wise. However, note that log messages + logged via the former take a different path to the + journal server than the later, and hence global + chronological ordering between the two streams cannot + be guaranteed. Using + sd_journal_print() has the + benefit of logging source code line, filenames, and + functions as metadata along all entries, and + guaranteeing chronological ordering with structured + log entries that are generated via + sd_journal_send(). Using + syslog() has the benefit of being + more portable. + + These functions implement a client to the Native Journal Protocol. + + + + Return Value + + The ten functions return 0 on success or a negative errno-style error code. The + errno3 + variable itself is not altered. + + If + systemd-journald8 + is not running (the socket is not present), those functions do + nothing, and also return 0. + + + + Thread safety + + + + sd_journal_sendv() and sd_journal_sendv_with_location() + are "async signal safe" in the meaning of + signal-safety7. + + + sd_journal_print(), + sd_journal_printv(), + sd_journal_send(), + sd_journal_perror(), + and their counterparts with _with_location + are not async signal safe. + + + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_stream_fd3, + syslog3, + perror3, + errno3, + systemd.journal-fields7, + signal7, + socket7 + + + + diff --git a/man/sd_journal_query_unique.xml b/man/sd_journal_query_unique.xml new file mode 100644 index 0000000..81ee55b --- /dev/null +++ b/man/sd_journal_query_unique.xml @@ -0,0 +1,175 @@ + + + + + + + + sd_journal_query_unique + systemd + + + + sd_journal_query_unique + 3 + + + + sd_journal_query_unique + sd_journal_enumerate_unique + sd_journal_enumerate_available_unique + sd_journal_restart_unique + SD_JOURNAL_FOREACH_UNIQUE + Read unique data fields from the journal + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_query_unique + sd_journal *j + const char *field + + + + int sd_journal_enumerate_available_unique + sd_journal *j + const void **data + size_t *length + + + + int sd_journal_enumerate_unique + sd_journal *j + const void **data + size_t *length + + + + void sd_journal_restart_unique + sd_journal *j + + + + SD_JOURNAL_FOREACH_UNIQUE + sd_journal *j + const void *data + size_t length + + + + + + + Description + + sd_journal_query_unique() queries the journal for all unique values the + specified field can take. It takes two arguments: the journal to query and the field name to look + for. Well-known field names are listed on + systemd.journal-fields7, + but any field can be specified. Field names must be specified without a trailing + =. After this function has been executed successfully the field values may be queried + using sd_journal_enumerate_unique() and + sd_journal_enumerate_available_unique(). Invoking one of those calls will change the + field name being queried and reset the enumeration index to the first field value that matches. + + sd_journal_enumerate_unique() may be used to iterate through all data fields + which match the previously selected field name as set with + sd_journal_query_unique(). On each invocation the next field data matching the field + name is returned. The order of the returned data fields is not defined. It takes three arguments: the + journal object, plus a pair of pointers to pointer/size variables where the data object and its size + shall be stored. The returned data is in a read-only memory map and is only valid until the next + invocation of sd_journal_enumerate_unique(). Note that the data returned will be + prefixed with the field name and =. Note that this call is subject to the data field + size threshold as controlled by sd_journal_set_data_threshold() and only the initial + part of the field up to the threshold is returned. An error is returned for fields which cannot be + retrieved. See the error list below for details. + + sd_journal_enumerate_available_unique() is similar to + sd_journal_enumerate_unique(), but silently skips any fields which may be valid, but + are too large or not supported by current implementation. + + sd_journal_restart_unique() resets the + data enumeration index to the beginning of the list. The next + invocation of sd_journal_enumerate_unique() + will return the first field data matching the field name + again. + + Note that the SD_JOURNAL_FOREACH_UNIQUE() macro may be used as a handy wrapper + around sd_journal_restart_unique() and + sd_journal_enumerate_available_unique(). + + Note that these functions currently are not influenced by + matches set with sd_journal_add_match() but + this might change in a later version of this software. + + To enumerate all field names currently in use (and thus all suitable field parameters for + sd_journal_query_unique()), use the + sd_journal_enumerate_fields3 + call. + + + + Return Value + + sd_journal_query_unique() returns 0 on success or a negative errno-style error + code. sd_journal_enumerate_unique() and + sd_journal_query_available_unique() return a positive integer if the next field data + has been read, 0 when no more fields remain, or a negative errno-style error code. + sd_journal_restart_unique() doesn't return anything. + + + Errors + + Returned errors may indicate the following problems: + + + + + + + + + + + + + + + + + Notes + + + + + + + + Examples + + Use the SD_JOURNAL_FOREACH_UNIQUE() macro to iterate through all values a field + of the journal can take (and which can be accessed on the given architecture and are not compressed with + an unsupported mechanism). The following example lists all unit names referenced in the journal: + + + + + + See Also + + + systemd1, + systemd.journal-fields7, + sd-journal3, + sd_journal_open3, + sd_journal_enumerate_fields3, + sd_journal_get_data3, + sd_journal_add_match3 + + + + diff --git a/man/sd_journal_seek_head.xml b/man/sd_journal_seek_head.xml new file mode 100644 index 0000000..869889a --- /dev/null +++ b/man/sd_journal_seek_head.xml @@ -0,0 +1,131 @@ + + + + + + + + sd_journal_seek_head + systemd + + + + sd_journal_seek_head + 3 + + + + sd_journal_seek_head + sd_journal_seek_tail + sd_journal_seek_monotonic_usec + sd_journal_seek_realtime_usec + sd_journal_seek_cursor + Seek to a position in the + journal + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_seek_head + sd_journal *j + + + + int sd_journal_seek_tail + sd_journal *j + + + + int sd_journal_seek_monotonic_usec + sd_journal *j + sd_id128_t boot_id + uint64_t usec + + + + int sd_journal_seek_realtime_usec + sd_journal *j + uint64_t usec + + + + int sd_journal_seek_cursor + sd_journal *j + const char *cursor + + + + + + Description + + sd_journal_seek_head() seeks to the beginning of the journal, i.e. to the + position before the oldest available entry. + + Similarly, sd_journal_seek_tail() may be used to seek to the end of the + journal, i.e. the position after the most recent available entry. + + sd_journal_seek_monotonic_usec() seeks to a position with the specified + monotonic timestamp, i.e. CLOCK_MONOTONIC. Since monotonic time restarts on every + reboot a boot ID needs to be specified as well. + + sd_journal_seek_realtime_usec() seeks to a position with the specified + realtime (wallclock) timestamp, i.e. CLOCK_REALTIME. Note that the realtime clock is + not necessarily monotonic. If a realtime timestamp is ambiguous, it is not defined which position is + sought to. + + sd_journal_seek_cursor() seeks to the position at the specified cursor + string. For details on cursors, see + sd_journal_get_cursor3. + If no entry matching the specified cursor is found the call will seek to the next closest entry (in terms + of time) instead. To verify whether the newly selected entry actually matches the cursor, use + sd_journal_test_cursor3. + + Note that these calls do not actually make any entry the new current entry, this needs to be done + in a separate step with a subsequent + sd_journal_next3 + invocation (or a similar call). Only then, entry data may be retrieved via + sd_journal_get_data3 + or an entry cursor be retrieved via + sd_journal_get_cursor3. + If no entry exists that matches exactly the specified seek address, the next closest is sought to. If + sd_journal_next3 is + used, the closest following entry will be sought to, if + sd_journal_previous3 + is used the closest preceding entry is sought to. + + + + Return Value + + The functions return 0 on success or a negative errno-style + error code. + + + + Notes + + + + + + + + See Also + + + systemd1, + sd-journal3, + sd_journal_open3, + sd_journal_next3, + sd_journal_get_data3, + sd_journal_get_cursor3, + sd_journal_get_realtime_usec3 + + + + diff --git a/man/sd_journal_stream_fd.xml b/man/sd_journal_stream_fd.xml new file mode 100644 index 0000000..40d2804 --- /dev/null +++ b/man/sd_journal_stream_fd.xml @@ -0,0 +1,120 @@ + + + + + + + + sd_journal_stream_fd + systemd + + + + sd_journal_stream_fd + 3 + + + + sd_journal_stream_fd + Create log stream file descriptor to the journal + + + + + #include <systemd/sd-journal.h> + + + int sd_journal_stream_fd + const char *identifier + int priority + int level_prefix + + + + + + + Description + + sd_journal_stream_fd() may be used to + create a log stream file descriptor. Log messages written to this + file descriptor as simple newline-separated text strings are + written to the journal. This file descriptor can be used + internally by applications or be made standard output or standard + error of other processes executed. + + sd_journal_stream_fd() takes a short + program identifier string as first argument, which will be written + to the journal as SYSLOG_IDENTIFIER= field for each log entry + (see + systemd.journal-fields7 + for more information). The second argument shall be the default + priority level for all messages. The priority level is one of + LOG_EMERG, LOG_ALERT, + LOG_CRIT, LOG_ERR, + LOG_WARNING, LOG_NOTICE, + LOG_INFO, LOG_DEBUG, as + defined in syslog.h, see + syslog3 + for details. The third argument is a boolean: if true kernel-style + log level prefixes (such as SD_WARNING) are + interpreted, see + sd-daemon3 + for more information. + + It is recommended that applications log UTF-8 messages only + with this API, but this is not enforced. + + Each invocation of sd_journal_stream_fd() allocates a new log stream file descriptor, + that is not shared with prior or later invocations. The file descriptor is write-only (its reading direction is + shut down), and O_NONBLOCK is turned off initially. + + + + Return Value + + The call returns a valid write-only file descriptor on + success or a negative errno-style error code. + + + + Signal safety + + sd_journal_stream_fd() is "async signal safe" in the meaning of signal-safety7. + + + + + Notes + + + + + + + + Examples + + Creating a log stream suitable for + fprintf3: + + + + + + See Also + + + systemd1, + sd-journal3, + sd-daemon3, + sd_journal_print3, + syslog3, + fprintf3, + systemd.journal-fields7 + + + + diff --git a/man/sd_listen_fds.xml b/man/sd_listen_fds.xml new file mode 100644 index 0000000..c37771b --- /dev/null +++ b/man/sd_listen_fds.xml @@ -0,0 +1,238 @@ + + + + + + + + sd_listen_fds + systemd + + + + sd_listen_fds + 3 + + + + sd_listen_fds + sd_listen_fds_with_names + SD_LISTEN_FDS_START + Check for file descriptors passed by the system manager + + + + + #include <systemd/sd-daemon.h> + + #define SD_LISTEN_FDS_START 3 + + + int sd_listen_fds + int unset_environment + + + + int sd_listen_fds_with_names + int unset_environment + char*** names + + + + + + Description + + sd_listen_fds() may be invoked by a daemon to check for file descriptors + passed by the service manager as part of the socket-based activation logic. It returns the number of + received file descriptors. If no file descriptors have been received, zero is returned. The first file + descriptor may be found at file descriptor number 3 (i.e. SD_LISTEN_FDS_START), the + remaining descriptors follow at 4, 5, 6, …, if any. + + The file descriptors passed this way may be closed at will by the processes receiving them: it's up + to the processes themselves to close them after use or whether to leave them open until the process exits + (in which case the kernel closes them automatically). Note that the file descriptors received by daemons + are duplicates of the file descriptors the service manager originally allocated and bound and of which it + continuously keeps a copy (except if Accept=yes is used). This means any socket option + changes and other changes made to the sockets will be visible to the service manager too. Most + importantly this means it's generally not a good idea to invoke shutdown2 on + such sockets, since it will shut down communication on the file descriptor the service manager holds for + the same socket too. Also note that if a daemon is restarted (and its associated sockets are not) it will + receive file descriptors to the very same sockets as the earlier invocations, thus all socket options + applied then will still apply. + + If a daemon receives more than one file descriptor, they will be passed in the same order as + configured in the systemd socket unit file (see + systemd.socket5 for + details) — if there's only one such file (see below). Nonetheless, it is recommended to verify the + correct socket types before using them. To simplify this checking, the functions + sd_is_fifo3, + sd_is_socket3, + sd_is_socket_inet3, + sd_is_socket_unix3 are + provided. In order to maximize flexibility, it is recommended to make these checks as loose as possible + without allowing incorrect setups. i.e. often, the actual port number a socket is bound to matters little + for the service to work, hence it should not be verified. On the other hand, whether a socket is a + datagram or stream socket matters a lot for the most common program logics and should be checked. + + This function call will set the FD_CLOEXEC flag for all + passed file descriptors to avoid further inheritance to children + of the calling process. + + If multiple socket units activate the same service, the order + of the file descriptors passed to its main process is undefined. + If additional file descriptors have been passed to the service + manager using + sd_pid_notify_with_fds3's + FDSTORE=1 messages, these file descriptors are + passed last, in arbitrary order, and with duplicates + removed. + + If the unset_environment parameter is + non-zero, sd_listen_fds() will unset the + $LISTEN_FDS, $LISTEN_PID and + $LISTEN_FDNAMES environment variables before + returning (regardless of whether the function call itself + succeeded or not). Further calls to + sd_listen_fds() will then return zero, but the + variables are no longer inherited by child processes. + + sd_listen_fds_with_names() is like + sd_listen_fds(), but optionally also returns + an array of strings with identification names for the passed file + descriptors, if that is available and the + names parameter is non-NULL. This + information is read from the $LISTEN_FDNAMES + variable, which may contain a colon-separated list of names. For + socket-activated services, these names may be configured with the + FileDescriptorName= setting in socket unit + files, see + systemd.socket5 + for details. For file descriptors pushed into the file descriptor + store (see above), the name is set via the + FDNAME= field transmitted via + sd_pid_notify_with_fds(). The primary usecase + for these names are services which accept a variety of file + descriptors which are not recognizable with functions like + sd_is_socket() alone, and thus require + identification via a name. It is recommended to rely on named file + descriptors only if identification via + sd_is_socket() and related calls is not + sufficient. Note that the names used are not unique in any + way. The returned array of strings has as many entries as file + descriptors have been received, plus a final NULL pointer + terminating the array. The caller needs to free the array itself + and each of its elements with libc's free() + call after use. If the names parameter is + NULL, the call is entirely equivalent to + sd_listen_fds(). + + Under specific conditions, the following automatic file + descriptor names are returned: + + + + <command>Special names</command> + + + + + + Name + Description + + + + + unknown + The process received no name for the specific file descriptor from the service manager. + + + + stored + The file descriptor originates in the service manager's per-service file descriptor store, and the FDNAME= field was absent when the file descriptor was submitted to the service manager. + + + + connection + The service was activated in per-connection style using Accept=yes in the socket unit file, and the file descriptor is the connection socket. + + + +
+ + + + + Return Value + + On failure, these calls returns a negative errno-style error + code. If + $LISTEN_FDS/$LISTEN_PID was + not set or was not correctly set for this daemon and hence no file + descriptors were received, 0 is returned. Otherwise, the number of + file descriptors passed is returned. The application may find them + starting with file descriptor SD_LISTEN_FDS_START, i.e. file + descriptor 3. + + + + Notes + + + + Internally, sd_listen_fds() checks + whether the $LISTEN_PID environment variable + equals the daemon PID. If not, it returns immediately. Otherwise, + it parses the number passed in the $LISTEN_FDS + environment variable, then sets the FD_CLOEXEC flag for the parsed + number of file descriptors starting from SD_LISTEN_FDS_START. + Finally, it returns the parsed + number. sd_listen_fds_with_names() does the + same but also parses $LISTEN_FDNAMES if + set. + + These functions are not designed for services that specify StandardInput=socket + as the $LISTEN_FDS variable is not set in their environment. + + + + Environment + + + + $LISTEN_PID + $LISTEN_FDS + $LISTEN_FDNAMES + + Set by the service manager for supervised + processes that use socket-based activation. This environment + variable specifies the data + sd_listen_fds() and + sd_listen_fds_with_names() parses. See + above for details. + + + + + + See Also + + + systemd1, + sd-daemon3, + sd_is_fifo3, + sd_is_socket3, + sd_is_socket_inet3, + sd_is_socket_unix3, + sd_pid_notify_with_fds3, + daemon7, + systemd.service5, + systemd.socket5 + + + + diff --git a/man/sd_login_monitor_new.xml b/man/sd_login_monitor_new.xml new file mode 100644 index 0000000..8118121 --- /dev/null +++ b/man/sd_login_monitor_new.xml @@ -0,0 +1,249 @@ + + + + + + + + sd_login_monitor_new + systemd + + + + sd_login_monitor_new + 3 + + + + sd_login_monitor_new + sd_login_monitor_unref + sd_login_monitor_unrefp + sd_login_monitor_flush + sd_login_monitor_get_fd + sd_login_monitor_get_events + sd_login_monitor_get_timeout + sd_login_monitor + Monitor login sessions, seats, users and virtual machines/containers + + + + + #include <systemd/sd-login.h> + + + int sd_login_monitor_new + const char *category + sd_login_monitor **ret + + + + sd_login_monitor *sd_login_monitor_unref + sd_login_monitor *m + + + + void sd_login_monitor_unrefp + sd_login_monitor **m + + + + int sd_login_monitor_flush + sd_login_monitor *m + + + + int sd_login_monitor_get_fd + sd_login_monitor *m + + + + int sd_login_monitor_get_events + sd_login_monitor *m + + + + int sd_login_monitor_get_timeout + sd_login_monitor *m + uint64_t *timeout_usec + + + + + + + Description + + sd_login_monitor_new() may be used to + monitor login sessions, users, seats, and virtual + machines/containers. Via a monitor object a file descriptor can be + integrated into an application defined event loop which is woken + up each time a user logs in, logs out or a seat is added or + removed, or a session, user, seat or virtual machine/container + changes state otherwise. The first parameter takes a string which + can be seat (to get only notifications about + seats being added, removed or changed), session + (to get only notifications about sessions being created or removed + or changed), uid (to get only notifications + when a user changes state in respect to logins) or + machine (to get only notifications when a + virtual machine or container is started or stopped). If + notifications shall be generated in all these conditions, + NULL may be passed. Note that in the future + additional categories may be defined. The second parameter returns + a monitor object and needs to be freed with the + sd_login_monitor_unref() call after + use. + + sd_login_monitor_unref() may be used to + destroy a monitor object. Note that this will invalidate any file + descriptor returned by + sd_login_monitor_get_fd(). + + sd_login_monitor_unrefp() is similar to + sd_login_monitor_unref() but takes a pointer + to a pointer to an sd_login_monitor object. This call + is useful in conjunction with GCC's and LLVM's Clean-up + Variable Attribute. Note that this function is defined as + inline function. Use a declaration like the following, in order to + allocate a login monitor object that is freed automatically as the + code block is left: + + { + __attribute__((cleanup(sd_login_monitor_unrefp))) sd_login_monitor *m = NULL; + int r; + … + r = sd_login_monitor_new(NULL, &m); + if (r < 0) { + errno = -r; + fprintf(stderr, "Failed to allocate login monitor object: %m\n"); + } + … +} + + sd_login_monitor_flush() may be used to + reset the wakeup state of the monitor object. Whenever an event + causes the monitor to wake up the event loop via the file + descriptor this function needs to be called to reset the wake-up + state. If this call is not invoked, the file descriptor will + immediately wake up the event loop again. + + sd_login_monitor_unref() and + sd_login_monitor_unrefp() execute no + operation if the passed in monitor object is + NULL. + + sd_login_monitor_get_fd() may be used + to retrieve the file descriptor of the monitor object that may be + integrated in an application defined event loop, based around + poll2 + or a similar interface. The application should include the + returned file descriptor as wake-up source for the events mask + returned by sd_login_monitor_get_events(). It + should pass a timeout value as returned by + sd_login_monitor_get_timeout(). Whenever a + wake-up is triggered the file descriptor needs to be reset via + sd_login_monitor_flush(). An application + needs to reread the login state with a function like + sd_get_seats3 + or similar to determine what changed. + + sd_login_monitor_get_events() will + return the poll() mask to wait for. This + function will return a combination of POLLIN, + POLLOUT and similar to fill into the + .events field of struct + pollfd. + + sd_login_monitor_get_timeout() will + return a timeout value for usage in poll(). + This returns a value in microseconds since the epoch of + CLOCK_MONOTONIC for timing out + poll() in timeout_usec. + See + clock_gettime2 + for details about CLOCK_MONOTONIC. If there + is no timeout to wait for this will fill in (uint64_t) + -1 instead. Note that poll() takes + a relative timeout in milliseconds rather than an absolute timeout + in microseconds. To convert the absolute 'µs' timeout into + relative 'ms', use code like the following: + + uint64_t t; +int msec; +sd_login_monitor_get_timeout(m, &t); +if (t == (uint64_t) -1) + msec = -1; +else { + struct timespec ts; + uint64_t n; + clock_gettime(CLOCK_MONOTONIC, &ts); + n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000; + msec = t > n ? (int) ((t - n + 999) / 1000) : 0; +} + + The code above does not do any error checking for brevity's + sake. The calculated msec integer can be passed + directly as poll()'s timeout + parameter. + + + + Return Value + + On success, + sd_login_monitor_new(), + sd_login_monitor_flush() and + sd_login_monitor_get_timeout() + return 0 or a positive integer. On success, + sd_login_monitor_get_fd() returns + a Unix file descriptor. On success, + sd_login_monitor_get_events() + returns a combination of POLLIN, + POLLOUT and suchlike. On failure, + these calls return a negative errno-style error + code. + + sd_login_monitor_unref() + always returns NULL. + + + Errors + + Returned errors may indicate the following problems: + + + + + -EINVAL + + An input parameter was invalid (out of range, or NULL, where + that is not accepted). The specified category to watch is not known. + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-login3, + sd_get_seats3, + poll2, + clock_gettime2 + + + + diff --git a/man/sd_machine_get_class.xml b/man/sd_machine_get_class.xml new file mode 100644 index 0000000..6e5fe9e --- /dev/null +++ b/man/sd_machine_get_class.xml @@ -0,0 +1,116 @@ + + + + + + + + sd_machine_get_class + systemd + + + + sd_machine_get_class + 3 + + + + sd_machine_get_class + sd_machine_get_ifindices + Determine the class and network interface indices of a + locally running virtual machine or container + + + + + #include <systemd/sd-login.h> + + + int sd_machine_get_class + const char* machine + char **class + + + + int sd_machine_get_ifindices + const char* machine + int **ret_ifindices + + + + + + Description + + sd_machine_get_class() may be used to + determine the class of a locally running virtual machine or + container that is registered with + systemd-machined.service8. + The string returned is either vm or + container. The returned string needs to be + freed with the libc free3 + call after use. + + sd_machine_get_ifindices() may be used to determine the numeric indices of the + network interfaces on the host that are pointing towards the specified locally running virtual machine or + container. The vm or container must be registered with + systemd-machined.service8. + The output parameter ret_ifindices may be passed as NULL when + the output value is not needed. The returned array needs to be freed with the libc free3 call after + use. + + + + Return Value + + On success, these functions return a non-negative integer. + sd_machine_get_ifindices() returns the number of the relevant network interfaces. + On failure, these calls return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -ENXIO + + The specified machine does not exist or is currently not running. + + + + + -EINVAL + + An input parameter was invalid (out of range, or NULL, where + that is not accepted). + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-login3, + systemd-machined.service8, + sd_pid_get_machine_name3 + + + + diff --git a/man/sd_notify.xml b/man/sd_notify.xml new file mode 100644 index 0000000..de40295 --- /dev/null +++ b/man/sd_notify.xml @@ -0,0 +1,471 @@ + + + + + + + + sd_notify + systemd + + + + sd_notify + 3 + + + + sd_notify + sd_notifyf + sd_pid_notify + sd_pid_notifyf + sd_pid_notify_with_fds + sd_notify_barrier + Notify service manager about start-up completion and other service status changes + + + + + #include <systemd/sd-daemon.h> + + + int sd_notify + int unset_environment + const char *state + + + + int sd_notifyf + int unset_environment + const char *format + … + + + + int sd_pid_notify + pid_t pid + int unset_environment + const char *state + + + + int sd_pid_notifyf + pid_t pid + int unset_environment + const char *format + … + + + + int sd_pid_notify_with_fds + pid_t pid + int unset_environment + const char *state + const int *fds + unsigned n_fds + + + + int sd_notify_barrier + int unset_environment + uint64_t timeout + + + + + + Description + sd_notify() may be called by a service + to notify the service manager about state changes. It can be used + to send arbitrary information, encoded in an + environment-block-like string. Most importantly, it can be used for + start-up completion notification. + + If the unset_environment parameter is + non-zero, sd_notify() will unset the + $NOTIFY_SOCKET environment variable before + returning (regardless of whether the function call itself + succeeded or not). Further calls to + sd_notify() will then fail, but the variable + is no longer inherited by child processes. + + The state parameter should contain a + newline-separated list of variable assignments, similar in style + to an environment block. A trailing newline is implied if none is + specified. The string may contain any kind of variable + assignments, but the following shall be considered + well-known: + + + + READY=1 + + Tells the service manager that service startup is finished, or the service finished loading its + configuration. This is only used by systemd if the service definition file has Type=notify + set. Since there is little value in signaling non-readiness, the only value services should send is + READY=1 (i.e. READY=0 is not defined). + + + + RELOADING=1 + + Tells the service manager that the service is + reloading its configuration. This is useful to allow the + service manager to track the service's internal state, and + present it to the user. Note that a service that sends this + notification must also send a READY=1 + notification when it completed reloading its + configuration. Reloads are propagated in the same way as they + are when initiated by the user. + + + + STOPPING=1 + + Tells the service manager that the service is + beginning its shutdown. This is useful to allow the service + manager to track the service's internal state, and present it + to the user. + + + + STATUS=… + + Passes a single-line UTF-8 status string back + to the service manager that describes the service state. This + is free-form and can be used for various purposes: general + state feedback, fsck-like programs could pass completion + percentages and failing programs could pass a human-readable + error message. Example: STATUS=Completed 66% of file + system check… + + + + ERRNO=… + + If a service fails, the errno-style error + code, formatted as string. Example: ERRNO=2 + for ENOENT. + + + + BUSERROR=… + + If a service fails, the D-Bus error-style + error code. Example: + BUSERROR=org.freedesktop.DBus.Error.TimedOut + + + + MAINPID=… + + The main process ID (PID) of the service, in + case the service manager did not fork off the process itself. + Example: MAINPID=4711 + + + + WATCHDOG=1 + + Tells the service manager to update the + watchdog timestamp. This is the keep-alive ping that services + need to issue in regular intervals if + WatchdogSec= is enabled for it. See + systemd.service5 + for information how to enable this functionality and + sd_watchdog_enabled3 + for the details of how the service can check whether the + watchdog is enabled. + + + + WATCHDOG=trigger + + Tells the service manager that the service detected an internal error that should be handled by + the configured watchdog options. This will trigger the same behaviour as if WatchdogSec= is + enabled and the service did not send WATCHDOG=1 in time. Note that + WatchdogSec= does not need to be enabled for WATCHDOG=trigger to trigger + the watchdog action. See + systemd.service5 for + information about the watchdog behavior. + + + + WATCHDOG_USEC=… + + Reset watchdog_usec value during runtime. + Notice that this is not available when using sd_event_set_watchdog() + or sd_watchdog_enabled(). + Example : WATCHDOG_USEC=20000000 + + + + EXTEND_TIMEOUT_USEC=… + + Tells the service manager to extend the startup, runtime or shutdown service timeout + corresponding the current state. The value specified is a time in microseconds during which the service must + send a new message. A service timeout will occur if the message isn't received, but only if the runtime of the + current state is beyond the original maximum times of TimeoutStartSec=, RuntimeMaxSec=, + and TimeoutStopSec=. + See systemd.service5 + for effects on the service timeouts. + + + + FDSTORE=1 + + Stores additional file descriptors in the service manager. File descriptors sent this way will + be maintained per-service by the service manager and will later be handed back using the usual file descriptor + passing logic at the next invocation of the service (e.g. when it is restarted), see + sd_listen_fds3. This is + useful for implementing services that can restart after an explicit request or a crash without losing + state. Any open sockets and other file descriptors which should not be closed during the restart may be stored + this way. Application state can either be serialized to a file in /run/, or better, stored + in a memfd_create2 memory + file descriptor. Note that the service manager will accept messages for a service only if its + FileDescriptorStoreMax= setting is non-zero (defaults to zero, see + systemd.service5). If + FDPOLL=0 is not set and the file descriptors sent are pollable (see + epoll_ctl2), then any + EPOLLHUP or EPOLLERR event seen on them will result in their + automatic removal from the store. Multiple arrays of file descriptors may be sent in separate messages, in + which case the arrays are combined. Note that the service manager removes duplicate (pointing to the same + object) file descriptors before passing them to the service. When a service is stopped, its file descriptor + store is discarded and all file descriptors in it are closed. Use sd_pid_notify_with_fds() + to send messages with FDSTORE=1, see below. + + + + FDSTOREREMOVE=1 + + Removes file descriptors from the file descriptor store. This field needs to be combined with + FDNAME= to specify the name of the file descriptors to remove. + + + + FDNAME=… + + When used in combination with FDSTORE=1, specifies a name for the submitted + file descriptors. When used with FDSTOREREMOVE=1, specifies the name for the file + descriptors to remove. This name is passed to the service during activation, and may be queried using + sd_listen_fds_with_names3. File + descriptors submitted without this field set, will implicitly get the name stored + assigned. Note that, if multiple file descriptors are submitted at once, the specified name will be assigned to + all of them. In order to assign different names to submitted file descriptors, submit them in separate + invocations of sd_pid_notify_with_fds(). The name may consist of arbitrary ASCII + characters except control characters or :. It may not be longer than 255 characters. If a + submitted name does not follow these restrictions, it is ignored. + + + + FDPOLL=0 + + When used in combination with FDSTORE=1, disables polling of the stored + file descriptors regardless of whether or not they are pollable. As this option disables automatic cleanup + of the stored file descriptors on EPOLLERR and EPOLLHUP, care must be taken to ensure proper manual cleanup. + Use of this option is not generally recommended except for when automatic cleanup has unwanted behavior such + as prematurely discarding file descriptors from the store. + + + + BARRIER=1 + + Tells the service manager that the client is explicitly requesting synchronization by + means of closing the file descriptor sent with this command. The service manager guarantees that the + processing of a BARRIER=1 command will only happen after all previous notification + messages sent before this command have been processed. Hence, this command accompanied with a single + file descriptor can be used to synchronize against reception of all previous status messages. Note + that this command cannot be mixed with other notifications, and has to be sent in a separate message + to the service manager, otherwise all assignments will be ignored. Note that sending 0 or more than 1 + file descriptor with this command is a violation of the protocol. + + + + It is recommended to prefix variable names that are not + listed above with X_ to avoid namespace + clashes. + + Note that systemd will accept status data sent from a + service only if the NotifyAccess= option is + correctly set in the service definition file. See + systemd.service5 + for details. + + Note that sd_notify() notifications may be attributed to units correctly only if either + the sending process is still around at the time PID 1 processes the message, or if the sending process is + explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally forked + off the process, i.e. on all processes that match NotifyAccess= or + NotifyAccess=. Conversely, if an auxiliary process of the unit sends an + sd_notify() message and immediately exits, the service manager might not be able to properly + attribute the message to the unit, and thus will ignore it, even if + NotifyAccess= is set for it. + + Hence, to eliminate all race conditions involving lookup of the client's unit and attribution of notifications + to units correctly, sd_notify_barrier() may be used. This call acts as a synchronization point + and ensures all notifications sent before this call have been picked up by the service manager when it returns + successfully. Use of sd_notify_barrier() is needed for clients which are not invoked by the + service manager, otherwise this synchronization mechanism is unnecessary for attribution of notifications to the + unit. + + sd_notifyf() is similar to + sd_notify() but takes a + printf()-like format string plus + arguments. + + sd_pid_notify() and + sd_pid_notifyf() are similar to + sd_notify() and + sd_notifyf() but take a process ID (PID) to + use as originating PID for the message as first argument. This is + useful to send notification messages on behalf of other processes, + provided the appropriate privileges are available. If the PID + argument is specified as 0, the process ID of the calling process + is used, in which case the calls are fully equivalent to + sd_notify() and + sd_notifyf(). + + sd_pid_notify_with_fds() is similar to + sd_pid_notify() but takes an additional array + of file descriptors. These file descriptors are sent along the + notification message to the service manager. This is particularly + useful for sending FDSTORE=1 messages, as + described above. The additional arguments are a pointer to the + file descriptor array plus the number of file descriptors in the + array. If the number of file descriptors is passed as 0, the call + is fully equivalent to sd_pid_notify(), i.e. + no file descriptors are passed. Note that sending file descriptors + to the service manager on messages that do not expect them (i.e. + without FDSTORE=1) they are immediately closed + on reception. + + sd_notify_barrier() allows the caller to + synchronize against reception of previously sent notification messages + and uses the BARRIER=1 command. It takes a relative + timeout value in microseconds which is passed to + ppoll2 + . A value of UINT64_MAX is interpreted as infinite timeout. + + + + + Return Value + + On failure, these calls return a negative errno-style error code. If $NOTIFY_SOCKET was + not set and hence no status message could be sent, 0 is returned. If the status was sent, these functions return a + positive value. In order to support both service managers that implement this scheme and those which do not, it is + generally recommended to ignore the return value of this call. Note that the return value simply indicates whether + the notification message was enqueued properly, it does not reflect whether the message could be processed + successfully. Specifically, no error is returned when a file descriptor is attempted to be stored using + FDSTORE=1 but the service is not actually configured to permit storing of file descriptors (see + above). + + + + Notes + + + + These functions send a single datagram with the + state string as payload to the AF_UNIX socket + referenced in the $NOTIFY_SOCKET environment + variable. If the first character of + $NOTIFY_SOCKET is @, the + string is understood as Linux abstract namespace socket. The + datagram is accompanied by the process credentials of the sending + service, using SCM_CREDENTIALS. + + + + Environment + + + + $NOTIFY_SOCKET + + Set by the service manager for supervised + processes for status and start-up completion notification. + This environment variable specifies the socket + sd_notify() talks to. See above for + details. + + + + + + Examples + + + Start-up Notification + + When a service finished starting up, it might issue the + following call to notify the service manager: + + sd_notify(0, "READY=1"); + + + + Extended Start-up Notification + + A service could send the following after completing + initialization: + + sd_notifyf(0, "READY=1\n" + "STATUS=Processing requests…\n" + "MAINPID=%lu", + (unsigned long) getpid()); + + + + Error Cause Notification + + A service could send the following shortly before exiting, on failure: + + sd_notifyf(0, "STATUS=Failed to start up: %s\n" + "ERRNO=%i", + strerror_r(errnum, (char[1024]){}, 1024), + errnum); + + + + Store a File Descriptor in the Service Manager + + To store an open file descriptor in the service manager, + in order to continue operation after a service restart without + losing state, use FDSTORE=1: + + sd_pid_notify_with_fds(0, 0, "FDSTORE=1\nFDNAME=foobar", &fd, 1); + + + + Eliminating race conditions + + When the client sending the notifications is not spawned + by the service manager, it may exit too quickly and the service + manager may fail to attribute them correctly to the unit. To + prevent such races, use sd_notify_barrier() + to synchronize against reception of all notifications sent before + this call is made. + + sd_notify(0, "READY=1"); + /* set timeout to 5 seconds */ + sd_notify_barrier(0, 5 * 1000000); + + + + + + See Also + + systemd1, + sd-daemon3, + sd_listen_fds3, + sd_listen_fds_with_names3, + sd_watchdog_enabled3, + daemon7, + systemd.service5 + + + + diff --git a/man/sd_path_lookup.xml b/man/sd_path_lookup.xml new file mode 100644 index 0000000..01fb1ed --- /dev/null +++ b/man/sd_path_lookup.xml @@ -0,0 +1,215 @@ + + + + + + + + sd_path_lookup + systemd + + + + sd_path_lookup + 3 + + + + sd_path_lookup + sd_path_lookup_strv + + Query well-known file system paths + + + + + #include <systemd/sd-path.h> + + + + enum { + SD_PATH_TEMPORARY, + SD_PATH_TEMPORARY_LARGE, + + SD_PATH_SYSTEM_BINARIES, + SD_PATH_SYSTEM_INCLUDE, + SD_PATH_SYSTEM_LIBRARY_PRIVATE, + SD_PATH_SYSTEM_LIBRARY_ARCH, + SD_PATH_SYSTEM_SHARED, + SD_PATH_SYSTEM_CONFIGURATION_FACTORY, + SD_PATH_SYSTEM_STATE_FACTORY, + + SD_PATH_SYSTEM_CONFIGURATION, + SD_PATH_SYSTEM_RUNTIME, + SD_PATH_SYSTEM_RUNTIME_LOGS, + SD_PATH_SYSTEM_STATE_PRIVATE, + SD_PATH_SYSTEM_STATE_LOGS, + SD_PATH_SYSTEM_STATE_CACHE, + SD_PATH_SYSTEM_STATE_SPOOL, + + SD_PATH_USER_BINARIES, + SD_PATH_USER_LIBRARY_PRIVATE, + SD_PATH_USER_LIBRARY_ARCH, + SD_PATH_USER_SHARED, + + SD_PATH_USER_CONFIGURATION, + SD_PATH_USER_RUNTIME, + SD_PATH_USER_STATE_CACHE, + + SD_PATH_USER, + SD_PATH_USER_DOCUMENTS, + SD_PATH_USER_MUSIC, + SD_PATH_USER_PICTURES, + SD_PATH_USER_VIDEOS, + SD_PATH_USER_DOWNLOAD, + SD_PATH_USER_PUBLIC, + SD_PATH_USER_TEMPLATES, + SD_PATH_USER_DESKTOP, + + SD_PATH_SEARCH_BINARIES, + SD_PATH_SEARCH_BINARIES_DEFAULT, + SD_PATH_SEARCH_LIBRARY_PRIVATE, + SD_PATH_SEARCH_LIBRARY_ARCH, + SD_PATH_SEARCH_SHARED, + SD_PATH_SEARCH_CONFIGURATION_FACTORY, + SD_PATH_SEARCH_STATE_FACTORY, + SD_PATH_SEARCH_CONFIGURATION, + + SD_PATH_SYSTEMD_UTIL, + SD_PATH_SYSTEMD_SYSTEM_UNIT, + SD_PATH_SYSTEMD_SYSTEM_PRESET, + SD_PATH_SYSTEMD_USER_UNIT, + SD_PATH_SYSTEMD_USER_PRESET, + SD_PATH_SYSTEMD_SYSTEM_CONF, + SD_PATH_SYSTEMD_USER_CONF, + SD_PATH_SYSTEMD_SEARCH_SYSTEM_UNIT, + SD_PATH_SYSTEMD_SEARCH_USER_UNIT, + SD_PATH_SYSTEMD_SYSTEM_GENERATOR, + SD_PATH_SYSTEMD_USER_GENERATOR, + SD_PATH_SYSTEMD_SEARCH_SYSTEM_GENERATOR, + SD_PATH_SYSTEMD_SEARCH_USER_GENERATOR, + SD_PATH_SYSTEMD_SLEEP, + SD_PATH_SYSTEMD_SHUTDOWN, + + SD_PATH_TMPFILES, + SD_PATH_SYSUSERS, + SD_PATH_SYSCTL, + SD_PATH_BINFMT, + SD_PATH_MODULES_LOAD, + SD_PATH_CATALOG, + + SD_PATH_SYSTEMD_SEARCH_NETWORK, +}; + + + int sd_path_lookup + uint64_t type + const char *suffix + char **paths + + + + int sd_path_lookup_strv + uint64_t type + const char *suffix + char ***paths + + + + + + Description + + sd_path_lookup() and sd_bus_path_lookup_strv() return a + single path or set of file system paths specified by the argument type. In case of + sd_path_lookup() a single NUL-terminated string is returned. + When type specifies a set of paths, they are concatenated using + : as a separator (as is traditionally done for e.g. $PATH or + $LD_LIBRARY_PATH). In case of sd_path_lookup_strv() a + NULL-terminated array of strings is returned (strv). If suffix + suffix is given, it is concatenated to each of the paths after a slash + (/). All returned paths are absolute. + + For paths which refer to user directories, the relevant XDG standard is followed, with support for + environment variables like $XDG_DOCUMENTS_DIR, $XDG_DESKTOP_DIR, + ..., and explicit configuration in /etc/xdg/user-dirs.conf or + ${XDG_CONFIG_HOME}/user-dirs.dirs. See + + XDG Base Directory Specification for details. + + systemd-path1 is + a wrapper around sd_path_lookup() and allows the same set of paths to be queried. + + + + + Return Value + + On success, sd_path_lookup() and sd_path_lookup_strv() + return a non-negative integer. On failure, a negative errno-style error number is returned by either + function. + + The returned string or string array (strv) must be + free3'd by the + caller. + + + Errors + + Returned errors may indicate the following problems: + + + + -EOPNOTSUPP + + Unknown identifier type. + + + + -EINVAL + + Output argument is NULL. + + + + -ENXIO + + Query failed because of an undefined environment variable (e.g. for + SD_PATH_USER_RUNTIME when $XDG_RUNTIME_DIR is not + defined). + + + + -ENOMEM + + Memory allocation failed. + + + + + + + Examples + + + Look up the location of ~/Documents + + + Note that the default answer of $HOME/Documents may be + overridden by user-dirs.conf or + $XDG_DOCUMENTS_DIR. + + + + + + + See Also + + + systemd-path1 + + + + diff --git a/man/sd_pid_get_owner_uid.xml b/man/sd_pid_get_owner_uid.xml new file mode 100644 index 0000000..c516083 --- /dev/null +++ b/man/sd_pid_get_owner_uid.xml @@ -0,0 +1,312 @@ + + + + + + + + sd_pid_get_owner_uid + systemd + + + + sd_pid_get_owner_uid + 3 + + + + sd_pid_get_owner_uid + sd_pid_get_session + sd_pid_get_user_unit + sd_pid_get_unit + sd_pid_get_machine_name + sd_pid_get_slice + sd_pid_get_user_slice + sd_pid_get_cgroup + sd_peer_get_owner_uid + sd_peer_get_session + sd_peer_get_user_unit + sd_peer_get_unit + sd_peer_get_machine_name + sd_peer_get_slice + sd_peer_get_user_slice + sd_peer_get_cgroup + Determine the owner uid of the user unit or session, + or the session, user unit, system unit, container/VM or slice that + a specific PID or socket peer belongs to + + + + + #include <systemd/sd-login.h> + + + int sd_pid_get_owner_uid + pid_t pid + uid_t *uid + + + + int sd_pid_get_session + pid_t pid + char **session + + + + int sd_pid_get_user_unit + pid_t pid + char **unit + + + + int sd_pid_get_unit + pid_t pid + char **unit + + + + int sd_pid_get_machine_name + pid_t pid + char **name + + + + int sd_pid_get_slice + pid_t pid + char **slice + + + + int sd_pid_get_user_slice + pid_t pid + char **slice + + + + int sd_pid_get_cgroup + pid_t pid + char **cgroup + + + + int sd_peer_get_owner_uid + int fd + uid_t *uid + + + + int sd_peer_get_session + int fd + char **session + + + + int sd_peer_get_user_unit + int fd + char **unit + + + + int sd_peer_get_unit + int fd + char **unit + + + + int sd_peer_get_machine_name + int fd + char **name + + + + int sd_peer_get_slice + int fd + char **slice + + + + int sd_peer_get_user_slice + int fd + char **slice + + + + int sd_peer_get_cgroup + int fd + char **cgroup + + + + + + Description + + sd_pid_get_owner_uid() may be used to + determine the Unix UID (user identifier) which owns the login + session or systemd user unit of a process identified by the + specified PID. For processes which are not part of a login session + and not managed by a user manager, this function will fail with + -ENODATA. + + sd_pid_get_session() may be used to + determine the login session identifier of a process identified by + the specified process identifier. The session identifier is a + short string, suitable for usage in file system paths. Please + note the login session may be limited to a stub process or two. + User processes may instead be started from their systemd user + manager, e.g. GUI applications started using DBus activation, as + well as service processes which are shared between multiple logins + of the same user. For processes which are not part of a login + session, this function will fail with -ENODATA. + The returned string needs to be freed with the libc free3 + call after use. + + sd_pid_get_user_unit() may be used to + determine the systemd user unit (i.e. user service or scope unit) + identifier of a process identified by the specified PID. The + unit name is a short string, suitable for usage in file system + paths. For processes which are not managed by a user manager, this + function will fail with -ENODATA. The + returned string needs to be freed with the libc free3 + call after use. + + sd_pid_get_unit() may be used to + determine the systemd system unit (i.e. system service or scope + unit) identifier of a process identified by the specified PID. The + unit name is a short string, suitable for usage in file system + paths. Note that not all processes are part of a system + unit/service. For processes not being part of a systemd system + unit, this function will fail with -ENODATA. + (More specifically, this call will not work for kernel threads.) + The returned string needs to be freed with the libc free3 + call after use. + + sd_pid_get_machine_name() may be used + to determine the name of the VM or container is a member of. The + machine name is a short string, suitable for usage in file system + paths. The returned string needs to be freed with the libc + free3 + call after use. For processes not part of a VM or container, this + function fails with -ENODATA. + + sd_pid_get_slice() may be used to + determine the slice unit the process is a member of. See + systemd.slice5 + for details about slices. The returned string needs to be freed + with the libc + free3 + call after use. + + Similarly, sd_pid_get_user_slice() + returns the user slice (as managed by the user's systemd instance) + of a process. + + sd_pid_get_cgroup() returns the control + group path of the specified process, relative to the root of the + hierarchy. Returns the path without trailing slash, except for + processes located in the root control group, where "/" is + returned. To find the actual control group path in the file system, + the returned path needs to be prefixed with + /sys/fs/cgroup/ (if the unified control group + setup is used), or + /sys/fs/cgroup/HIERARCHY/ + (if the legacy multi-hierarchy control group setup is used). + + If the pid parameter of any of these + functions is passed as 0, the operation is executed for the + calling process. + + The sd_peer_get_owner_uid(), + sd_peer_get_session(), + sd_peer_get_user_unit(), + sd_peer_get_unit(), + sd_peer_get_machine_name(), + sd_peer_get_slice(), + sd_peer_get_user_slice() and + sd_peer_get_cgroup() calls operate similarly to their PID counterparts, but accept a + connected AF_UNIX socket and retrieve information about the connected peer process. + Note that these fields are retrieved via /proc/, and hence are not suitable for + authorization purposes, as they are subject to races. + + + + Return Value + + On success, these calls return 0 or a positive integer. On failure, these calls return a negative + errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -ESRCH + + The specified PID does not refer to a running process. + + + + + -EBADF + + The specified socket file descriptor was invalid. + + + + -ENODATA + + The given field is not specified for the described process or peer. + + + + + -EINVAL + + An input parameter was invalid (out of range, or NULL, where + that is not accepted). + + + + -ENOMEM + + Memory allocation failed. + + + + + + + Notes + + + + Note that the login session identifier as + returned by sd_pid_get_session() + is completely unrelated to the process session + identifier as returned by + getsid2. + + + + See Also + + + systemd1, + sd-login3, + sd_session_is_active3, + getsid2, + systemd.slice5, + systemd-machined.service8 + + + + diff --git a/man/sd_seat_get_active.xml b/man/sd_seat_get_active.xml new file mode 100644 index 0000000..110862c --- /dev/null +++ b/man/sd_seat_get_active.xml @@ -0,0 +1,162 @@ + + + + + + + + sd_seat_get_active + systemd + + + + sd_seat_get_active + 3 + + + + sd_seat_get_active + sd_seat_get_sessions + sd_seat_can_tty + sd_seat_can_graphical + Determine state of a specific seat + + + + + #include <systemd/sd-login.h> + + + int sd_seat_get_active + const char *seat + char **session + uid_t *uid + + + + int sd_seat_get_sessions + const char *seat + char ***ret_sessions + uid_t **ret_uids + unsigned int *ret_n_uids + + + + int sd_seat_can_tty + const char *seat + + + + int sd_seat_can_graphical + const char *seat + + + + + + Description + + sd_seat_get_active() may be used to + determine which session is currently active on a seat, if there is + any. Returns the session identifier and the user identifier of the + Unix user the session is belonging to. Either the session or the + user identifier parameter can be passed NULL, + in case only one of the parameters shall be queried. The returned + string needs to be freed with the libc + free3 + call after use. + + sd_seat_get_sessions() may be used to determine all sessions on the specified + seat. Returns two arrays, one (NULL terminated) with the session identifiers of the + sessions and one with the user identifiers of the Unix users the sessions belong to. An additional + parameter may be used to return the number of entries in the latter array. This value is the same as the + return value if the return value is nonnegative. The output parameters may be passed as + NULL in case these output values are not needed. The arrays and the strings + referenced by them need to be freed with the libc free3 call after + use. Note that instead of an empty array NULL may be returned and should be + considered equivalent to an empty array. + + sd_seat_can_tty() may be used to + determine whether a specific seat provides TTY functionality, i.e. + is useful as a text console. + + sd_seat_can_graphical() may be used to + determine whether a specific seat provides graphics functionality, + i.e. is useful as a graphics display. + + If the seat parameter of any of these + functions is passed as NULL, the operation is + executed for the seat of the session of the calling process, if + there is any. + + + + Return Value + + On success, sd_seat_get_active() returns 0 or a positive integer. On success, + sd_seat_get_sessions() returns the number of entries in the session identifier + array. If the test succeeds, + sd_seat_can_tty() and sd_seat_can_graphical() return a positive + integer, if it fails 0. On failure, these calls return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -ENODATA + + The given field is not specified for the described seat. + + + + + -ENXIO + + The specified seat is unknown. + + + + + -EINVAL + + An input parameter was invalid (out of range, or NULL, where + that is not accepted). + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + History + + In the past, sd_seat_can_multi_session() was used to check whether the seat + supports multiple sessions. All seats support that now, so that function has been deprecated and always + returns true. + + + + See Also + + + systemd1, + sd-login3, + sd_session_get_seat3 + + + + diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml new file mode 100644 index 0000000..b69fa13 --- /dev/null +++ b/man/sd_session_is_active.xml @@ -0,0 +1,315 @@ + + + + + + + + sd_session_is_active + systemd + + + + sd_session_is_active + 3 + + + + sd_session_is_active + sd_session_is_remote + sd_session_get_state + sd_session_get_uid + sd_session_get_seat + sd_session_get_service + sd_session_get_type + sd_session_get_class + sd_session_get_desktop + sd_session_get_display + sd_session_get_tty + sd_session_get_vt + sd_session_get_remote_host + sd_session_get_remote_user + Determine state of a specific session + + + + + #include <systemd/sd-login.h> + + + int sd_session_is_active + const char *session + + + + int sd_session_is_remote + const char *session + + + + int sd_session_get_state + const char *session + char **state + + + + int sd_session_get_uid + const char *session + uid_t *uid + + + + int sd_session_get_seat + const char *session + char **seat + + + + int sd_session_get_service + const char *session + char **service + + + + int sd_session_get_type + const char *session + char **type + + + + int sd_session_get_class + const char *session + char **class + + + + int sd_session_get_desktop + const char *session + char **desktop + + + + int sd_session_get_display + const char *session + char **display + + + + int sd_session_get_remote_host + const char *session + char **remote_host + + + + int sd_session_get_remote_user + const char *session + char **remote_user + + + + int sd_session_get_tty + const char *session + char **tty + + + + int sd_session_get_vt + const char *session + unsigned int *vt + + + + + + Description + + sd_session_is_active() may be used to + determine whether the session identified by the specified session + identifier is currently active (i.e. currently in the foreground + and available for user input) or not. + + sd_session_is_remote() may be used to + determine whether the session identified by the specified session + identifier is a remote session (i.e. its remote host is known) or + not. + + sd_session_get_state() may be used to + determine the state of the session identified by the specified + session identifier. The following states are currently known: + online (session logged in, but session not + active, i.e. not in the foreground), active + (session logged in and active, i.e. in the foreground), + closing (session nominally logged out, but some + processes belonging to it are still around). In the future + additional states might be defined, client code should be written + to be robust in regards to additional state strings being + returned. This function is a more generic version of + sd_session_is_active(). The returned string + needs to be freed with the libc + free3 + call after use. + + sd_session_get_uid() may be used to + determine the user identifier of the Unix user the session + identified by the specified session identifier belongs to. + + sd_session_get_seat() may be used to + determine the seat identifier of the seat the session identified + by the specified session identifier belongs to. Note that not all + sessions are attached to a seat, this call will fail (returning + -ENODATA) for them. The returned string needs + to be freed with the libc + free3 + call after use. + + sd_session_get_service() may be used to + determine the name of the service (as passed during PAM session + setup) that registered the session identified by the specified + session identifier. The returned string needs to be freed with the + libc + free3 + call after use. + + sd_session_get_type() may be used to + determine the type of the session identified by the specified + session identifier. The returned string is one of + x11, wayland, + tty, mir or + unspecified and needs to be freed with the libc + free3 + call after use. + + sd_session_get_class() may be used to + determine the class of the session identified by the specified + session identifier. The returned string is one of + user, greeter, + lock-screen, or background + and needs to be freed with the libc + free3 + call after use. + + sd_session_get_desktop() may be used to + determine the brand of the desktop running on the session + identified by the specified session identifier. This field can be + set freely by desktop environments and does not follow any special + formatting. However, desktops are strongly recommended to use the + same identifiers and capitalization as for + $XDG_CURRENT_DESKTOP, as defined by the Desktop + Entry Specification. The returned string needs to be freed + with the libc + free3 + call after use. + + sd_session_get_display() may be used to + determine the X11 display of the session identified by the + specified session identifier. The returned string needs to be + freed with the libc + free3 + call after use. + + sd_session_get_remote_host() may be + used to determine the remote hostname of the session identified by + the specified session identifier. The returned string needs to be + freed with the libc + free3 + call after use. + + sd_session_get_remote_user() may be + used to determine the remote username of the session identified by + the specified session identifier. The returned string needs to be + freed with the libc + free3 + call after use. Note that this value is rarely known to the + system, and even then should not be relied on. + + sd_session_get_tty() may be used to + determine the TTY device of the session identified by the + specified session identifier. The returned string needs to be + freed with the libc + free3 + call after use. + + sd_session_get_vt() may be used to + determine the VT number of the session identified by the specified + session identifier. This function will return an error if the seat + does not support VTs. + + If the session parameter of any of these + functions is passed as NULL, the operation is + executed for the session the calling process is a member of, if + there is any. + + + + Return Value + + If the test succeeds, + sd_session_is_active() and + sd_session_is_remote() return a + positive integer; if it fails, 0. On success, + sd_session_get_state(), + sd_session_get_uid(), + sd_session_get_seat(), + sd_session_get_service(), + sd_session_get_type(), + sd_session_get_class(), + sd_session_get_display(), + sd_session_get_remote_user(), + sd_session_get_remote_host() and + sd_session_get_tty() return 0 or + a positive integer. On failure, these calls return a + negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -ENXIO + + The specified session does not exist. + + + + + -ENODATA + + The given field is not specified for the described session. + + + + + -EINVAL + + An input parameter was invalid (out of range, or NULL, where + that is not accepted). + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-login3, + sd_pid_get_session3 + + + + diff --git a/man/sd_uid_get_state.xml b/man/sd_uid_get_state.xml new file mode 100644 index 0000000..087a2d5 --- /dev/null +++ b/man/sd_uid_get_state.xml @@ -0,0 +1,191 @@ + + + + + + + + sd_uid_get_state + systemd + + + + sd_uid_get_state + 3 + + + + sd_uid_get_state + sd_uid_is_on_seat + sd_uid_get_sessions + sd_uid_get_seats + sd_uid_get_display + Determine login state of a specific Unix user ID + + + + + #include <systemd/sd-login.h> + + + int sd_uid_get_state + uid_t uid + char **state + + + + int sd_uid_is_on_seat + uid_t uid + int require_active + const char *seat + + + + int sd_uid_get_sessions + uid_t uid + int require_active + char ***sessions + + + + int sd_uid_get_seats + uid_t uid + int require_active + char ***seats + + + + int sd_uid_get_display + uid_t uid + char **session + + + + + + Description + + sd_uid_get_state() may be used to + determine the login state of a specific Unix user identifier. The + following states are currently known: offline + (user not logged in at all), lingering (user + not logged in, but some user services running), + online (user logged in, but not active, i.e. + has no session in the foreground), active (user + logged in, and has at least one active session, i.e. one session + in the foreground), closing (user not logged + in, and not lingering, but some processes are still around). In + the future additional states might be defined, client code should + be written to be robust in regards to additional state strings + being returned. The returned string needs to be freed with the + libc + free3 + call after use. + + sd_uid_is_on_seat() may be used to + determine whether a specific user is logged in or active on a + specific seat. Accepts a Unix user identifier and a seat + identifier string as parameters. The + require_active parameter is a boolean + value. If non-zero (true), this function will test if the user is + active (i.e. has a session that is in the foreground and accepting + user input) on the specified seat, otherwise (false) only if the + user is logged in (and possibly inactive) on the specified + seat. + + sd_uid_get_sessions() may be used to + determine the current sessions of the specified user. Accepts a + Unix user identifier as parameter. The + require_active parameter controls whether + the returned list shall consist of only those sessions where the + user is currently active (> 0), where the user is currently + online but possibly inactive (= 0), or logged in but + possibly closing the session (< 0). The call returns a + NULL terminated string array of session + identifiers in sessions which needs to be + freed by the caller with the libc + free3 + call after use, including all the strings referenced. If the + string array parameter is passed as NULL, the + array will not be filled in, but the return code still indicates + the number of current sessions. Note that instead of an empty + array NULL may be returned and should be + considered equivalent to an empty array. + + Similarly, sd_uid_get_seats() may be + used to determine the list of seats on which the user currently + has sessions. Similar semantics apply, however note that the user + may have multiple sessions on the same seat as well as sessions + with no attached seat and hence the number of entries in the + returned array may differ from the one returned by + sd_uid_get_sessions(). + + sd_uid_get_display() returns the name + of the "primary" session of a user. If the user has graphical + sessions, it will be the oldest graphical session. Otherwise, it + will be the oldest open session. + + + + Return Value + + On success, sd_uid_get_state() returns 0 or a positive integer. If the test + succeeds, sd_uid_is_on_seat() returns a positive integer; if it fails, 0. + sd_uid_get_sessions() and sd_uid_get_seats() return the number + of entries in the returned arrays. sd_uid_get_display() returns a non-negative code + on success. On failure, these calls return a negative errno-style error code. + + + Errors + + Returned errors may indicate the following problems: + + + + + -ENODATA + + The given field is not specified for the described user. + + + + + -ENXIO + + The specified seat is unknown. + + + + + -EINVAL + + An input parameter was invalid (out of range, or NULL, + where that is not accepted). This is also returned if the passed user ID is + 0xFFFF or 0xFFFFFFFF, which are undefined on Linux. + + + + + -ENOMEM + + Memory allocation failed. + + + + + + + + + See Also + + + systemd1, + sd-login3, + sd_pid_get_owner_uid3 + + + + diff --git a/man/sd_watchdog_enabled.xml b/man/sd_watchdog_enabled.xml new file mode 100644 index 0000000..1abc2f8 --- /dev/null +++ b/man/sd_watchdog_enabled.xml @@ -0,0 +1,142 @@ + + + + + + + + sd_watchdog_enabled + systemd + + + + sd_watchdog_enabled + 3 + + + + sd_watchdog_enabled + Check whether the service manager expects watchdog keep-alive notifications from a service + + + + + #include <systemd/sd-daemon.h> + + + int sd_watchdog_enabled + int unset_environment + uint64_t *usec + + + + + + Description + sd_watchdog_enabled() may be called by + a service to detect whether the service manager expects regular + keep-alive watchdog notification events from it, and the timeout + after which the manager will act on the service if it did not get + such a notification. + + If the $WATCHDOG_USEC environment + variable is set, and the $WATCHDOG_PID variable + is unset or set to the PID of the current process, the service + manager expects notifications from this process. The manager will + usually terminate a service when it does not get a notification + message within the specified time after startup and after each + previous message. It is recommended that a daemon sends a + keep-alive notification message to the service manager every half + of the time returned here. Notification messages may be sent with + sd_notify3 + with a message string of WATCHDOG=1. + + If the unset_environment parameter is + non-zero, sd_watchdog_enabled() will unset + the $WATCHDOG_USEC and + $WATCHDOG_PID environment variables before + returning (regardless of whether the function call itself + succeeded or not). Those variables are no longer inherited by + child processes. Further calls to + sd_watchdog_enabled() will also return with + zero. + + If the usec parameter is non-NULL, + sd_watchdog_enabled() will write the timeout + in µs for the watchdog logic to it. + + To enable service supervision with the watchdog logic, use + WatchdogSec= in service files. See + systemd.service5 + for details. + + Use + sd_event_set_watchdog3 + to enable automatic watchdog support in + sd-event3-based event loops. + + + + Return Value + + On failure, this call returns a negative errno-style error + code. If the service manager expects watchdog keep-alive + notification messages to be sent, > 0 is returned, otherwise 0 + is returned. Only if the return value is > 0, the + usec parameter is valid after the + call. + + + + Notes + + + + Internally, this function parses the + $WATCHDOG_PID and + $WATCHDOG_USEC environment variable. The call + will ignore these variables if $WATCHDOG_PID + does not contain the PID of the current process, under the + assumption that in that case, the variables were set for a + different process further up the process tree. + + + + Environment + + + + $WATCHDOG_PID + + Set by the system manager for supervised + process for which watchdog support is enabled, and contains + the PID of that process. See above for + details. + + + + $WATCHDOG_USEC + + Set by the system manager for supervised + process for which watchdog support is enabled, and contains + the watchdog timeout in µs. See above for + details. + + + + + + See Also + + systemd1, + sd-daemon3, + daemon7, + systemd.service5, + sd_notify3, + sd_event_set_watchdog3 + + + + diff --git a/man/send-unit-files-changed.c b/man/send-unit-files-changed.c new file mode 100644 index 0000000..dfd38a1 --- /dev/null +++ b/man/send-unit-files-changed.c @@ -0,0 +1,18 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#define _cleanup_(f) __attribute__((cleanup(f))) + +int send_unit_files_changed(sd_bus *bus) { + _cleanup_(sd_bus_message_unrefp) sd_bus_message *message = NULL; + int r; + + r = sd_bus_message_new_signal(bus, &message, + "/org/freedesktop/systemd1", + "org.freedesktop.systemd1.Manager", + "UnitFilesChanged"); + if (r < 0) + return r; + + return sd_bus_send(bus, message, NULL); +} diff --git a/man/shutdown.xml b/man/shutdown.xml new file mode 100644 index 0000000..24a934f --- /dev/null +++ b/man/shutdown.xml @@ -0,0 +1,156 @@ + + + + + + + + shutdown + systemd + + + + shutdown + 8 + + + + shutdown + Halt, power off or reboot the machine + + + + + shutdown + OPTIONS + TIME + WALL + + + + + Description + + shutdown may be used to halt, power off, or reboot the machine. + + The first argument may be a time string (which is usually + now). Optionally, this may be followed by a + wall message to be sent to all logged-in users before going + down. + + The time string may either be in the format + hh:mm for hour/minutes specifying the time to + execute the shutdown at, specified in 24h clock format. + Alternatively it may be in the syntax +m + referring to the specified number of minutes m from now. + now is an alias for +0, i.e. + for triggering an immediate shutdown. If no time argument is + specified, +1 is implied. + + Note that to specify a wall message you must specify a time + argument, too. + + If the time argument is used, 5 minutes before the system + goes down the /run/nologin file is created to + ensure that further logins shall not be allowed. + + + + Options + + The following options are understood: + + + + + + + + + + + + + Halt the machine. + + + + + + + Power the machine off (the default). + + + + + + + Reboot the machine. + + + + + + The same as , but does not override the action to take if + it is "halt". E.g. shutdown --reboot -h means "poweroff", but shutdown + --halt -h means "halt". + + + + + + Do not halt, power off, or reboot, but just write the wall message. + + + + + + Do not send wall message before halt, power off, or reboot. + + + + + + Cancel a pending shutdown. This may be used to cancel the effect of an invocation of + shutdown with a time argument that is not +0 or + now. + + + + + + Show a pending shutdown action and time if + there is any. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Compatibility + + The shutdown command in previous init systems (including sysvinit) defaulted to + single-user mode instead of powering off the machine. To change into single-user mode, use + systemctl rescue instead. + + + + See Also + + systemd1, + systemctl1, + halt8, + wall1 + + + + diff --git a/man/standard-conf.xml b/man/standard-conf.xml new file mode 100644 index 0000000..f02b9b0 --- /dev/null +++ b/man/standard-conf.xml @@ -0,0 +1,71 @@ + + + + + + + + Configuration Directories and Precedence + + Configuration files are read from directories in /etc/, + /run/, /usr/local/lib/, and /usr/lib/, in + order of precedence, as listed in the SYNOPSIS section above. Files must have the + .conf extension. Files in /etc/ override files with the same name + in /run/, /usr/local/lib/, and + /usr/lib/. Files in /run/ override files with the same name + under /usr/. + + All configuration files are sorted by their filename in lexicographic order, regardless of which of + the directories they reside in. If multiple files specify the same option, the entry in the file with the + lexicographically latest name will take precedence. Thus, the configuration in a certain file may either + be replaced completely (by placing a file with the same name in a directory with higher priority), or + individual settings might be changed (by specifying additional settings in a file with a different name + that is ordered later). + + Packages should install their configuration files in /usr/lib/ (distribution + packages) or /usr/local/lib/ (local installs). Files in /etc/ + are reserved for the local administrator, who may use this logic to override the configuration files + installed by vendor packages. It is recommended to prefix all filenames with a two-digit number and a + dash, to simplify the ordering of the files. + + If the administrator wants to disable a configuration file supplied by the vendor, the recommended + way is to place a symlink to /dev/null in the configuration directory in + /etc/, with the same filename as the vendor configuration file. If the vendor + configuration file is included in the initrd image, the image has to be regenerated. + + + + Configuration Directories and Precedence + + The default configuration is set during compilation, so configuration is only needed when it is + necessary to deviate from those defaults. Initially, the main configuration file in + /etc/systemd/ contains commented out entries showing the defaults as a guide to the + administrator. Local overrides can be created by editing this file or by creating drop-ins, as described + below. Using drop-ins for local configuration is recommended over modifications to the main configuration + file. + + In addition to the "main" configuration file, drop-in configuration snippets are read from + /usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/, + and /etc/systemd/*.conf.d/. Those drop-ins have higher precedence and override the + main configuration file. Files in the *.conf.d/ configuration subdirectories are + sorted by their filename in lexicographic order, regardless of in which of the subdirectories they + reside. When multiple files specify the same option, for options which accept just a single value, the + entry in the file sorted last takes precedence, and for options which accept a list of values, entries + are collected as they occur in the sorted files. + + When packages need to customize the configuration, they can install drop-ins under + /usr/. Files in /etc/ are reserved for the local administrator, + who may use this logic to override the configuration files installed by vendor packages. Drop-ins have to + be used to override package drop-ins, since the main configuration file has lower precedence. It is + recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to + simplify the ordering of the files. + + To disable a configuration file supplied by the vendor, the recommended way is to place a symlink + to /dev/null in the configuration directory in /etc/, with the + same filename as the vendor configuration file. + + diff --git a/man/standard-options.xml b/man/standard-options.xml new file mode 100644 index 0000000..d42f329 --- /dev/null +++ b/man/standard-options.xml @@ -0,0 +1,89 @@ + + + + + + + + + + + Print a short help text and exit. + + + + + + + + Print a short version string and exit. + + + + + + + + Do not pipe output into a pager. + + + + + + + Do not query the user for authentication for privileged operations. + + + + BOOL + + + Enable or disable printing of the legend, i.e. column headers and the footer with hints. The + legend is printed by default, unless disabled with or similar. + + + + + + + + Do not print the legend, i.e. column headers and the + footer with hints. + + + + + + + + Copy the contents of config files to standard output. + Before each file, the filename is printed as a comment. + + + + + MODE + + Shows output formatted as JSON. Expects one of short (for the + shortest possible output without any redundant whitespace or line breaks), pretty + (for a pretty version of the same, with indentation and line breaks) or off (to turn + off JSON output, the default). + + + + + + + + When used with kill, choose which signal to send to selected processes. Must + be one of the well-known signal specifiers such as SIGTERM, + SIGINT or SIGSTOP. If omitted, defaults to + . + + The special value help will list the known values and the program will exit + immediately, and the special value list will list known values along with the + numerical signal numbers and the program will exit immediately. + + + diff --git a/man/standard-specifiers.xml b/man/standard-specifiers.xml new file mode 100644 index 0000000..7aa7aca --- /dev/null +++ b/man/standard-specifiers.xml @@ -0,0 +1,90 @@ + + + + + + + + + %a + Architecture + A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit5 for a full list. + + + %A + Operating system image version + The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. + + + %b + Boot ID + The boot ID of the running system, formatted as string. See random4 for more information. + + + %B + Operating system build ID + The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. + + + %H + Host name + The hostname of the running system. + + + %l + Short host name + The hostname of the running system, truncated at the first dot to remove any domain component. + + + %m + Machine ID + The machine ID of the running system, formatted as string. See machine-id5 for more information. + + + %M + Operating system image identifier + The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. + + + %o + Operating system ID + The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release5 for more information. + + + %q + Pretty host name + The pretty hostname of the running system, as read from the PRETTY_HOSTNAME= field of /etc/machine-info. If not set, resolves to the short hostname. See machine-info5 for more information. + + + %T + Directory for temporary files + This is either /tmp or the path $TMPDIR, $TEMP or $TMP are set to. (Note that the directory may be specified without a trailing slash.) + + + %v + Kernel release + Identical to uname -r output. + + + %V + Directory for larger and persistent temporary files + This is either /var/tmp or the path $TMPDIR, $TEMP or $TMP are set to. (Note that the directory may be specified without a trailing slash.) + + + %w + Operating system version ID + The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. + + + %W + Operating system variant ID + The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. + + + %% + Single percent sign + Use %% in place of % to specify a single percent sign. + + diff --git a/man/supported-controllers.xml b/man/supported-controllers.xml new file mode 100644 index 0000000..61cdf46 --- /dev/null +++ b/man/supported-controllers.xml @@ -0,0 +1,14 @@ + + + + + + + +The following controller names may be specified: , , +, , , , , +, , and . + + diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml new file mode 100644 index 0000000..4d810e6 --- /dev/null +++ b/man/sysctl.d.xml @@ -0,0 +1,193 @@ + + + + + + + sysctl.d + systemd + + + + sysctl.d + 5 + + + + sysctl.d + Configure kernel parameters at boot + + + + /etc/sysctl.d/*.conf + /run/sysctl.d/*.conf + /usr/lib/sysctl.d/*.conf + + key.name.under.proc.sys = some value +key/name/under/proc/sys = some value +key/middle.part.with.dots/foo = 123 +key.middle/part/with/dots.foo = 123 +-key.that.will.not.fail = value +key.pattern.*.with.glob = whatever +-key.pattern.excluded.with.glob +key.pattern.overridden.with.glob = custom + + + + + Description + + At boot, + systemd-sysctl.service8 + reads configuration files from the above directories to configure + sysctl8 + kernel parameters. + + + + Configuration Format + + The configuration files contain a list of variable + assignments, separated by newlines. Empty lines and lines whose + first non-whitespace character is # or + ; are ignored. + + Note that either / or . may be used as separators within + sysctl variable names. If the first separator is a slash, remaining slashes and dots are left intact. If + the first separator is a dot, dots and slashes are interchanged. + kernel.domainname=foo and kernel/domainname=foo are equivalent and + will cause foo to be written to + /proc/sys/kernel/domainname. Either + net.ipv4.conf.enp3s0/200.forwarding or + net/ipv4/conf/enp3s0.200/forwarding may be used to refer to + /proc/sys/net/ipv4/conf/enp3s0.200/forwarding. A glob + glob7 pattern may be + used to write the same value to all matching keys. Keys for which an explicit pattern exists will be + excluded from any glob matching. In addition, a key may be explicitly excluded from being set by any + matching glob patterns by specifying the key name prefixed with a - character and not + followed by =, see SYNOPSIS. + + Any access permission errors and attempts to write variables not present on the local system are + logged at debug level and do not cause the service to fail. Other types of errors when setting variables + are logged with higher priority and cause the service to return failure at the end (after processing + other variables). As an exception, if a variable assignment is prefixed with a single + - character, failure to set the variable for any reason will be logged at debug level + and will not cause the service to fail. + + The settings configured with sysctl.d files will be applied early on boot. The + network interface-specific options will also be applied individually for each network interface as it + shows up in the system. (More specifically, net.ipv4.conf.*, + net.ipv6.conf.*, net.ipv4.neigh.* and + net.ipv6.neigh.*). + + Many sysctl parameters only become available when certain + kernel modules are loaded. Modules are usually loaded on demand, + e.g. when certain hardware is plugged in or network brought up. + This means that + systemd-sysctl.service8 + which runs during early boot will not configure such parameters if + they become available after it has run. To set such parameters, it + is recommended to add an + udev7 + rule to set those parameters when they become available. + Alternatively, a slightly simpler and less efficient option is to + add the module to + modules-load.d5, + causing it to be loaded statically before sysctl settings are + applied (see example below). + + + + + + Examples + + Set kernel YP domain name + /etc/sysctl.d/domain-name.conf: + + + kernel.domainname=example.com + + + + Apply settings available only when a certain module is loaded (method one) + /etc/udev/rules.d/99-bridge.rules: + + + ACTION=="add", SUBSYSTEM=="module", KERNEL=="br_netfilter", \ + RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/net/bridge" + + + /etc/sysctl.d/bridge.conf: + + + net.bridge.bridge-nf-call-ip6tables = 0 +net.bridge.bridge-nf-call-iptables = 0 +net.bridge.bridge-nf-call-arptables = 0 + + + This method applies settings when the module is + loaded. Please note that, unless the br_netfilter + module is loaded, bridged packets will not be filtered by + Netfilter (starting with kernel 3.18), so simply not loading the + module is sufficient to avoid filtering. + + + + Apply settings available only when a certain module is loaded (method two) + /etc/modules-load.d/bridge.conf: + + + br_netfilter + + /etc/sysctl.d/bridge.conf: + + + net.bridge.bridge-nf-call-ip6tables = 0 +net.bridge.bridge-nf-call-iptables = 0 +net.bridge.bridge-nf-call-arptables = 0 + + + This method forces the module to be always loaded. Please + note that, unless the br_netfilter module is + loaded, bridged packets will not be filtered with Netfilter + (starting with kernel 3.18), so simply not loading the module is + sufficient to avoid filtering. + + + + Set network routing properties for all interfaces + /etc/sysctl.d/20-rp_filter.conf: + + net.ipv4.conf.default.rp_filter = 2 +net.ipv4.conf.*.rp_filter = 2 +-net.ipv4.conf.all.rp_filter +net.ipv4.conf.hub0.rp_filter = 1 + + + The key will be set to "2" for all interfaces, except "hub0". We set + net.ipv4.conf.default.rp_filter first, so any interfaces which are added + later will get this value (this also covers any interfaces detected while we're + running). The glob matches any interfaces which were detected earlier. The glob + will also match net.ipv4.conf.all.rp_filter, which we don't want to set at all, so + it is explicitly excluded. And "hub0" is excluded from the glob because it has an explicit setting. + + + + + + + See Also + + systemd1, + systemd-sysctl.service8, + systemd-delta1, + sysctl8, + sysctl.conf5, + modprobe8 + + + + diff --git a/man/system-only.xml b/man/system-only.xml new file mode 100644 index 0000000..afd3d32 --- /dev/null +++ b/man/system-only.xml @@ -0,0 +1,16 @@ + + + + + + + +This option is only available for system services and is not supported for services +running in per-user instances of the service manager. + +These options are only available for system services and are not supported for services +running in per-user instances of the service manager. + + diff --git a/man/system-or-user-ns.xml b/man/system-or-user-ns.xml new file mode 100644 index 0000000..7a302d5 --- /dev/null +++ b/man/system-or-user-ns.xml @@ -0,0 +1,16 @@ + + + + + + + +This option is only available for system services, or for services running in per-user + instances of the service manager when PrivateUsers= is enabled. + +These options are only available for system services, or for services running in per-user + instances of the service manager when PrivateUsers= is enabled. + + diff --git a/man/systemctl.xml b/man/systemctl.xml new file mode 100644 index 0000000..00ae580 --- /dev/null +++ b/man/systemctl.xml @@ -0,0 +1,2530 @@ + + +%entities; +]> + + + + + + systemctl + systemd + + + + systemctl + 1 + + + + systemctl + Control the systemd system and service manager + + + + + systemctl + OPTIONS + COMMAND + UNIT + + + + + Description + + systemctl may be used to introspect and + control the state of the systemd system and + service manager. Please refer to + systemd1 + for an introduction into the basic concepts and functionality this + tool manages. + + + + Commands + + The following commands are understood: + + + Unit Commands (Introspection and Modification) + + + + list-units PATTERN… + + + List units that systemd currently has in memory. This includes units that are + either referenced directly or through a dependency, units that are pinned by applications programmatically, + or units that were active in the past and have failed. By default only units which are active, have pending + jobs, or have failed are shown; this can be changed with option . If one or more + PATTERNs are specified, only units matching one of them are shown. The units + that are shown are additionally filtered by and if those + options are specified. + + Note that this command does not show unit templates, but only instances of unit + templates. Units templates that aren't instantiated are not runnable, and will thus never show up + in the output of this command. Specifically this means that foo@.service + will never be shown in this list — unless instantiated, e.g. as + foo@bar.service. Use list-unit-files (see below) for + listing installed unit template files. + + Produces output similar to + UNIT LOAD ACTIVE SUB DESCRIPTION + sys-module-fuse.device loaded active plugged /sys/module/fuse + -.mount loaded active mounted Root Mount + boot-efi.mount loaded active mounted /boot/efi + systemd-journald.service loaded active running Journal Service + systemd-logind.service loaded active running Login Service +● user@1000.service loaded failed failed User Manager for UID 1000 + … + systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories + +LOAD = Reflects whether the unit definition was properly loaded. +ACTIVE = The high-level unit activation state, i.e. generalization of SUB. +SUB = The low-level unit activation state, values depend on unit type. + +123 loaded units listed. Pass --all to see loaded but inactive units, too. +To show all installed unit files use 'systemctl list-unit-files'. + + The header and the last unit of a given type are underlined if the terminal supports + that. A colored dot is shown next to services which were masked, not found, or otherwise + failed. + + The LOAD column shows the load state, one of loaded, + not-found, bad-setting, error, + masked. The ACTIVE columns shows the general unit state, one of + active, reloading, inactive, + failed, activating, deactivating. The SUB + column shows the unit-type-specific detailed state of the unit, possible values vary by unit type. The list + of possible LOAD, ACTIVE, and SUB states is not constant and new systemd releases may both add and remove + values. systemctl --state=help command maybe be used to display the + current set of possible values. + + This is the default command. + + + + + list-automounts PATTERN… + + + List automount units currently in memory, ordered by mount path. If one or more + PATTERNs are specified, only automount units matching one of them are shown. + Produces output similar to + +WHAT WHERE MOUNTED IDLE TIMEOUT UNIT +/dev/sdb1 /mnt/test no 120s mnt-test.automount +binfmt_misc /proc/sys/fs/binfmt_misc yes 0 proc-sys-fs-binfmt_misc.automount + +2 automounts listed. + + + Also see , , and . + + + + + list-sockets PATTERN… + + + List socket units currently in memory, ordered by listening address. If one or more + PATTERNs are specified, only socket units matching one of them are + shown. Produces output similar to + +LISTEN UNIT ACTIVATES +/dev/initctl systemd-initctl.socket systemd-initctl.service +… +[::]:22 sshd.socket sshd.service +kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service + +5 sockets listed. + Note: because the addresses might contains spaces, this output + is not suitable for programmatic consumption. + + + Also see , , and . + + + + + list-timers PATTERN… + + + List timer units currently in memory, ordered by the time they elapse next. If one or more + PATTERNs are specified, only units matching one of them are shown. + Produces output similar to + +NEXT LEFT LAST PASSED UNIT ACTIVATES +- - Thu 2017-02-23 13:40:29 EST 3 days ago ureadahead-stop.timer ureadahead-stop.service +Sun 2017-02-26 18:55:42 EST 1min 14s left Thu 2017-02-23 13:54:44 EST 3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service +Sun 2017-02-26 20:37:16 EST 1h 42min left Sun 2017-02-26 11:56:36 EST 6h ago apt-daily.timer apt-daily.service +Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago snapd.refresh.timer snapd.refresh.service + + + + NEXT shows the next time the timer will run. + LEFT shows how long till the next time the timer runs. + LAST shows the last time the timer ran. + PASSED shows how long has passed since the timer last ran. + UNIT shows the name of the timer + ACTIVATES shows the name the service the timer activates when it runs. + + Also see and . + + + + + is-active PATTERN… + + + Check whether any of the specified units are active + (i.e. running). Returns an exit code + 0 if at least one is active, or + non-zero otherwise. Unless is + specified, this will also print the current unit state to + standard output. + + + + + is-failed PATTERN… + + + Check whether any of the specified units are in a + "failed" state. Returns an exit code + 0 if at least one has failed, + non-zero otherwise. Unless is + specified, this will also print the current unit state to + standard output. + + + + + status PATTERN…|PID…] + + + Show runtime status information about the whole system or about one or more units followed + by most recent log data from the journal. If no positional arguments are specified, and no unit + filter is given with , , or + , shows the status of the whole system. If combined with + , follows that with the status of all units. If positional arguments are + specified, each positional argument is treated as either a unit name to show, or a glob pattern + to show units whose names match that pattern, or a PID to show the unit containing that PID. When + , , or are used, units + are additionally filtered by the TYPE and ACTIVE state. + + This function is intended to generate human-readable output. If you are looking for + computer-parsable output, use show instead. By default, this function only + shows 10 lines of output and ellipsizes lines to fit in the terminal window. This can be changed + with and , see above. In addition, + journalctl --unit=NAME or journalctl + --user-unit=NAME use a similar filter for messages and might + be more convenient. + + Note that this operation only displays runtime status, i.e. information about + the current invocation of the unit (if it is running) or the most recent invocation (if it is not + running anymore, and has not been released from memory). Information about earlier invocations, + invocations from previous system boots, or prior invocations that have already been released from + memory may be retrieved via journalctl --unit=. + + systemd implicitly loads units as necessary, so just running the status + will attempt to load a file. The command is thus not useful for determining if something was + already loaded or not. The units may possibly also be quickly unloaded after the operation is + completed if there's no reason to keep it in memory thereafter. + + + Example output from systemctl status + + $ systemctl status bluetooth +● bluetooth.service - Bluetooth service + Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled) + Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago + Docs: man:bluetoothd(8) + Main PID: 930 (bluetoothd) + Status: "Running" + Tasks: 1 + Memory: 648.0K + CPU: 435ms + CGroup: /system.slice/bluetooth.service + └─930 /usr/lib/bluetooth/bluetoothd + +Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service +Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered +Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5) + + + The dot ("●") uses color on supported terminals to summarize the unit state at a + glance. Along with its color, its shape varies according to its state: + inactive or maintenance is a white circle ("○"), + active is a green dot ("●"), deactivating is a white dot, + failed or error is a red cross ("×"), and + reloading is a green clockwise circle arrow ("↻"). + + The "Loaded:" line in the output will show loaded if the unit has been + loaded into memory. Other possible values for "Loaded:" include: error if + there was a problem loading it, not-found if no unit file was found for this + unit, bad-setting if an essential unit file setting could not be parsed and + masked if the unit file has been masked. Along with showing the path to the + unit file, this line will also show the enablement state. Enabled units are included in the + dependency network between units, and thus are started at boot or via some other form of + activation. See the full table of possible enablement states — including the definition of + masked — in the documentation for the is-enabled command. + + + The "Active:" line shows active state. The value is usually active or + inactive. Active could mean started, bound, plugged in, etc depending on the + unit type. The unit could also be in process of changing states, reporting a state of + activating or deactivating. A special + failed state is entered when the service failed in some way, such as a crash, + exiting with an error code or timing out. If the failed state is entered the cause will be logged + for later reference. + + + + + + + show PATTERN…|JOB… + + + Show properties of one or more units, jobs, or the manager itself. If no argument is specified, + properties of the manager will be shown. If a unit name is specified, properties of the unit are shown, and + if a job ID is specified, properties of the job are shown. By default, empty properties are suppressed. Use + to show those too. To select specific properties to show, use + . This command is intended to be used whenever computer-parsable output is + required. Use status if you are looking for formatted human-readable output. + + Many properties shown by systemctl show map directly to configuration settings of + the system and service manager and its unit files. Note that the properties shown by the command are + generally more low-level, normalized versions of the original configuration settings and expose runtime + state in addition to configuration. For example, properties shown for service units include the service's + current main process identifier as MainPID (which is runtime state), and time settings + are always exposed as properties ending in the …USec suffix even if a matching + configuration options end in …Sec, because microseconds is the normalized time unit used + internally by the system and service manager. + + For details about many of these properties, see the documentation of the D-Bus interface + backing these properties, see + org.freedesktop.systemd15. + + + + + cat PATTERN… + + + Show backing files of one or more units. Prints the + "fragment" and "drop-ins" (source files) of units. Each + file is preceded by a comment which includes the file + name. Note that this shows the contents of the backing files + on disk, which may not match the system manager's + understanding of these units if any unit files were + updated on disk and the daemon-reload + command wasn't issued since. + + + + + help PATTERN…|PID… + + + Show manual pages for one or more units, if + available. If a PID is given, the manual pages for the unit + the process belongs to are shown. + + + + + + list-dependencies + UNIT... + + + + Shows units required and wanted by the specified + units. This recursively lists units following the + Requires=, + Requisite=, + ConsistsOf=, + Wants=, BindsTo= + dependencies. If no units are specified, + default.target is implied. + + By default, only target units are recursively + expanded. When is passed, all other + units are recursively expanded as well. + + Options , + , + may be used to change what types of dependencies + are shown. + + Note that this command only lists units currently loaded into memory by the service manager. In + particular, this command is not suitable to get a comprehensive list at all reverse dependencies on a + specific unit, as it won't list the dependencies declared by units currently not loaded. + + + + + + + start PATTERN… + + + Start (activate) one or more units specified on the command line. + + Note that unit glob patterns expand to names of units currently in memory. Units which are + not active and are not in a failed state usually are not in memory, and will not be matched by + any pattern. In addition, in case of instantiated units, systemd is often unaware of the instance + name until the instance has been started. Therefore, using glob patterns with + start has limited usefulness. Also, secondary alias names of units are not + considered. + + Option may be used to also operate on inactive units which are + referenced by other loaded units. Note that this is not the same as operating on "all" possible + units, because as the previous paragraph describes, such a list is ill-defined. Nevertheless, + systemctl start --all GLOB may be useful if all the + units that should match the pattern are pulled in by some target which is known to be loaded. + + + + + stop PATTERN… + + + Stop (deactivate) one or more units specified on the command line. + + This command will fail if the unit does not exist or if stopping of the unit is prohibited (see + RefuseManualStop= in + systemd.unit5). + It will not fail if any of the commands configured to stop the unit + (ExecStop=, etc.) fail, because the manager will still forcibly terminate the + unit. + + + + reload PATTERN… + + + Asks all units listed on the command line to reload + their configuration. Note that this will reload the + service-specific configuration, not the unit configuration + file of systemd. If you want systemd to reload the + configuration file of a unit, use the + daemon-reload command. In other words: + for the example case of Apache, this will reload Apache's + httpd.conf in the web server, not the + apache.service systemd unit + file. + + This command should not be confused with the + daemon-reload command. + + + + + restart PATTERN… + + + Stop and then start one or more units specified on the command line. If the units are not running + yet, they will be started. + + Note that restarting a unit with this command does not necessarily flush out all of the unit's + resources before it is started again. For example, the per-service file descriptor storage facility (see + FileDescriptorStoreMax= in + systemd.service5) will + remain intact as long as the unit has a job pending, and is only cleared when the unit is fully stopped and + no jobs are pending anymore. If it is intended that the file descriptor store is flushed out, too, during a + restart operation an explicit systemctl stop command followed by systemctl + start should be issued. + + + + try-restart PATTERN… + + + Stop and then start one or more units specified on the + command line if the units are running. This does nothing + if units are not running. + + + + + reload-or-restart PATTERN… + + + Reload one or more units if they support it. If not, stop and then start them instead. If the units + are not running yet, they will be started. + + + + try-reload-or-restart PATTERN… + + + Reload one or more units if they support it. If not, stop and then start them instead. This does + nothing if the units are not running. + + + + + isolate UNIT + + + Start the unit specified on the command line and its dependencies + and stop all others, unless they have + (see + systemd.unit5). + If a unit name with no extension is given, an extension of + .target will be assumed. + + This command is dangerous, since it will immediately stop processes that are not enabled in + the new target, possibly including the graphical environment or terminal you are currently using. + + + Note that this operation is allowed only on units where + is enabled. See + systemd.unit5 + for details. + + + + kill PATTERN… + + + Send a signal to one or more processes of the + unit. Use to select which + process to kill. Use to select + the signal to send. + + + + clean PATTERN… + + + Remove the configuration, state, cache, logs or runtime data of the specified units. Use + to select which kind of resource to remove. For service units this may + be used to remove the directories configured with ConfigurationDirectory=, + StateDirectory=, CacheDirectory=, + LogsDirectory= and RuntimeDirectory=, see + systemd.exec5 + for details. For timer units this may be used to clear out the persistent timestamp data if + Persistent= is used and is selected, see + systemd.timer5. This + command only applies to units that use either of these settings. If is + not specified, both the cache and runtime data are removed (as these two types of data are + generally redundant and reproducible on the next invocation of the unit). + + + + freeze PATTERN… + + + Freeze one or more units specified on the + command line using cgroup freezer + + Freezing the unit will cause all processes contained within the cgroup corresponding to the unit + to be suspended. Being suspended means that unit's processes won't be scheduled to run on CPU until thawed. + Note that this command is supported only on systems that use unified cgroup hierarchy. Unit is automatically + thawed just before we execute a job against the unit, e.g. before the unit is stopped. + + + + thaw PATTERN… + + + Thaw (unfreeze) one or more units specified on the + command line. + + This is the inverse operation to the freeze command and resumes the execution of + processes in the unit's cgroup. + + + + set-property UNIT PROPERTY=VALUE… + + + Set the specified unit properties at runtime where + this is supported. This allows changing configuration + parameter properties such as resource control settings at + runtime. Not all properties may be changed at runtime, but + many resource control settings (primarily those in + systemd.resource-control5) + may. The changes are applied immediately, and stored on disk + for future boots, unless is + passed, in which case the settings only apply until the + next reboot. The syntax of the property assignment follows + closely the syntax of assignments in unit files. + + Example: systemctl set-property foobar.service CPUWeight=200 + + If the specified unit appears to be inactive, the + changes will be only stored on disk as described + previously hence they will be effective when the unit will + be started. + + Note that this command allows changing multiple properties at the same time, which is + preferable over setting them individually. + + Example: systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes + + Like with unit file configuration settings, assigning an empty setting usually resets a + property to its defaults. + + Example: systemctl set-property avahi-daemon.service IPAddressDeny= + + + + + + bind + UNIT + PATH + [PATH] + + + Bind-mounts a file or directory from the host into the specified unit's mount + namespace. The first path argument is the source file or directory on the host, the second path + argument is the destination file or directory in the unit's mount namespace. When the latter is + omitted, the destination path in the unit's mount namespace is the same as the source path on the + host. When combined with the switch, a ready-only bind mount is + created. When combined with the switch, the destination path is first + created before the mount is applied. + + Note that this option is currently only supported for units that run within a mount namespace + (e.g.: with , , etc.). This command + supports bind-mounting directories, regular files, device nodes, AF_UNIX + socket nodes, as well as FIFOs. The bind mount is ephemeral, and it is undone as soon as the + current unit process exists. Note that the namespace mentioned here, where the bind mount will be + added to, is the one where the main service process runs. Other processes (those exececuted by + , , etc.) run in distinct namespaces. + + + + + + mount-image + UNIT + IMAGE + [PATH + [PARTITION_NAME:MOUNT_OPTIONS]] + + + Mounts an image from the host into the specified unit's mount namespace. The first + path argument is the source image on the host, the second path argument is the destination + directory in the unit's mount namespace (i.e. inside + /). The following argument, if any, is + interpreted as a colon-separated tuple of partition name and comma-separated list of mount options + for that partition. The format is the same as the service + setting. When combined with the switch, a ready-only mount is + created. When combined with the switch, the destination path is first + created before the mount is applied. + + Note that this option is currently only supported for units that run within a mount namespace + (i.e. with , , etc.). Note that the + namespace mentioned here where the image mount will be added to, is the one where the main service + process runs. Note that the namespace mentioned here, where the bind mount will be + added to, is the one where the main service process runs. Other processes (those exececuted by + , , etc.) run in distinct namespaces. + + + Example: + systemctl mount-image foo.service /tmp/img.raw /var/lib/image root:ro,nosuid + systemctl mount-image --mkdir bar.service /tmp/img.raw /var/lib/baz/img + + + + + service-log-level SERVICE [LEVEL] + + If the LEVEL argument is not given, print the current + log level as reported by service SERVICE. + + If the optional argument LEVEL is provided, then change the + current log level of the service to LEVEL. The log level should be a + typical syslog log level, i.e. a value in the range 0…7 or one of the strings + emerg, alert, crit, + err, warning, notice, + info, debug; see syslog3 + for details. + + The service must have the appropriate + BusName=destination property and also implement the + generic + org.freedesktop.LogControl15 + interface. (systemctl will use the generic D-Bus protocol to access the + org.freedesktop.LogControl1.LogLevel interface for the D-Bus name + destination.) + + + + service-log-target SERVICE [TARGET] + + If the TARGET argument is not given, print the current + log target as reported by service SERVICE. + + If the optional argument TARGET is provided, then change the + current log target of the service to TARGET. The log target should be + one of the strings console (for log output to the service's standard error + stream), kmsg (for log output to the kernel log buffer), + journal (for log output to + systemd-journald.service8 + using the native journal protocol), syslog (for log output to the classic + syslog socket /dev/log), null (for no log output + whatsoever) or auto (for an automatically determined choice, typically + equivalent to console if the service is invoked interactively, and + journal or syslog otherwise). + + For most services, only a small subset of log targets make sense. In particular, most + "normal" services should only implement console, journal, + and null. Anything else is only appropriate for low-level services that + are active in very early boot before proper logging is established. + + The service must have the appropriate + BusName=destination property and also implement the + generic + org.freedesktop.LogControl15 + interface. (systemctl will use the generic D-Bus protocol to access the + org.freedesktop.LogControl1.LogLevel interface for the D-Bus name + destination.) + + + + reset-failed [PATTERN…] + + + Reset the failed state of the specified units, or if no unit name is passed, reset + the state of all units. When a unit fails in some way (i.e. process exiting with non-zero error code, + terminating abnormally or timing out), it will automatically enter the failed state and + its exit code and status is recorded for introspection by the administrator until the service is + stopped/re-started or reset with this command. + + In addition to resetting the failed state of a unit it also resets various other + per-unit properties: the start rate limit counter of all unit types is reset to zero, as is the restart + counter of service units. Thus, if a unit's start limit (as configured with + StartLimitIntervalSec=/StartLimitBurst=) is hit and the unit refuses + to be started again, use this command to make it startable again. + + + + + + + Unit File Commands + + + + list-unit-files PATTERN… + + + List unit files installed on the system, in combination with their enablement state (as + reported by is-enabled). If one or more PATTERNs + are specified, only unit files whose name matches one of them are shown (patterns matching unit + file system paths are not supported). + + Unlike list-units this command will list template units in addition to + explicitly instantiated units. + + + + + enable UNIT… + enable PATH… + + + Enable one or more units or unit instances. This will create a set of symlinks, as encoded in the + [Install] sections of the indicated unit files. After the symlinks have been created, + the system manager configuration is reloaded (in a way equivalent to daemon-reload), in + order to ensure the changes are taken into account immediately. Note that this does + not have the effect of also starting any of the units being enabled. If this is + desired, combine this command with the switch, or invoke start + with appropriate arguments later. Note that in case of unit instance enablement (i.e. enablement of units of + the form foo@bar.service), symlinks named the same as instances are created in the + unit configuration directory, however they point to the single template unit file they are instantiated + from. + + This command expects either valid unit names (in which case various unit file directories are + automatically searched for unit files with appropriate names), or absolute paths to unit files (in which + case these files are read directly). If a specified unit file is located outside of the usual unit file + directories, an additional symlink is created, linking it into the unit configuration path, thus ensuring + it is found when requested by commands such as start. The file system where the linked + unit files are located must be accessible when systemd is started (e.g. anything underneath + /home/ or /var/ is not allowed, unless those directories are + located on the root file system). + + This command will print the file system operations executed. This output may be suppressed by passing + . + + + Note that this operation creates only the symlinks suggested in the [Install] + section of the unit files. While this command is the recommended way to manipulate the unit configuration + directory, the administrator is free to make additional changes manually by placing or removing symlinks + below this directory. This is particularly useful to create configurations that deviate from the suggested + default installation. In this case, the administrator must make sure to invoke + daemon-reload manually as necessary, in order to ensure the changes are taken into + account. + + + Enabling units should not be confused with starting (activating) units, as done by the + start command. Enabling and starting units is orthogonal: units may be enabled without + being started and started without being enabled. Enabling simply hooks the unit into various suggested + places (for example, so that the unit is automatically started on boot or when a particular kind of + hardware is plugged in). Starting actually spawns the daemon process (in case of service units), or binds + the socket (in case of socket units), and so on. + + Depending on whether , , , + or is specified, this enables the unit for the system, for the calling user only, + for only this boot of the system, or for all future logins of all users. Note that in the last case, no + systemd daemon configuration is reloaded. + + Using enable on masked units is not supported and results in an error. + + + + + disable UNIT… + + + Disables one or more units. This removes all symlinks to the unit files backing the specified units + from the unit configuration directory, and hence undoes any changes made by enable or + link. Note that this removes all symlinks to matching unit files, + including manually created symlinks, and not just those actually created by enable or + link. Note that while disable undoes the effect of + enable, the two commands are otherwise not symmetric, as disable may + remove more symlinks than a prior enable invocation of the same unit created. + + This command expects valid unit names only, it does not accept paths to unit files. + + In addition to the units specified as arguments, all units are disabled that are listed in the + Also= setting contained in the [Install] section of any of the unit + files being operated on. + + This command implicitly reloads the system manager configuration after completing the operation. Note + that this command does not implicitly stop the units that are being disabled. If this is desired, either + combine this command with the switch, or invoke the stop command + with appropriate arguments later. + + This command will print information about the file system operations (symlink removals) + executed. This output may be suppressed by passing . + + + This command honors , , + and in a similar way as enable. + + + + + reenable UNIT… + + + Reenable one or more units, as specified on the command line. This is a combination of + disable and enable and is useful to reset the symlinks a unit file is + enabled with to the defaults configured in its [Install] section. This command expects + a unit name only, it does not accept paths to unit files. + + + + + preset UNIT… + + + Reset the enable/disable status one or more unit files, as specified on + the command line, to the defaults configured in the preset policy files. This + has the same effect as disable or + enable, depending how the unit is listed in the preset + files. + + Use to control whether units shall be + enabled and disabled, or only enabled, or only disabled. + + If the unit carries no install information, it will be silently ignored + by this command. UNIT must be the real unit name, + any alias names are ignored silently. + + For more information on the preset policy format, see + systemd.preset5. + + + + + + preset-all + + + Resets all installed unit files to the defaults + configured in the preset policy file (see above). + + Use to control + whether units shall be enabled and disabled, or only + enabled, or only disabled. + + + + + is-enabled UNIT… + + + Checks whether any of the specified unit files are + enabled (as with enable). Returns an + exit code of 0 if at least one is enabled, non-zero + otherwise. Prints the current enable status (see table). + To suppress this output, use . + To show installation targets, use . + + + + + <command>is-enabled</command> output + + + + + + Name + Description + Exit Code + + + + + enabled + Enabled via .wants/, .requires/ or Alias= symlinks (permanently in /etc/systemd/system/, or transiently in /run/systemd/system/). + 0 + + + enabled-runtime + + + linked + Made available through one or more symlinks to the unit file (permanently in /etc/systemd/system/ or transiently in /run/systemd/system/), even though the unit file might reside outside of the unit file search path. + > 0 + + + linked-runtime + + + alias + The name is an alias (symlink to another unit file). + 0 + + + masked + Completely disabled, so that any start operation on it fails (permanently in /etc/systemd/system/ or transiently in /run/systemd/systemd/). + > 0 + + + masked-runtime + + + static + The unit file is not enabled, and has no provisions for enabling in the [Install] unit file section. + 0 + + + indirect + The unit file itself is not enabled, but it has a non-empty Also= setting in the [Install] unit file section, listing other unit files that might be enabled, or it has an alias under a different name through a symlink that is not specified in Also=. For template unit files, an instance different than the one specified in DefaultInstance= is enabled. + 0 + + + disabled + The unit file is not enabled, but contains an [Install] section with installation instructions. + > 0 + + + generated + The unit file was generated dynamically via a generator tool. See systemd.generator7. Generated unit files may not be enabled, they are enabled implicitly by their generator. + 0 + + + transient + The unit file has been created dynamically with the runtime API. Transient units may not be enabled. + 0 + + + bad + The unit file is invalid or another error occurred. Note that is-enabled will not actually return this state, but print an error message instead. However the unit file listing printed by list-unit-files might show it. + > 0 + + + +
+ + + + + + mask UNIT… + + + Mask one or more units, as specified on the command line. This will link these unit files + to /dev/null, making it impossible to start them. This is a stronger version + of disable, since it prohibits all kinds of activation of the unit, including + enablement and manual activation. Use this option with care. This honors the + option to only mask temporarily until the next reboot of the + system. The option may be used to ensure that the units are also + stopped. This command expects valid unit names only, it does not accept unit file paths. + + Note that this will create a symlink under the unit's name in + /etc/systemd/system/ (in case is not specified) + or /run/systemd/system/ (in case is + specified). If a matching unit file already exists under these directories this operation will + hence fail. This means that the operation is primarily useful to mask units shipped by the vendor + (as those are shipped in /usr/lib/systemd/system/ and not the aforementioned + two directories), but typically doesn't work for units created locally (as those are typically + placed precisely in the two aforementioned directories). Similar restrictions apply for + mode, in which case the directories are below the user's home directory + however. + + + + + unmask UNIT… + + + Unmask one or more unit files, as specified on the command line. This will undo the effect of + mask. This command expects valid unit names only, it does not accept unit file + paths. + + + + + link PATH… + + + Link a unit file that is not in the unit file search path into the unit file search path. This + command expects an absolute path to a unit file. The effect of this may be undone with + disable. The effect of this command is that a unit file is made available for commands + such as start, even though it is not installed directly in the unit search path. The + file system where the linked unit files are located must be accessible when systemd is started + (e.g. anything underneath /home/ or /var/ is not allowed, unless + those directories are located on the root file system). + + + + + revert UNIT… + + + Revert one or more unit files to their vendor versions. This command removes drop-in configuration + files that modify the specified units, as well as any user-configured unit file that overrides a matching + vendor supplied unit file. Specifically, for a unit foo.service the matching directories + foo.service.d/ with all their contained files are removed, both below the persistent and + runtime configuration directories (i.e. below /etc/systemd/system and + /run/systemd/system); if the unit file has a vendor-supplied version (i.e. a unit file + located below /usr/) any matching persistent or runtime unit file that overrides it is + removed, too. Note that if a unit file has no vendor-supplied version (i.e. is only defined below + /etc/systemd/system or /run/systemd/system, but not in a unit + file stored below /usr/), then it is not removed. Also, if a unit is masked, it is + unmasked. + + Effectively, this command may be used to undo all changes made with systemctl + edit, systemctl set-property and systemctl mask and puts + the original unit file with its settings back in effect. + + + + + add-wants TARGET + UNIT… + add-requires TARGET + UNIT… + + + Adds Wants= or Requires= + dependencies, respectively, to the specified + TARGET for one or more units. + + This command honors , + , and + in a way similar to + enable. + + + + + + edit UNIT… + + + Edit a drop-in snippet or a whole replacement file if + is specified, to extend or override the + specified unit. + + Depending on whether (the default), + , or is specified, + this command creates a drop-in file for each unit either for the system, + for the calling user, or for all futures logins of all users. Then, + the editor (see the "Environment" section below) is invoked on + temporary files which will be written to the real location if the + editor exits successfully. + + If is specified, this will copy the + original units instead of creating drop-in files. + + If is specified and any units do + not already exist, new unit files will be opened for editing. + + If is specified, the changes will + be made temporarily in /run/ and they will be + lost on the next reboot. + + If the temporary file is empty upon exit, the modification of + the related unit is canceled. + + After the units have been edited, systemd configuration is + reloaded (in a way that is equivalent to daemon-reload). + + + Note that this command cannot be used to remotely edit units + and that you cannot temporarily edit units which are in + /etc/, since they take precedence over + /run/. + + + + + get-default + + + Return the default target to boot into. This returns + the target unit name default.target + is aliased (symlinked) to. + + + + + set-default TARGET + + + Set the default target to boot into. This sets + (symlinks) the default.target alias + to the given target unit. + + + + + + + + Machine Commands + + + + list-machines PATTERN… + + + List the host and all running local containers with + their state. If one or more + PATTERNs are specified, only + containers matching one of them are shown. + + + + + + + + Job Commands + + + + list-jobs PATTERN… + + + List jobs that are in progress. If one or more + PATTERNs are specified, only + jobs for units matching one of them are shown. + + When combined with or the list is augmented with + information on which other job each job is waiting for, and which other jobs are waiting for it, see + above. + + + + cancel JOB… + + + Cancel one or more jobs specified on the command line + by their numeric job IDs. If no job ID is specified, cancel + all pending jobs. + + + + + + + Environment Commands + + systemd supports an environment block that is passed to processes the manager + spawns. The names of the variables can contain ASCII letters, digits, and the underscore + character. Variable names cannot be empty or start with a digit. In variable values, most characters + are allowed, but the whole sequence must be valid UTF-8. (Note that control characters like newline + (NL), tab (TAB), or the escape character + (ESC), are valid ASCII and thus valid UTF-8). The total + length of the environment block is limited to _SC_ARG_MAX value defined by + sysconf3. + + + + + show-environment + + + Dump the systemd manager environment block. This is the environment + block that is passed to all processes the manager spawns. The environment + block will be dumped in straightforward form suitable for sourcing into + most shells. If no special characters or whitespace is present in the variable + values, no escaping is performed, and the assignments have the form + VARIABLE=value. If whitespace or characters which have + special meaning to the shell are present, dollar-single-quote escaping is + used, and assignments have the form VARIABLE=$'value'. + This syntax is known to be supported by + bash1, + zsh1, + ksh1, + and + busybox1's + ash1, + but not + dash1 + or + fish1. + + + + + set-environment VARIABLE=VALUE… + + + Set one or more systemd manager environment variables, as specified on the command + line. This command will fail if variable names and values do not conform to the rules listed + above. + + + + unset-environment VARIABLE… + + + Unset one or more systemd manager environment + variables. If only a variable name is specified, it will be + removed regardless of its value. If a variable and a value + are specified, the variable is only removed if it has the + specified value. + + + + + import-environment + VARIABLE… + + + + Import all, one or more environment variables set on the client into the systemd manager + environment block. If a list of environment variable names is passed, client-side values are then + imported into the manager's environment block. If any names are not valid environment variable + names or have invalid values according to the rules described above, an error is raised. If no + arguments are passed, the entire environment block inherited by the systemctl + process is imported. In this mode, any inherited invalid environment variables are quietly + ignored. + + Importing of the full inherited environment block (calling this command without any + arguments) is deprecated. A shell will set dozens of variables which only make sense locally and + are only meant for processes which are descendants of the shell. Such variables in the global + environment block are confusing to other processes. + + + + + + + Manager State Commands + + + + daemon-reload + + + Reload the systemd manager configuration. This will + rerun all generators (see + systemd.generator7), + reload all unit files, and recreate the entire dependency + tree. While the daemon is being reloaded, all sockets + systemd listens on behalf of user configuration will stay + accessible. + + This command should not be confused with the + reload command. + + + + + daemon-reexec + + + Reexecute the systemd manager. This will serialize the + manager state, reexecute the process and deserialize the + state again. This command is of little use except for + debugging and package upgrades. Sometimes, it might be + helpful as a heavy-weight daemon-reload. + While the daemon is being reexecuted, all sockets systemd listening + on behalf of user configuration will stay accessible. + + + + + + log-level [LEVEL] + + If no argument is given, print the current log level of the manager. If an + optional argument LEVEL is provided, then the command changes the + current log level of the manager to LEVEL (accepts the same values as + described in + systemd1). + + + + + log-target [TARGET] + + If no argument is given, print the current log target of the manager. If an + optional argument TARGET is provided, then the command changes the + current log target of the manager to TARGET (accepts the same values as + , described in + systemd1). + + + + + service-watchdogs [yes|no] + + If no argument is given, print the current state of service runtime watchdogs of + the manager. If an optional boolean argument is provided, then globally enables or disables the + service runtime watchdogs () and emergency actions (e.g. + or ); see + systemd.service5. + The hardware watchdog is not affected by this setting. + + + + + + System Commands + + + + is-system-running + + + Checks whether the system is operational. This + returns success (exit code 0) when the system is fully up + and running, specifically not in startup, shutdown or + maintenance mode, and with no failed services. Failure is + returned otherwise (exit code non-zero). In addition, the + current state is printed in a short string to standard + output, see the table below. Use to + suppress this output. + + Use to wait until the boot + process is completed before printing the current state and + returning the appropriate error status. If + is in use, states initializing or + starting will not be reported, instead + the command will block until a later state (such as + running or degraded) + is reached. + + + <command>is-system-running</command> output + + + + + + + Name + Description + Exit Code + + + + + initializing + Early bootup, before + basic.target is reached + or the maintenance state entered. + + > 0 + + + starting + Late bootup, before the job queue + becomes idle for the first time, or one of the + rescue targets are reached. + > 0 + + + running + The system is fully + operational. + 0 + + + degraded + The system is operational but one or more + units failed. + > 0 + + + maintenance + The rescue or emergency target is + active. + > 0 + + + stopping + The manager is shutting + down. + > 0 + + + offline + The manager is not + running. Specifically, this is the operational + state if an incompatible program is running as + system manager (PID 1). + > 0 + + + unknown + The operational state could not be + determined, due to lack of resources or another + error cause. + > 0 + + + +
+ + + + + default + + + Enter default mode. This is equivalent to systemctl isolate default.target. This + operation is blocking by default, use to request asynchronous behavior. + + + + + rescue + + + Enter rescue mode. This is equivalent to systemctl isolate rescue.target. This + operation is blocking by default, use to request asynchronous behavior. + + + + emergency + + + Enter emergency mode. This is equivalent to systemctl isolate + emergency.target. This operation is blocking by default, use to + request asynchronous behavior. + + + + halt + + + Shut down and halt the system. This is mostly equivalent to systemctl start halt.target + --job-mode=replace-irreversibly --no-block, but also prints a wall message to all users. This command is + asynchronous; it will return after the halt operation is enqueued, without waiting for it to complete. Note + that this operation will simply halt the OS kernel after shutting down, leaving the hardware powered + on. Use systemctl poweroff for powering off the system (see below). + + If combined with , shutdown of all running services is skipped, however all + processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the + system halt. If is specified twice, the operation is immediately executed without + terminating any processes or unmounting any file systems. This may result in data loss. Note that when + is specified twice the halt operation is executed by systemctl + itself, and the system manager is not contacted. This means the command should succeed even when the system + manager has crashed. + + + + poweroff + + + Shut down and power-off the system. This is mostly equivalent to systemctl start + poweroff.target --job-mode=replace-irreversibly --no-block, but also prints a wall message to all + users. This command is asynchronous; it will return after the power-off operation is enqueued, without + waiting for it to complete. + + If combined with , shutdown of all running services is skipped, however all + processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the + powering off. If is specified twice, the operation is immediately executed without + terminating any processes or unmounting any file systems. This may result in data loss. Note that when + is specified twice the power-off operation is executed by + systemctl itself, and the system manager is not contacted. This means the command should + succeed even when the system manager has crashed. + + + + reboot + + + Shut down and reboot the system. + + This command mostly equivalent to systemctl start reboot.target + --job-mode=replace-irreversibly --no-block, but also prints a wall message to all + users. This command is asynchronous; it will return after the reboot operation is enqueued, + without waiting for it to complete. + + If combined with , shutdown of all running services is skipped, however all + processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the + reboot. If is specified twice, the operation is immediately executed without + terminating any processes or unmounting any file systems. This may result in data loss. Note that when + is specified twice the reboot operation is executed by + systemctl itself, and the system manager is not contacted. This means the command should + succeed even when the system manager has crashed. + + If the switch is given, it will be passed as the optional + argument to the reboot2 + system call. + + Options , , and + can be used to select what to do after the + reboot. See the descriptions of those options for details. + + + + + kexec + + + Shut down and reboot the system via kexec. This is equivalent to + systemctl start kexec.target --job-mode=replace-irreversibly --no-block. This command is + asynchronous; it will return after the reboot operation is enqueued, without waiting for it to + complete. + + If combined with , shutdown of all running services is skipped, however all + processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the + reboot. + + + + + exit EXIT_CODE + + + Ask the service manager to quit. This is only supported for user service managers (i.e. in + conjunction with the option) or in containers and is equivalent to + poweroff otherwise. This command is asynchronous; it will return after the exit + operation is enqueued, without waiting for it to complete. + + The service manager will exit with the specified exit code, if + EXIT_CODE is passed. + + + + + switch-root ROOT INIT + + + Switches to a different root directory and executes a new system manager process below it. + This is intended for use in the initrd, and will transition from the initrd's system manager + process (a.k.a. "init" process) to the main system manager process which is loaded from the + actual host root files system. This call takes two arguments: the directory that is to become the + new root directory, and the path to the new system manager binary below it to execute as PID 1. + If the latter is omitted or the empty string, a systemd binary will automatically be searched for + and used as init. If the system manager path is omitted, equal to the empty string or identical + to the path to the systemd binary, the state of the initrd's system manager process is passed to + the main system manager, which allows later introspection of the state of the services involved + in the initrd boot phase. + + + + + suspend + + + Suspend the system. This will trigger activation of the special target unit + suspend.target. This command is asynchronous, and will return after the suspend + operation is successfully enqueued. It will not wait for the suspend/resume cycle to complete. + + + + + hibernate + + + Hibernate the system. This will trigger activation of the special target unit + hibernate.target. This command is asynchronous, and will return after the hibernation + operation is successfully enqueued. It will not wait for the hibernate/thaw cycle to complete. + + + + + hybrid-sleep + + + Hibernate and suspend the system. This will trigger activation of the special target unit + hybrid-sleep.target. This command is asynchronous, and will return after the hybrid + sleep operation is successfully enqueued. It will not wait for the sleep/wake-up cycle to complete. + + + + + suspend-then-hibernate + + + Suspend the system and hibernate it after the delay specified in systemd-sleep.conf. + This will trigger activation of the special target unit suspend-then-hibernate.target. + This command is asynchronous, and will return after the hybrid sleep operation is successfully enqueued. + It will not wait for the sleep/wake-up or hibernate/thaw cycle to complete. + + + + + + + Parameter Syntax + + Unit commands listed above take either a single unit name (designated as UNIT), + or multiple unit specifications (designated as PATTERN…). In the first case, the + unit name with or without a suffix must be given. If the suffix is not specified (unit name is "abbreviated"), + systemctl will append a suitable suffix, .service by default, and a type-specific suffix in + case of commands which operate only on specific unit types. For example, + # systemctl start sshd and + # systemctl start sshd.service + are equivalent, as are + # systemctl isolate default + and + # systemctl isolate default.target + Note that (absolute) paths to device nodes are automatically converted to device unit names, and other (absolute) + paths to mount unit names. + # systemctl status /dev/sda +# systemctl status /home + are equivalent to: + # systemctl status dev-sda.device +# systemctl status home.mount + In the second case, shell-style globs will be matched against the primary names of all units currently in memory; + literal unit names, with or without a suffix, will be treated as in the first case. This means that literal unit + names always refer to exactly one unit, but globs may match zero units and this is not considered an + error. + + Glob patterns use + fnmatch3, + so normal shell-style globbing rules are used, and + *, ?, + [] may be used. See + glob7 + for more details. The patterns are matched against the primary names of + units currently in memory, and patterns which do not match anything + are silently skipped. For example: + # systemctl stop sshd@*.service + will stop all sshd@.service instances. Note that alias names of units, and units that aren't + in memory are not considered for glob expansion. + + + For unit file commands, the specified UNIT should be the name of the unit file + (possibly abbreviated, see above), or the absolute path to the unit file: + # systemctl enable foo.service + or + # systemctl link /path/to/foo.service + + + + + + + Options + + The following options are understood: + + + + + + + + The argument is a comma-separated list of unit types such as and + . When units are listed with list-units, + show, or status, only units of the specified types will be + shown. By default, units of all types are shown. + + As a special case, if one of the arguments is , a list of allowed values + will be printed and the program will exit. + + + + + + + + The argument is a comma-separated list of unit LOAD, SUB, or ACTIVE states. When listing + units with list-units, show, or status, + show only those in the specified states. Use or + to show only failed units. + + As a special case, if one of the arguments is , a list of allowed values + will be printed and the program will exit. + + + + + + + + + When showing unit/job/manager properties with the + show command, limit display to properties + specified in the argument. The argument should be a + comma-separated list of property names, such as + MainPID. Unless specified, all known + properties are shown. If specified more than once, all + properties with the specified names are shown. Shell + completion is implemented for property names. + + For the manager itself, + systemctl show + will show all available properties, most of which are derived or closely match the options described in + systemd-system.conf5. + + + Properties for units vary by unit type, so showing any + unit (even a non-existent one) is a way to list properties + pertaining to this type. Similarly, showing any job will list + properties pertaining to all jobs. Properties for units are + documented in + systemd.unit5, + and the pages for individual unit types + systemd.service5, + systemd.socket5, + etc. + + + + + + + + Equivalent to , i.e. shows the + value of the property without the property name or =. Note that using + once will also affect all properties listed with + /. + + + + + + + + + When listing units with list-units, also show inactive units and + units which are following other units. When showing unit/job/manager properties, show all + properties regardless whether they are set or not. + + To list all units installed in the file system, use the + list-unit-files command instead. + + When listing units with list-dependencies, recursively show + dependencies of all dependent units (by default only dependencies of target units are + shown). + + When used with status, show journal messages in full, even if they include + unprintable characters or are very long. By default, fields with unprintable characters are + abbreviated as "blob data". (Note that the pager may escape unprintable characters again.) + + + + + + + + + When listing units, also show units of local + containers. Units of local containers will be prefixed with + the container name, separated by a single colon character + (:). + + + + + + + + Show reverse dependencies between units with + list-dependencies, i.e. follow + dependencies of type WantedBy=, + RequiredBy=, + PartOf=, BoundBy=, + instead of Wants= and similar. + + + + + + + + + With list-dependencies, show the + units that are ordered before the specified unit. In other + words, recursively list units following the + After= dependency. + + Note that any After= dependency is + automatically mirrored to create a + Before= dependency. Temporal dependencies + may be specified explicitly, but are also created implicitly + for units which are WantedBy= targets + (see + systemd.target5), + and as a result of other directives (for example + RequiresMountsFor=). Both explicitly + and implicitly introduced dependencies are shown with + list-dependencies. + + When passed to the list-jobs command, for each printed job show which other jobs are + waiting for it. May be combined with to show both the jobs waiting for each job as + well as all jobs each job is waiting for. + + + + + + + + With list-dependencies, show the + units that are ordered after the specified unit. In other + words, recursively list units following the + Before= dependency. + + When passed to the list-jobs command, for each printed job show which other jobs it + is waiting for. May be combined with to show both the jobs waiting for each job as + well as all jobs each job is waiting for. + + + + + + + + When used with status, + cat, list-units, and + list-unit-files, those commands print all + specified units and the dependencies of those units. + + Options , + , + may be used to change what types of dependencies + are shown. + + + + + + + + + Do not ellipsize unit names, process tree entries, + journal output, or truncate unit descriptions in the output + of status, list-units, + list-jobs, and + list-timers. + Also, show installation targets in the output of + is-enabled. + + + + + + + + When printing properties with show, only print the value, and skip the + property name and =. Also see option above. + + + + + + + + When showing sockets, show the type of the socket. + + + + + + + + When queuing a new job, this option controls how to deal with + already queued jobs. It takes one of fail, + replace, + replace-irreversibly, + isolate, + ignore-dependencies, + ignore-requirements, + flush, or + triggering. Defaults to + replace, except when the + isolate command is used which implies the + isolate job mode. + + If fail is specified and a requested + operation conflicts with a pending job (more specifically: + causes an already pending start job to be reversed into a stop + job or vice versa), cause the operation to fail. + + If replace (the default) is + specified, any conflicting pending job will be replaced, as + necessary. + + If replace-irreversibly is specified, + operate like replace, but also mark the new + jobs as irreversible. This prevents future conflicting + transactions from replacing these jobs (or even being enqueued + while the irreversible jobs are still pending). Irreversible + jobs can still be cancelled using the cancel + command. This job mode should be used on any transaction which + pulls in shutdown.target. + + isolate is only valid for start + operations and causes all other units to be stopped when the + specified unit is started. This mode is always used when the + isolate command is used. + + flush will cause all queued jobs to + be canceled when the new job is enqueued. + + If ignore-dependencies is specified, + then all unit dependencies are ignored for this new job and + the operation is executed immediately. If passed, no required + units of the unit passed will be pulled in, and no ordering + dependencies will be honored. This is mostly a debugging and + rescue tool for the administrator and should not be used by + applications. + + ignore-requirements is similar to + ignore-dependencies, but only causes the + requirement dependencies to be ignored, the ordering + dependencies will still be honored. + + + triggering may only be used with + systemctl stop. In this mode, the specified + unit and any active units that trigger it are stopped. See the + discussion of + Triggers= in systemd.unit5 + for more information about triggering units. + + + + + + + + + When enqueuing a unit job (for example as effect of a systemctl start + invocation or similar), show brief information about all jobs enqueued, covering both the requested + job and any added because of unit dependencies. Note that the output will only include jobs + immediately part of the transaction requested. It is possible that service start-up program code + run as effect of the enqueued jobs might request further jobs to be pulled in. This means that + completion of the listed jobs might ultimately entail more jobs than the listed ones. + + + + + + + + Shorthand for fail. + When used with the kill command, + if no units were killed, the operation results in an error. + + + + + + + + + When system shutdown or sleep state is requested, this option controls checking of inhibitor + locks. It takes one of auto, yes or + no. Defaults to auto, which will behave like + yes for interactive invocations (i.e. from a TTY) and no for + non-interactive invocations. yes lets the request respect inhibitor locks. + no lets the request ignore inhibitor locks. + + Applications can establish inhibitor locks to prevent certain important operations (such as + CD burning) from being interrupted by system shutdown or sleep. Any user may take these locks and + privileged users may override these locks. If any locks are taken, shutdown and sleep state + requests will normally fail (unless privileged). However, if no is specified or + auto is specified on a non-interactive requests, the operation will be + attempted. If locks are present, the operation may require additional privileges. + + Option provides another way to override inhibitors. + + + + + + + + Shortcut for . + + + + + + + + Just print what would be done. Currently supported by verbs + halt, poweroff, reboot, + kexec, suspend, hibernate, + hybrid-sleep, suspend-then-hibernate, + default, rescue, + emergency, and exit. + + + + + + + + + Suppress printing of the results of various commands + and also the hints about truncated log lines. This does not + suppress output of commands for which the printed output is + the only result (like show). Errors are + always printed. + + + + + + + + Do not synchronously wait for the requested operation + to finish. If this is not specified, the job will be + verified, enqueued and systemctl will + wait until the unit's start-up is completed. By passing this + argument, it is only verified and enqueued. This option may not be + combined with . + + + + + + + + Synchronously wait for started units to terminate again. + This option may not be combined with . + Note that this will wait forever if any given unit never terminates + (by itself or by getting stopped explicitly); particularly services + which use RemainAfterExit=yes. + + When used with is-system-running, wait + until the boot process is completed before returning. + + + + + + + + + + + List units in failed state. This is equivalent to + . + + + + + + + + Do not send wall message before halt, power-off and reboot. + + + + + + + + When used with enable and + disable, operate on the global user + configuration directory, thus enabling or disabling a unit + file globally for all future logins of all users. + + + + + + + + When used with enable and + disable, do not implicitly reload daemon + configuration after executing the changes. + + + + + + + + When used with start and related + commands, disables asking for passwords. Background services + may require input of a password or passphrase string, for + example to unlock system hard disks or cryptographic + certificates. Unless this option is specified and the + command is invoked from a terminal, + systemctl will query the user on the + terminal for the necessary secrets. Use this option to + switch this behavior off. In this case, the password must be + supplied by some other means (for example graphical password + agents) or the service might fail. This also disables + querying the user for authentication for privileged + operations. + + + + + + + + When used with kill, choose which + processes to send a signal to. Must be one of + , or + to select whether to kill only the main + process, the control process or all processes of the + unit. The main process of the unit is the one that defines + the life-time of it. A control process of a unit is one that + is invoked by the manager to induce state changes of it. For + example, all processes started due to the + ExecStartPre=, + ExecStop= or + ExecReload= settings of service units are + control processes. Note that there is only one control + process per unit at a time, as only one state change is + executed at a time. For services of type + Type=forking, the initial process started + by the manager for ExecStart= is a + control process, while the process ultimately forked off by + that one is then considered the main process of the unit (if + it can be determined). This is different for service units + of other types, where the process forked off by the manager + for ExecStart= is always the main process + itself. A service unit consists of zero or one main process, + zero or one control process plus any number of additional + processes. Not all unit types manage processes of these + types however. For example, for mount units, control processes + are defined (which are the invocations of + &MOUNT_PATH; and + &UMOUNT_PATH;), but no main process + is defined. If omitted, defaults to + . + + + + + + + + + + Select what type of per-unit resources to remove when the clean command is + invoked, see below. Takes one of configuration, state, + cache, logs, runtime to select the + type of resource. This option may be specified more than once, in which case all specified resource + types are removed. Also accepts the special value all as a shortcut for + specifying all five resource types. If this option is not specified defaults to the combination of + cache and runtime, i.e. the two kinds of resources that + are generally considered to be redundant and can be reconstructed on next invocation. + + + + + + + + + When used with enable, overwrite + any existing conflicting symlinks. + + When used with edit, create all of the + specified units which do not already exist. + + When used with halt, poweroff, reboot or + kexec, execute the selected operation without shutting down all units. However, all + processes will be killed forcibly and all file systems are unmounted or remounted read-only. This is hence a + drastic but relatively safe option to request an immediate reboot. If is specified + twice for these operations (with the exception of kexec), they will be executed + immediately, without terminating any processes or unmounting any file systems. Warning: specifying + twice with any of these operations might result in data loss. Note that when + is specified twice the selected operation is executed by + systemctl itself, and the system manager is not contacted. This means the command should + succeed even when the system manager has crashed. + + + + + + + + When used with halt, poweroff or reboot, set a + short message explaining the reason for the operation. The message will be logged together with the default + shutdown message. + + + + + + + + When used with enable, the units + will also be started. When used with disable or + mask, the units will also be stopped. The start + or stop operation is only carried out when the respective enable or + disable operation has been successful. + + + + + + + + When used with + enable/disable/is-enabled + (and related commands), use the specified root path when looking for unit + files. If this option is present, systemctl will operate on + the file system directly, instead of communicating with the systemd + daemon to carry out changes. + + + + + + + + Takes a path to a disk image file or block device node. If specified, all operations + are applied to file system in the indicated disk image. This option is similar to + , but operates on file systems stored in disk images or block devices. The + disk image should either contain just a file system or a set of file systems within a GPT partition + table, following the Discoverable Partitions + Specification. For further information on supported disk images, see + systemd-nspawn1's + switch of the same name. + + + + + + + When used with enable, + disable, edit, + (and related commands), make changes only temporarily, so + that they are lost on the next reboot. This will have the + effect that changes are not made in subdirectories of + /etc/ but in /run/, + with identical immediate effects, however, since the latter + is lost on reboot, the changes are lost too. + + Similarly, when used with + set-property, make changes only + temporarily, so that they are lost on the next + reboot. + + + + + + + + Takes one of full (the default), + enable-only, + disable-only. When used with the + preset or preset-all + commands, controls whether units shall be disabled and + enabled according to the preset rules, or only enabled, or + only disabled. + + + + + + + + + When used with status, controls the number of journal lines to show, + counting from the most recent ones. Takes a positive integer argument, or 0 to disable journal + output. Defaults to 10. + + + + + + + + + When used with status, controls the + formatting of the journal entries that are shown. For the + available choices, see + journalctl1. + Defaults to short. + + + + + + + + When used with the reboot, poweroff, or + halt command, indicate to the system's firmware to reboot into the firmware + setup interface for the next boot. Note that this functionality is not available on all systems. + + + + + + + + + When used with the reboot, poweroff, or + halt command, indicate to the system's boot loader to show the boot loader menu + on the following boot. Takes a time value as parameter — indicating the menu timeout. Pass zero + in order to disable the menu timeout. Note that not all boot loaders support this functionality. + + + + + + + + + When used with the reboot, poweroff, or + halt command, indicate to the system's boot loader to boot into a specific + boot loader entry on the following boot. Takes a boot loader entry identifier as argument, + or help in order to list available entries. Note that not all boot loaders + support this functionality. + + + + + + + + This switch is used with reboot. The value is architecture and firmware specific. As an example, recovery + might be used to trigger system recovery, and fota might be used to trigger a + firmware over the air update. + + + + + + + + When used with list-dependencies, + list-units or list-machines, + the output is printed as a list instead of a tree, and the bullet + circles are omitted. + + + + + + + + Change the format of printed timestamps. The following values may be used: + + + + + (this is the default) + Day YYYY-MM-DD HH:MM:SS TZ + + + + + + + @seconds-since-the-epoch + + + + + + + + Day YYYY-MM-DD HH:MM:SS.UUUUUU TZ + + + + + + + Day YYYY-MM-DD HH:MM:SS UTC + + + + + + + + Day YYYY-MM-DD HH:MM:SS.UUUUUU UTC + + + + + + + + + When used with bind, creates the destination file or directory before + applying the bind mount. Note that even though the name of this option suggests that it is suitable only for + directories, this option also creates the destination file node to mount over if the object to mount is not + a directory, but a regular file, device node, socket or FIFO. + + + + + + Only allowed with reload-or-restart. Enqueues restart jobs for all + units that have the needs-restart mark, and reload jobs for units that have the + needs-reload mark. When a unit marked for reload does not support reload, restart + will be queued. Those properties can be set using set-property Markers=…. + + Unless is used, systemctl will wait for the + queued jobs to finish. + + + + + + When used with bind, creates a read-only bind mount. + + + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + systemctl uses the return codes defined by LSB, as defined in + LSB 3.0.0. + + + + LSB return codes + + + + + Value + Description in LSB + Use in systemd + + + + + 0 + "program is running or service is OK" + unit is active + + + 1 + "program is dead and /var/run pid file exists" + unit not failed (used by is-failed) + + + 2 + "program is dead and /var/lock lock file exists" + unused + + + 3 + "program is not running" + unit is not active + + + 4 + "program or service status is unknown" + no such unit + + + +
+ + The mapping of LSB service states to systemd unit states is imperfect, so it is better to + not rely on those return values but to look for specific unit states and substates instead. + + + + + Environment + + + + $SYSTEMD_EDITOR + + Editor to use when editing units; overrides + $EDITOR and $VISUAL. If neither + $SYSTEMD_EDITOR nor $EDITOR nor + $VISUAL are present or if it is set to an empty + string or if their execution failed, systemctl will try to execute well + known editors in this order: + editor1, + nano1, + vim1, + vi1. + + + + + + + + + + + + + + + + + + See Also + + systemd1, + journalctl1, + loginctl1, + machinectl1, + systemd.unit5, + systemd.resource-control5, + systemd.special7, + wall1, + systemd.preset5, + systemd.generator7, + glob7 + + + + diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml new file mode 100644 index 0000000..500a9e4 --- /dev/null +++ b/man/systemd-analyze.xml @@ -0,0 +1,1354 @@ + + + + + + + + systemd-analyze + systemd + + + + systemd-analyze + 1 + + + + systemd-analyze + Analyze and debug system manager + + + + + systemd-analyze + OPTIONS + time + + + systemd-analyze + OPTIONS + blame + + + systemd-analyze + OPTIONS + critical-chain + UNIT + + + + systemd-analyze + OPTIONS + dump + PATTERN + + + + systemd-analyze + OPTIONS + plot + >file.svg + + + systemd-analyze + OPTIONS + dot + PATTERN + >file.dot + + + + systemd-analyze + OPTIONS + unit-files + + + systemd-analyze + OPTIONS + unit-paths + + + systemd-analyze + OPTIONS + exit-status + STATUS + + + systemd-analyze + OPTIONS + capability + CAPABILITY + + + systemd-analyze + OPTIONS + condition + CONDITION… + + + systemd-analyze + OPTIONS + syscall-filter + SET… + + + systemd-analyze + OPTIONS + filesystems + SET… + + + systemd-analyze + OPTIONS + calendar + SPEC + + + systemd-analyze + OPTIONS + timestamp + TIMESTAMP + + + systemd-analyze + OPTIONS + timespan + SPAN + + + systemd-analyze + OPTIONS + cat-config + NAME|PATH + + + systemd-analyze + OPTIONS + compare-versions + VERSION1 + OP + VERSION2 + + + systemd-analyze + OPTIONS + verify + FILE + + + systemd-analyze + OPTIONS + security + UNIT + + + systemd-analyze + OPTIONS + inspect-elf + FILE + + + + + Description + + systemd-analyze may be used to determine + system boot-up performance statistics and retrieve other state and + tracing information from the system and service manager, and to + verify the correctness of unit files. It is also used to access + special functions useful for advanced system manager debugging. + + If no command is passed, systemd-analyze + time is implied. + + + <command>systemd-analyze time</command> + + This command prints the time spent in the kernel before userspace has been reached, the time + spent in the initrd before normal system userspace has been reached, and the time normal system + userspace took to initialize. Note that these measurements simply measure the time passed up to the + point where all system services have been spawned, but not necessarily until they fully finished + initialization or the disk is idle. + + + <command>Show how long the boot took</command> + + # in a container +$ systemd-analyze time +Startup finished in 296ms (userspace) +multi-user.target reached after 275ms in userspace + +# on a real machine +$ systemd-analyze time +Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s +multi-user.target reached after 47.820s in userspace + + + + + + <command>systemd-analyze blame</command> + + This command prints a list of all running units, ordered by the time they took to initialize. + This information may be used to optimize boot-up times. Note that the output might be misleading as the + initialization of one service might be slow simply because it waits for the initialization of another + service to complete. Also note: systemd-analyze blame doesn't display results for + services with Type=simple, because systemd considers such services to be started + immediately, hence no measurement of the initialization delays can be done. Also note that this command + only shows the time units took for starting up, it does not show how long unit jobs spent in the + execution queue. In particular it shows the time units spent in activating state, + which is not defined for units such as device units that transition directly from + inactive to active. This command hence gives an impression of the + performance of program code, but cannot accurately reflect latency introduced by waiting for + hardware and similar events. + + + <command>Show which units took the most time during boot</command> + + $ systemd-analyze blame + 32.875s pmlogger.service + 20.905s systemd-networkd-wait-online.service + 13.299s dev-vda1.device + ... + 23ms sysroot.mount + 11ms initrd-udevadm-cleanup-db.service + 3ms sys-kernel-config.mount + + + + + + <command>systemd-analyze critical-chain <optional><replaceable>UNIT</replaceable>...</optional></command> + + This command prints a tree of the time-critical chain of units (for each of the specified + UNITs or for the default target otherwise). The time after the unit is + active or started is printed after the "@" character. The time the unit takes to start is printed after + the "+" character. Note that the output might be misleading as the initialization of services might + depend on socket activation and because of the parallel execution of units. Also, similarly to the + blame command, this only takes into account the time units spent in + activating state, and hence does not cover units that never went through an + activating state (such as device units that transition directly from + inactive to active). Moreover it does not show information on + jobs (and in particular not jobs that timed out). + + + <command>systemd-analyze critical-chain</command> + + $ systemd-analyze critical-chain +multi-user.target @47.820s +└─pmie.service @35.968s +548ms + └─pmcd.service @33.715s +2.247s + └─network-online.target @33.712s + └─systemd-networkd-wait-online.service @12.804s +20.905s + └─systemd-networkd.service @11.109s +1.690s + └─systemd-udevd.service @9.201s +1.904s + └─systemd-tmpfiles-setup-dev.service @7.306s +1.776s + └─kmod-static-nodes.service @6.976s +177ms + └─systemd-journald.socket + └─system.slice + └─-.slice + + + + + + <command>systemd-analyze dump [<replaceable>pattern</replaceable>…]</command> + + Without any parameter, this command outputs a (usually very long) human-readable serialization of + the complete service manager state. Optional glob pattern may be specified, causing the output to be + limited to units whose names match one of the patterns. The output format is subject to change without + notice and should not be parsed by applications. This command is rate limited for unprivileged users. + + + Show the internal state of user manager + + $ systemd-analyze --user dump +Timestamp userspace: Thu 2019-03-14 23:28:07 CET +Timestamp finish: Thu 2019-03-14 23:28:07 CET +Timestamp generators-start: Thu 2019-03-14 23:28:07 CET +Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET +Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET +Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET +-> Unit proc-timer_list.mount: + Description: /proc/timer_list + ... +-> Unit default.target: + Description: Main user target +... + + + + + + <command>systemd-analyze plot</command> + + This command prints an SVG graphic detailing which system services have been started at what + time, highlighting the time they spent on initialization. + + + <command>Plot a bootchart</command> + + $ systemd-analyze plot >bootup.svg +$ eog bootup.svg& + + + + + + <command>systemd-analyze dot [<replaceable>pattern</replaceable>...]</command> + + This command generates textual dependency graph description in dot format for further processing + with the GraphViz + dot1 + tool. Use a command line like systemd-analyze dot | dot -Tsvg >systemd.svg to + generate a graphical dependency tree. Unless or is + passed, the generated graph will show both ordering and requirement dependencies. Optional pattern + globbing style specifications (e.g. *.target) may be given at the end. A unit + dependency is included in the graph if any of these patterns match either the origin or destination + node. + + + Plot all dependencies of any unit whose name starts with <literal>avahi-daemon</literal> + + + $ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg +$ eog avahi.svg + + + + Plot the dependencies between all known target units + + $ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \ + | dot -Tsvg >targets.svg +$ eog targets.svg + + + + + <command>systemd-analyze unit-paths</command> + + This command outputs a list of all directories from which unit files, .d + overrides, and .wants, .requires symlinks may be + loaded. Combine with to retrieve the list for the user manager instance, and + for the global configuration of user manager instances. + + + <command>Show all paths for generated units</command> + + $ systemd-analyze unit-paths | grep '^/run' +/run/systemd/system.control +/run/systemd/transient +/run/systemd/generator.early +/run/systemd/system +/run/systemd/system.attached +/run/systemd/generator +/run/systemd/generator.late + + + + Note that this verb prints the list that is compiled into systemd-analyze + itself, and does not communicate with the running manager. Use + systemctl [--user] [--global] show -p UnitPath --value + to retrieve the actual list that the manager uses, with any empty directories omitted. + + + + <command>systemd-analyze exit-status <optional><replaceable>STATUS</replaceable>...</optional></command> + + This command prints a list of exit statuses along with their "class", i.e. the source of the + definition (one of glibc, systemd, LSB, or + BSD), see the Process Exit Codes section in + systemd.exec5. + If no additional arguments are specified, all known statuses are shown. Otherwise, only the + definitions for the specified codes are shown. + + + <command>Show some example exit status names</command> + + $ systemd-analyze exit-status 0 1 {63..65} +NAME STATUS CLASS +SUCCESS 0 glibc +FAILURE 1 glibc +- 63 - +USAGE 64 BSD +DATAERR 65 BSD + + + + + + <command>systemd-analyze capability <optional><replaceable>CAPABILITY</replaceable>...</optional></command> + + This command prints a list of Linux capabilities along with their numeric IDs. See capabilities7 + for details. If no argument is specified the full list of capabilities known to the service manager and + the kernel is shown. Capabilities defined by the kernel but not known to the service manager are shown + as cap_???. Optionally, if arguments are specified they may refer to specific + cabilities by name or numeric ID, in which case only the indicated capabilities are shown in the + table. + + + <command>Show some example capability names</command> + + $ systemd-analyze capability 0 1 {30..32} +NAME NUMBER +cap_chown 0 +cap_dac_override 1 +cap_audit_control 30 +cap_setfcap 31 +cap_mac_override 32 + + + + + <command>systemd-analyze condition <replaceable>CONDITION</replaceable>...</command> + + This command will evaluate Condition*=... and + Assert*=... assignments, and print their values, and + the resulting value of the combined condition set. See + systemd.unit5 + for a list of available conditions and asserts. + + + Evaluate conditions that check kernel versions + + $ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \ + 'ConditionKernelVersion = >=5.1' \ + 'ConditionACPower=|false' \ + 'ConditionArchitecture=|!arm' \ + 'AssertPathExists=/etc/os-release' +test.service: AssertPathExists=/etc/os-release succeeded. +Asserts succeeded. +test.service: ConditionArchitecture=|!arm succeeded. +test.service: ConditionACPower=|false failed. +test.service: ConditionKernelVersion=>=5.1 succeeded. +test.service: ConditionKernelVersion=!<4.0 succeeded. +Conditions succeeded. + + + + + <command>systemd-analyze syscall-filter <optional><replaceable>SET</replaceable>...</optional></command> + + This command will list system calls contained in the specified system call set + SET, or all known sets if no sets are specified. Argument + SET must include the @ prefix. + + + + <command>systemd-analyze filesystems <optional><replaceable>SET</replaceable>...</optional></command> + + This command will list filesystems in the specified filesystem set + SET, or all known sets if no sets are specified. Argument + SET must include the @ prefix. + + + + <command>systemd-analyze calendar <replaceable>EXPRESSION</replaceable>...</command> + + This command will parse and normalize repetitive calendar time events, and will calculate when + they elapse next. This takes the same input as the OnCalendar= setting in + systemd.timer5, + following the syntax described in + systemd.time7. By + default, only the next time the calendar expression will elapse is shown; use + to show the specified number of next times the expression + elapses. Each time the expression elapses forms a timestamp, see the timestamp + verb below. + + + Show leap days in the near future + + $ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0' + Original form: *-2-29 0:0:0 +Normalized form: *-02-29 00:00:00 + Next elapse: Sat 2020-02-29 00:00:00 UTC + From now: 11 months 15 days left + Iter. #2: Thu 2024-02-29 00:00:00 UTC + From now: 4 years 11 months left + Iter. #3: Tue 2028-02-29 00:00:00 UTC + From now: 8 years 11 months left + Iter. #4: Sun 2032-02-29 00:00:00 UTC + From now: 12 years 11 months left + Iter. #5: Fri 2036-02-29 00:00:00 UTC + From now: 16 years 11 months left + + + + + + <command>systemd-analyze timestamp <replaceable>TIMESTAMP</replaceable>...</command> + + This command parses a timestamp (i.e. a single point in time) and outputs the normalized form and + the difference between this timestamp and now. The timestamp should adhere to the syntax documented in + systemd.time7, + section "PARSING TIMESTAMPS". + + + Show parsing of timestamps + + $ systemd-analyze timestamp yesterday now tomorrow + Original form: yesterday +Normalized form: Mon 2019-05-20 00:00:00 CEST + (in UTC): Sun 2019-05-19 22:00:00 UTC + UNIX seconds: @15583032000 + From now: 1 day 9h ago + + Original form: now +Normalized form: Tue 2019-05-21 09:48:39 CEST + (in UTC): Tue 2019-05-21 07:48:39 UTC + UNIX seconds: @1558424919.659757 + From now: 43us ago + + Original form: tomorrow +Normalized form: Wed 2019-05-22 00:00:00 CEST + (in UTC): Tue 2019-05-21 22:00:00 UTC + UNIX seconds: @15584760000 + From now: 14h left + + + + + + <command>systemd-analyze timespan <replaceable>EXPRESSION</replaceable>...</command> + + This command parses a time span (i.e. a difference between two timestamps) and outputs the + normalized form and the equivalent value in microseconds. The time span should adhere to the syntax + documented in + systemd.time7, + section "PARSING TIME SPANS". Values without units are parsed as seconds. + + + Show parsing of timespans + + $ systemd-analyze timespan 1s 300s '1year 0.000001s' +Original: 1s + μs: 1000000 + Human: 1s + +Original: 300s + μs: 300000000 + Human: 5min + +Original: 1year 0.000001s + μs: 31557600000001 + Human: 1y 1us + + + + + + <command>systemd-analyze cat-config</command> + <replaceable>NAME</replaceable>|<replaceable>PATH</replaceable>... + + This command is similar to systemctl cat, but operates on config files. It + will copy the contents of a config file and any drop-ins to standard output, using the usual systemd + set of directories and rules for precedence. Each argument must be either an absolute path including + the prefix (such as /etc/systemd/logind.conf or + /usr/lib/systemd/logind.conf), or a name relative to the prefix (such as + systemd/logind.conf). + + + Showing logind configuration + $ systemd-analyze cat-config systemd/logind.conf +# /etc/systemd/logind.conf +... +[Login] +NAutoVTs=8 +... + +# /usr/lib/systemd/logind.conf.d/20-test.conf +... some override from another package + +# /etc/systemd/logind.conf.d/50-override.conf +... some administrator override + + + + + + <command>systemd-analyze compare-versions + <replaceable>VERSION1</replaceable> + <optional><replaceable>OP</replaceable></optional> + <replaceable>VERSION2</replaceable></command> + + This command has two distinct modes of operation, depending on whether the operator + OP is specified. + + In the first mode — when OP is not specified — it will compare the two + version strings and print either VERSION1 < + VERSION2, or VERSION1 == + VERSION2, or VERSION1 > + VERSION2 as appropriate. + + The exit status is 0 if the versions are equal, 11 if + the version of the right is smaller, and 12 if the version of the left is + smaller. (This matches the convention used by rpmdev-vercmp.) + + In the second mode — when OP is specified — it will compare the two + version strings using the operation OP and return 0 + (success) if they condition is satisfied, and 1 (failure) + otherwise. OP may be lt, le, + eq, ne, ge, gt. In this + mode, no output is printed. + (This matches the convention used by + dpkg1 + .) + + + Compare versions of a package + + +$ systemd-analyze compare-versions systemd-250~rc1.fc36.aarch64 systemd-251.fc36.aarch64 +systemd-250~rc1.fc36.aarch64 < systemd-251.fc36.aarch64 +$ echo $? +12 + +$ systemd-analyze compare-versions 1 lt 2; echo $? +0 +$ systemd-analyze compare-versions 1 ge 2; echo $? +1 + + + + + + <command>systemd-analyze verify <replaceable>FILE</replaceable>...</command> + + This command will load unit files and print warnings if any errors are detected. Files specified + on the command line will be loaded, but also any other units referenced by them. A unit's name on disk + can be overridden by specifying an alias after a colon; see below for an example. The full unit search + path is formed by combining the directories for all command line arguments, and the usual unit load + paths. The variable $SYSTEMD_UNIT_PATH is supported, and may be used to replace or + augment the compiled in set of unit load paths; see + systemd.unit5. All + units files present in the directories containing the command line arguments will be used in preference + to the other paths. + + The following errors are currently detected: + + unknown sections and directives, + + missing dependencies which are required to start the given unit, + + man pages listed in Documentation= which are not found in the + system, + + commands listed in ExecStart= and similar which are not found in + the system or not executable. + + + + Misspelt directives + + $ cat ./user.slice +[Unit] +WhatIsThis=11 +Documentation=man:nosuchfile(1) +Requires=different.service + +[Service] +Description=x + +$ systemd-analyze verify ./user.slice +[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit' +[./user.slice:13] Unknown section 'Service'. Ignoring. +Error: org.freedesktop.systemd1.LoadFailed: + Unit different.service failed to load: + No such file or directory. +Failed to create user.slice/start: Invalid argument +user.slice: man nosuchfile(1) command failed with code 16 + + + + + Missing service units + + $ tail ./a.socket ./b.socket +==> ./a.socket <== +[Socket] +ListenStream=100 + +==> ./b.socket <== +[Socket] +ListenStream=100 +Accept=yes + +$ systemd-analyze verify ./a.socket ./b.socket +Service a.service not loaded, a.socket cannot be started. +Service b@0.service not loaded, b.socket cannot be started. + + + + + Aliasing a unit + + $ cat /tmp/source +[Unit] +Description=Hostname printer + +[Service] +Type=simple +ExecStart=/usr/bin/echo %H +MysteryKey=true + +$ systemd-analyze verify /tmp/source +Failed to prepare filename /tmp/source: Invalid argument + +$ systemd-analyze verify /tmp/source:alias.service +/tmp/systemd-analyze-XXXXXX/alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring. + + + + + + + <command>systemd-analyze security <optional><replaceable>UNIT</replaceable>...</optional></command> + + This command analyzes the security and sandboxing settings of one or more specified service + units. If at least one unit name is specified the security settings of the specified service units are + inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded, + long-running service units are inspected and a terse table with results shown. The command checks for + various security-related service settings, assigning each a numeric "exposure level" value, depending + on how important a setting is. It then calculates an overall exposure level for the whole unit, which + is an estimation in the range 0.0…10.0 indicating how exposed a service is security-wise. High exposure + levels indicate very little applied sandboxing. Low exposure levels indicate tight sandboxing and + strongest security restrictions. Note that this only analyzes the per-service security features systemd + itself implements. This means that any additional security mechanisms applied by the service code + itself are not accounted for. The exposure level determined this way should not be misunderstood: a + high exposure level neither means that there is no effective sandboxing applied by the service code + itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels do + indicate however that most likely the service might benefit from additional settings applied to + them. + + Please note that many of the security and sandboxing settings individually can be circumvented — + unless combined with others. For example, if a service retains the privilege to establish or undo mount + points many of the sandboxing options can be undone by the service code itself. Due to that is + essential that each service uses the most comprehensive and strict sandboxing and security settings + possible. The tool will take into account some of these combinations and relationships between the + settings, but not all. Also note that the security and sandboxing settings analyzed here only apply to + the operations executed by the service code itself. If a service has access to an IPC system (such as + D-Bus) it might request operations from other services that are not subject to the same + restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access + policy is not validated too. + + + Analyze <filename index="false">systemd-logind.service</filename> + + $ systemd-analyze security --no-pager systemd-logind.service + NAME DESCRIPTION EXPOSURE +✗ PrivateNetwork= Service has access to the host's network 0.5 +✗ User=/DynamicUser= Service runs as root user 0.4 +✗ DeviceAllow= Service has no device ACL 0.2 +✓ IPAddressDeny= Service blocks all IP address ranges +... +→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂 + + + + + + <command>systemd-analyze inspect-elf <replaceable>FILE</replaceable>...</command> + + This command will load the specified files, and if they are ELF objects (executables, + libraries, core files, etc.) it will parse the embedded packaging metadata, if any, and print + it in a table or json format. See the + Packaging Metadata documentation for more information. + + + Table output + + $ systemd-analyze inspect-elf --json=pretty /tmp/core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000 +{ + "elfType" : "coredump", + "elfArchitecture" : "AMD x86-64", + "/home/bluca/git/fsverity-utils/fsverity" : { + "type" : "deb", + "name" : "fsverity-utils", + "version" : "1.3-1", + "buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee" + }, + "/home/bluca/git/fsverity-utils/libfsverity.so.0" : { + "type" : "deb", + "name" : "fsverity-utils", + "version" : "1.3-1", + "buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88" + } +} + + + + + + + + Options + + The following options are understood: + + + + + + Operates on the system systemd instance. This + is the implied default. + + + + + + Operates on the user systemd + instance. + + + + + + Operates on the system-wide configuration for + user systemd instance. + + + + + + + When used in conjunction with the + dot command (see above), selects which + dependencies are shown in the dependency graph. If + is passed, only dependencies of type + After= or Before= are + shown. If is passed, only + dependencies of type Requires=, + Requisite=, + Wants= and Conflicts= + are shown. If neither is passed, this shows dependencies of + all these types. + + + + + + + When used in conjunction with the + dot command (see above), this selects which + relationships are shown in the dependency graph. Both options + require a + glob7 + pattern as an argument, which will be matched against the + left-hand and the right-hand, respectively, nodes of a + relationship. + + Each of these can be used more than once, in which case + the unit name must match one of the values. When tests for + both sides of the relation are present, a relation must pass + both tests to be shown. When patterns are also specified as + positional arguments, they must match at least one side of the + relation. In other words, patterns specified with those two + options will trim the list of edges matched by the positional + arguments, if any are given, and fully determine the list of + edges shown otherwise. + + + + timespan + + When used in conjunction with the + critical-chain command (see above), also + show units, which finished timespan + earlier, than the latest unit in the same level. The unit of + timespan is seconds unless + specified with a different unit, e.g. + "50ms". + + + + + + Do not invoke + man1 + to verify the existence of man pages listed in Documentation=. + + + + + + Invoke unit generators, see + systemd.generator7. + Some generators require root privileges. Under a normal user, running with + generators enabled will generally result in some warnings. + + + + + + Control verification of units and their dependencies and whether + systemd-analyze verify exits with a non-zero process exit status or not. With + yes, return a non-zero process exit status when warnings arise during verification + of either the specified unit or any of its associated dependencies. With no, + return a non-zero process exit status when warnings arise during verification of only the specified + unit. With one, return a non-zero process exit status when warnings arise during + verification of either the specified unit or its immediate dependencies. If this option is not + specified, zero is returned as the exit status regardless whether warnings arise during verification + or not. + + + + + + With cat-files and verify, + operate on files underneath the specified root path PATH. + + + + + + With cat-files and verify, + operate on files inside the specified image path PATH. + + + + + + With security, perform an offline security review + of the specified unit files, i.e. does not have to rely on PID 1 to acquire security + information for the files like the security verb when used by itself does. + This means that can be used with and + as well. If a unit's overall exposure level is above that set by + (default value is 100), will return + an error. + + + + + + With security , takes into + consideration the specified portable profile when assessing unit settings. + The profile can be passed by name, in which case the well-known system locations will + be searched, or it can be the full path to a specific drop-in file. + + + + + + With security, allow the user to set a custom value + to compare the overall exposure level with, for the specified unit files. If a unit's + overall exposure level, is greater than that set by the user, security + will return an error. can be used with + as well and its default value is 100. + + + + + + With security, allow the user to define a custom set of + requirements formatted as a JSON file against which to compare the specified unit file(s) + and determine their overall exposure level to security threats. + + + Accepted Assessment Test Identifiers + + + + + + Assessment Test Identifier + + + + + UserOrDynamicUser + + + SupplementaryGroups + + + PrivateMounts + + + PrivateDevices + + + PrivateTmp + + + PrivateNetwork + + + PrivateUsers + + + ProtectControlGroups + + + ProtectKernelModules + + + ProtectKernelTunables + + + ProtectKernelLogs + + + ProtectClock + + + ProtectHome + + + ProtectHostname + + + ProtectSystem + + + RootDirectoryOrRootImage + + + LockPersonality + + + MemoryDenyWriteExecute + + + NoNewPrivileges + + + CapabilityBoundingSet_CAP_SYS_ADMIN + + + CapabilityBoundingSet_CAP_SET_UID_GID_PCAP + + + CapabilityBoundingSet_CAP_SYS_PTRACE + + + CapabilityBoundingSet_CAP_SYS_TIME + + + CapabilityBoundingSet_CAP_NET_ADMIN + + + CapabilityBoundingSet_CAP_SYS_RAWIO + + + CapabilityBoundingSet_CAP_SYS_MODULE + + + CapabilityBoundingSet_CAP_AUDIT + + + CapabilityBoundingSet_CAP_SYSLOG + + + CapabilityBoundingSet_CAP_SYS_NICE_RESOURCE + + + CapabilityBoundingSet_CAP_MKNOD + + + CapabilityBoundingSet_CAP_CHOWN_FSETID_SETFCAP + + + CapabilityBoundingSet_CAP_DAC_FOWNER_IPC_OWNER + + + CapabilityBoundingSet_CAP_KILL + + + CapabilityBoundingSet_CAP_NET_BIND_SERVICE_BROADCAST_RAW + + + CapabilityBoundingSet_CAP_SYS_BOOT + + + CapabilityBoundingSet_CAP_MAC + + + CapabilityBoundingSet_CAP_LINUX_IMMUTABLE + + + CapabilityBoundingSet_CAP_IPC_LOCK + + + CapabilityBoundingSet_CAP_SYS_CHROOT + + + CapabilityBoundingSet_CAP_BLOCK_SUSPEND + + + CapabilityBoundingSet_CAP_WAKE_ALARM + + + CapabilityBoundingSet_CAP_LEASE + + + CapabilityBoundingSet_CAP_SYS_TTY_CONFIG + + + CapabilityBoundingSet_CAP_BPF + + + UMask + + + KeyringMode + + + ProtectProc + + + ProcSubset + + + NotifyAccess + + + RemoveIPC + + + Delegate + + + RestrictRealtime + + + RestrictSUIDSGID + + + RestrictNamespaces_user + + + RestrictNamespaces_mnt + + + RestrictNamespaces_ipc + + + RestrictNamespaces_pid + + + RestrictNamespaces_cgroup + + + RestrictNamespaces_uts + + + RestrictNamespaces_net + + + RestrictAddressFamilies_AF_INET_INET6 + + + RestrictAddressFamilies_AF_UNIX + + + RestrictAddressFamilies_AF_NETLINK + + + RestrictAddressFamilies_AF_PACKET + + + RestrictAddressFamilies_OTHER + + + SystemCallArchitectures + + + SystemCallFilter_swap + + + SystemCallFilter_obsolete + + + SystemCallFilter_clock + + + SystemCallFilter_cpu_emulation + + + SystemCallFilter_debug + + + SystemCallFilter_mount + + + SystemCallFilter_module + + + SystemCallFilter_raw_io + + + SystemCallFilter_reboot + + + SystemCallFilter_privileged + + + SystemCallFilter_resources + + + IPAddressDeny + + + DeviceAllow + + + AmbientCapabilities + + + +
+ + See example "JSON Policy" below. + + + + + + With the security command, generate a JSON formatted + output of the security analysis table. The format is a JSON array with objects + containing the following fields: set which indicates if the setting has + been enabled or not, name which is what is used to refer to the setting, + json_field which is the JSON compatible identifier of the setting, + description which is an outline of the setting state, and + exposure which is a number in the range 0.0…10.0, where a higher value + corresponds to a higher security threat. The JSON version of the table is printed to standard + output. The MODE passed to the option can be one of three: + which is the default, and + which respectively output a prettified or shorted JSON version of the security table. + + + + + + When used with the calendar command, show the specified number of + iterations the specified calendar expression will elapse next. Defaults to 1. + + + + + + When used with the calendar command, show next iterations relative + to the specified point in time. If not specified defaults to the current time. + + + + + + When used with the condition command, evaluate all the + Condition*=... and Assert*=... + assignments in the specified unit file. The full unit search path is formed by combining the + directories for the specified unit with the usual unit load paths. The variable + $SYSTEMD_UNIT_PATH is supported, and may be used to replace or augment the + compiled in set of unit load paths; see + systemd.unit5. All + units files present in the directory containing the specified unit will be used in preference to the + other paths. + + + + + + + + + + Suppress hints and other non-essential output. + + + + + + + + + + + Exit status + + For most commands, 0 is returned on success, and a non-zero failure code otherwise. + + With the verb compare-versions, in the two-argument form, + 12, 0, 11 is returned if the second + version string is respectively larger, equal, or smaller to the first. In the three-argument form, + 0 or 1 if the condition is respectively true or false. + + + + + + Examples + + + JSON Policy + + The JSON file passed as a path parameter to has a top-level + JSON object, with keys being the assessment test identifiers mentioned above. The values in the file + should be JSON objects with one or more of the following fields: + (string), (string), (string), + (unsigned integer), and (unsigned integer). If any of + these fields corresponding to a specific id of the unit file is missing from the JSON object, the + default built-in field value corresponding to that same id is used for security analysis as default. + The weight and range fields are used in determining the overall exposure level of the unit files: the + value of each setting is assigned a badness score, which is multiplied by the policy weight and divided + by the policy range to determine the overall exposure that the setting implies. The computed badness is + summed across all settings in the unit file, normalized to the 1…100 range, and used to determine the + overall exposure level of the unit. By allowing users to manipulate these fields, the 'security' verb + gives them the option to decide for themself which ids are more important and hence should have a + greater effect on the exposure level. A weight of 0 means the setting will not be + checked. + + +{ + "PrivateDevices": + { + "description_good": "Service has no access to hardware devices", + "description_bad": "Service potentially has access to hardware devices", + "weight": 1000, + "range": 1 + }, + "PrivateMounts": + { + "description_good": "Service cannot install system mounts", + "description_bad": "Service may install system mounts", + "weight": 1000, + "range": 1 + }, + "PrivateNetwork": + { + "description_good": "Service has no access to the host's network", + "description_bad": "Service has access to the host's network", + "weight": 2500, + "range": 1 + }, + "PrivateTmp": + { + "description_good": "Service has no access to other software's temporary files", + "description_bad": "Service has access to other software's temporary files", + "weight": 1000, + "range": 1 + }, + "PrivateUsers": + { + "description_good": "Service does not have access to other users", + "description_bad": "Service has access to other users", + "weight": 1000, + "range": 1 + } +} + + + + + + See Also + + systemd1, + systemctl1 + + + + diff --git a/man/systemd-ask-password-console.service.xml b/man/systemd-ask-password-console.service.xml new file mode 100644 index 0000000..03b7317 --- /dev/null +++ b/man/systemd-ask-password-console.service.xml @@ -0,0 +1,67 @@ + + + + + + + + systemd-ask-password-console.service + systemd + + + + systemd-ask-password-console.service + 8 + + + + systemd-ask-password-console.service + systemd-ask-password-console.path + systemd-ask-password-wall.service + systemd-ask-password-wall.path + Query the user for system passwords on the + console and via wall + + + + systemd-ask-password-console.service + systemd-ask-password-console.path + systemd-ask-password-wall.service + systemd-ask-password-wall.path + + + + Description + + systemd-ask-password-console.service is + a system service that queries the user for system passwords (such + as hard disk encryption keys and SSL certificate passphrases) on + the console. It is intended to be used during boot to ensure + proper handling of passwords necessary for boot. + systemd-ask-password-wall.service is a system + service that informs all logged in users for system passwords via + wall1. + It is intended to be used after boot to ensure that users are + properly notified. + + See the developer + documentation for more information about the system password logic. + + + Note that these services invoke + systemd-tty-ask-password-agent1 + with either the --watch --console or + --watch --wall command line parameters. + + + + See Also + + systemd1, + systemd-tty-ask-password-agent1, + wall1 + + + + diff --git a/man/systemd-ask-password.xml b/man/systemd-ask-password.xml new file mode 100644 index 0000000..27f7775 --- /dev/null +++ b/man/systemd-ask-password.xml @@ -0,0 +1,252 @@ + + + + + + + + systemd-ask-password + systemd + + + + systemd-ask-password + 1 + + + + systemd-ask-password + Query the user for a system password + + + + + systemd-ask-password OPTIONS MESSAGE + + + + + Description + + systemd-ask-password may be used to query + a system password or passphrase from the user, using a question + message specified on the command line. When run from a TTY it will + query a password on the TTY and print it to standard output. When + run with no TTY or with it will use the + system-wide query mechanism, which allows active users to respond via + several agents, listed below. + + The purpose of this tool is to query system-wide passwords + — that is passwords not attached to a specific user account. + Examples include: unlocking encrypted hard disks when they are + plugged in or at boot, entering an SSL certificate passphrase for + web and VPN servers. + + Existing agents are: + + + A boot-time password agent asking the user for + passwords using + plymouth8, + + + A boot-time password agent querying the user + directly on the console — + systemd-ask-password-console.service8, + + + An agent requesting password input via a + wall1 + message — + systemd-ask-password-wall.service8, + + + A TTY agent that is temporarily spawned during + systemctl1 + invocations, + + A command line agent which can be started + temporarily to process queued password + requests — systemd-tty-ask-password-agent --query. + + + + Answering system-wide password queries is a privileged operation, hence + all the agents listed above (except for the last one), run as privileged + system services. The last one also needs elevated privileges, so + should be run through + sudo8 + or similar. + + Additional password agents may be implemented according to + the systemd Password Agent + Specification. + + If a password is queried on a TTY, the user may press TAB to + hide the asterisks normally shown for each character typed. + Pressing Backspace as first key achieves the same effect. + + + + + Options + + The following options are understood: + + + + + + Specify an icon name alongside the password + query, which may be used in all agents supporting graphical + display. The icon name should follow the XDG + Icon Naming Specification. + + + + + Specify an identifier for this password + query. This identifier is freely choosable and allows + recognition of queries by involved agents. It should include + the subsystem doing the query and the specific object the + query is done for. Example: + --id=cryptsetup:/dev/sda5. + + + + + Configure a kernel keyring key name to use as + cache for the password. If set, then the tool will try to push + any collected passwords into the kernel keyring of the root + user, as a key of the specified name. If combined with + , it will also try to retrieve + such cached passwords from the key in the kernel keyring + instead of querying the user right away. By using this option, + the kernel keyring may be used as effective cache to avoid + repeatedly asking users for passwords, if there are multiple + objects that may be unlocked with the same password. The + cached key will have a timeout of 2.5min set, after which it + will be purged from the kernel keyring. Note that it is + possible to cache multiple passwords under the same keyname, + in which case they will be stored as NUL-separated list of + passwords. Use + keyctl1 + to access the cached key via the kernel keyring + directly. Example: --keyname=cryptsetup + + + + + Configure a credential to read the password from – if it exists. This may be used in + conjunction with the LoadCredential= and SetCredential= + settings in unit files. See + systemd.exec5 for + details. If not specified, defaults to password. This option has no effect if no + credentials directory is passed to the program (i.e. $CREDENTIALS_DIRECTORY is not + set) or if the no credential of the specified name exists. + + + + + + Specify the query timeout in seconds. Defaults + to 90s. A timeout of 0 waits indefinitely. + + + + + + Controls whether to echo user input. Takes a boolean or the special string + masked, the default being the latter. If enabled the typed characters are echoed + literally, which is useful for prompting for usernames and other non-protected data. If disabled the + typed characters are not echoed in any form, the user will not get feedback on their input. If set to + masked, an asterisk (*) is echoed for each character + typed. In this mode, if the user hits the tabulator key (↹), echo is turned + off. (Alternatively, if the user hits the backspace key (⌫) while no data has + been entered otherwise, echo is turned off, too). + + + + + + + Equivalent to , see above. + + + + + + Controls whether or not to prefix the query with a + lock and key emoji (🔐), if the TTY settings permit this. The default + is auto, which defaults to yes, + unless is given. + + + + + + Never ask for password on current TTY even if + one is available. Always use agent system. + + + + + + If passed, accept cached passwords, i.e. + passwords previously entered. + + + + + + When used in conjunction with + accept multiple passwords. + This will output one password per line. + + + + + + Do not print passwords to standard output. This is useful if you want to store a + password in kernel keyring with but do not want it to show up on screen + or in logs. + + + + + + By default, when the acquired password is written to standard output it is suffixed + by a newline character. This may be turned off with the switch, similarly to the + switch of the same name of the echo1 + command. + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemd-ask-password-console.service8, + systemd-tty-ask-password-agent1, + keyctl1, + plymouth8, + wall1 + + + + diff --git a/man/systemd-backlight@.service.xml b/man/systemd-backlight@.service.xml new file mode 100644 index 0000000..7294910 --- /dev/null +++ b/man/systemd-backlight@.service.xml @@ -0,0 +1,70 @@ + + + + + + + + systemd-backlight@.service + systemd + + + + systemd-backlight@.service + 8 + + + + systemd-backlight@.service + systemd-backlight + Load and save the display backlight brightness at boot and shutdown + + + + systemd-backlight@.service + /usr/lib/systemd/systemd-backlight save [backlight|leds]:DEVICE + /usr/lib/systemd/systemd-backlight load [backlight|leds]:DEVICE + + + + Description + + systemd-backlight@.service is a service + that restores the display backlight brightness at early boot and + saves it at shutdown. On disk, the backlight brightness is stored + in /var/lib/systemd/backlight/. During + loading, if the udev property is + not set to false, the brightness is clamped to a value of at + least 1 or 5% of maximum brightness, whichever is greater. This + restriction will be removed when the kernel allows user space to + reliably set a brightness value which does not turn off the + display. + + + + Kernel Command Line + + systemd-backlight understands the + following kernel command line parameter: + + + + systemd.restore_state= + + Takes a boolean argument. Defaults to + 1. If 0, does not + restore the backlight settings on boot. However, settings will + still be stored on shutdown. + + + + + + See Also + + systemd1 + + + + diff --git a/man/systemd-binfmt.service.xml b/man/systemd-binfmt.service.xml new file mode 100644 index 0000000..25c5e6d --- /dev/null +++ b/man/systemd-binfmt.service.xml @@ -0,0 +1,68 @@ + + + + + + + + systemd-binfmt.service + systemd + + + + systemd-binfmt.service + 8 + + + + systemd-binfmt.service + systemd-binfmt + Configure additional binary formats for executables at boot + + + + systemd-binfmt.service + /usr/lib/systemd/systemd-binfmt + + + + Description + + systemd-binfmt.service is an early boot + service that registers additional binary formats for executables + in the kernel. + + See + binfmt.d5 + for information about the configuration of this service. + + + Options + + + + + If passed, instead of registering configured binary formats in the kernel, the + reverse operation is executed: all currently registered binary formats are unregistered from the + kernel. + + + + + + + + + + + See Also + + systemd1, + binfmt.d5, + wine8 + + + + diff --git a/man/systemd-bless-boot-generator.xml b/man/systemd-bless-boot-generator.xml new file mode 100644 index 0000000..992e0e9 --- /dev/null +++ b/man/systemd-bless-boot-generator.xml @@ -0,0 +1,48 @@ + + + + + + + + systemd-bless-boot-generator + systemd + + + + systemd-bless-boot-generator + 8 + + + + systemd-bless-boot-generator + Pull systemd-bless-boot.service into the initial boot transaction when boot counting is in effect + + + + /usr/lib/systemd/system-generators/systemd-bless-boot-generator + + + + Description + + systemd-bless-boot-generator is a generator that pulls + systemd-bless-boot.service into the initial boot transaction when boot counting, as + implemented by systemd-boot7, is + enabled. + + systemd-bless-boot-generator implements + systemd.generator7. + + + + See Also + + systemd1, + systemd-bless-boot.service8, + systemd-boot7 + + + + diff --git a/man/systemd-bless-boot.service.xml b/man/systemd-bless-boot.service.xml new file mode 100644 index 0000000..bccf22c --- /dev/null +++ b/man/systemd-bless-boot.service.xml @@ -0,0 +1,113 @@ + + + + + + + + systemd-bless-boot.service + systemd + + + + systemd-bless-boot.service + 8 + + + + systemd-bless-boot.service + systemd-bless-boot + Mark current boot process as successful + + + + systemd-bless-boot.service + /usr/lib/systemd/systemd-bless-boot + + + + Description + + systemd-bless-boot.service is a system service that marks the current boot process as + successful. It's automatically pulled into the initial transaction when + systemd-bless-boot-generator8 + detects that systemd-boot7 style + boot counting is used. + + Internally, the service operates based on the LoaderBootCountPath EFI variable (of the + vendor UUID 4a67b082-0a4c-41cf-b6c7-440b29bb8c4), which is passed from the boot loader to the + OS. It contains a file system path (relative to the EFI system partition) of the Boot Loader Specification compliant boot loader entry + file or unified kernel image file that was used to boot up the + system. systemd-bless-boot.service removes the two 'tries done' and 'tries left' numeric boot + counters from the filename, which indicates to future invocations of the boot loader that the entry has completed + booting successfully at least once. (This service will hence rename the boot loader entry file or unified kernel + image file on the first successful boot.) + + + + Options + + The /usr/lib/systemd/systemd-bless-boot executable may also be invoked from the + command line, taking one of the following command arguments: + + + + + + The current status of the boot loader entry file or unified kernel image file is shown. This + outputs one of good, bad, indeterminate, + clean, depending on the state and previous invocations of the command. The string + indeterminate is shown initially after boot, before it has been marked as "good" or + "bad". The string good is shown after the boot was marked as "good" with the + command below, and "bad" conversely after the command was + invoked. The string clean is returned when boot counting is currently not in effect. + + This command is implied if no command argument is specified. + + + + + + When invoked, the current boot loader entry file or unified kernel image file will be marked as + "good", executing the file rename operation described above. This command is intended to be invoked at the end + of a successful boot. The systemd-bless-boot.service unit invokes this + command. + + + + + + When called the 'tries left' counter in the boot loader entry file name or unified kernel image + file name is set to zero, marking the boot loader entry or kernel image as "bad", so that the boot loader won't + consider it anymore on future boots (at least as long as there are other entries available that are not marked + "bad" yet). This command is normally not executed, but can be used to instantly put an end to the boot counting + logic if a problem is detected and persistently mark the boot entry as bad. + + + + + + This command undoes any marking of the current boot loader entry file or unified kernel image + file as good or bad. This is implemented by renaming the boot loader entry file or unified kernel image file + back to the path encoded in the LoaderBootCountPath EFI variable. + + + + + + + + + + See Also + + systemd1, + systemd-boot7, + systemd.special7 + + + + diff --git a/man/systemd-boot-check-no-failures.service.xml b/man/systemd-boot-check-no-failures.service.xml new file mode 100644 index 0000000..39a2aa8 --- /dev/null +++ b/man/systemd-boot-check-no-failures.service.xml @@ -0,0 +1,52 @@ + + + + + + + + systemd-boot-check-no-failures.service + systemd + + + + systemd-boot-check-no-failures.service + 8 + + + + systemd-boot-check-no-failures.service + systemd-boot-check-no-failures + verify that the system booted up cleanly + + + + systemd-boot-check-no-failures.service + /usr/lib/systemd/system-boot-check-no-failures + + + + Description + + systemd-boot-check-no-failures.service is a system service that checks whether the + system booted up successfully. This service implements a very minimal test only: whether there are any failed units on + the system. This service is disabled by default. When enabled, it is ordered before + boot-complete.target, thus ensuring the target cannot be reached when the system booted up + with failed services. + + Note that due the simple nature of this check this service is probably not suitable for deployment in most + scenarios. It is primarily useful only as example for developing more fine-grained checks to order before + boot-complete.target. + + + + See Also + + systemd1, + systemd.special7 + + + + diff --git a/man/systemd-boot-system-token.service.xml b/man/systemd-boot-system-token.service.xml new file mode 100644 index 0000000..f2e30a9 --- /dev/null +++ b/man/systemd-boot-system-token.service.xml @@ -0,0 +1,76 @@ + + + + + + + + systemd-boot-system-token.service + systemd + + + + systemd-boot-system-token.service + 8 + + + + systemd-boot-system-token.service + Generate an initial boot loader system token and random seed + + + + systemd-boot-system-token.service + + + + Description + + systemd-boot-system-token.service is a system service that automatically + generates a 'system token' to store in an EFI variable in the system's NVRAM and a random seed to store + on the EFI System Partition ESP on disk. The boot loader may then combine these two randomized data + fields by cryptographic hashing, and pass it to the OS it boots as initialization seed for its entropy + pool. The random seed stored in the ESP is refreshed on each reboot ensuring that multiple subsequent + boots will boot with different seeds. The 'system token' is generated randomly once, and then + persistently stored in the system's EFI variable storage. + + The systemd-boot-system-token.service unit invokes the bootctl + random-seed command, which updates the random seed in the ESP, and initializes the 'system + token' if it's not initialized yet. The service is conditionalized so that it is run only when all of the + below apply: + + + A boot loader is used that implements the Boot Loader Interface (which defines the 'system + token' concept). + + Either a 'system token' was not set yet, or the boot loader has not passed the OS a + random seed yet (and thus most likely has been missing the random seed file in the + ESP). + + The system is not running in a VM environment. This case is explicitly excluded since + on VM environments the ESP backing storage and EFI variable storage is typically not physically + separated and hence booting the same OS image in multiple instances would replicate both, thus reusing + the same random seed and 'system token' among all instances, which defeats its purpose. Note that it's + still possible to use boot loader random seed provisioning in this mode, but the automatic logic + implemented by this service has no effect then, and the user instead has to manually invoke the + bootctl random-seed acknowledging these restrictions. + + + For further details see + bootctl1, regarding + the command this service invokes. + + + + See Also + + systemd1, + bootctl1, + systemd-boot7 + + + + diff --git a/man/systemd-boot.xml b/man/systemd-boot.xml new file mode 100644 index 0000000..0eee532 --- /dev/null +++ b/man/systemd-boot.xml @@ -0,0 +1,541 @@ + + + + + + + systemd-boot + systemd + + + + systemd-boot + 7 + + + + systemd-boot + sd-boot + A simple UEFI boot manager + + + + Description + + systemd-boot (short: sd-boot) is a simple UEFI boot + manager. It provides a textual menu to select the entry to boot and an editor for the kernel command + line. systemd-boot supports systems with UEFI firmware only. + + systemd-boot loads boot entry information from the EFI system partition (ESP), + usually mounted at /efi/, /boot/, or + /boot/efi/ during OS runtime, as well as from the Extended Boot Loader partition + (XBOOTLDR) if it exists (usually mounted to /boot/). Configuration file fragments, + kernels, initrds and other EFI images to boot generally need to reside on the ESP or the Extended Boot + Loader partition. Linux kernels must be built with to be able to be + directly executed as an EFI image. During boot systemd-boot automatically assembles a + list of boot entries from the following sources: + + + Boot entries defined with Boot Loader Specification Type #1 + description files located in /loader/entries/ on the ESP and the Extended Boot + Loader Partition. These usually describe Linux kernel images with associated initrd images, but + alternatively may also describe other arbitrary EFI executables. + + Unified kernel images, Boot + Loader Specification Type #2, which are executable EFI binaries in + /EFI/Linux/ on the ESP and the Extended Boot Loader Partition. + + The Microsoft Windows EFI boot manager, if installed. + + The Apple macOS boot manager, if installed. + + The EFI Shell binary, if installed. + + A reboot into the UEFI firmware setup option, if supported by the firmware. + + Secure boot variables enrollement if the UEFI firmware is in setup-mode and files are provided + on the ESP. + + + systemd-boot supports the following features: + + + Basic boot manager configuration changes (such as timeout + configuration, default boot entry selection, …) may be made directly from the boot loader UI at + boot-time, as well as during system runtime with EFI variables. + + The boot manager integrates with the systemctl command to implement + features such as systemctl reboot --boot-loader-entry=… (for rebooting into a + specific boot menu entry, i.e. "reboot into Windows") and systemctl reboot + --boot-loader-menu=… (for rebooting into the boot loader menu), by implementing the Boot Loader Interface. See + systemctl1 for + details. + + An EFI variable set by the boot loader informs the OS about the EFI System Partition used + during boot. This is then used to automatically mount the correct EFI System Partition to + /efi/ or /boot/ during OS runtime. See + systemd-gpt-auto-generator8 + for details. + + The boot manager provides information about the boot time spent in UEFI firmware using + the Boot Loader Interface. This + information can be displayed using + systemd-analyze1. + + + The boot manager implements boot counting and automatic fallback to older, working boot + entries on failure. See Automatic Boot + Assessment. + + The boot manager optionally reads a random seed from the ESP partition, combines it + with a 'system token' stored in a persistent EFI variable and derives a random seed to use by the OS as + entropy pool initialization, providing a full entropy pool during early boot. + + The boot manager allows for secure boot variables to be enrolled if the UEFI firmware is + in setup-mode. Additionally, variables can be automatically enrolled if configured. + + + bootctl1 + may be used from a running system to locate the ESP and the Extended Boot Loader Partition, list + available entries, and install systemd-boot itself. + + kernel-install8 + may be used to copy kernel images onto the ESP or the Extended Boot Loader Partition and to generate + description files compliant with the Boot Loader + Specification. + + systemd-stub7 + may be used as UEFI boot stub for executed kernels, which is useful to show graphical boot splashes + before transitioning into the Linux world. It is also capable of automatically picking up auxiliary + credential files (for boot parameterization) and system extension images, as companion files to the + booted kernel images. + + + + Key bindings + The following keys may be used in the boot menu: + + + + + + ↑ (Up) + ↓ (Down) + j + k + PageUp + PageDown + Home + End + Navigate up/down in the entry list + + + + ↵ (Enter) + → (Right) + Boot selected entry + + + + d + Make selected entry the default + + + + e + Edit the kernel command line for selected entry + + + + + + t + Increase the timeout before default entry is booted + + + + - + T + Decrease the timeout + + + + r + Change screen resolution, skipping any unsupported modes. + + + + R + Reset screen resolution to firmware or configuration file default. + + + + p + Print status + + + + h + ? + F1 + Show a help screen + + + + f + Reboot into firmware interface. + + For compatibility with the keybindings of several firmware implementations this operation + may also be reached with F2, F10, Del and + Esc. + + + + The following keys may be pressed during bootup or in the boot menu to directly boot a specific + entry: + + + + l + Linux + + + + w + Windows + + + + a + macOS + + + + s + EFI shell + + + + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + Boot entry number 1 … 9 + + + + The boot menu is shown when a non-zero menu timeout has been configured. If the menu timeout has + been set to zero, it is sufficient to press any key — before the boot loader initializes — to bring up + the boot menu, except for the keys listed immediately above as they directly boot into the selected boot + menu item. Note that depending on the firmware implementation the time window where key presses are + accepted before the boot loader initializes might be short. If the window is missed, reboot and try + again, possibly pressing a suitable key (e.g. the space bar) continuously; on most systems it should be + possible to hit the time window after a few attempts. To avoid this problem, consider setting a non-zero + timeout, thus showing the boot menu unconditionally. Some desktop environments might offer an option to + directly boot into the boot menu, to avoid the problem altogether. Alternatively, use the command line + systemctl reboot --boot-loader-menu=0 from the shell. + + In the editor, most keys simply insert themselves, but the following keys + may be used to perform additional actions: + + + + ← (Left) + → (Right) + Home + End + Navigate left/right + + + + Esc + Ctrlc + Abort the edit and quit the editor + + + + Ctrlk + Clear the command line forwards + + + + Ctrlw + AltBackspace + Delete word backwards + + + + CtrlDel + Altd + Delete word forwards + + + + ↵ (Enter) + Boot entry with the edited command line + + + + Note that unless configured otherwise in the UEFI firmware, systemd-boot will + use the US keyboard layout, so key labels might not match for keys like +/-. + + + + + Files + + The files systemd-boot processes generally reside on the UEFI ESP which is + usually mounted to /efi/, /boot/ or + /boot/efi/ during OS runtime. It also processes files on the Extended Boot Loader + partition which is typically mounted to /boot/, if it + exists. + + systemd-boot reads runtime configuration such as the boot timeout and default + entry from /loader/loader.conf on the ESP (in combination with data read from EFI + variables). See + loader.conf5. + + Boot entry description files following the Boot Loader Specification are read from + /loader/entries/ on the ESP and the Extended Boot Loader partition. + + Unified kernel boot entries following the Boot Loader Specification are read from + /EFI/Linux/ on the ESP and the Extended Boot Loader partition. + + Optionally, a random seed for early boot entropy pool provisioning is stored in + /loader/random-seed in the ESP. + + During initialization, sd-boot automatically loads all driver files placed in + the /EFI/systemd/drivers/ directory of the ESP. The files placed there must have an + extension of the EFI architecture ID followed by .efi (e.g. for x86-64 this means a + suffix of x64.efi). This may be used to automatically load file system drivers and + similar, to extend the native firmware support. + + Enrollment of Secure Boot variables can be performed manually or automatically if files are available + under /keys/NAME/{db,KEK,PK}.auth, NAME + being the display name for the set of variables in the menu. If one of the sets is named auto + then it might be enrolled automatically depending on whether secure-boot-enroll is set + to force or not. + + + + EFI Variables + + The following EFI variables are defined, set and read by systemd-boot, under the + vendor UUID 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f, for communication between the boot + loader and the OS: + + + + LoaderBootCountPath + If boot counting is enabled, contains the path to the file in whose name the boot counters are + encoded. Set by the boot + loader. systemd-bless-boot.service8 + uses this information to mark a boot as successful as determined by the successful activation of the + boot-complete.target target unit. + + + + LoaderConfigTimeout + LoaderConfigTimeoutOneShot + The menu timeout in seconds. Read by the boot loader. LoaderConfigTimeout + is maintained persistently, while LoaderConfigTimeoutOneShot is a one-time override which is + read once (in which case it takes precedence over LoaderConfigTimeout) and then + removed. LoaderConfigTimeout may be manipulated with the + t/T keys, see above. + + + + LoaderDevicePartUUID + + Contains the partition UUID of the EFI System Partition the boot loader was run from. Set by + the boot + loader. systemd-gpt-auto-generator8 + uses this information to automatically find the disk booted from, in order to discover various other partitions + on the same disk automatically. + + + + LoaderEntries + + A list of the identifiers of all discovered boot loader entries. Set by the boot + loader. + + + + LoaderEntryDefault + LoaderEntryOneShot + + The identifier of the default boot loader entry. Set primarily by the OS and read by the boot + loader. LoaderEntryOneShot sets the default entry for the next boot only, while + LoaderEntryDefault sets it persistently for all future + boots. bootctl1's + and commands make use of these variables. The boot + loader modifies LoaderEntryDefault on request, when the d key is used, see + above. + + + + LoaderEntrySelected + + The identifier of the boot loader entry currently being booted. Set by the boot + loader. + + + + LoaderFeatures + + A set of flags indicating the features the boot loader supports. Set by the boot loader. Use + bootctl1 to view this + data. + + + + LoaderFirmwareInfo + LoaderFirmwareType + + Brief firmware information. Set by the boot loader. Use + bootctl1 to view this + data. + + + + LoaderImageIdentifier + + The path of executable of the boot loader used for the current boot, relative to the EFI System + Partition's root directory. Set by the boot loader. Use + bootctl1 to view this + data. + + + + LoaderInfo + + Brief information about the boot loader. Set by the boot loader. Use + bootctl1 to view this + data. + + + + LoaderTimeExecUSec + LoaderTimeInitUSec + LoaderTimeMenuUsec + + Information about the time spent in various parts of the boot loader. Set by the boot + loader. Use systemd-analyze1 + to view this data. + + + + LoaderRandomSeed + + A binary random seed systemd-boot may optionally pass to the + OS. This is a volatile EFI variable that is hashed at boot from the combination of a random seed + stored in the ESP (in /loader/random-seed) and a "system token" persistently + stored in the EFI variable LoaderSystemToken (see below). During early OS boot the + system manager reads this variable and passes it to the OS kernel's random pool, crediting the full + entropy it contains. This is an efficient way to ensure the system starts up with a fully initialized + kernel random pool — as early as the initrd phase. systemd-boot reads + the random seed from the ESP, combines it with the "system token", and both derives a new random seed + to update in-place the seed stored in the ESP, and the random seed to pass to the OS from it via + SHA256 hashing in counter mode. This ensures that different physical systems that boot the same + "golden" OS image — i.e. containing the same random seed file in the ESP — will still pass a + different random seed to the OS. It is made sure the random seed stored in the ESP is fully + overwritten before the OS is booted, to ensure different random seed data is used between subsequent + boots. + + See Random Seeds for + further information. + + + + LoaderSystemToken + + A binary random data field, that is used for generating the random seed to pass to + the OS (see above). Note that this random data is generally only generated once, during OS + installation, and is then never updated again. + + + + Many of these variables are defined by the Boot Loader Interface. + + + + Boot Counting + + systemd-boot implements a simple boot counting mechanism on top of the Boot Loader Specification, for automatic and unattended + fallback to older kernel versions/boot loader entries when a specific entry continuously fails. Any boot loader + entry file and unified kernel image file that contains a + followed by one or two numbers (if + two they need to be separated by a -), before the .conf or + .efi suffix is subject to boot counting: the first of the two numbers ('tries left') is + decreased by one on every boot attempt, the second of the two numbers ('tries done') is increased by one (if 'tries + done' is absent it is considered equivalent to 0). Depending on the current value of these two counters the boot + entry is considered to be in one of three states: + + + If the 'tries left' counter of an entry is greater than zero the entry is considered to be in + 'indeterminate' state. This means the entry has not completed booting successfully yet, but also hasn't been + determined not to work. + + If the 'tries left' counter of an entry is zero it is considered to be in 'bad' state. This means + no further attempts to boot this item will be made (that is, unless all other boot entries are also in 'bad' + state), as all attempts to boot this entry have not completed successfully. + + If the 'tries left' and 'tries done' counters of an entry are absent it is considered to be in + 'good' state. This means further boot counting for the entry is turned off, as it successfully booted at least + once. The + systemd-bless-boot.service8 + service moves the currently booted entry from 'indeterminate' into 'good' state when a boot attempt completed + successfully. + + + Generally, when new entries are added to the boot loader, they first start out in 'indeterminate' state, + i.e. with a 'tries left' counter greater than zero. The boot entry remains in this state until either it managed to + complete a full boot successfully at least once (in which case it will be in 'good' state) — or the 'tries left' + counter reaches zero (in which case it will be in 'bad' state). + + Example: let's say a boot loader entry file foo.conf is set up for 3 boot tries. The + installer will hence create it under the name foo+3.conf. On first boot, the boot loader will + rename it to foo+2-1.conf. If that boot does not complete successfully, the boot loader will + rename it to foo+1-2.conf on the following boot. If that fails too, it will finally be renamed + foo+0-3.conf by the boot loader on next boot, after which it will be considered 'bad'. If the + boot succeeds however the entry file will be renamed to foo.conf by the OS, so that it is + considered 'good' from then on. + + The boot menu takes the 'tries left' counter into account when sorting the menu entries: entries in 'bad' + state are ordered at the beginning of the list, and entries in 'good' or 'indeterminate' at the end. The user can + freely choose to boot any entry of the menu, including those already marked 'bad'. If the menu entry to boot is + automatically determined, this means that 'good' or 'indeterminate' entries are generally preferred (as the bottom + item of the menu is the one booted by default), and 'bad' entries will only be considered if there are no 'good' or + 'indeterminate' entries left. + + The kernel-install8 kernel + install framework optionally sets the initial 'tries left' counter to the value specified in + /etc/kernel/tries when a boot loader entry is first created. + + + + See Also + + bootctl1, + loader.conf5, + systemd-bless-boot.service8, + systemd-boot-system-token.service8, + kernel-install8, + systemd-stub7, + Boot Loader Specification, + Boot Loader Interface + + + diff --git a/man/systemd-cat.xml b/man/systemd-cat.xml new file mode 100644 index 0000000..a4b6139 --- /dev/null +++ b/man/systemd-cat.xml @@ -0,0 +1,171 @@ + + + + + + + + systemd-cat + systemd + + + + systemd-cat + 1 + + + + systemd-cat + Connect a pipeline or program's output with the journal + + + + + systemd-cat OPTIONS COMMAND ARGUMENTS + + + systemd-cat OPTIONS + + + + + Description + + systemd-cat may be used to connect the + standard input and output of a process to the journal, or as a + filter tool in a shell pipeline to pass the output the previous + pipeline element generates to the journal. + + If no parameter is passed, systemd-cat + will write everything it reads from standard input (stdin) to the + journal. + + If parameters are passed, they are executed as command line + with standard output (stdout) and standard error output (stderr) + connected to the journal, so that all it writes is stored in the + journal. + + + + Options + + The following options are understood: + + + + + + + + + + Specify a short string that is used to + identify the logging tool. If not specified, no identification + string is written to the journal. + + + + + + + Specify the default priority level for the + logged messages. Pass one of + emerg, + alert, + crit, + err, + warning, + notice, + info, + debug, or a + value between 0 and 7 (corresponding to the same named + levels). These priority values are the same as defined by + syslog3. + Defaults to info. Note that this simply + controls the default, individual lines may be logged with + different levels if they are prefixed accordingly. For details, + see below. + + + + + + Specifies the default priority level for + messages from the process's standard error output (stderr). + Usage of this option is the same as the + option, above, and both can be + used at once. When both are used, + will specify the default priority for standard output (stdout). + + + If is not specified, + messages from stderr will still be logged, with the same + default priority level as stdout. + + Also, note that when stdout and stderr use the same + default priority, the messages will be strictly ordered, + because one channel is used for both. When the default priority + differs, two channels are used, and so stdout messages will not + be strictly ordered with respect to stderr messages - though + they will tend to be approximately ordered. + + + + + + Controls whether lines read are parsed for syslog priority level prefixes. If enabled + (the default), a line prefixed with a priority prefix such as <5> is logged + at priority 5 (notice), and similarly for the other priority levels. Takes a + boolean argument. + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Examples + + + Invoke a program + + This calls /bin/ls + with standard output and error connected to the journal: + + # systemd-cat ls + + + + Usage in a shell pipeline + + This builds a shell pipeline also invoking + /bin/ls and writes the output it generates + to the journal: + + # ls | systemd-cat + + + Even though the two examples have very similar effects, the first is preferable, since only one + process is running at a time and both stdout and stderr are captured, while in the second example, only + stdout is captured. + + + + See Also + + systemd1, + systemctl1, + logger1 + + + + diff --git a/man/systemd-cgls.xml b/man/systemd-cgls.xml new file mode 100644 index 0000000..3fa0a35 --- /dev/null +++ b/man/systemd-cgls.xml @@ -0,0 +1,147 @@ + + + + + + + + systemd-cgls + systemd + + + + systemd-cgls + 1 + + + + systemd-cgls + Recursively show control group contents + + + + + systemd-cgls + OPTIONS + CGROUP + + + systemd-cgls + OPTIONS + | + UNIT + + + + + Description + + systemd-cgls recursively shows the + contents of the selected Linux control group hierarchy in a tree. + If arguments are specified, shows all member processes of the + specified control groups plus all their subgroups and their + members. The control groups may either be specified by their full + file paths or are assumed in the systemd control group hierarchy. + If no argument is specified and the current working directory is + beneath the control group mount point + /sys/fs/cgroup/, shows the contents of the + control group the working directory refers to. Otherwise, the full + systemd control group hierarchy is shown. + + By default, empty control groups are not shown. + + + + Options + + The following options are understood: + + + + + + Do not hide empty control groups in the + output. + + + + + + + Do not ellipsize process tree members. + + + + + + + + Show cgroup subtrees for the specified units. + + + + + + + Show cgroup subtrees for the specified user units. + + + + + + + Include kernel threads in output. + + + + + + + + Limit control groups shown to the part + corresponding to the container + MACHINE. + + + + + + Controls whether to include information about extended attributes of the listed + control groups in the output. Expects a boolean value, defaults to yes. + + + + + + Controls whether to include the numeric ID of the listed control groups in the + output. Expects a boolean value, defaults to yes. + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemctl1, + systemd-cgtop1, + systemd-nspawn1, + ps1 + + + + diff --git a/man/systemd-cgtop.xml b/man/systemd-cgtop.xml new file mode 100644 index 0000000..b948f50 --- /dev/null +++ b/man/systemd-cgtop.xml @@ -0,0 +1,349 @@ + + + + + + + + systemd-cgtop + systemd + + + + systemd-cgtop + 1 + + + + systemd-cgtop + Show top control groups by their resource usage + + + + + systemd-cgtop + OPTIONS + GROUP + + + + + Description + + systemd-cgtop shows the top control + groups of the local Linux control group hierarchy, ordered by + their CPU, memory, or disk I/O load. The display is refreshed in + regular intervals (by default every 1s), similar in style to + top1. + If a control group path is specified, shows only the services of + the specified control group. + + If systemd-cgtop is not connected to a + tty, no column headers are printed and the default is to only run + one iteration. The argument, if + given, is honored. This mode is suitable for scripting. + + Resource usage is only accounted for control groups with the appropriate controllers turned on: + cpu controller for CPU usage, memory controller for memory usage, + and io controller for disk I/O consumption. If resource monitoring for these resources + is required, it is recommended to add the CPUAccounting=1, + MemoryAccounting=1 and IOAccounting=1 settings in the unit files in + question. See + systemd.resource-control5 + for details. + + The CPU load value can be between 0 and 100 times the number of + processors the system has. For example, if the system has 8 processors, + the CPU load value is going to be between 0% and 800%. The number of + processors can be found in /proc/cpuinfo. + + To emphasize: unless CPUAccounting=1, MemoryAccounting=1, and + IOAccounting=1 are enabled for the services in question, no resource accounting will + be available for system services and the data shown by systemd-cgtop will be + incomplete. + + + + Options + + The following options are understood: + + + + + + + Order by control group + path name. + + + + + + + Order by number of tasks/processes in the control group. + + + + + + + Order by CPU load. + + + + + + + Order by memory usage. + + + + + + + Order by disk I/O load. + + + + + + + Run in "batch" mode: do not accept input and + run until the iteration limit set with + is exhausted or until killed. + This mode could be useful for sending output from + systemd-cgtop to other programs or to a + file. + + + + + + + Format byte counts (as in memory usage and I/O metrics) and CPU time + with raw numeric values rather than human-readable + numbers. + + + + + + + Controls whether the CPU usage is shown as + percentage or time. By default, the CPU usage is shown as + percentage. This setting may also be toggled at runtime by + pressing the % key. + + + + + + Count only userspace processes instead of all + tasks. By default, all tasks are counted: each kernel thread + and each userspace thread individually. With this setting, + kernel threads are excluded from the count and each userspace + process only counts as one task, regardless of how many + threads it consists of. This setting may also be toggled at + runtime by pressing the P key. This option + may not be combined with + . + + + + + + Count only userspace processes and kernel + threads instead of all tasks. By default, all tasks are + counted: each kernel thread and each userspace thread + individually. With this setting, kernel threads are included in + the count and each userspace process only counts as one task, + regardless of how many threads it consists of. This setting may + also be toggled at runtime by pressing the k + key. This option may not be combined with + . + + + + + + Controls whether the number of processes shown + for a control group shall include all processes that are + contained in any of the child control groups as well. Takes a + boolean argument, which defaults to yes. If + enabled, the processes in child control groups are included, if + disabled, only the processes in the control group itself are + counted. This setting may also be toggled at runtime by + pressing the r key. Note that this setting + only applies to process counting, i.e. when the + or options are + used. It has not effect if all tasks are counted, in which + case the counting is always recursive. + + + + + + + Perform only this many iterations. A value of + 0 indicates that the program should run + indefinitely. + + + + + + A shortcut for . + + + + + + + Specify refresh delay in seconds (or if one of + ms, us, + min is specified as unit in this time + unit). This setting may also be increased and decreased at + runtime by pressing the + and + - keys. + + + + + + Maximum control group tree traversal depth. + Specifies how deep systemd-cgtop shall + traverse the control group hierarchies. If 0 is specified, + only the root group is monitored. For 1, only the first level + of control groups is monitored, and so on. Defaults to + 3. + + + + + + + Limit control groups shown to the part + corresponding to the container + MACHINE. + This option may not be used when a control group path is specified. + + + + + + + + + + Keys + + systemd-cgtop is an interactive tool and + may be controlled via user input using the following keys: + + + + h + + Shows a short help text. + + + + + + Immediately refresh output. + + + + q + + Terminate the program. + + + + p + t + c + m + i + + Sort the control groups by path, number of + tasks, CPU load, memory usage, or I/O load, respectively. This + setting may also be controlled using the + command line + switch. + + + + % + + Toggle between showing CPU time as time or + percentage. This setting may also be controlled using the + command line switch. + + + + + + - + + Increase or decrease refresh delay, + respectively. This setting may also be controlled using the + command line + switch. + + + + P + + Toggle between counting all tasks, or only + userspace processes. This setting may also be controlled using + the command line switch (see + above). + + + + k + + Toggle between counting all tasks, or only + userspace processes and kernel threads. This setting may also + be controlled using the command line + switch (see above). + + + + r + + Toggle between recursively including or + excluding processes in child control groups in control group + process counts. This setting may also be controlled using the + command line switch. This key is + not available if all tasks are counted, it is only available + if processes are counted, as enabled with the + P or k + keys. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemctl1, + systemd-cgls1, + systemd.resource-control5, + top1 + + + + diff --git a/man/systemd-coredump.xml b/man/systemd-coredump.xml new file mode 100644 index 0000000..0f41c69 --- /dev/null +++ b/man/systemd-coredump.xml @@ -0,0 +1,457 @@ + + + + + + + + systemd-coredump + systemd + + + + systemd-coredump + 8 + + + + systemd-coredump + systemd-coredump.socket + systemd-coredump@.service + Acquire, save and process core dumps + + + + /usr/lib/systemd/systemd-coredump + /usr/lib/systemd/systemd-coredump + systemd-coredump@.service + systemd-coredump.socket + + + + Description + systemd-coredump@.service is a system service to process core dumps. It will + log a summary of the event to + systemd-journald.service8, + including information about the process identifier, owner, the signal that killed the process, and the + stack trace if possible. It may also save the core dump for later processing. See the "Information about + the crashed process" section below. + + The behavior of a specific program upon reception of a signal is governed by a few + factors which are described in detail in + core5. + In particular, the core dump will only be processed when the related resource limits are sufficient. + + + Core dumps can be written to the journal or saved as a file. In both cases, they can be retrieved + for further processing, for example in + gdb1. + See coredumpctl1, + in particular the list and debug verbs. + + By default, systemd-coredump will log the core dump to the journal, including a + backtrace if possible, and store the core dump (an image of the memory contents of the process) itself in + an external file in /var/lib/systemd/coredump. These core dumps are deleted after a + few days by default; see /usr/lib/tmpfiles.d/systemd.conf for details. Note that the + removal of core files from the file system and the purging of journal entries are independent, and the + core file may be present without the journal entry, and journal entries may point to since-removed core + files. Some metadata is attached to core files in the form of extended attributes, so the core files are + useful for some purposes even without the full metadata available in the journal entry. + + For further details see systemd Coredump + Handling. + + + Invocation of <command>systemd-coredump</command> + + The systemd-coredump executable does the actual work. It is invoked twice: + once as the handler by the kernel, and the second time in the + systemd-coredump@.service to actually write the data to the journal and process + and save the core file. + + When the kernel invokes systemd-coredump to handle a core dump, it runs in + privileged mode, and will connect to the socket created by the + systemd-coredump.socket unit, which in turn will spawn an unprivileged + systemd-coredump@.service instance to process the core dump. Hence + systemd-coredump.socket and systemd-coredump@.service are + helper units which do the actual processing of core dumps and are subject to normal service + management. + + It is also possible to invoke systemd-coredump with + option. In this case, systemd-coredump expects a + journal entry in the journal + Journal Export Format + on standard input. The entry should contain a MESSAGE= field and any additional + metadata fields the caller deems reasonable. systemd-coredump will append additional + metadata fields in the same way it does for core dumps received from the kernel. In this mode, no core + dump is stored in the journal. + + + + + Configuration + For programs started by systemd, process resource limits can be set by directive + LimitCORE=, see + systemd.exec5. + + + In order to be used by the kernel to handle core dumps, + systemd-coredump must be configured in + sysctl8 + parameter kernel.core_pattern. The syntax of this parameter is explained in + core5. + systemd installs the file /usr/lib/sysctl.d/50-coredump.conf which configures + kernel.core_pattern accordingly. This file may be masked or overridden to use a different + setting following normal + sysctl.d5 + rules. If the sysctl configuration is modified, it must be updated in the kernel before it + takes effect, see + sysctl8 + and + systemd-sysctl8. + + + In order to be used in the mode, an appropriate backtrace + handler must be installed on the sender side. For example, in case of + python1, this + means a sys.excepthook must be installed, see + systemd-coredump-python. + + + The behavior of systemd-coredump itself is configured through the configuration file + /etc/systemd/coredump.conf and corresponding snippets + /etc/systemd/coredump.conf.d/*.conf, see + coredump.conf5. A new + instance of systemd-coredump is invoked upon receiving every core dump. Therefore, changes + in these files will take effect the next time a core dump is received. + + Resources used by core dump files are restricted in two ways. Parameters like maximum size of acquired + core dumps and files can be set in files /etc/systemd/coredump.conf and snippets mentioned + above. In addition the storage time of core dump files is restricted by systemd-tmpfiles, + corresponding settings are by default in /usr/lib/tmpfiles.d/systemd.conf. The default is + to delete core dumps after a few days; see the above file for details. + + + Disabling coredump processing + + To disable potentially resource-intensive processing by systemd-coredump, set + Storage=none ProcessSizeMax=0 in + coredump.conf5. + + + + + + Information about the crashed process + + coredumpctl1 can + be used to retrieve saved core dumps independently of their location, to display information, and to + process them e.g. by passing to the GNU debugger (gdb). + + Data stored in the journal can be also viewed with + journalctl1 as usual + (or from any other process, using the + sd-journal3 API). + The relevant messages have MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1: + $ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose +… +MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 +COREDUMP_PID=552351 +COREDUMP_UID=1000 +COREDUMP_GID=1000 +COREDUMP_SIGNAL_NAME=SIGSEGV +COREDUMP_SIGNAL=11 +COREDUMP_TIMESTAMP=1614342930000000 +COREDUMP_COMM=Web Content +COREDUMP_EXE=/usr/lib64/firefox/firefox +COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope +COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser … +COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-….scope +COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web….552351.….zst +… + + + The following fields are saved (if known) with the journal entry + + + + COREDUMP_UID= + COREDUMP_PID= + COREDUMP_GID= + The process number (PID), owner user number (UID), and group number (GID) of the + crashed process. + + When the crashed process was part of a container (or in a process or user namespace in + general), those are the values as seen outside, in the namespace where + systemd-coredump is running. + + + + + COREDUMP_TIMESTAMP= + The time of the crash as reported by the kernel (in µs since the epoch). + + + + + COREDUMP_RLIMIT= + The core file size soft resource limit, see + getrlimit2. + + + + + COREDUMP_UNIT= + COREDUMP_SLICE= + The system unit and slice names. + + When the crashed process was in container, those are the units names + outside, in the main system manager. + + + + + COREDUMP_CGROUP= + + The primary cgroup of the unit of the crashed process. + + When the crashed process was in a container, this is the full path, as seen outside of the + container. + + + + + COREDUMP_PROC_CGROUP= + Control group information in the format used in + /proc/self/cgroup. On systems with the unified cgroup hierarchy, this is a + single path prefixed with 0::, and multiple paths prefixed with controller numbers + on legacy systems. + + When the crashed process was in a container, this is the full path, as seen outside of the + container. + + + + + COREDUMP_OWNER_UID= + COREDUMP_USER_UNIT= + COREDUMP_SESSION= + The numerical UID of the user owning the login session or systemd user unit of the + crashed process, the user manager unit, and the sesion identifier. All three fields are only present + for user processes. + + When the crashed process was in container, those are the values outside, + in the main system. + + + + + COREDUMP_SIGNAL_NAME= + COREDUMP_SIGNAL= + + The terminating signal name (with the SIG prefix + kill1 + expects signal names without the prefix; kill2 uses + the prefix; all systemd tools accept signal names both with and without the prefix. + ) and numerical value. (Both are included because signal numbers vary by + architecture.) + + + + + COREDUMP_CWD= + COREDUMP_ROOT= + + The current working directory and root directory of the crashed process. + + When the crashed process is in a container, those paths are relative to the root of the + container's mount namespace. + + + + + COREDUMP_OPEN_FDS= + + Information about open file descriptors, in the following format: + fd:/path/to/file +pos: ... +flags: ... +... + +fd:/path/to/file +pos: ... +flags: ... +... + + + The first line contains the file descriptor number fd and the path, + while subsequent lines show the contents of + /proc/pid/fdinfo/fd. + + + + + COREDUMP_EXE= + + The destination of the /proc/pid/exe + symlink. + + When the crashed process is in a container, that path is relative to the root of the + container's mount namespace. + + + + COREDUMP_CMDLINE= + COREDUMP_COMM= + COREDUMP_ENVIRON= + COREDUMP_PROC_AUXV= + COREDUMP_PROC_LIMITS= + COREDUMP_PROC_MAPS= + COREDUMP_PROC_MOUNTINFO= + COREDUMP_PROC_STATUS= + + Fields that map the per-process entries in the /proc/ + filesystem: /proc/pid/cmdline (the command line of + the crashed process), /proc/pid/comm (the command + name associated with the process), /proc/pid/environ + (the environment block of the crashed process), + /proc/pid/auxv (the auxiliary vector of the crashed + process, see getauxval3), + /proc/pid/limits (the soft and hard resource limits), + /proc/pid/maps (memory regions visible to the process + and their access permissions), /proc/pid/mountinfo + (mount points in the process's mount namespace), + /proc/pid/status (various metadata about the + process). + + See + proc5 + for more information. + + + + COREDUMP_HOSTNAME= + + The system hostname. + + When the crashed process was in container, this is the container hostname. + + + + + COREDUMP_CONTAINER_CMDLINE= + + For processes running in a container, the commandline of the process spawning the + container (the first parent process with a different mount namespace). + + + + COREDUMP= + + When the core is stored in the journal, the core image itself. + + + + + COREDUMP_FILENAME= + + When the core is stored externally, the path to the core file. + + + + + COREDUMP_TRUNCATED= + + Set to 1 when the saved coredump was truncated. (A partial core + image may still be processed by some tools, though obviously not all information is available.) + + + + + COREDUMP_PACKAGE_NAME= + COREDUMP_PACKAGE_VERSION= + COREDUMP_PACKAGE_JSON= + + If the executable contained .package metadata ELF notes, they will be + parsed and attached. The package and packageVersion + of the 'main' ELF module (ie: the executable) will be appended individually. The + JSON-formatted content of all modules will be appended as a single JSON object, each with + the module name as the key. For more information about this metadata format and content, see + the coredump metadata spec. + + + + + MESSAGE= + + The message generated by systemd-coredump that includes the + backtrace if it was successfully generated. When systemd-coredump is invoked with + , this field is provided by the caller. + + + + Various other fields exist in the journal entry, but pertain to the logging process, + i.e. systemd-coredump, not the crashed process. See + systemd.journal-fields7. + + + The following fields are saved (if known) with the external file listed in + COREDUMP_FILENAME= as extended attributes: + + + + user.coredump.pid + user.coredump.uid + user.coredump.gid + user.coredump.signal + user.coredump.timestamp + user.coredump.rlimit + user.coredump.hostname + user.coredump.comm + user.coredump.exe + + Those are the same as COREDUMP_PID=, + COREDUMP_UID=, COREDUMP_GID=, + COREDUMP_SIGNAL=, COREDUMP_TIMESTAMP=, + COREDUMP_RLIMIT=, COREDUMP_HOSTNAME=, + COREDUMP_COMM=, and COREDUMP_EXE=, described above. + + + + + Those can be viewed using + getfattr1. + For the core file described in the journal entry shown above: + $ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web….552351.….zst +# file: /var/lib/systemd/coredump/core.Web….552351.….zst +user.coredump.pid="552351" +user.coredump.uid="1000" +user.coredump.gid="1000" +user.coredump.signal="11" +user.coredump.timestamp="1614342930000000" +user.coredump.comm="Web Content" +user.coredump.exe="/usr/lib64/firefox/firefox" +… + + + + + + See Also + + coredump.conf5, + coredumpctl1, + systemd-journald.service8, + systemd-tmpfiles8, + core5, + sysctl.d5, + systemd-sysctl.service8, + systemd Coredump Handling + + + diff --git a/man/systemd-creds.xml b/man/systemd-creds.xml new file mode 100644 index 0000000..ce49d0e --- /dev/null +++ b/man/systemd-creds.xml @@ -0,0 +1,454 @@ + + + + + + + + systemd-creds + systemd + + + + systemd-creds + 1 + + + + systemd-creds + Lists, shows, encrypts and decrypts service credentials + + + + + systemd-creds + OPTIONS + COMMAND + ARGS + + + + + Description + + systemd-creds is a tool for listing, showing, encrypting and decrypting unit + credentials. Credentials are limited-size binary or textual objects that may be passed to unit + processes. They are primarily used for passing cryptographic keys (both public and private) or + certificates, user account information or identity information from the host to services. + + Credentials are configured in unit files via the LoadCredential=, + SetCredential=, LoadCredentialEncrypted= and + SetCredentialEncrypted= settings, see + systemd.exec5 for + details. + + For further information see System and Service + Credentials documentation. + + + + Commands + + The following commands are understood: + + + + list + + Show a list of credentials passed into the current execution context. This command + shows the files in the directory referenced by the $CREDENTIALS_DIRECTORY + environment variable, and is intended to be executed from within service context. + + Along with each credential name, the size and security state is shown. The latter is one of + secure (in case the credential is backed by unswappable memory, + i.e. ramfs), weak (in case it is backed by any other type of + memory), or insecure (if having any access mode that is not 0400, i.e. if readable + by anyone but the owner). + + + + cat credential... + + Show contents of specified credentials passed into the current execution + context. Takes one or more credential names, whose contents shall be written to standard + output. + + When combined with or the output is + transcoded in simple ways before outputting. + + + + setup + + Generates a host encryption key for credentials, if one has not been generated + already. This ensures the /var/lib/systemd/credential.secret file is initialized + with a random secret key if it doesn't exist yet. This secret key is used when encrypting/decrypting + credentials with encrypt or decrypt, and is only accessible to + the root user. Note that there's typically no need to invoke this command explicitly as it is + implicitly called when encrypt is invoked, and credential host key encryption + selected. + + + + encrypt input|- output|- + + Loads the specified (unencrypted plaintext) input credential file, encrypts it and + writes the (encrypted ciphertext) output to the specified target credential file. The resulting file + may be referenced in the LoadCredentialEncrypted= setting in unit files, or its + contents used literally in SetCredentialEncrypted= settings. + + Takes two file system paths. The file name part of the output path is embedded as name in the + encrypted credential, to ensure encrypted credentials cannot be renamed and reused for different + purposes without this being noticed. The credential name to embed may be overridden with the + setting. The input or output paths may be specified as -, + in which case the credential data is read from/written to standard input and standard output. If the + output path is specified as - the credential name cannot be derived from the file + system path, and thus should be specified explicitly via the switch. + + The credential data is encrypted and authenticated symmetrically with one of the following + encryption keys: + + + A secret key automatically derived from the system's TPM2 chip. This encryption key + is not stored on the host system and thus decryption is only possible with access to the original + TPM2 chip. Or in other words, the credential secured in this way can only be decrypted again by the + local machine. + + A secret key stored in the /var/lib/systemd/credential.secret + file which is only accessible to the root user. This "host" encryption key is stored on the host + file system, and thus decryption is possible with access to the host file system and sufficient + privileges. The key is automatically generated when needed, but can also be created explicitly with + the setup command, see above. + + A combination of the above: an encryption key derived from both the TPM2 chip and + the host file system. This means decryption requires both access to the original TPM2 chip and the + OS installation. This is the default mode of operation if a TPM2 chip is available and + /var/lib/systemd/ resides on persistent media. + + + Which of the three keys shall be used for encryption may be configured with the + switch. Depending on the use-case for the encrypted credential the key + to use may differ. For example, for credentials that shall be accessible from the initrd, encryption + with the host key is not appropriate, since access to the host key is typically not available from + the initrd. Thus, for such credentials only the TPM2 key should be used. + + Encrypted credentials are always encoded in Base64. + + Use decrypt (see below) to undo the encryption operation, and acquire the + decrypted plaintext credential from the encrypted ciphertext credential. + + The credential data is encrypted using AES256-GCM, i.e. providing both confidentiality and + integrity, keyed by a SHA256 hash of one or both of the secret keys described above. + + + + + decrypt input|- + output|- + + Undoes the effect of the encrypt operation: loads the specified + (encrypted ciphertext) input credential file, decrypts and authenticates it and writes the (decrypted + plaintext) output to the specified target credential file. + + Takes one or two file system paths. The file name part of the input path is compared with the + credential name embedded in the encrypted file. If it does not match decryption fails. This is done + in order to ensure that encrypted credentials are not re-purposed without this being detected. The + credential name to compare with the embedded credential name may also be overridden with the + switch. If the input path is specified as -, the + encrypted credential is read from standard input. If only one path is specified or the output path + specified as -, the decrypted credential is written to standard output. In this + mode, the expected name embedded in the credential cannot be derived from the path and should be + specified explicitly with . + + Decrypting credentials requires access to the original TPM2 chip and/or credentials host key, + see above. Information about which keys are required is embedded in the encrypted credential data, + and thus decryption is entirely automatic. + + + + has-tpm2 + + Reports whether the system is equipped with a TPM2 device usable for protecting + credentials. If a TPM2 device has been discovered, is supported, and is being used by firmware, + by the OS kernel drivers and by userspace (i.e. systemd) this prints yes and exits + with exit status zero. If no such device is discovered/supported/used, prints + no. Otherwise prints partial. In either of these two cases + exits with non-zero exit status. It also shows four lines indicating separately whether firmware, + drivers, the system and the kernel discovered/support/use TPM2. + + Combine with to suppress the output. + + + + + + + + + Options + + + + + + + When specified with the list and cat commands + operates on the credentials passed to system as a whole instead of on those passed to the current + execution context. This is useful in container environments where credentials may be passed in from + the container manager. + + + + + + When specified with the cat or decrypt + commands, transcodes the output before showing it. Takes one of base64, + unbase64, hex or unhex as argument, in order + to encode/decode the credential data with Base64 or as series of hexadecimal values. + + Note that this has no effect on the encrypt command, as encrypted + credentials are unconditionally encoded in Base64. + + + + + + When specified with cat or decrypt controls + whether to add a trailing newline character to the end of the output if it doesn't end in one, + anyway. Takes one of auto, yes or no. The + default mode of auto will suffix the output with a single newline character only + when writing credential data to a TTY. + + + + + + + When specified with encrypt controls whether to show the encrypted + credential as SetCredentialEncrypted= setting that may be pasted directly into a + unit file. + + + + name + + When specified with the encrypt command controls the credential + name to embed in the encrypted credential data. If not specified the name is chosen automatically + from the filename component of the specified output path. If specified as empty string no + credential name is embedded in the encrypted credential, and no verification of credential name is + done when the credential is decrypted. + + When specified with the decrypt command control the credential name to + validate the credential name embedded in the encrypted credential with. If not specified the name is + chosen automatically from the filename component of the specified input path. If no credential name + is embedded in the encrypted credential file (i.e. the with an empty string + was used when encrypted) the specified name has no effect as no credential name validation is + done. + + Embedding the credential name in the encrypted credential is done in order to protect against + reuse of credentials for purposes they weren't originally intended for, under the assumption the + credential name is chosen carefully to encode its intended purpose. + + + + timestamp + + When specified with the encrypt command controls the timestamp to + embed into the encrypted credential. Defaults to the current time. Takes a timestamp specification in + the format described in + systemd.time7. + + When specified with the decrypt command controls the timestamp to use to + validate the "not-after" timestamp that was configured with during + encryption. If not specified defaults to the current system time. + + + + timestamp + + When specified with the encrypt command controls the time when the + credential shall not be used anymore. This embeds the specified timestamp in the encrypted + credential. During decryption the timestamp is checked against the current system clock, and if the + timestamp is in the past the decryption will fail. By default no such timestamp is set. Takes a + timestamp specification in the format described in + systemd.time7. + + + + + + + + When specified with the encrypt command controls the + encryption/signature key to use. Takes one of host, tpm2, + host+tpm2, tpm2-absent, auto, + auto-initrd. See above for details on the three key types. If set to + auto (which is the default) the TPM2 key is used if a TPM2 device is found and not + running in a container. The host key is used if /var/lib/systemd/ is on + persistent media. This means on typical systems the encryption is by default bound to both the TPM2 + chip and the OS installation, and both need to be available to decrypt the credential again. If + auto is selected but neither TPM2 is available (or running in container) nor + /var/lib/systemd/ is on persistent media, encryption will fail. If set to + tpm2-absent a fixed zero length key is used (thus, in this mode no confidentiality + nor authenticity are provided!). This logic is useful to cover for systems that lack a TPM2 chip but + where credentials shall be generated. Note that decryption of such credentials is refused on systems + that have a TPM2 chip and where UEFI SecureBoot is enabled (this is done so that such a locked down + system cannot be tricked into loading a credential generated this way that lacks authentication + information). If set to auto-initrd a TPM2 key is used if a TPM2 is found. If not + a fixed zero length key is used, equivalent to tpm2-absent mode. This option is + particularly useful to generate credentials files that are encrypted/authenticated against TPM2 where + available but still work on systems lacking support for this. + + The switch is a shortcut for . Similar, + is a shortcut for . + + When encrypting credentials that shall be used in the initrd (where + /var/lib/systemd/ is typically not available) make sure to use + mode, to disable binding against the host secret. + + This switch has no effect on the decrypt command, as information on which + key to use for decryption is included in the encrypted credential already. + + + + PATH + + Controls the TPM2 device to use. Expects a device node path referring to the TPM2 + chip (e.g. /dev/tpmrm0). Alternatively the special value auto + may be specified, in order to automatically determine the device node of a suitable TPM2 device (of + which there must be exactly one). The special value list may be used to enumerate + all suitable TPM2 devices currently discovered. + + + + PCR + + Configures the TPM2 PCRs (Platform Configuration Registers) to bind the encryption + key to. Takes a + separated list of numeric PCR indexes in the range 0…23. If not + used, defaults to PCR 7 only. If an empty string is specified, binds the encryption key to no PCRs at + all. For details about the PCRs available, see the documentation of the switch of the same name for + systemd-cryptenroll1. + + + + PATH + PCR + + Configures a TPM2 signed PCR policy to bind encryption to, for use with the + encrypt command. The option accepts a path to + a PEM encoded RSA public key, to bind the encryption to. If this is not specified explicitly, but a + file tpm2-pcr-public-key.pem exists in one of the directories + /etc/systemd/, /run/systemd/, + /usr/lib/systemd/ (searched in this order), it is automatically used. The + option takes a list of TPM2 PCR indexes to bind to (same + syntax as described above). If not specified defaults to 11 (i.e. this + binds the policy to any unified kernel image for which a PCR signature can be provided). + + Note the difference between and + : the former binds decryption to the current, specific PCR + values; the latter binds decryption to any set of PCR values for which a signature by the specified + public key can be provided. The latter is hence more useful in scenarios where software updates shall + be possible without losing access to all previously encrypted secrets. + + + + PATH + + Takes a path to a TPM2 PCR signature file as generated by the + systemd-measure1 + tool and that may be used to allow the decrypt command to decrypt credentials that + are bound to specific signed PCR values. If this this is not specified explicitly, and a credential + with a signed PCR policy is attempted to be decrypted, a suitable signature file + tpm2-pcr-signature.json is searched for in /etc/systemd/, + /run/systemd/, /usr/lib/systemd/ (in this order) and + used. + + + + + + + When used with has-tpm2 suppresses the output, and only returns an + exit status indicating support for TPM2. + + + + + + + + + + Exit status + + On success, 0 is returned. + + In case of the has-tpm2 command returns 0 if a TPM2 device is discovered, + supported and used by firmware, driver, and userspace (i.e. systemd). Otherwise returns the OR + combination of the value 1 (in case firmware support is missing), 2 (in case driver support is missing) + and 4 (in case userspace support is missing). If no TPM2 support is available at all, value 7 is hence + returned. + + + + Examples + + + Encrypt a password for use as credential + + The following command line encrypts the specified password hunter2, writing the result + to a file password.cred. + + # echo -n hunter2 | systemd-creds encrypt - password.cred + + This decrypts the file password.cred again, revealing the literal password: + + # systemd-creds decrypt password.cred +hunter2 + + + + Encrypt a password and include it in a unit file + + The following command line prompts the user for a password and generates a + SetCredentialEncrypted= line from it for a credential named + mysql-password, suitable for inclusion in a unit file. + + # systemd-ask-password -n | systemd-creds encrypt --name=mysql-password -p - - +🔐 Password: **** +SetCredentialEncrypted=mysql-password: \ + k6iUCUh0RJCQyvL8k8q1UyAAAAABAAAADAAAABAAAAASfFsBoPLIm/dlDoGAAAAAAAAAA \ + NAAAAAgAAAAAH4AILIOZ3w6rTzYsBy9G7liaCAd4i+Kpvs8mAgArzwuKxd0ABDjgSeO5k \ + mKQc58zM94ZffyRmuNeX1lVHE+9e2YD87KfRFNoDLS7F3YmCb347gCiSk2an9egZ7Y0Xs \ + 700Kr6heqQswQEemNEc62k9RJnEl2q7SbcEYguegnPQUATgAIAAsAAAASACA/B90W7E+6 \ + yAR9NgiIJvxr9bpElztwzB5lUJAxtMBHIgAQACCaSV9DradOZz4EvO/LSaRyRSq2Hj0ym \ + gVJk/dVzE8Uxj8H3RbsT7rIBH02CIgm/Gv1ukSXO3DMHmVQkDG0wEciyageTfrVEer8z5 \ + 9cUQfM5ynSaV2UjeUWEHuz4fwDsXGLB9eELXLztzUU9nsAyLvs3ZRR+eEK/A== + + The generated line can be pasted 1:1 into a unit file, and will ensure the acquired password will + be made available in the $CREDENTIALS_DIRECTORY/mysql-password + credential file for the started service. + + Utilizing the unit file drop-in logic this can be used to securely pass a password credential to + a unit. A similar, more comprehensive set of commands to insert a password into a service + xyz.service: + + # mkdir -p /etc/systemd/system/xyz.service.d +# systemd-ask-password -n | ( echo "[Service]" && systemd-creds encrypt --name=mysql-password -p - - ) > /etc/systemd/system/xyz.service.d/50-password.conf +# systemctl daemon-reload +# systemctl restart xyz.service + + + + + See Also + + systemd1, + systemd.exec5, + systemd-measure1 + + + + diff --git a/man/systemd-cryptenroll.xml b/man/systemd-cryptenroll.xml new file mode 100644 index 0000000..813f10e --- /dev/null +++ b/man/systemd-cryptenroll.xml @@ -0,0 +1,489 @@ + + + + + + + + systemd-cryptenroll + systemd + + + + systemd-cryptenroll + 1 + + + + systemd-cryptenroll + Enroll PKCS#11, FIDO2, TPM2 token/devices to LUKS2 encrypted volumes + + + + + systemd-cryptenroll + OPTIONS + DEVICE + + + + + Description + + systemd-cryptenroll is a tool for enrolling hardware security tokens and devices + into a LUKS2 encrypted volume, which may then be used to unlock the volume during boot. Specifically, it + supports tokens and credentials of the following kind to be enrolled: + + + PKCS#11 security tokens and smartcards that may carry an RSA key pair (e.g. various + YubiKeys) + + FIDO2 security tokens that implement the hmac-secret extension (most + FIDO2 keys, including YubiKeys) + + TPM2 security devices + + Regular passphrases + + Recovery keys. These are similar to regular passphrases, however are randomly generated + on the computer and thus generally have higher entropy than user-chosen passphrases. Their character + set has been designed to ensure they are easy to type in, while having high entropy. They may also be + scanned off screen using QR codes. Recovery keys may be used for unlocking LUKS2 volumes wherever + passphrases are accepted. They are intended to be used in combination with an enrolled hardware + security token, as a recovery option when the token is lost. + + + In addition, the tool may be used to enumerate currently enrolled security tokens and wipe a subset + of them. The latter may be combined with the enrollment operation of a new security token, in order to + update or replace enrollments. + + The tool supports only LUKS2 volumes, as it stores token meta-information in the LUKS2 JSON token + area, which is not available in other encryption formats. + + + + Limitations + + Note that currently when enrolling a new key of one of the five supported types listed above, it is + required to first provide a passphrase or recovery key (i.e. one of the latter two key types). For + example, it's currently not possible to unlock a device with a FIDO2 key in order to enroll a new FIDO2 + key. Instead, in order to enroll a new FIDO2 key, it is necessary to provide an already enrolled regular + passphrase or recovery key. Thus, if in future key roll-over is desired it's generally recommended to + combine TPM2, FIDO2, PKCS#11 key enrollment with enrolling a regular passphrase or recovery key. + + Also note that support for enrolling multiple FIDO2 tokens is currently not too useful, as while + unlocking systemd-cryptsetup cannot identify which token is currently plugged in and + thus does not know which authentication request to send to the device. This limitation does not apply to + tokens enrolled via PKCS#11 — because tokens of this type may be identified immediately, before + authentication. + + + + Compatibility + + Security technology both in systemd and in the general industry constantly evolves. In order to + provide best security guarantees, the way TPM2, FIDO2, PKCS#11 devices are enrolled is regularly updated + in newer versions of systemd. Whenever this happens the following compatibility guarantees are given: + + + Old enrollments continue to be supported and may be unlocked with newer versions of + systemd-cryptsetup@.service8. + + The opposite is not guaranteed however: it might not be possible to unlock volumes with + enrollments done with a newer version of systemd-cryptenroll with an older version + of systemd-cryptsetup. + + + That said, it is generally recommended to use matching versions of + systemd-cryptenroll and systemd-cryptsetup, since this is best + tested and supported. + + It might be advisable to re-enroll existing enrollments to take benefit of newer security features, + as they are added to systemd. + + + + Options + + The following options are understood: + + + + + + Enroll a regular password/passphrase. This command is mostly equivalent to + cryptsetup luksAddKey, however may be combined with + in one call, see below. + + + + + + Enroll a recovery key. Recovery keys are mostly identical to passphrases, but are + computer-generated instead of being chosen by a human, and thus have a guaranteed high entropy. The + key uses a character set that is easy to type in, and may be scanned off screen via a QR code. + + + + + PATH + + Use a file instead of a password/passphrase read from stdin to unlock the volume. + Expects the PATH to the file containing your key to unlock the volume. Currently there is nothing like + or so this file has to only + contain the full key. + + + + URI + + Enroll a PKCS#11 security token or smartcard (e.g. a YubiKey). Expects a PKCS#11 + smartcard URI referring to the token. Alternatively the special value auto may + be specified, in order to automatically determine the URI of a currently plugged in security token + (of which there must be exactly one). The special value list may be used to + enumerate all suitable PKCS#11 tokens currently plugged in. The security token must contain an RSA + key pair which is used to encrypt the randomly generated key that is used to unlock the LUKS2 + volume. The encrypted key is then stored in the LUKS2 JSON token header area. + + In order to unlock a LUKS2 volume with an enrolled PKCS#11 security token, specify the + option in the respective /etc/crypttab line: + + myvolume /dev/sda1 - pkcs11-uri=auto + + See + crypttab5 for a + more comprehensive example of a systemd-cryptenroll invocation and its matching + /etc/crypttab line. + + + + STRING + Specify COSE algorithm used in credential generation. The default value is + es256. Supported values are es256, rs256 + and eddsa. + + es256 denotes ECDSA over NIST P-256 with SHA-256. rs256 + denotes 2048-bit RSA with PKCS#1.5 padding and SHA-256. eddsa denotes + EDDSA over Curve25519 with SHA-512. + + Note that your authenticator may not support some algorithms. + + + + PATH + + Enroll a FIDO2 security token that implements the hmac-secret + extension (e.g. a YubiKey). Expects a hidraw device referring to the FIDO2 + device (e.g. /dev/hidraw1). Alternatively the special value + auto may be specified, in order to automatically determine the device node of a + currently plugged in security token (of which there must be exactly one). The special value + list may be used to enumerate all suitable FIDO2 tokens currently plugged in. Note + that many hardware security tokens that implement FIDO2 also implement the older PKCS#11 + standard. Typically FIDO2 is preferable, given it's simpler to use and more modern. + + In order to unlock a LUKS2 volume with an enrolled FIDO2 security token, specify the + option in the respective /etc/crypttab line: + + myvolume /dev/sda1 - fido2-device=auto + + See + crypttab5 for a + more comprehensive example of a systemd-cryptenroll invocation and its matching + /etc/crypttab line. + + + + BOOL + + When enrolling a FIDO2 security token, controls whether to require the user to enter + a PIN when unlocking the volume (the FIDO2 clientPin feature). Defaults to + yes. (Note: this setting is without effect if the security token does not support + the clientPin feature at all, or does not allow enabling or disabling + it.) + + + + BOOL + + When enrolling a FIDO2 security token, controls whether to require the user to + verify presence (tap the token, the FIDO2 up feature) when unlocking the volume. + Defaults to yes. (Note: this setting is without effect if the security token does not support + the up feature at all, or does not allow enabling or disabling it.) + + + + + BOOL + + When enrolling a FIDO2 security token, controls whether to require user verification + when unlocking the volume (the FIDO2 uv feature). Defaults to + no. (Note: this setting is without effect if the security token does not support + the uv feature at all, or does not allow enabling or disabling it.) + + + + PATH + + Enroll a TPM2 security chip. Expects a device node path referring to the TPM2 chip + (e.g. /dev/tpmrm0). Alternatively the special value auto may + be specified, in order to automatically determine the device node of a currently discovered TPM2 + device (of which there must be exactly one). The special value list may be used to + enumerate all suitable TPM2 devices currently discovered. + + In order to unlock a LUKS2 volume with an enrolled TPM2 security chip, specify the + option in the respective /etc/crypttab line: + + myvolume /dev/sda1 - tpm2-device=auto + + See + crypttab5 for a + more comprehensive example of a systemd-cryptenroll invocation and its matching + /etc/crypttab line. + + Use (see below) to configure which TPM2 PCR indexes to bind the + enrollment to. + + + + PCR + + Configures the TPM2 PCRs (Platform Configuration Registers) to bind the enrollment + requested via to. Takes a + separated list of + numeric PCR indexes in the range 0…23. If not used, defaults to PCR 7 only. If an empty string is + specified, binds the enrollment to no PCRs at all. PCRs allow binding the enrollment to specific + software versions and system state, so that the enrolled unlocking key is only accessible (may be + "unsealed") if specific trusted software and/or configuration is used. + + + Well-known PCR Definitions + + + + + + + + + + + + + + + PCR + Explanation + + + + + + 0 + Core system firmware executable code; changes on firmware updates + + + + 1 + Core system firmware data/host platform configuration; typically contains serial and model numbers, changes on basic hardware/CPU/RAM replacements + + + + 2 + Extended or pluggable executable code; includes option ROMs on pluggable hardware + + + + 3 + Extended or pluggable firmware data; includes information about pluggable hardware + + + + 4 + Boot loader and additional drivers; changes on boot loader updates. The shim project will measure the PE binary it chain loads into this PCR. If the Linux kernel is invoked as UEFI PE binary, it is measured here, too. sd-stub7 measures system extension images read from the ESP here too (see systemd-sysext8). + + + + 5 + GPT/Partition table; changes when the partitions are added, modified or removed + + + + 6 + Power state events; changes on system suspend/sleep + + + + 7 + Secure boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR. + + + + + + + 9 + The Linux kernel measures all initrds it receives into this PCR. + + + + + 10 + The IMA project measures its runtime state into this PCR. + + + + 11 + systemd-stub7 measures the ELF kernel image, embedded initrd and other payload of the PE image it is placed in into this PCR. Unlike PCR 4 (where the same data should be measured into), this PCR value should be easy to pre-calculate, as this only contains static parts of the PE binary. Use this PCR to bind TPM policies to a specific kernel image, possibly with an embedded initrd. systemd-pcrphase.service8 measures boot phase strings into this PCR at various milestones of the boot process. + + + + 12 + systemd-boot7 measures any specified kernel command line into this PCR. systemd-stub7 measures any manually specified kernel command line (i.e. a kernel command line that overrides the one embedded in the unified PE image) and loaded credentials into this PCR. (Note that if systemd-boot and systemd-stub are used in combination the command line might be measured twice!) + + + + 13 + systemd-stub7 measures any systemd-sysext8 images it loads and passed to the booted kernel into this PCR. + + + + 14 + The shim project measures its "MOK" certificates and hashes into this PCR. + + + +
+ + For most applications it should be sufficient to bind against PCR 7 (and possibly PCR 14, if + shim/MOK is desired), as this includes measurements of the trusted certificates (and possibly hashes) + that are used to validate all components of the boot process up to and including the OS kernel. In + order to simplify firmware and OS version updates it's typically not advisable to include PCRs such + as 0 and 2 in the binding of the enrollment, since the program code they cover should already be + protected indirectly through the certificates measured into PCR 7. Validation through these + certificates is typically preferable over validation through direct measurements as it is less + brittle in context of OS/firmware updates: the measurements will change on every update, but code + signatures likely will validate against pre-existing certificates. + + + + BOOL + + When enrolling a TPM2 device, controls whether to require the user to enter a PIN + when unlocking the volume in addition to PCR binding, based on TPM2 policy authentication. Defaults + to no. Despite being called PIN, any character can be used, not just numbers. + + + Note that incorrect PIN entry when unlocking increments the TPM dictionary attack lockout + mechanism, and may lock out users for a prolonged time, depending on its configuration. The lockout + mechanism is a global property of the TPM, systemd-cryptenroll does not control or + configure the lockout mechanism. You may use tpm2-tss tools to inspect or configure the dictionary + attack lockout, with tpm2_getcap1 + and tpm2_dictionarylockout1 + commands, respectively. + + + + PATH + PCR + PATH + + Configures a TPM2 signed PCR policy to bind encryption to. The + option accepts a path to a PEM encoded RSA public key, to bind + the encryption to. If this is not specified explicitly, but a file + tpm2-pcr-public-key.pem exists in one of the directories + /etc/systemd/, /run/systemd/, + /usr/lib/systemd/ (searched in this order), it is automatically used. The + option takes a list of TPM2 PCR indexes to bind to (same + syntax as described above). If not specified defaults to 11 (i.e. this + binds the policy to any unified kernel image for which a PCR signature can be provided). + + Note the difference between and + : the former binds decryption to the current, specific PCR + values; the latter binds decryption to any set of PCR values for which a signature by the specified + public key can be provided. The latter is hence more useful in scenarios where software updates shell + be possible without losing access to all previously encrypted LUKS2 volumes. + + The option takes a path to a TPM2 PCR signature file + as generated by the + systemd-measure1 + tool. If this this is not specified explicitly a suitable signature file + tpm2-pcr-signature.json is searched for in /etc/systemd/, + /run/systemd/, /usr/lib/systemd/ (in this order) and + used. If a signature file is specified or found it is used to verify if the volume can be unlocked + with it given the current PCR state, before the new slot is written to disk. This is intended as + safety net to ensure that access to a volume is not lost if a public key is enrolled for which no + valid signature for the current PCR state is available. If the supplied signature does not unlock the + current PCR state and public key combination, no slot is enrolled and the operation will fail. If no + signature file is specified or found no such safety verification is done. + + + + SLOT + + Wipes one or more LUKS2 key slots. Takes a comma separated list of numeric slot + indexes, or the special strings all (for wiping all key slots), + empty (for wiping all key slots that are unlocked by an empty passphrase), + password (for wiping all key slots that are unlocked by a traditional passphrase), + recovery (for wiping all key slots that are unlocked by a recovery key), + pkcs11 (for wiping all key slots that are unlocked by a PKCS#11 token), + fido2 (for wiping all key slots that are unlocked by a FIDO2 token), + tpm2 (for wiping all key slots that are unlocked by a TPM2 chip), or any + combination of these strings or numeric indexes, in which case all slots matching either are + wiped. As safety precaution an operation that wipes all slots without exception (so that the volume + cannot be unlocked at all anymore, unless the volume key is known) is refused. + + This switch may be used alone, in which case only the requested wipe operation is executed. It + may also be used in combination with any of the enrollment options listed above, in which case the + enrollment is completed first, and only when successful the wipe operation executed — and the newly + added slot is always excluded from the wiping. Combining enrollment and slot wiping may thus be used to + update existing enrollments: + + systemd-cryptenroll /dev/sda1 --wipe-slot=tpm2 --tpm2-device=auto + + The above command will enroll the TPM2 chip, and then wipe all previously created TPM2 + enrollments on the LUKS2 volume, leaving only the newly created one. Combining wiping and enrollment + may also be used to replace enrollments of different types, for example for changing from a PKCS#11 + enrollment to a FIDO2 one: + + systemd-cryptenroll /dev/sda1 --wipe-slot=pkcs11 --fido2-device=auto + + Or for replacing an enrolled empty password by TPM2: + + systemd-cryptenroll /dev/sda1 --wipe-slot=empty --tpm2-device=auto + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + Examples + + crypttab5 and + systemd-measure1 + contain various examples employing systemd-cryptenroll. + + + + See Also + + systemd1, + systemd-cryptsetup@.service8, + crypttab5, + cryptsetup8, + systemd-measure1 + + + + diff --git a/man/systemd-cryptsetup-generator.xml b/man/systemd-cryptsetup-generator.xml new file mode 100644 index 0000000..5ba024a --- /dev/null +++ b/man/systemd-cryptsetup-generator.xml @@ -0,0 +1,224 @@ + + + + + + + + systemd-cryptsetup-generator + systemd + + + + systemd-cryptsetup-generator + 8 + + + + systemd-cryptsetup-generator + Unit generator for /etc/crypttab + + + + /usr/lib/systemd/system-generators/systemd-cryptsetup-generator + + + + Description + + systemd-cryptsetup-generator is a + generator that translates /etc/crypttab into + native systemd units early at boot and when configuration of the + system manager is reloaded. This will create + systemd-cryptsetup@.service8 + units as necessary. + + systemd-cryptsetup-generator implements + systemd.generator7. + + + + Kernel Command Line + + systemd-cryptsetup-generator + understands the following kernel command line parameters: + + + + luks= + rd.luks= + + Takes a boolean argument. Defaults to yes. If + no, disables the generator entirely. rd.luks= is honored only + in the initrd while luks= is honored by both the main system and in the initrd. + + + + + luks.crypttab= + rd.luks.crypttab= + + Takes a boolean argument. Defaults to yes. If + no, causes the generator to ignore any devices configured in + /etc/crypttab (luks.uuid= will still work however). + rd.luks.crypttab= is honored only in initrd while + luks.crypttab= is honored by both the main system and the initrd. + + + + + luks.uuid= + rd.luks.uuid= + + Takes a LUKS superblock UUID as argument. This will activate the specified device as + part of the boot process as if it was listed in /etc/crypttab. This option may + be specified more than once in order to set up multiple devices. rd.luks.uuid= is + honored only in the initrd, while luks.uuid= is honored by both the main system + and the initrd. + + If /etc/crypttab contains entries with the same UUID, then the name, + keyfile and options specified there will be used. Otherwise, the device will have the name + luks-UUID. + + If /etc/crypttab exists, only those UUIDs specified on the kernel command + line will be activated in the initrd or the real root. + + + + + luks.name= + rd.luks.name= + + Takes a LUKS super block UUID followed by an + = and a name. This implies + rd.luks.uuid= or + luks.uuid= and will additionally make the + LUKS device given by the UUID appear under the provided + name. + + This parameter is the analogue of the first crypttab + 5 field volume-name. + + rd.luks.name= is honored only in the initrd, while + luks.name= is honored by both the main system and the initrd. + + + + + luks.data= + rd.luks.data= + + Takes a LUKS super block UUID followed by a = and a block device + specification for device hosting encrypted data. + + For those entries specified with rd.luks.uuid= or + luks.uuid=, the data device will be set to the one specified by + rd.luks.data= or luks.data= of the corresponding UUID. + + LUKS data device parameter is useful for specifying encrypted data devices with detached headers specified in + luks.options entry containing header= argument. For example, + rd.luks.uuid=b40f1abf-2a53-400a-889a-2eccc27eaa40 + rd.luks.options=b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/path/to/luks.hdr + rd.luks.data=b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx. + Hence, in this case, we will attempt to unlock LUKS device assembled from data device /dev/sdx + and LUKS header (metadata) put in /path/to/luks.hdr file. This syntax is for now + only supported on a per-device basis, i.e. you have to specify LUKS device UUID. + + This parameter is the analogue of the second crypttab + 5 field encrypted-device. + + rd.luks.data= is honored only in the initrd, while + luks.data= is honored by both the main system and in the initrd. + + + + + luks.key= + rd.luks.key= + + Takes a password file name as argument or a + LUKS super block UUID followed by a = and a + password file name. + + For those entries specified with + rd.luks.uuid= or + luks.uuid=, the password file will be set + to the one specified by rd.luks.key= or + luks.key= of the corresponding UUID, or the + password file that was specified without a UUID. + + It is also possible to specify an external device which + should be mounted before we attempt to unlock the LUKS device. + systemd-cryptsetup will use password file stored on that + device. Device containing password file is specified by + appending colon and a device identifier to the password file + path. For example, + rd.luks.uuid=b40f1abf-2a53-400a-889a-2eccc27eaa40 + rd.luks.key=b40f1abf-2a53-400a-889a-2eccc27eaa40=/keyfile:LABEL=keydev. + Hence, in this case, we will attempt to mount file system + residing on the block device with label keydev. + This syntax is for now only supported on a per-device basis, + i.e. you have to specify LUKS device UUID. + + This parameter is the analogue of the third crypttab + 5 field key-file. + + rd.luks.key= is honored only in the initrd, while + luks.key= is honored by both the main system and in the initrd. + + + + + luks.options= + rd.luks.options= + + Takes a LUKS super block UUID followed by an + = and a string of options separated by + commas as argument. This will override the options for the + given UUID. + If only a list of options, without an UUID, is + specified, they apply to any UUIDs not specified elsewhere, + and without an entry in + /etc/crypttab. + + This parameter is the analogue of the fourth crypttab + 5 field options. + + It is possible to specify an external device which + should be mounted before we attempt to unlock the LUKS device. + systemd-cryptsetup will assemble LUKS device by combining + data device specified in luks.data with + detached LUKS header found in header= + argument. For example, + rd.luks.uuid=b40f1abf-2a53-400a-889a-2eccc27eaa40 + rd.luks.options=b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/luks.hdr:LABEL=hdrdev + rd.luks.data=b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx. + Hence, in this case, we will attempt to mount file system + residing on the block device with label hdrdev, and look + for luks.hdr on that file system. Said header will be used + to unlock (decrypt) encrypted data stored on /dev/sdx. + This syntax is for now only supported on a per-device basis, + i.e. you have to specify LUKS device UUID. + + rd.luks.options= is honored only by initial + RAM disk (initrd) while luks.options= is + honored by both the main system and the initrd. + + + + + + + See Also + + systemd1, + crypttab5, + systemd-cryptsetup@.service8, + systemd-cryptenroll1, + cryptsetup8, + systemd-fstab-generator8 + + + + diff --git a/man/systemd-cryptsetup@.service.xml b/man/systemd-cryptsetup@.service.xml new file mode 100644 index 0000000..1697ccc --- /dev/null +++ b/man/systemd-cryptsetup@.service.xml @@ -0,0 +1,94 @@ + + + + + + + + systemd-cryptsetup@.service + systemd + + + + systemd-cryptsetup@.service + 8 + + + + systemd-cryptsetup@.service + + systemd-cryptsetup + Full disk decryption logic + + + + systemd-cryptsetup@.service + system-systemd\x2dcryptsetup.slice + /usr/lib/systemd/systemd-cryptsetup + + + + Description + + systemd-cryptsetup@.service is a service responsible for setting up encrypted + block devices. It is instantiated for each device that requires decryption for access. + + systemd-cryptsetup@.service instances are part of the + system-systemd\x2dcryptsetup.slice slice, which is destroyed only very late in the + shutdown procedure. This allows the encrypted devices to remain up until filesystems have been unmounted. + + + systemd-cryptsetup@.service will ask + for hard disk passwords via the password agent logic, in + order to query the user for the password using the right mechanism at boot + and during runtime. + + At early boot and when the system manager configuration is reloaded, /etc/crypttab is + translated into systemd-cryptsetup@.service units by + systemd-cryptsetup-generator8. + + In order to unlock a volume a password or binary key is + required. systemd-cryptsetup@.service tries to acquire a suitable password or binary + key via the following mechanisms, tried in order: + + + If a key file is explicitly configured (via the third column in + /etc/crypttab), a key read from it is used. If a PKCS#11 token, FIDO2 token or + TPM2 device is configured (using the pkcs11-uri=, fido2-device=, + tpm2-device= options) the key is decrypted before use. + + If no key file is configured explicitly this way, a key file is automatically loaded + from /etc/cryptsetup-keys.d/volume.key and + /run/cryptsetup-keys.d/volume.key, if present. Here + too, if a PKCS#11/FIDO2/TPM2 token/device is configured, any key found this way is decrypted before + use. + + If the try-empty-password option is specified it is then attempted + to unlock the volume with an empty password. + + The kernel keyring is then checked for a suitable cached password from previous + attempts. + + Finally, the user is queried for a password, possibly multiple times, unless + the headless option is set. + + + If no suitable key may be acquired via any of the mechanisms describes above, volume activation fails. + + + + See Also + + systemd1, + systemd-cryptsetup-generator8, + crypttab5, + systemd-cryptenroll1, + cryptsetup8 + + + + diff --git a/man/systemd-debug-generator.xml b/man/systemd-debug-generator.xml new file mode 100644 index 0000000..65de9ca --- /dev/null +++ b/man/systemd-debug-generator.xml @@ -0,0 +1,85 @@ + + + +%entities; +]> + + + + + systemd-debug-generator + systemd + + + + systemd-debug-generator + 8 + + + + systemd-debug-generator + Generator for enabling a runtime debug shell and + masking specific units at boot + + + + /usr/lib/systemd/system-generators/systemd-debug-generator + + + + Description + + systemd-debug-generator is a generator + that reads the kernel command line and understands three + options: + + If the or + option is specified and followed by a unit name, this unit is + masked for the runtime (i.e. for this session — from boot to shutdown), similarly to the effect of + systemctl1's + mask command. This is useful to boot with + certain units removed from the initial boot transaction for + debugging system startup. May be specified more than once. + is honored only by initial + RAM disk (initrd) while is + honored only in the main system. + + If the or + option is specified + and followed by a unit name, a start job for this unit is added to + the initial transaction. This is useful to start one or more + additional units at boot. May be specified more than once. + is honored only by initial + RAM disk (initrd) while is + honored only in the main system. + + If the or + option is + specified, the debug shell service + debug-shell.service is pulled into the boot + transaction and a debug shell will be spawned during early boot. + By default, &DEBUGTTY; is used, but a specific tty can also be set, + either with or without the /dev/ prefix. + Note that the shell may also be turned on persistently by enabling it with + systemctl1's + enable command. + is honored only by initial + RAM disk (initrd) while is + honored only in the main system. + + systemd-debug-generator implements + systemd.generator7. + + + + See Also + + systemd1, + systemctl1, + kernel-command-line7 + + + + diff --git a/man/systemd-delta.xml b/man/systemd-delta.xml new file mode 100644 index 0000000..7a83bc9 --- /dev/null +++ b/man/systemd-delta.xml @@ -0,0 +1,178 @@ + + + + + + + + systemd-delta + systemd + + + + systemd-delta + 1 + + + + systemd-delta + Find overridden configuration files + + + + + systemd-delta + OPTIONS + PREFIX/SUFFIX|SUFFIX + + + + + Description + + systemd-delta may be used to identify and + compare configuration files that override other configuration + files. Files in /etc/ have highest priority, + files in /run/ have the second highest + priority, …, files in /usr/lib/ have lowest + priority. Files in a directory with higher priority override files + with the same name in directories of lower priority. In addition, + certain configuration files can have .d + directories which contain "drop-in" files with configuration + snippets which augment the main configuration file. "Drop-in" + files can be overridden in the same way by placing files with the + same name in a directory of higher priority (except that, in case + of "drop-in" files, both the "drop-in" file name and the name of + the containing directory, which corresponds to the name of the + main configuration file, must match). For a fuller explanation, + see + systemd.unit5. + + + The command line argument will be split into a prefix and a + suffix. Either is optional. The prefix must be one of the + directories containing configuration files + (/etc/, /run/, + /usr/lib/, …). If it is given, only + overriding files contained in this directory will be shown. + Otherwise, all overriding files will be shown. The suffix must be + a name of a subdirectory containing configuration files like + tmpfiles.d, sysctl.d or + systemd/system. If it is given, only + configuration files in this subdirectory (across all configuration + paths) will be analyzed. Otherwise, all configuration files will + be analyzed. If the command line argument is not given at all, all + configuration files will be analyzed. See below for some + examples. + + + + Options + + The following options are understood: + + + + + + + When listing the differences, only list those + that are asked for. The list itself is a comma-separated list + of desired difference types. + + Recognized types are: + + + + masked + + Show masked files + + + + equivalent + + Show overridden files that while + overridden, do not differ in content. + + + + redirected + + Show files that are redirected to + another. + + + + overridden + + Show overridden, and changed + files. + + + + extended + + Show *.conf files + in drop-in directories for units. + + + + unchanged + + Show unmodified files + too. + + + + + + + + + When showing modified files, when a file is + overridden show a diff as well. This option takes a boolean + argument. If omitted, it defaults to + . + + + + + + + + + + Examples + + To see all local configuration: + systemd-delta + + To see all runtime configuration: + systemd-delta /run + + To see all system unit configuration changes: + systemd-delta systemd/system + + To see all runtime "drop-in" changes for system units: + systemd-delta --type=extended /run/systemd/system + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemd.unit5 + + + + diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml new file mode 100644 index 0000000..d68bde0 --- /dev/null +++ b/man/systemd-detect-virt.xml @@ -0,0 +1,302 @@ + + + + + + + + systemd-detect-virt + systemd + + + + systemd-detect-virt + 1 + + + + systemd-detect-virt + Detect execution in a virtualized environment + + + + + systemd-detect-virt + OPTIONS + + + + + Description + + systemd-detect-virt detects execution in + a virtualized environment. It identifies the virtualization + technology and can distinguish full machine virtualization from + container virtualization. systemd-detect-virt + exits with a return value of 0 (success) if a virtualization + technology is detected, and non-zero (error) otherwise. By default, + any type of virtualization is detected, and the options + and can be used + to limit what types of virtualization are detected. + + When executed without will print a + short identifier for the detected virtualization technology. The + following technologies are currently identified: + + + Known virtualization technologies (both + VM, i.e. full hardware virtualization, + and container, i.e. shared kernel virtualization) + + + + + + + Type + ID + Product + + + + + VM + qemu + QEMU software virtualization, without KVM + + + + kvm + Linux KVM kernel virtual machine, in combination with QEMU. Not used for other virtualizers using the KVM interfaces, such as Oracle VirtualBox or Amazon EC2 Nitro, see below. + + + + amazon + Amazon EC2 Nitro using Linux KVM + + + + zvm + s390 z/VM + + + + vmware + VMware Workstation or Server, and related products + + + + microsoft + Hyper-V, also known as Viridian or Windows Server Virtualization + + + + oracle + Oracle VM VirtualBox (historically marketed by innotek and Sun Microsystems), for legacy and KVM hypervisor + + + + powervm + IBM PowerVM hypervisor — comes as firmware with some IBM POWER servers + + + + xen + Xen hypervisor (only domU, not dom0) + + + + bochs + Bochs Emulator + + + + uml + User-mode Linux + + + + parallels + Parallels Desktop, Parallels Server + + + + bhyve + bhyve, FreeBSD hypervisor + + + + qnx + QNX hypervisor + + + + acrn + ACRN hypervisor + + + + apple + Apple virtualization framework + + + + sre + LMHS SRE hypervisor + + + + google + Google Compute Engine + + + + Container + openvz + OpenVZ/Virtuozzo + + + + lxc + Linux container implementation by LXC + + + + lxc-libvirt + Linux container implementation by libvirt + + + + systemd-nspawn + systemd's minimal container implementation, see systemd-nspawn1 + + + + docker + Docker container manager + + + + podman + Podman container manager + + + + rkt + rkt app container runtime + + + + wsl + Windows Subsystem for Linux + + + + proot + proot userspace chroot/bind mount emulation + + + + pouch + Pouch Container Engine + + + +
+ + If multiple virtualization solutions are used, only the + "innermost" is detected and identified. That means if both + machine and container virtualization are used in + conjunction, only the latter will be identified (unless + is passed). + Windows Subsystem for Linux is not a Linux container, + but an environment for running Linux userspace applications on + top of the Windows kernel using a Linux-compatible interface. + WSL is categorized as a container for practical purposes. + Multiple WSL environments share the same kernel and services + should generally behave like when being run in a container. + + + + Options + + The following options are understood: + + + + + + + Only detects container virtualization (i.e. + shared kernel virtualization). + + + + + + + Only detects hardware virtualization. + + + + + + + Detect whether invoked in a + chroot2 + environment. In this mode, no output is written, but the return + value indicates whether the process was invoked in a + chroot() + environment or not. + + + + + + Detect whether invoked in a user namespace. In this mode, no + output is written, but the return value indicates whether the process was invoked + inside of a user namespace or not. See + user_namespaces7 + for more information. + + + + + + + Suppress output of the virtualization + technology identifier. + + + + + + Output all currently known and detectable container and VM environments. + + + + + + + + + + Exit status + + If a virtualization technology is detected, 0 is returned, a + non-zero code otherwise. + + + + See Also + + systemd1, + systemd-nspawn1, + chroot2, + namespaces7 + + + + diff --git a/man/systemd-dissect.xml b/man/systemd-dissect.xml new file mode 100644 index 0000000..b04dadc --- /dev/null +++ b/man/systemd-dissect.xml @@ -0,0 +1,308 @@ + + + + + + + + systemd-dissect + systemd + + + + systemd-dissect + 1 + + + + systemd-dissect + Dissect Discoverable Disk Images (DDIs) + + + + + systemd-dissect OPTIONS IMAGE + + + systemd-dissect OPTIONS IMAGE PATH + + + systemd-dissect OPTIONS PATH + + + systemd-dissect OPTIONS IMAGE PATH TARGET + + + systemd-dissect OPTIONS IMAGE SOURCE PATH + + + + + Description + + systemd-dissect is a tool for introspecting and interacting with file system OS + disk images, specifically Discoverable Disk Images (DDIs). It supports five different operations: + + + Show general OS image information, including the image's + os-release5 data, + machine ID, partition information and more. + + Mount an OS image to a local directory. In this mode it will dissect the OS image and + mount the included partitions according to their designation onto a directory and possibly + sub-directories. + + Unmount an OS image from a local directory. In this mode it will recursively unmount + the mounted partitions and remove the underlying loop device, including all the partition sub-devices. + + + Copy files and directories in and out of an OS image. + + + The tool may operate on three types of OS images: + + + OS disk images containing a GPT partition table envelope, with partitions marked + according to the Discoverable Partitions + Specification. + + OS disk images containing just a plain file-system without an enveloping partition + table. (This file system is assumed to be the root file system of the OS.) + + OS disk images containing a GPT or MBR partition table, with a single + partition only. (This partition is assumed to contain the root file system of the OS.) + + + OS images may use any kind of Linux-supported file systems. In addition they may make use of LUKS + disk encryption, and contain Verity integrity information. Note that qualifying OS images may be booted + with systemd-nspawn1's + switch, and be used as root file system for system service using the + RootImage= unit file setting, see + systemd.exec5. + + Note that the partition table shown when invoked without command switch (as listed below) does not + necessarily show all partitions included in the image, but just the partitions that are understood and + considered part of an OS disk image. Specifically, partitions of unknown types are ignored, as well as + duplicate partitions (i.e. more than one per partition type), as are root and /usr/ + partitions of architectures not compatible with the local system. In other words: this tool will display + what it operates with when mounting the image. To display the complete list of partitions use a tool such + as fdisk8. + + + + Commands + + If neither of the command switches listed below are passed the specified disk image is opened and + general information about the image and the contained partitions and their use is shown. + + + + + + + Mount the specified OS image to the specified directory. This will dissect the image, + determine the OS root file system — as well as possibly other partitions — and mount them to the + specified directory. If the OS image contains multiple partitions marked with the Discoverable Partitions Specification + multiple nested mounts are established. This command expects two arguments: a path to an image file + and a path to a directory where to mount the image. + + To unmount an OS image mounted like this use the operation. + + When the OS image contains LUKS encrypted or Verity integrity protected file systems + appropriate volumes are automatically set up and marked for automatic disassembly when the image is + unmounted. + + The OS image may either be specified as path to an OS image stored in a regular file or may + refer to block device node (in the latter case the block device must be the "whole" device, i.e. not + a partition device). (The other supported commands described here support this, too.) + + All mounted file systems are checked with the appropriate fsck8 + implementation in automatic fixing mode, unless explicitly turned off () or + read-only operation is requested (). + + + + + + This is a shortcut for . + + + + + + + Unmount an OS image from the specified directory. This command expects one argument: + a directory where an OS image was mounted. + + All mounted partitions will be recursively unmounted, and the underlying loop device will be + removed, along with all its partition sub-devices. + + + + + + This is a shortcut for . + + + + + + + Copies a file or directory from the specified OS image into the specified location on + the host file system. Expects three arguments: a path to an image file, a source path (relative to + the image's root directory) and a destination path (relative to the current working directory, or an + absolute path, both outside of the image). If the destination path is omitted or specified as dash + (-), the specified file is written to standard output. If the source path in the + image file system refers to a regular file it is copied to the destination path. In this case access + mode, extended attributes and timestamps are copied as well, but file ownership is not. If the source + path in the image refers to a directory, it is copied to the destination path, recursively with all + containing files and directories. In this case the file ownership is copied too. + + + + + + + Copies a file or directory from the specified location in the host file system into + the specified OS image. Expects three arguments: a path to an image file, a source path (relative to + the current working directory, or an absolute path, both outside of the image) and a destination path + (relative to the image's root directory). If the source path is omitted or specified as dash + (-), the data to write is read from standard input. If the source path in the host + file system refers to a regular file, it is copied to the destination path. In this case access mode, + extended attributes and timestamps are copied as well, but file ownership is not. If the source path + in the host file system refers to a directory it is copied to the destination path, recursively with + all containing files and directories. In this case the file ownership is copied + too. + + As with file system checks are implicitly run before the copy + operation begins. + + + + + + + + + + Options + + The following options are understood: + + + + + + + Operate in read-only mode. By default will establish + writable mount points. If this option is specified they are established in read-only mode + instead. + + + + + + Turn off automatic file system checking. By default when an image is accessed for + writing (by or ) the file systems contained in the + OS image are automatically checked using the appropriate fsck8 + command, in automatic fixing mode. This behavior may be switched off using + . + + + + + + Turn off automatic growing of accessed file systems to their partition size, if + marked for that in the GPT partition table. By default when an image is accessed for writing (by + or ) the file systems contained in the OS image + are automatically grown to their partition sizes, if bit 59 in the GPT partition flags is set for + partition types that are defined by the Discoverable Partitions Specification. This + behavior may be switched off using . File systems are grown automatically + on access if all of the following conditions are met: + + The file system is mounted writable + The file system currently is smaller than the partition it is contained in (and thus can be grown) + The image contains a GPT partition table + The file system is stored on a partition defined by the Discoverable Partitions Specification + Bit 59 of the GPT partition flags for this partition is set, as per specification + The option is not passed. + + + + + + + + If combined with the directory to mount the OS image to is + created if it is missing. Note that the directory is not automatically removed when the disk image is + unmounted again. + + + + + + If combined with the specified directory where the OS image + is mounted is removed after unmounting the OS image. + + + + + + Takes one of disabled, loop, + all, crypto. If disabled the image is + accessed with empty block discarding turned off. If loop discarding is enabled if + operating on a regular file. If crypt discarding is enabled even on encrypted file + systems. If all discarding is unconditionally enabled. + + + + + + + + Configure various aspects of Verity data integrity for the OS image. Option + specifies a hex-encoded top-level Verity hash to use for setting up the + Verity integrity protection. Option specifies the path to a file + containing a PKCS#7 signature for the hash. This signature is passed to the kernel during activation, + which will match it against signature keys available in the kernel keyring. Option + specifies a path to a file with the Verity data to use for the OS + image, in case it is stored in a detached file. It is recommended to embed the Verity data directly + in the image, using the Verity mechanisms in the Discoverable Partitions Specification. + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemd-nspawn1, + systemd.exec5, + Discoverable Partitions Specification, + umount8, + fdisk8 + + + + diff --git a/man/systemd-environment-d-generator.xml b/man/systemd-environment-d-generator.xml new file mode 100644 index 0000000..a85ef49 --- /dev/null +++ b/man/systemd-environment-d-generator.xml @@ -0,0 +1,53 @@ + + +%entities; +]> + + + + + systemd-environment-d-generator + systemd + + + + systemd-environment-d-generator + 8 + + + + systemd-environment-d-generator + 30-systemd-environment-d-generator + Load variables specified by environment.d + + + + + &USER_ENV_GENERATOR_DIR;/30-systemd-environment-d-generator + + + + Description + + systemd-environment-d-generator is a + systemd.environment-generator7 + that reads environment configuration specified by + environment.d5 + configuration files and passes it to the + systemd1 + user manager instance. + + + + See Also + + systemd1, + systemctl1, + systemd.environment-generator7, + systemd.generator7 + + + + diff --git a/man/systemd-escape.xml b/man/systemd-escape.xml new file mode 100644 index 0000000..f5d78be --- /dev/null +++ b/man/systemd-escape.xml @@ -0,0 +1,182 @@ + + + + + + + + systemd-escape + systemd + + + + systemd-escape + 1 + + + + systemd-escape + Escape strings for usage in systemd unit names + + + + + systemd-escape + OPTIONS + STRING + + + + + Description + + systemd-escape may be used to escape + strings for inclusion in systemd unit names. The command may be + used to escape and to undo escaping of strings. + + The command takes any number of strings on the command line, + and will process them individually, one after another. It will + output them separated by spaces to stdout. + + By default, this command will escape the strings passed, + unless is passed which results in the + inverse operation being applied. If is given, a + special mode of escaping is applied instead, which assumes the + string is already escaped but will escape everything that + appears obviously non-escaped. + + For details on the escaping and unescaping algorithms see the relevant section in + systemd.unit5. + + + + Options + + The following options are understood: + + + + + + Appends the specified unit type suffix to the + escaped string. Takes one of the unit types supported by + systemd, such as service or + mount. May not be used in conjunction with + , or + . + + + + + + Inserts the escaped strings in a unit name + template. Takes a unit name template such as + foobar@.service. With + , expects instantiated unit names + for this template and extracts and unescapes just the instance + part. May not be used in conjunction with + , + or + . + + + + + + + When escaping or unescaping a string, assume it refers to a file system path. This eliminates + leading, trailing or duplicate / characters and rejects . and + .. path components. This is particularly useful for generating strings suitable for + unescaping with the %f specifier in unit files, see + systemd.unit5. + + + + + + + + Instead of escaping the specified strings, + undo the escaping, reversing the operation. May not be used in + conjunction with or + . + + + + + + + Like , but only + escape characters that are obviously not escaped yet, and + possibly automatically append an appropriate unit type suffix + to the string. May not be used in conjunction with + , or + . + + + + + + With , unescape + and print only the instance part of an instantiated unit name + template. Results in an error for an uninstantiated template + like ssh@.service or a non-template name + like ssh.service. + Must be used in conjunction with + and may not be used in conjunction with + . + + + + + + + + + + Examples + + To escape a single string: + $ systemd-escape 'Hallöchen, Meister' +Hall\xc3\xb6chen\x2c\x20Meister + + To undo escaping on a single string: + $ systemd-escape -u 'Hall\xc3\xb6chen\x2c\x20Meister' +Hallöchen, Meister + + To generate the mount unit for a path: + $ systemd-escape -p --suffix=mount "/tmp//waldi/foobar/" +tmp-waldi-foobar.mount + + To generate instance names of three strings: + $ systemd-escape --template=systemd-nspawn@.service 'My Container 1' 'containerb' 'container/III' +systemd-nspawn@My\x20Container\x201.service systemd-nspawn@containerb.service systemd-nspawn@container-III.service + + To extract the instance part of an instantiated unit: + $ systemd-escape -u --instance 'systemd-nspawn@My\x20Container\x201.service' +My Container 1 + + To extract the instance part of an instance of a particular template: + $ systemd-escape -u --template=systemd-nspawn@.service 'systemd-nspawn@My\x20Container\x201.service' +My Container 1 + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + systemd.unit5, + systemctl1 + + + + diff --git a/man/systemd-firstboot.xml b/man/systemd-firstboot.xml new file mode 100644 index 0000000..66d8299 --- /dev/null +++ b/man/systemd-firstboot.xml @@ -0,0 +1,389 @@ + + + + + + + + systemd-firstboot + systemd + + + + systemd-firstboot + 1 + + + + systemd-firstboot + systemd-firstboot.service + Initialize basic system settings on or before the first boot-up of a system + + + + + systemd-firstboot + OPTIONS + + + systemd-firstboot.service + + + + Description + + systemd-firstboot initializes the most + basic system settings interactively on the first boot, or + optionally non-interactively when a system image is created. + The service is started if ConditionFirstBoot=yes + is satisfied. This essentially means that /etc/ + is empty, see + systemd.unit5 + for details. + + The following settings may be set up: + + + The system locale, more specifically the two + locale variables LANG= and + LC_MESSAGES + + The system keyboard map + + The system time zone + + The system hostname + + The machine ID of the system + + The root user's password + + + Each of the fields may either be queried interactively by + users, set non-interactively on the tool's command line, or be + copied from a host system that is used to set up the system + image. + + If a setting is already initialized, it will not be + overwritten and the user will not be prompted for the + setting. + + Note that this tool operates directly on the file system and + does not involve any running system services, unlike + localectl1, + timedatectl1 + or + hostnamectl1. + This allows systemd-firstboot to operate on + mounted but not booted disk images and in early boot. It is not + recommended to use systemd-firstboot on the + running system while it is up. + + + + Options + + The following options are understood: + + + + + Takes a directory path as an argument. All + paths will be prefixed with the given alternate + root path, including config search + paths. This is useful to operate on a system image mounted to + the specified directory instead of the host system itself. + + + + + + Takes a path to a disk image file or block device node. If specified all operations + are applied to file system in the indicated disk image. This is similar to + but operates on file systems stored in disk images or block devices. The disk image should either + contain just a file system or a set of file systems within a GPT partition table, following the + Discoverable Partitions + Specification. For further information on supported disk images, see + systemd-nspawn1's + switch of the same name. + + + + + + + Sets the system locale, more specifically the + LANG= and LC_MESSAGES + settings. The argument should be a valid locale identifier, + such as de_DE.UTF-8. This controls the + locale.conf5 + configuration file. + + + + + + Sets the system keyboard layout. The argument should be a valid keyboard map, + such as de-latin1. This controls the KEYMAP entry in the + vconsole.conf5 + configuration file. + + + + + + Sets the system time zone. The argument should + be a valid time zone identifier, such as + Europe/Berlin. This controls the + localtime5 + symlink. + + + + + + Sets the system hostname. The argument should + be a hostname, compatible with DNS. This controls the + hostname5 + configuration file. + + + + + + Sets the system's machine ID. This controls + the + machine-id5 + file. + + + + + + + + Sets the password of the system's root user. This creates/modifies the + passwd5 and + shadow5 + files. This setting exists in three forms: accepts the password to + set directly on the command line, reads it from a file and + accepts an already hashed password on the command line. See + shadow5 + for more information on the format of the hashed password. Note that it is not recommended to specify + plaintext passwords on the command line, as other users might be able to see them simply by invoking + ps1. + + + + + + + Sets the shell of the system's root user. This creates/modifies the + passwd5 + file. + + + + + + Sets the system's kernel command line. This controls the + /etc/kernel/cmdline file which is used by + kernel-install8. + + + + + + + + + + + + Prompt the user interactively for a specific + basic setting. Note that any explicit configuration settings + specified on the command line take precedence, and the user is + not prompted for it. + + + + + + Query the user for locale, keymap, timezone, hostname, + root's password, and root's shell. This is equivalent to specifying + , + , + , + , + , + in combination. + + + + + + + + + + + Copy a specific basic setting from the host. + This only works in combination with + (see above). + + + + + + Copy locale, keymap, time zone, root password and shell from the host. This is + equivalent to specifying + , + , + , + , + in combination. + + + + + + + Initialize the system's machine ID to a random + ID. This only works in combination with + . + + + + + + systemd-firstboot doesn't modify existing files unless + is specified. For modifications to /etc/passwd and + /etc/shadow, systemd-firstboot only modifies the entry of the + root user instead of overwriting the entire file. + + + + + + Removes the password of the system's root user, enabling login as root without a + password unless the root account is locked. Note that this is extremely insecure and hence this + option should not be used lightly. + + + + + + Takes a boolean argument. By default when prompting the user for configuration + options a brief welcome text is shown before the first question is asked. Pass false to this option + to turn off the welcome text. + + + + + + + + + Credentials + + systemd-firstboot supports the service credentials logic as implemented by + LoadCredential=/SetCredential= (see + systemd.exec1 for + details). The following credentials are used when passed in: + + + + passwd.hashed-password.root + passwd.plaintext-password.root + + A hashed or plaintext version of the root password to use, in place of prompting the + user. These credentials are equivalent to the same ones defined for the + systemd-sysusers.service8 + service. + + + + passwd.shell.root + + Specifies the shell binary to use for the specified account. + Equivalent to the credential of the same name defined for the + systemd-sysusers.service8 + service. + + + + firstboot.locale + firstboot.locale-messages + + These credentials specify the locale settings to set during first boot, in place of + prompting the user. + + + + firstboot.keymap + + This credential specifies the keyboard setting to set during first boot, in place of + prompting the user. + + + + firstboot.timezone + + This credential specifies the system timezone setting to set during first boot, in + place of prompting the user. + + + + Note that by default the systemd-firstboot.service unit file is set up to + inherit the listed credentials + from the service manager. Thus, when invoking a container with an unpopulated /etc/ + for the first time it is possible to configure the root user's password to be systemd + like this: + + # systemd-nspawn --image=… --set-credential=firstboot.locale:de_DE.UTF-8 … + + Note that these credentials are only read and applied during the first boot process. Once they are + applied they remain applied for subsequent boots, and the credentials are not considered anymore. + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Kernel Command Line + + + + systemd.firstboot= + + Takes a boolean argument, defaults to on. If off, systemd-firstboot.service + won't interactively query the user for basic settings at first boot, even if those settings are not + initialized yet. + + + + + + See Also + + systemd1, + locale.conf5, + vconsole.conf5, + localtime5, + hostname5, + machine-id5, + shadow5, + systemd-machine-id-setup1, + localectl1, + timedatectl1, + hostnamectl1 + + + + diff --git a/man/systemd-fsck@.service.xml b/man/systemd-fsck@.service.xml new file mode 100644 index 0000000..45104bb --- /dev/null +++ b/man/systemd-fsck@.service.xml @@ -0,0 +1,121 @@ + + + + + + + + systemd-fsck@.service + systemd + + + + systemd-fsck@.service + 8 + + + + systemd-fsck@.service + systemd-fsck-root.service + systemd-fsck-usr.service + systemd-fsck + File system checker logic + + + + systemd-fsck@.service + systemd-fsck-root.service + systemd-fsck-usr.service + /usr/lib/systemd/systemd-fsck + + + + Description + + systemd-fsck@.service, systemd-fsck-root.service, and + systemd-fsck-usr.service are services responsible for file system checks. They are + instantiated for each device that is configured for file system checking. + systemd-fsck-root.service and systemd-fsck-usr.service are + responsible for file system checks on the root and /usr file system, respectively, but only if the root + filesystem was not checked in the initrd. systemd-fsck@.service is used for all + other file systems and for the root file system in the initrd. + + These services are started at boot if in /etc/fstab + for the file system is set to a value greater than zero, but only if it is also configured to be + mounted at boot (i.e. without noauto option). The file system check for root is + performed before the other file systems. Other file systems may be checked in parallel, except when + they are on the same rotating disk. + + systemd-fsck does not know any details + about specific filesystems, and simply executes file system + checkers specific to each filesystem type + (fsck.type). These checkers will decide if + the filesystem should actually be checked based on the time since + last check, number of mounts, unclean unmount, etc. + + systemd-fsck-root.service and systemd-fsck-usr.service + will activate reboot.target if fsck returns the "System + should reboot" condition, or emergency.target if fsck + returns the "Filesystem errors left uncorrected" condition. + + systemd-fsck@.service will fail if + fsck returns with either "System should reboot" + or "Filesystem errors left uncorrected" conditions. For filesystems + listed in /etc/fstab without nofail + or noauto options, local-fs.target + will then activate emergency.target. + + + + Kernel Command Line + + systemd-fsck understands these kernel + command line parameters: + + + + fsck.mode= + + One of auto, + force, skip. Controls + the mode of operation. The default is auto, + and ensures that file system checks are done when the file + system checker deems them necessary. force + unconditionally results in full file system checks. + skip skips any file system + checks. + + + + fsck.repair= + + One of preen, + yes, no. Controls the + mode of operation. The default is preen, + and will automatically repair problems that can be safely + fixed. yes will answer yes to all + questions by fsck and no will answer no to + all questions. + + + + + + See Also + + systemd1, + fsck8, + systemd-quotacheck.service8, + fsck.btrfs8, + fsck.cramfs8, + fsck.ext48, + fsck.fat8, + fsck.hfsplus8, + fsck.minix8, + fsck.ntfs8, + fsck.xfs8 + + + + diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml new file mode 100644 index 0000000..29d9bd4 --- /dev/null +++ b/man/systemd-fstab-generator.xml @@ -0,0 +1,255 @@ + + + + + + + + systemd-fstab-generator + systemd + + + + systemd-fstab-generator + 8 + + + + systemd-fstab-generator + Unit generator for /etc/fstab + + + + /usr/lib/systemd/system-generators/systemd-fstab-generator + + + + Description + + systemd-fstab-generator is a generator + that translates /etc/fstab (see + fstab5 + for details) into native systemd units early at boot and when + configuration of the system manager is reloaded. This will + instantiate mount and swap units as necessary. + + The passno field is treated like a simple + boolean, and the ordering information is discarded. However, if + the root file system is checked, it is checked before all the + other file systems. + + See + systemd.mount5 + and + systemd.swap5 + for more information about special /etc/fstab + mount options this generator understands. + + One special topic is handling of symbolic links. Historical init + implementations supported symlinks in /etc/fstab. + Because mount units will refuse mounts where the target is a symbolic link, + this generator will resolve any symlinks as far as possible when processing + /etc/fstab in order to enhance backwards compatibility. + If a symlink target does not exist at the time that this generator runs, it + is assumed that the symlink target is the final target of the mount. + + systemd-fstab-generator implements + systemd.generator7. + + + + Kernel Command Line + + systemd-fstab-generator understands the + following kernel command line parameters: + + + + + fstab= + rd.fstab= + + Takes a boolean argument. Defaults to yes. If + no, causes the generator to ignore any mounts or swap devices configured in + /etc/fstab. rd.fstab= is honored only in the initrd, while + fstab= is honored by both the main system and the initrd. + + + + root= + + Configures the operating system's root filesystem to mount when running in the + initrd. This accepts a device node path (usually /dev/disk/by-uuid/… or + /dev/disk/by-label/… or similar), or the special values gpt-auto + and tmpfs. + + Use gpt-auto to explicitly request automatic root file system discovery via + systemd-gpt-auto-generator8. + + Use tmpfs in order to mount a tmpfs5 file + system as root file system of the OS. This is useful in combination with + mount.usr= (see below) in order to combine a volatile root file system with a + separate, immutable /usr/ file system. Also see + systemd.volatile= below. + + + + rootfstype= + + Takes the root filesystem type that will be + passed to the mount command. rootfstype= is + honored by the initrd. + + + + rootflags= + + Takes the root filesystem mount options to use. rootflags= is + honored by the initrd. + + Note that unlike most kernel command line options this setting does not override settings made + in configuration files (specifically: the mount option string in + /etc/fstab). See + systemd-remount-fs.service8. + + + + mount.usr= + + Takes the /usr/ filesystem + to be mounted by the initrd. If + mount.usrfstype= or + mount.usrflags= is set, then + mount.usr= will default to the value set in + root=. + + Otherwise, this parameter defaults to the + /usr/ entry found in + /etc/fstab on the root filesystem. + + mount.usr= is honored by the initrd. + + + + + mount.usrfstype= + + Takes the /usr/ filesystem + type that will be passed to the mount command. If + mount.usr= or + mount.usrflags= is set, then + mount.usrfstype= will default to the value + set in rootfstype=. + + Otherwise, this value will be read from the + /usr/ entry in + /etc/fstab on the root filesystem. + + mount.usrfstype= is honored by the + initrd. + + + + mount.usrflags= + + Takes the /usr/ filesystem + mount options to use. If mount.usr= or + mount.usrfstype= is set, then + mount.usrflags= will default to the value + set in rootflags=. + + Otherwise, this value will be read from the + /usr/ entry in + /etc/fstab on the root filesystem. + + mount.usrflags= is honored by the + initrd. + + + + roothash= + usrhash= + + These options are primarily read by + systemd-veritysetup-generator8. When + set this indicates that the root file system (or /usr/) shall be mounted from + Verity volumes with the specified hashes. If these kernel command line options are set the root (or + /usr/) file system is thus mounted from a device mapper volume + /dev/mapper/root (or /dev/mapper/usr). + + + + systemd.volatile= + + Controls whether the system shall boot up in volatile mode. Takes a boolean argument or the + special value . + + If false (the default), this generator makes no changes to the mount tree and the system is booted up in + normal mode. + + If true the generator ensures + systemd-volatile-root.service8 + is run in the initrd. This service changes the mount table before transitioning to the host system, + so that a volatile memory file system (tmpfs) is used as root directory, with only + /usr/ mounted into it from the configured root file system, in read-only mode. + This way the system operates in fully stateless mode, with all configuration and state reset at boot + and lost at shutdown, as /etc/ and /var/ will be served + from the (initially unpopulated) volatile memory file system. + + If set to the generator will leave the root directory mount point unaltered, + however will mount a tmpfs file system to /var/. In this mode the normal + system configuration (i.e. the contents of /etc/) is in effect (and may be modified during + system runtime), however the system state (i.e. the contents of /var/) is reset at boot and + lost at shutdown. + + If this setting is set to overlay the root file system is set up as + overlayfs mount combining the read-only root directory with a writable + tmpfs, so that no modifications are made to disk, but the file system may be modified + nonetheless with all changes being lost at reboot. + + Note that in none of these modes the root directory, /etc/, /var/ + or any other resources stored in the root file system are physically removed. It's thus safe to boot a system + that is normally operated in non-volatile mode temporarily into volatile mode, without losing data. + + Note that with the exception of overlay mode, enabling this setting will + only work correctly on operating systems that can boot up with only /usr/ + mounted, and are able to automatically populate /etc/, and also + /var/ in case of systemd.volatile=yes. + + Also see root=tmpfs above, for a method to combine a + tmpfs file system with a regular /usr/ file system (as + configured via mount.usr=). The main distinction between + systemd.volatile=yes, and root=tmpfs in combination + mount.usr= is that the former operates on top of a regular root file system and + temporarily obstructs the files and directories above its /usr/ subdirectory, + while the latter does not hide any files, but simply mounts a unpopulated tmpfs as root file system + and combines it with a user picked /usr/ file system. + + + + systemd.swap= + + Takes a boolean argument or enables the option if specified + without an argument. If disabled, causes the generator to ignore + any swap devices configured in /etc/fstab. + Defaults to enabled. + + + + + + See Also + + systemd1, + fstab5, + systemd.mount5, + systemd.swap5, + systemd-cryptsetup-generator8, + systemd-gpt-auto-generator8, + kernel-command-line7, + Known Environment Variables + + + diff --git a/man/systemd-getty-generator.xml b/man/systemd-getty-generator.xml new file mode 100644 index 0000000..a31ed66 --- /dev/null +++ b/man/systemd-getty-generator.xml @@ -0,0 +1,97 @@ + + + + + + + + systemd-getty-generator + systemd + + + + systemd-getty-generator + 8 + + + + systemd-getty-generator + Generator for enabling getty instances on the + console + + + + /usr/lib/systemd/system-generators/systemd-getty-generator + + + + Description + + systemd-getty-generator is a generator that automatically instantiates + serial-getty@.service on the kernel consoles, if they can function as ttys and are + not provided by the virtual console subsystem. It will also instantiate + serial-getty@.service instances for virtualizer consoles, if execution in a + virtualized environment is detected. If execution in a container environment is detected, it will instead + enable console-getty.service for /dev/console, and + container-getty@.service instances for additional container pseudo TTYs as requested + by the container manager (see Container + Interface). This should ensure that the user is shown a login prompt at the right + place, regardless of which environment the system is started in. For example, it is sufficient to + redirect the kernel console with a kernel command line argument such as console= to + get both kernel messages and a getty prompt on a serial TTY. See The kernel's command-line + parameters for more information on the console= kernel parameter. + + systemd-getty-generator implements + systemd.generator7. + + Further information about configuration of gettys can be + found in + systemd + for Administrators, Part XVI: Gettys on Serial Consoles (and + Elsewhere). + + + + Kernel Command Line + + systemd-getty-generator understands the following + kernel-command-line7 + parameters: + + + + systemd.getty_auto= + + this options take an optional boolean argument, and default to yes. + The generator is enabled by default, and a false value may be used to disable it. + + + + + + + Environment + + + + $SYSTEMD_GETTY_AUTO + + This variable takes an optional boolean argument, and default to yes. + The generator is enabled by default, and a false value may be used to disable it. + + + + + + + See Also + + systemd1, + kernel-command-line7, + agetty8 + + + + diff --git a/man/systemd-gpt-auto-generator.xml b/man/systemd-gpt-auto-generator.xml new file mode 100644 index 0000000..9ac9c24 --- /dev/null +++ b/man/systemd-gpt-auto-generator.xml @@ -0,0 +1,283 @@ + + + + + + + + systemd-gpt-auto-generator + systemd + + + + systemd-gpt-auto-generator + 8 + + + + systemd-gpt-auto-generator + Generator for automatically discovering and mounting root, /home/, + /srv/, /var/ and /var/tmp/ partitions, as + well as discovering and enabling swap partitions, based on GPT partition type GUIDs + + + + /usr/lib/systemd/system-generators/systemd-gpt-auto-generator + + + + Description + + systemd-gpt-auto-generator is a unit generator that automatically discovers + root, /home/, /srv/, /var/, + /var/tmp/, the EFI System Partition, the Extended Boot Loader Partition and swap + partitions and creates mount and swap units for them, based on the partition type GUIDs of GUID partition + tables (GPT), see UEFI Specification, chapter 5. It + implements the Discoverable Partitions + Specification. Note that this generator has no effect on non-GPT systems, and on specific mount + points that are directories already containing files. Also, on systems where the units are explicitly + configured (for example, listed in fstab5), the + units this generator creates are overridden, but additional implicit dependencies might be + created. + + This generator will only look for the root partition on the same physical disk where the EFI System + Partition (ESP) is located. Note that support from the boot loader is required: the EFI variable + LoaderDevicePartUUID of the 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f + vendor UUID is used to determine from which partition, and hence the disk from which the system was + booted. If the boot loader does not set this variable, this generator will not be able to autodetect the + root partition. See the Boot Loader + Interface for details. + + Similarly, this generator will only look for the other partitions on the same physical disk as the + root partition. In this case, boot loader support is not required. These partitions will not be searched + for on systems where the root file system is distributed on multiple disks, for example via btrfs RAID. + + + systemd-gpt-auto-generator is useful for centralizing file system + configuration in the partition table and making configuration in /etc/fstab or on + the kernel command line unnecessary. + + This generator looks for the partitions based on their + partition type GUID. The following partition type GUIDs are + identified: + + + Partition Type GUIDs + + + + + + + + Partition Type GUID + Name + Mount Point + Explanation + + + + + SD_GPT_ROOT_X86_64 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 + Root Partition (x86-64) + / + The first partition with this type UUID, located on the same disk as the ESP, is used as the root file system / on AMD64 / 64-bit x86 systems. + + + SD_GPT_ROOT_ARM64 b921b045-1df0-41c3-af44-4c6f280d3fae + Root Partition (64-bit ARM) + / + The first partition with this type UUID, located on the same disk as the ESP, is used as the root file system / on AArch64 / 64-bit ARM systems. + + + + SD_GPT_ROOT_ALPHA SD_GPT_ROOT_ARC SD_GPT_ROOT_ARM SD_GPT_ROOT_ARM64 SD_GPT_ROOT_IA64 SD_GPT_ROOT_LOONGARCH64 SD_GPT_ROOT_MIPS SD_GPT_ROOT_MIPS64 SD_GPT_ROOT_MIPS_LE SD_GPT_ROOT_MIPS64_LE SD_GPT_ROOT_PARISC SD_GPT_ROOT_PPC SD_GPT_ROOT_PPC64 SD_GPT_ROOT_PPC64_LE SD_GPT_ROOT_RISCV32 SD_GPT_ROOT_RISCV64 SD_GPT_ROOT_S390 SD_GPT_ROOT_S390X SD_GPT_ROOT_TILEGX SD_GPT_ROOT_X86 SD_GPT_ROOT_X86_64 SD_GPT_USR_ALPHA SD_GPT_USR_ARC SD_GPT_USR_ARM SD_GPT_USR_IA64 SD_GPT_USR_LOONGARCH64 SD_GPT_USR_MIPS_LE SD_GPT_USR_MIPS64_LE SD_GPT_USR_PARISC SD_GPT_USR_PPC SD_GPT_USR_PPC64 SD_GPT_USR_PPC64_LE SD_GPT_USR_RISCV32 SD_GPT_USR_RISCV64 SD_GPT_USR_S390 SD_GPT_USR_S390X SD_GPT_USR_TILEGX SD_GPT_USR_X86 + + root partitions for other architectures + / + The first partition with the type UUID matching the architecture, located on the same disk as the ESP, is used as the root file system /. For the full list and constant values, see Discoverable Partitions Specification. + + + SD_GPT_HOME 933ac7e1-2eb4-4f13-b844-0e14e2aef915 + Home Partition + /home/ + The first partition with this type UUID on the same disk as the ESP is mounted to /home/. + + + SD_GPT_SRV 3b8f8425-20e0-4f3b-907f-1a25a76f98e8 + Server Data Partition + /srv/ + The first partition with this type UUID on the same disk as the ESP is mounted to /srv/. + + + SD_GPT_VAR 4d21b016-b534-45c2-a9fb-5c16e091fd2d + Variable Data Partition + /var/ + The first partition with this type UUID on the same disk as the ESP is mounted to /var/ — under the condition its partition UUID matches the first 128 bit of the HMAC-SHA256 of the GPT type uuid of this partition keyed by the machine ID of the installation stored in machine-id5. + + + SD_GPT_TMP 7ec6f557-3bc5-4aca-b293-16ef5df639d1 + Temporary Data Partition + /var/tmp/ + The first partition with this type UUID on the same disk as the ESP is mounted to /var/tmp/. + + + SD_GPT_SWAP 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f + Swap + n/a + All partitions with this type UUID on the same disk as the ESP are used as swap. + + + SD_GPT_ESP c12a7328-f81f-11d2-ba4b-00a0c93ec93b + EFI System Partition (ESP) + /efi/ or /boot/ + The first partition with this type UUID located on the same disk as the root partition is mounted to /boot/ or /efi/, see below. + + + SD_GPT_XBOOTLDR bc13c2ff-59e6-4262-a352-b275fd6f7172 + Extended Boot Loader Partition + /boot/ + The first partition with this type UUID located on the same disk as the root partition is mounted to /boot/, see below. + + + +
+ + This generator understands the following attribute flags for partitions: + + + Partition Attribute Flags + + + + + + + Flag + Applicable to + Explanation + + + + + SD_GPT_FLAG_READ_ONLY 0x1000000000000000 + /, /home/, /srv/, /var/, /var/tmp/, Extended Boot Loader Partition + Partition is mounted read-only + + + + SD_GPT_FLAG_NO_AUTO 0x8000000000000000 + /, /home/, /srv/, /var/, /var/tmp/, Extended Boot Loader Partition + Partition is not mounted automatically + + + + SD_GPT_FLAG_NO_BLOCK_IO_PROTOCOL 0x0000000000000002 + EFI System Partition (ESP) + Partition is not mounted automatically + + + +
+ + The /home/, /srv/, /var/ and + /var/tmp/ partitions may be encrypted in LUKS format. In this case, a device mapper + device is set up under the names /dev/mapper/home, + /dev/mapper/srv, /dev/mapper/var and + /dev/mapper/tmp. Note that this might create conflicts if the same partition is + listed in /etc/crypttab with a different device mapper device name. + + When systemd is running in the initrd the / partition may be encrypted in LUKS + format as well. In this case, a device mapper device is set up under the name /dev/mapper/root, + and a sysroot.mount is set up that mounts the device under /sysroot. + For more information, see bootup7. + + + The root partition can be specified by symlinking /run/systemd/volatile-root + to /dev/block/$major:$minor. This is especially useful if the root mount has been + replaced by some form of volatile file system (overlayfs). + + + Mount and automount units for the EFI System Partition (ESP) are generated on EFI systems. The ESP + is mounted to /boot/ (except if an Extended Boot Loader partition exists, see + below), unless a mount point directory /efi/ exists, in which case it is mounted + there. Since this generator creates an automount unit, the mount will only be activated on-demand, when + accessed. On systems where /boot/ (or /efi/ if it exists) is an + explicitly configured mount (for example, listed in fstab5) or where + the /boot/ (or /efi/) mount point is non-empty, no mount units + are generated. + + If the disk contains an Extended Boot Loader partition, as defined in the Boot Loader Specification, it is made + available at /boot/ (by means of an automount point, similar to the ESP, see + above). If both an EFI System Partition and an Extended Boot Loader partition exist the latter is + preferably mounted to /boot/. Make sure to create both /efi/ + and /boot/ to ensure both partitions are mounted. + + When using this generator in conjunction with btrfs file + systems, make sure to set the correct default subvolumes on them, + using btrfs subvolume set-default. + + systemd-gpt-auto-generator implements + systemd.generator7. + + + + Kernel Command Line + + systemd-gpt-auto-generator understands the following kernel command line + parameters: + + + + + systemd.gpt_auto + rd.systemd.gpt_auto + + Those options take an optional boolean argument, and default to yes. + The generator is enabled by default, and a false value may be used to disable it + (e.g. systemd.gpt_auto=0). + + + + + root= + + When used with the special value gpt-auto, automatic discovery of + the root partition based on the GPT partition type is enabled. Any other value disables this + generator. + + + + rw + ro + + Mount the root partition read-write or read-only initially. + + Note that unlike most kernel command line options these settings do not override configuration + in the file system, and the file system may be remounted later. See + systemd-remount-fs.service8. + + + + + + + See Also + + systemd1, + systemd.mount5, + systemd.swap5, + systemd-fstab-generator8, + systemd-cryptsetup@.service8, + machine-id5, + cryptsetup8, + fstab5, + btrfs8 + + + + diff --git a/man/systemd-halt.service.xml b/man/systemd-halt.service.xml new file mode 100644 index 0000000..96072ae --- /dev/null +++ b/man/systemd-halt.service.xml @@ -0,0 +1,93 @@ + + + + + + + + systemd-halt.service + systemd + + + + systemd-halt.service + 8 + + + + systemd-halt.service + systemd-poweroff.service + systemd-reboot.service + systemd-kexec.service + systemd-shutdown + System shutdown logic + + + + systemd-halt.service + systemd-poweroff.service + systemd-reboot.service + systemd-kexec.service + /usr/lib/systemd/systemd-shutdown + /usr/lib/systemd/system-shutdown/ + + + + Description + + systemd-halt.service is a system + service that is pulled in by halt.target and + is responsible for the actual system halt. Similarly, + systemd-poweroff.service is pulled in by + poweroff.target, + systemd-reboot.service by + reboot.target and + systemd-kexec.service by + kexec.target to execute the respective + actions. + + When these services are run, they ensure that PID 1 is + replaced by the + /usr/lib/systemd/systemd-shutdown tool which + is then responsible for the actual shutdown. Before shutting down, + this binary will try to unmount all remaining file systems, + disable all remaining swap devices, detach all remaining storage + devices and kill all remaining processes. + + It is necessary to have this code in a separate binary + because otherwise rebooting after an upgrade might be broken — the + running PID 1 could still depend on libraries which are not + available any more, thus keeping the file system busy, which then + cannot be re-mounted read-only. + + Immediately before executing the actual system + halt/poweroff/reboot/kexec systemd-shutdown + will run all executables in + /usr/lib/systemd/system-shutdown/ and pass + one arguments to them: either halt, + poweroff, reboot or + kexec, depending on the chosen action. All + executables in this directory are executed in parallel, and + execution of the action is not continued before all executables + finished. + + Note that systemd-halt.service (and the + related units) should never be executed directly. Instead, trigger + system shutdown with a command such as systemctl + halt or suchlike. + + + + See Also + + systemd1, + systemctl1, + systemd.special7, + reboot2, + systemd-suspend.service8, + bootup7 + + + + diff --git a/man/systemd-hibernate-resume-generator.xml b/man/systemd-hibernate-resume-generator.xml new file mode 100644 index 0000000..910fcae --- /dev/null +++ b/man/systemd-hibernate-resume-generator.xml @@ -0,0 +1,83 @@ + + + + + + + + systemd-hibernate-resume-generator + systemd + + + + systemd-hibernate-resume-generator + 8 + + + + systemd-hibernate-resume-generator + Unit generator for resume= kernel parameter + + + + /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator + + + + Description + + systemd-hibernate-resume-generator is a + generator that initiates the procedure to resume the system from hibernation. + It instantiates the + systemd-hibernate-resume@.service8 + unit according to the value of parameter + specified on the kernel command line, which will instruct the kernel + to resume the system from the hibernation image on that device. + + + + Kernel Command Line + + systemd-hibernate-resume-generator + understands the following kernel command line parameters: + + + + + resume= + + Takes a path to the resume device. Both + persistent block device paths like + /dev/disk/by-foo/bar and + fstab5-style + specifiers like FOO=bar are + supported. + + + + resumeflags= + + Takes the resume device mount options to + use. Defaults rootflags= if not specified. + + + + noresume + + Do not try to resume from hibernation. If this parameter is + present, resume= is ignored. + + + + + + See Also + + systemd1, + systemd-hibernate-resume@.service8, + kernel-command-line7 + + + + diff --git a/man/systemd-hibernate-resume@.service.xml b/man/systemd-hibernate-resume@.service.xml new file mode 100644 index 0000000..b6ae1f9 --- /dev/null +++ b/man/systemd-hibernate-resume@.service.xml @@ -0,0 +1,56 @@ + + + + + + + + systemd-hibernate-resume@.service + systemd + + + + systemd-hibernate-resume@.service + 8 + + + + systemd-hibernate-resume@.service + systemd-hibernate-resume + Resume from hibernation + + + + systemd-hibernate-resume@.service + /usr/lib/systemd/systemd-hibernate-resume + + + + Description + + systemd-hibernate-resume@.service + initiates the resume from hibernation. It is instantiated with the + device to resume from as the template argument. + + systemd-hibernate-resume only supports + the in-kernel hibernation implementation, see + Swap suspend. + Internally, it works by writing the major:minor of specified + device node to /sys/power/resume. + + Failing to initiate a resume is not an error condition. It + may mean that there was no resume image (e. g. if the system has + been simply powered off and not hibernated). In such case, the + boot is ordinarily continued. + + + + See Also + + systemd1, + systemd-hibernate-resume-generator8 + + + + diff --git a/man/systemd-homed.service.xml b/man/systemd-homed.service.xml new file mode 100644 index 0000000..2bc1dba --- /dev/null +++ b/man/systemd-homed.service.xml @@ -0,0 +1,110 @@ + + + + + + + + systemd-homed.service + systemd + + + + systemd-homed.service + 8 + + + + systemd-homed.service + systemd-homed + Home Area/User Account Manager + + + + systemd-homed.service + /usr/lib/systemd/systemd-homed + + + + Description + + systemd-homed is a system service that may be used to create, remove, change or + inspect home areas (directories and network mounts and real or loopback block devices with a filesystem, + optionally encrypted). + + Most of systemd-homed's functionality is accessible through the + homectl1 command. + + See the Home Directories documentation for + details about the format and design of home areas managed by + systemd-homed.service. + + Each home directory managed by systemd-homed.service synthesizes a local user + and group. These are made available to the system using the User/Group Record Lookup API via Varlink, and thus may be + browsed with + userdbctl1. + + + + Key Management + + User records are cryptographically signed with a public/private key pair (the signature is part of + the JSON record itself). For a user to be permitted to log in locally the public key matching the + signature of their user record must be installed. For a user record to be modified locally the private + key matching the signature must be installed locally, too. The keys are stored in the + /var/lib/systemd/home/ directory: + + + + + /var/lib/systemd/home/local.private + + The private key of the public/private key pair used for local records. Currently, + only a single such key may be installed. + + + + /var/lib/systemd/home/local.public + + The public key of the public/private key pair used for local records. Currently, + only a single such key may be installed. + + + + /var/lib/systemd/home/*.public + + Additional public keys. Any users whose user records are signed with any of these keys + are permitted to log in locally. An arbitrary number of keys may be installed this + way. + + + + All key files listed above are in PEM format. + + In order to migrate a home directory from a host foobar to another host + quux it is hence sufficient to copy + /var/lib/systemd/home/local.public from the host foobar to + quux, maybe calling the file on the destination /var/lib/systemd/home/foobar.public, reflecting the origin of the key. If the + user record should be modifiable on quux the pair + /var/lib/systemd/home/local.public and + /var/lib/systemd/home/local.private need to be copied from foobar + to quux, and placed under the identical paths there, as currently only a single + private key is supported per host. Note of course that the latter means that user records + generated/signed before the key pair is copied in, lose their validity. + + + + See Also + + systemd1, + homed.conf5, + homectl1, + pam_systemd_home8, + userdbctl1, + org.freedesktop.home15 + + + diff --git a/man/systemd-hostnamed.service.xml b/man/systemd-hostnamed.service.xml new file mode 100644 index 0000000..0e42f67 --- /dev/null +++ b/man/systemd-hostnamed.service.xml @@ -0,0 +1,82 @@ + + + + + + + + systemd-hostnamed.service + systemd + + + + systemd-hostnamed.service + 8 + + + + systemd-hostnamed.service + systemd-hostnamed + Daemon to control system hostname from programs + + + + systemd-hostnamed.service + /usr/lib/systemd/systemd-hostnamed + + + + Description + + systemd-hostnamed.service is a system service that may be used to change the + system's hostname and related machine metadata from user programs. It is automatically activated on + request and terminates itself when unused. + + It currently offers access to five variables: + + The current hostname (Example: dhcp-192-168-47-11) + + + The static (configured) hostname (Example: + lennarts-computer) + + The pretty hostname (Example: Lennart's Computer) + + + A suitable icon name for the local host (Example: + computer-laptop) + + A chassis type (Example: tablet) + + + + The static hostname is stored in /etc/hostname, see + hostname5 for more + information. The pretty hostname, chassis type, and icon name are stored in + /etc/machine-info, see + machine-info5. + + The tool + hostnamectl1 is a + command line client to this service. + + See + org.freedesktop.hostname15 + and + org.freedesktop.LogControl15 + for a description of the D-Bus API. + + + + See Also + + systemd1, + hostname5, + machine-info5, + hostnamectl1, + sethostname2 + + + + diff --git a/man/systemd-hwdb.xml b/man/systemd-hwdb.xml new file mode 100644 index 0000000..70c052e --- /dev/null +++ b/man/systemd-hwdb.xml @@ -0,0 +1,84 @@ + + + + + + + + systemd-hwdb + systemd + + + + systemd-hwdb + 8 + + + + systemd-hwdbhardware database management tool + + + + + systemd-hwdb options update + + + systemd-hwdb options query modalias + + + + Description + systemd-hwdb expects a command and command + specific arguments. It manages the binary hardware database. + + + Options + + + + + Generate in /usr/lib/udev instead of /etc/udev. + + + + + + + Alternate root path in the filesystem. + + + + + + + When updating, return non-zero exit value on any parsing error. + + + + + + + systemd-hwdb + <arg choice="opt"><replaceable>options</replaceable></arg> + update + Update the binary database. + + + systemd-hwdb + <arg choice="opt"><replaceable>options</replaceable></arg> + query + <arg><replaceable>MODALIAS</replaceable></arg> + + Query database and print result. + + + + + See Also + + hwdb7 + + + diff --git a/man/systemd-id128.xml b/man/systemd-id128.xml new file mode 100644 index 0000000..5fc78a4 --- /dev/null +++ b/man/systemd-id128.xml @@ -0,0 +1,138 @@ + + + + + + + + systemd-id128 + systemd + + + + systemd-id128 + 1 + + + + systemd-id128 + Generate and print sd-128 identifiers + + + + + systemd-id128 + OPTIONS + new + + + + systemd-id128 + OPTIONS + machine-id + + + + systemd-id128 + OPTIONS + boot-id + + + + systemd-id128 + OPTIONS + invocation-id + + + + + Description + + id128 may be used to conveniently print + sd-id1283 + UUIDs. What identifier is printed depends on the specific verb. + + With new, a new random identifier will be generated. + + With machine-id, the identifier of the current machine will be + printed. See + machine-id5. + + + With boot-id, the identifier of the current boot will be + printed. + + Both machine-id and boot-id may be combined + with the switch to + generate application-specific IDs. See + sd_id128_get_machine3 + for the discussion when this is useful. + + With invocation-id, the identifier of the current service invocation + will be printed. This is available in systemd services. See + systemd.exec5. + + + With show, well-known IDs are printed (for now, only GPT partition type UUIDs), + along with brief identifier strings. When no arguments are specified, all known IDs are shown. When + arguments are specified, they must be the identifiers or ID values of one or more known IDs, which are + then printed. Combine with to list the IDs in UUID style, i.e. the way GPT + partition type UUIDs are usually shown. + + + + Options + + The following options are understood: + + + + + + + Generate output as programming language snippets. + + + + + + + With this option, an identifier that is the result of hashing the + application identifier app-id and the machine identifier will be + printed. The app-id argument must be a valid sd-id128 string + identifying the application. + + + + + + + + Generate output as an UUID formatted in the "canonical representation", with five + groups of digits separated by hyphens. See the + wikipedia + for more discussion. + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + See Also + + systemd1, + sd-id1283, + sd_id128_get_machine3 + + + + diff --git a/man/systemd-importd.service.xml b/man/systemd-importd.service.xml new file mode 100644 index 0000000..1e3c17b --- /dev/null +++ b/man/systemd-importd.service.xml @@ -0,0 +1,56 @@ + + + + + + + + systemd-importd.service + systemd + + + + systemd-importd.service + 8 + + + + systemd-importd.service + systemd-importd + VM and container image import and export service + + + + systemd-importd.service + /usr/lib/systemd/systemd-importd + + + + Description + + systemd-importd is a system service that allows importing, exporting and downloading of + system images suitable for running as VM or containers. It is a companion service for + systemd-machined.service8, and provides the implementation for + machinectl1's + pull-raw, pull-tar, import-raw, + import-tar, import-fs, export-raw, and export-tar commands. + + See + org.freedesktop.import15 + and + org.freedesktop.LogControl15 + for a description of the D-Bus API. + + + + See Also + + systemd1, + machinectl1, + systemd-machined.service8, + systemd-nspawn1 + + + + diff --git a/man/systemd-inhibit.xml b/man/systemd-inhibit.xml new file mode 100644 index 0000000..f6595f1 --- /dev/null +++ b/man/systemd-inhibit.xml @@ -0,0 +1,154 @@ + + + + + + + + systemd-inhibit + systemd + + + + systemd-inhibit + 1 + + + + systemd-inhibit + Execute a program with an inhibition lock taken + + + + + systemd-inhibit OPTIONS COMMAND ARGUMENTS + + + systemd-inhibit OPTIONS --list + + + + + Description + + systemd-inhibit may be used to execute a + program with a shutdown, sleep, or idle inhibitor lock taken. The + lock will be acquired before the specified command line is + executed and released afterwards. + + Inhibitor locks may be used to block or delay system sleep + and shutdown requests from the user, as well as automatic idle + handling of the OS. This is useful to avoid system suspends while + an optical disc is being recorded, or similar operations that + should not be interrupted. + + For more information see the Inhibitor + Lock Developer Documentation. + + + + Options + + The following options are understood: + + + + + + Takes a colon-separated list of one or more + operations to inhibit: + shutdown, + sleep, + idle, + handle-power-key, + handle-suspend-key, + handle-hibernate-key, + handle-lid-switch, + for inhibiting reboot/power-off/halt/kexec, + suspending/hibernating, the automatic idle detection, or the + low-level handling of the power/sleep key and the lid switch, + respectively. If omitted, defaults to + idle:sleep:shutdown. + + + + + + Takes a short, human-readable descriptive + string for the program taking the lock. If not passed, + defaults to the command line string. + + + + + + Takes a short, human-readable descriptive + string for the reason for taking the lock. Defaults to + "Unknown reason". + + + + + + Takes either block or + delay and describes how the lock is + applied. If block is used (the default), + the lock prohibits any of the requested operations without + time limit, and only privileged users may override it. If + delay is used, the lock can only delay the + requested operations for a limited time. If the time elapses, + the lock is ignored and the operation executed. The time limit + may be specified in + logind.conf5. + Note that delay is only available for + sleep and + shutdown. + + + + + + Lists all active inhibition locks instead of + acquiring one. + + + + + + + + + + + + Exit status + + Returns the exit status of the executed program. + + + + Example + + # systemd-inhibit wodim foobar.iso + + This burns the ISO image + foobar.iso on a CD using + wodim1, + and inhibits system sleeping, shutdown and idle while + doing so. + + + + + + See Also + + systemd1, + logind.conf5 + + + + diff --git a/man/systemd-initctl.service.xml b/man/systemd-initctl.service.xml new file mode 100644 index 0000000..b435800 --- /dev/null +++ b/man/systemd-initctl.service.xml @@ -0,0 +1,49 @@ + + + + + + + + systemd-initctl.service + systemd + + + + systemd-initctl.service + 8 + + + + systemd-initctl.service + systemd-initctl.socket + systemd-initctl + /dev/initctl compatibility + + + + systemd-initctl.service + systemd-initctl.socket + /usr/lib/systemd/systemd-initctl + + + + Description + + systemd-initctl is a system service + that implements compatibility with the + /dev/initctl FIFO file system object, as + implemented by the SysV init system. + systemd-initctl is automatically activated on + request and terminates itself when it is unused. + + + + See Also + + systemd1 + + + + diff --git a/man/systemd-integritysetup-generator.xml b/man/systemd-integritysetup-generator.xml new file mode 100644 index 0000000..44248b2 --- /dev/null +++ b/man/systemd-integritysetup-generator.xml @@ -0,0 +1,48 @@ + + + + + + + + systemd-integritysetup-generator + systemd + + + + systemd-integritysetup-generator + 8 + + + + systemd-integritysetup-generator + Unit generator for integrity protected block devices + + + + /usr/lib/systemd/system-generators/systemd-integritysetup-generator + + + + Description + + systemd-integritysetup-generator is a generator that translates /etc/integritytab entries into + native systemd units early at boot. This will create + systemd-integritysetup@.service8 + units as necessary. + + systemd-integritysetup-generator implements + systemd.generator7. + + + + See Also + + systemd1, + systemd-integritysetup@.service8, + integritysetup8 + + + + diff --git a/man/systemd-integritysetup@.service.xml b/man/systemd-integritysetup@.service.xml new file mode 100644 index 0000000..3dca2c3 --- /dev/null +++ b/man/systemd-integritysetup@.service.xml @@ -0,0 +1,98 @@ + + + + + + + + systemd-integritysetup@.service + systemd + + + + systemd-integritysetup@.service + 8 + + + + systemd-integritysetup@.service + systemd-integritysetup + Disk integrity protection logic + + + + systemd-integritysetup@.service + /usr/lib/systemd/systemd-integritysetup + + + + Description + + systemd-integritysetup@.service is a service responsible for setting up integrity + protected block devices. It should be instantiated for each device that requires integrity + protection. + + At early boot and when the system manager configuration is reloaded, entries from + integritytab5 are + converted into systemd-integritysetup@.service units by + systemd-integritysetup-generator8. + + systemd-integritysetup@.service calls systemd-integritysetup. + + + + Commands + + The following commands are understood by systemd-integritysetup: + + + + + + volume + device + [key-file|-] + [option(s)|-] + + + Create a block device volume using + device. See + integritytab5 + and + + Kernel dm-integrity documentation for details. + + + + + + + volume + + + Detach (destroy) the block device + volume. + + + + + + + + Print short information about command syntax. + + + + + + See Also + + systemd1, + integritytab5, + systemd-integritysetup-generator8, + integritysetup8 + + + + diff --git a/man/systemd-journal-gatewayd.service.xml b/man/systemd-journal-gatewayd.service.xml new file mode 100644 index 0000000..609d050 --- /dev/null +++ b/man/systemd-journal-gatewayd.service.xml @@ -0,0 +1,324 @@ + + + + + + + + systemd-journal-gatewayd.service + systemd + + + + systemd-journal-gatewayd.service + 8 + + + + systemd-journal-gatewayd.service + systemd-journal-gatewayd.socket + systemd-journal-gatewayd + HTTP server for journal events + + + + systemd-journal-gatewayd.service + systemd-journal-gatewayd.socket + + /usr/lib/systemd/systemd-journal-gatewayd + OPTIONS + + + + + Description + + systemd-journal-gatewayd serves journal + events over the network. Clients must connect using + HTTP. The server listens on port 19531 by default. + If is specified, the server expects + HTTPS connections. + + The program is started by + systemd1 + and expects to receive a single socket. Use + systemctl start systemd-journal-gatewayd.socket to start + the service, and systemctl enable systemd-journal-gatewayd.socket + to have it started on boot. + + + + Options + + The following options are understood: + + + + + + Specify the path to a file or AF_UNIX stream socket to read the + server certificate from. The certificate must be in PEM format. This option switches + systemd-journal-gatewayd into HTTPS mode and must be used together with + . + + + + + + Specify the path to a file or AF_UNIX stream socket to read the + secret server key corresponding to the certificate specified with from. The + key must be in PEM format. + + + + + + Specify the path to a file or AF_UNIX stream socket to read a CA + certificate from. The certificate must be in PEM format. + + + + + + + Limit served entries to entries from system + services and the kernel, or to entries from services of + current user. This has the same meaning as + and options + for + journalctl1. If + neither is specified, all accessible entries are served. + + + + + + + + Serve entries interleaved from all available + journals, including other machines. This has the same meaning + as option for + journalctl1. + + + + + + + Takes a directory path as argument. If + specified, systemd-journal-gatewayd will serve the + specified journal directory DIR instead of + the default runtime and system journal paths. + + + + + + Takes a file glob as an argument. Serve + entries from the specified journal files matching + GLOB instead of the default runtime + and system journal paths. May be specified multiple times, in + which case files will be suitably interleaved. This has the same meaning as + option for + journalctl1. + + + + + + + + + + Supported URLs + + The following URLs are recognized: + + + + /browse + + Interactive browsing. + + + + /entries[?option1&option2=value…] + + Retrieval of events in various formats. + + The part of the HTTP header + determines the format. Supported values are described below. + + + The part of the HTTP header + determines the range of events returned. Supported values are + described below. + + + GET parameters can be used to modify what events are + returned. Supported parameters are described below. + + + + + /machine + + Return a JSON structure describing the machine. + + Example: + { "machine_id" : "8cf7ed9d451ea194b77a9f118f3dc446", + "boot_id" : "3d3c9efaf556496a9b04259ee35df7f7", + "hostname" : "fedora", + "os_pretty_name" : "Fedora 19 (Rawhide)", + "virtualization" : "kvm", + …} + + + + + + /fields/FIELD_NAME + + Return a list of values of this field present in the logs. + + + + + + + Accept header + + + + + + Recognized formats: + + + + text/plain + + The default. Plaintext syslog-like output, + one line per journal entry + (like journalctl --output short). + + + + + application/json + + Entries are formatted as JSON data structures, + one per line + (like journalctl --output json). + See Journal JSON Format + for more information. + + + + + text/event-stream + + Entries are formatted as JSON data structures, + wrapped in a format suitable for + Server-Sent Events + (like journalctl --output json-sse). + + + + + + application/vnd.fdo.journal + + Entries are serialized into a binary (but mostly text-based) stream suitable for + backups and network transfer (like journalctl --output export). See Journal Export Format + for more information. + + + + + + + Range header + + + + + + where + cursor is a cursor string, + num_skip is an integer, + num_entries is an unsigned integer. + + + Range defaults to all available events. + + + + URL GET parameters + + Following parameters can be used as part of the URL: + + + + follow + + wait for new events + (like journalctl --follow, except that + the number of events returned is not limited). + + + + + discrete + + Test that the specified cursor refers to an + entry in the journal. Returns just this entry. + + + + + boot + + Limit events to the current boot of the system + (like journalctl -b). + + + + KEY=match + + Match journal fields. See + systemd.journal-fields7. + + + + + + + Examples + Retrieve events from this boot from local journal in + Journal Export Format: + curl --silent -H'Accept: application/vnd.fdo.journal' \ + 'http://localhost:19531/entries?boot' + + + Listen for core dumps: + curl 'http://localhost:19531/entries?follow&MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1' + + + + See Also + + systemd1, + journalctl1, + systemd.journal-fields7, + systemd-journald.service8, + systemd-journal-remote.service8, + systemd-journal-upload.service8 + + + + diff --git a/man/systemd-journal-remote.service.xml b/man/systemd-journal-remote.service.xml new file mode 100644 index 0000000..c8a702a --- /dev/null +++ b/man/systemd-journal-remote.service.xml @@ -0,0 +1,348 @@ + + +%entities; +]> + + + + + + systemd-journal-remote.service + systemd + + + + systemd-journal-remote.service + 8 + + + + systemd-journal-remote.service + systemd-journal-remote.socket + systemd-journal-remote + Receive journal messages over the network + + + + systemd-journal-remote.service + systemd-journal-remote.socket + + /usr/lib/systemd/systemd-journal-remote + OPTIONS + -o/--output=DIR|FILE + SOURCES + + + + + Description + + systemd-journal-remote is a command to receive serialized journal + events and store them to journal files. Input streams are in the + Journal Export Format, + i.e. like the output from journalctl --output=export. For transport over the + network, this serialized stream is usually carried over an HTTPS connection. + + systemd-journal-remote.service is a system service that uses + systemd-journal-remote to listen for connections. + systemd-journal-remote.socket configures the network address that + systemd-journal-remote.service listens on. By default this is port 19532. + What connections are accepted and how the received data is stored can be configured through the + journal-remote.conf5 + configuration file. + + + + Sources + + + Sources can be either "active" + (systemd-journal-remote requests and pulls + the data), or "passive" + (systemd-journal-remote waits for a + connection and then receives events pushed by the other side). + + + + systemd-journal-remote can read more than one + event stream at a time. They will be interleaved in the output + file. In case of "active" connections, each "source" is one + stream, and in case of "passive" connections, each connection can + result in a separate stream. Sockets can be configured in + "accept" mode (i.e. only one connection), or "listen" mode (i.e. + multiple connections, each resulting in a stream). + + + + When there are no more connections, and no more can be created + (there are no listening sockets), then + systemd-journal-remote will exit. + + + Active sources can be specified in the following + ways: + + + + SOURCES + + When is given as a + positional argument, events will be read from standard input. + Other positional arguments will be treated as filenames + to open and read from. + + + + + + With the + option, + events will be retrieved using HTTP from + ADDRESS. This URL should refer to the + root of a remote + systemd-journal-gatewayd8 + instance, e.g. http://some.host:19531/ or + https://some.host:19531/. + + + + + + Program to invoke to retrieve data. The journal + event stream must be generated on standard output. + + Examples: + + --getter='curl "-HAccept: application/vnd.fdo.journal" https://some.host:19531/' + + --getter='wget --header="Accept: application/vnd.fdo.journal" -O- https://some.host:19531/' + + + + + Passive sources can be specified in the following + ways: + + + + + + ADDRESS must be an + address suitable for (cf. + systemd.socket5). + systemd-journal-remote will listen on this + socket for connections. Each connection is expected to be a + stream of journal events. + + + + + + + + ADDRESS must be + either a negative integer, in which case it will be + interpreted as the (negated) file descriptor number, or an + address suitable for (c.f. + systemd.socket5). + In the first case, the server listens on port 19532 by default, + and the matching file descriptor must be inherited through + $LISTEN_FDS/$LISTEN_PID. + In the second case, an HTTP or HTTPS server will be spawned on + this port, respectively for and + . Currently, only POST requests + to /upload with Content-Type: + application/vnd.fdo.journal are supported. + + + + + $LISTEN_FDS + + systemd-journal-remote + supports the + $LISTEN_FDS/$LISTEN_PID + protocol. Open sockets inherited through socket activation + behave like those opened with + described above, unless they are specified as an argument in + + or + + above. In the latter case, an HTTP or HTTPS server will be + spawned using this descriptor and connections must be made + over the HTTP protocol. + + + + + + + Takes a path to a SSL secret key file in PEM format. Defaults to + &CERTIFICATE_ROOT;/private/journal-remote.pem. This option can be used with + . If the path refers to an AF_UNIX stream socket + in the file system a connection is made to it and the key read from it. + + + + + + Takes a path to a SSL certificate file in PEM format. Defaults to + &CERTIFICATE_ROOT;/certs/journal-remote.pem. This option can be used with + . If the path refers to an AF_UNIX stream socket + in the file system a connection is made to it and the certificate read from it. + + + + + + Takes a path to a SSL CA certificate file in PEM format, or . If + is set, then certificate checking will be disabled. Defaults to + &CERTIFICATE_ROOT;/ca/trusted.pem. This option can be used with + . If the path refers to an AF_UNIX stream socket + in the file system a connection is made to it and the certificate read from it. + + + + + + + Takes a comma separated list of gnutls logging categories. + This option can be used with or + . + + + + + + + + Sinks + + The location of the output journal can be specified + with or . + + + + + + + + Will write to this journal file. The filename + must end with .journal. The file will be + created if it does not exist. If necessary (journal file full, + or corrupted), the file will be renamed following normal + journald rules and a new journal file will be created in its + stead. + + + + + + + Will create journal files underneath directory + DIR. The directory must exist. If + necessary (journal files over size, or corrupted), journal + files will be rotated following normal journald rules. Names + of files underneath DIR will be + generated using the rules described below. + + + + If is not used, the output + directory /var/log/journal/remote/ will be + used. In case the output file is not specified, journal files + will be created underneath the selected directory. Files will be + called + remote-hostname.journal, + where the hostname part is the + escaped hostname of the source endpoint of the connection, or the + numerical address if the hostname cannot be determined. + + In the case that "active" sources are given by the positional + arguments or option, the output file name + must always be given explicitly. + + + + Options + + The following options are understood: + + + + + + One of none or + host. For the first, only one output + journal file is used. For the latter, a separate output file + is used, based on the hostname of the other endpoint of a + connection. + + In the case that "active" sources are given by the positional + arguments or option, the output file name must + always be given explicitly and only none + is allowed. + + + + [BOOL] + + If this is set to yes then compress + the data in the journal using XZ. The default is yes. + + + + + [BOOL] + + If this is set to yes then + periodically sign the data in the journal using Forward Secure Sealing. + The default is no. + + + + + + + + + Examples + Copy local journal events to a different journal directory: + +journalctl -o export | systemd-journal-remote -o /tmp/dir/foo.journal - + + + + Retrieve all available events from a remote + systemd-journal-gatewayd8 + instance and store them in + /var/log/journal/remote/remote-some.host.journal: + +systemd-journal-remote --url http://some.host:19531/ + + + + Retrieve current boot events and wait for new events from a remote + systemd-journal-gatewayd8 + instance, and store them in + /var/log/journal/remote/remote-some.host.journal: + +systemd-journal-remote --url http://some.host:19531/entries?boot&follow + + + + + + See Also + + journal-remote.conf5, + journalctl1, + systemd-journal-gatewayd.service8, + systemd-journal-upload.service8, + systemd-journald.service8 + + + diff --git a/man/systemd-journal-upload.service.xml b/man/systemd-journal-upload.service.xml new file mode 100644 index 0000000..ce9bbdf --- /dev/null +++ b/man/systemd-journal-upload.service.xml @@ -0,0 +1,292 @@ + + +%entities; +]> + + + + + + systemd-journal-upload.service + systemd + + + + systemd-journal-upload.service + 8 + + + + systemd-journal-upload.service + systemd-journal-upload + Send journal messages over the network + + + + systemd-journal-upload.service + + /usr/lib/systemd/systemd-journal-upload + OPTIONS + -u/--url=URL + SOURCES + + + + + Description + + systemd-journal-upload will upload journal entries to the URL specified + with . This program reads journal entries from one or more journal files, + similarly to + journalctl1. + Unless limited by one of the options specified below, all journal entries accessible to the user + the program is running as will be uploaded, and then the program will wait and send new entries + as they become available. + + systemd-journal-upload transfers the raw content of journal file and + uses HTTP as a transport protocol. + + systemd-journal-upload.service is a system service that uses + systemd-journal-upload to upload journal entries to a server. It uses the + configuration in + journal-upload.conf5. + At least the URL= option must be specified. + + + + Options + + + + + + + + Upload to the specified + address. URL may specify either + just the hostname or both the protocol and + hostname. https is the default. + The port number may be specified after a colon (:), + otherwise 19532 will be used by default. + + + + + + + + Limit uploaded entries to entries from system + services and the kernel, or to entries from services of + current user. This has the same meaning as + and options + for + journalctl1. If + neither is specified, all accessible entries are uploaded. + + + + + + + + Upload entries interleaved from all available + journals, including other machines. This has the same meaning + as option for + journalctl1. + + + + + + + Takes a directory path as argument. Upload + entries from the specified journal directory + DIR instead of the default runtime + and system journal paths. This has the same meaning as + option for + journalctl1. + + + + + + + Takes a file glob as an argument. Upload + entries from the specified journal files matching + GLOB instead of the default runtime + and system journal paths. May be specified multiple times, in + which case files will be suitably interleaved. This has the same meaning as + option for + journalctl1. + + + + + + + Upload entries from the location in the + journal specified by the passed cursor. This has the same + meaning as option for + journalctl1. + + + + + + Upload entries from the location in the + journal after the location specified by + the this cursor. This has the same meaning as + option for + journalctl1. + + + + + =PATH + + Upload entries from the location in the + journal after the location specified by + the cursor saved in file at PATH + (/var/lib/systemd/journal-upload/state by default). + After an entry is successfully uploaded, update this file + with the cursor of that entry. + + + + + =BOOL + + + If set to yes, then systemd-journal-upload waits for input. + + + + + + + + Takes a path to a SSL key file in PEM format, or . + If is set, then client certificate authentication checking + will be disabled. + Defaults to &CERTIFICATE_ROOT;/private/journal-upload.pem. + + + + + + + + Takes a path to a SSL certificate file in PEM format, or . + If is set, then client certificate authentication checking + will be disabled. + Defaults to &CERTIFICATE_ROOT;/certs/journal-upload.pem. + + + + + + + + Takes a path to a SSL CA certificate file in PEM format, or /. + If / is set, then certificate checking will be disabled. + Defaults to &CERTIFICATE_ROOT;/ca/trusted.pem. + + + + + + + + + + Exit status + + On success, 0 is returned; otherwise, a non-zero + failure code is returned. + + + + Examples + + Setting up certificates for authentication + + Certificates signed by a trusted authority are used to + verify that the server to which messages are uploaded is + legitimate, and vice versa, that the client is trusted. + + A suitable set of certificates can be generated with + openssl. Note, 2048 bits of key length + is minimally recommended to use for security reasons: + + openssl req -newkey rsa:2048 -days 3650 -x509 -nodes \ + -out ca.pem -keyout ca.key -subj '/CN=Certificate authority/' + +cat >ca.conf <<EOF +[ ca ] +default_ca = this + +[ this ] +new_certs_dir = . +certificate = ca.pem +database = ./index +private_key = ca.key +serial = ./serial +default_days = 3650 +default_md = default +policy = policy_anything + +[ policy_anything ] +countryName = optional +stateOrProvinceName = optional +localityName = optional +organizationName = optional +organizationalUnitName = optional +commonName = supplied +emailAddress = optional +EOF + +touch index +echo 0001 >serial + +SERVER=server +CLIENT=client + +openssl req -newkey rsa:2048 -nodes -out $SERVER.csr -keyout $SERVER.key -subj "/CN=$SERVER/" +openssl ca -batch -config ca.conf -notext -in $SERVER.csr -out $SERVER.pem + +openssl req -newkey rsa:2048 -nodes -out $CLIENT.csr -keyout $CLIENT.key -subj "/CN=$CLIENT/" +openssl ca -batch -config ca.conf -notext -in $CLIENT.csr -out $CLIENT.pem + + + Generated files ca.pem, + server.pem, and + server.key should be installed on server, + and ca.pem, + client.pem, and + client.key on the client. The location of + those files can be specified using + TrustedCertificateFile=, + ServerCertificateFile=, + and ServerKeyFile= in + /etc/systemd/journal-remote.conf and + /etc/systemd/journal-upload.conf, + respectively. The default locations can be queried by using + systemd-journal-remote --help and + systemd-journal-upload --help. + + + + + See Also + + journal-upload.conf5, + systemd-journal-remote.service8, + journalctl1, + systemd-journald.service8, + systemd-journal-gatewayd.service8 + + + diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml new file mode 100644 index 0000000..8fa8644 --- /dev/null +++ b/man/systemd-journald.service.xml @@ -0,0 +1,357 @@ + + + + + + + + systemd-journald.service + systemd + + + + systemd-journald.service + 8 + + + + systemd-journald.service + systemd-journald.socket + systemd-journald-dev-log.socket + systemd-journald-audit.socket + systemd-journald@.service + systemd-journald@.socket + systemd-journald-varlink@.socket + systemd-journald + Journal service + + + + systemd-journald.service + systemd-journald.socket + systemd-journald-dev-log.socket + systemd-journald-audit.socket + systemd-journald@.service + systemd-journald@.socket + systemd-journald-varlink@.socket + /usr/lib/systemd/systemd-journald + + + + Description + + systemd-journald is a system service + that collects and stores logging data. It creates and maintains + structured, indexed journals based on logging information that is + received from a variety of sources: + + + Kernel log messages, via kmsg + + Simple system log messages, via the libc syslog3 + call + + Structured system log messages via the native Journal API, see + sd_journal_print3 + and Native Journal + Protocol + + Standard output and standard error of service units. For further details see + below. + + Audit records, originating from the kernel audit subsystem + + + The daemon will implicitly collect numerous metadata fields + for each log messages in a secure and unfakeable way. See + systemd.journal-fields7 + for more information about the collected metadata. + + + Log data collected by the journal is primarily text-based but can also include binary data where + necessary. Individual fields making up a log record stored in the journal may be up to 2⁶⁴-1 bytes in size. + + The journal service stores log data either persistently below /var/log/journal or in a + volatile way below /run/log/journal/ (in the latter case it is lost at reboot). By default, log + data is stored persistently if /var/log/journal/ exists during boot, with an implicit fallback + to volatile storage otherwise. Use Storage= in + journald.conf5 to configure + where log data is placed, independently of the existence of /var/log/journal/. + + Note that journald will initially use volatile storage, until a call to + journalctl --flush (or sending SIGUSR1 to journald) will cause + it to switch to persistent logging (under the conditions mentioned above). This is done automatically + on boot via systemd-journal-flush.service. + + On systems where /var/log/journal/ does not exist yet but where persistent logging is + desired (and the default journald.conf is used), it is sufficient to create the directory, and + ensure it has the correct access modes and ownership: + + mkdir -p /var/log/journal +systemd-tmpfiles --create --prefix /var/log/journal + + See + journald.conf5 + for information about the configuration of this service. + + + + Stream logging + + The systemd service manager invokes all service processes with standard output and standard error connected + to the journal by default. This behaviour may be altered via the + StandardOutput=/StandardError= unit file settings, see + systemd.exec5 for details. The + journal converts the log byte stream received this way into individual log records, splitting the stream at newline + (\n, ASCII 10) and NUL bytes. + + If systemd-journald.service is stopped, the stream connections associated with all + services are terminated. Further writes to those streams by the service will result in EPIPE + errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error + ignore such errors. If the SIGPIPE UNIX signal handler is not blocked or turned off, such + write attempts will also result in such process signals being generated, see + signal7. + To mitigate this issue, systemd service manager explicitly turns off the SIGPIPE + signal for all invoked processes by default (this may be changed for each unit individually via the + IgnoreSIGPIPE= option, see + systemd.exec5 for + details). After the standard output/standard error streams have been terminated they may not be recovered + until the services they are associated with are restarted. Note that during normal operation, + systemd-journald.service stores copies of the file descriptors for those streams in + the service manager. If systemd-journald.service is restarted using + systemctl restart or equivalent operation instead of a pair of separate + systemctl stop and systemctl start commands (or equivalent + operations), these stream connections are not terminated and survive the restart. It is thus safe to + restart systemd-journald.service, but stopping it is not recommended. + + Note that the log record metadata for records transferred via such standard output/error streams reflect the + metadata of the peer the stream was originally created for. If the stream connection is passed on to other + processes (such as further child processes forked off the main service process), the log records will not reflect + their metadata, but will continue to describe the original process. This is different from the other logging + transports listed above, which are inherently record based and where the metadata is always associated with the + individual record. + + In addition to the implicit standard output/error logging of services, stream logging is also available + via the systemd-cat1 command + line tool. + + Currently, the number of parallel log streams systemd-journald will accept is limited to + 4096. When this limit is reached further log streams may be established but will receive + EPIPE right from the beginning. + + + + Journal Namespaces + + Journal 'namespaces' are both a mechanism for logically isolating the log stream of projects + consisting of one or more services from the rest of the system and a mechanism for improving + performance. Multiple journal namespaces may exist simultaneously, each defining its own, independent log + stream managed by its own instance of systemd-journald. Namespaces are independent of + each other, both in the data store and in the IPC interface. By default only a single 'default' namespace + exists, managed by systemd-journald.service (and its associated socket + units). Additional namespaces are created by starting an instance of the + systemd-journald@.service service template. The instance name is the namespace + identifier, which is a short string used for referencing the journal namespace. Service units may be + assigned to a specific journal namespace through the LogNamespace= unit file setting, + see systemd.exec5 for + details. The switch of + journalctl1 may be + used to view the log stream of a specific namespace. If the switch is not used the log stream of the + default namespace is shown, i.e. log data from other namespaces is not visible. + + Services associated with a specific log namespace may log via syslog, the native logging protocol + of the journal and via stdout/stderr; the logging from all three transports is associated with the + namespace. + + By default only the default namespace will collect kernel and audit log messages. + + The systemd-journald instance of the default namespace is configured through + /etc/systemd/journald.conf (see below), while the other instances are configured + through /etc/systemd/journald@NAMESPACE.conf. The journal + log data for the default namespace is placed in + /var/log/journal/MACHINE_ID (see below) while the data + for the other namespaces is located in + /var/log/journal/MACHINE_ID.NAMESPACE. + + + + Signals + + + + SIGUSR1 + + Request that journal data from /run/ is flushed to + /var/ in order to make it persistent (if this is enabled). This must be used + after /var/ is mounted, as otherwise log data from /run/ is + never flushed to /var/ regardless of the configuration. Use the + journalctl --flush command to request flushing of the journal files, and wait for + the operation to complete. See + journalctl1 for + details. + + + + SIGUSR2 + + Request immediate rotation of the journal files. Use the journalctl + --rotate command to request journal file rotation, and wait for the operation to + complete. + + + + SIGRTMIN+1 + + Request that all unwritten log data is written to disk. Use the journalctl + --sync command to trigger journal synchronization, and wait for the operation to + complete. + + + + + + Kernel Command Line + + A few configuration parameters from + journald.conf may be overridden on the kernel + command line: + + + + systemd.journald.forward_to_syslog= + systemd.journald.forward_to_kmsg= + systemd.journald.forward_to_console= + systemd.journald.forward_to_wall= + + Enables/disables forwarding of collected log + messages to syslog, the kernel log buffer, the system console + or wall. + + + See + journald.conf5 + for information about these settings. + + + + + + Note that these kernel command line options are only honoured by the default namespace, see + above. + + + + Access Control + + Journal files are, by default, owned and readable by the + systemd-journal system group but are not + writable. Adding a user to this group thus enables them to read + the journal files. + + By default, each user, with a UID outside the range of system users, + dynamic service users, and the nobody user, will get their own set of + journal files in /var/log/journal/. See + Users, Groups, UIDs and GIDs on systemd systems + for more details about UID ranges. These journal + files will not be owned by the user, however, in order to avoid + that the user can write to them directly. Instead, file system + ACLs are used to ensure the user gets read access only. + + Additional users and groups may be granted access to journal + files via file system access control lists (ACL). Distributions + and administrators may choose to grant read access to all members + of the wheel and adm system + groups with a command such as the following: + + # setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/ + + Note that this command will update the ACLs both for + existing journal files and for future journal files created in the + /var/log/journal/ directory. + + + + Files + + + + /etc/systemd/journald.conf + + Configure systemd-journald behavior. See + journald.conf5. + + + + + /run/log/journal/machine-id/*.journal + /run/log/journal/machine-id/*.journal~ + /var/log/journal/machine-id/*.journal + /var/log/journal/machine-id/*.journal~ + + systemd-journald writes entries to files in + /run/log/journal/machine-id/ + or + /var/log/journal/machine-id/ + with the .journal suffix. If the daemon is + stopped uncleanly, or if the files are found to be corrupted, + they are renamed using the .journal~ + suffix, and systemd-journald starts writing + to a new file. /run/ is used when + /var/log/journal is not available, or + when is set in the + journald.conf5 + configuration file. + + When systemd-journald ceases writing to a journal file, + it will be renamed to original-name@suffix.journal + (or original-name@suffix.journal~). + Such files are "archived" and will not be written to any more. + + In general, it is safe to read or copy any journal file (active or archived). + journalctl1 + and the functions in the + sd-journal3 + library should be able to read all entries that have been fully written. + + systemd-journald will automatically remove the oldest + archived journal files to limit disk use. See SystemMaxUse= + and related settings in + journald.conf5. + + + + + /dev/kmsg + /dev/log + /run/systemd/journal/dev-log + /run/systemd/journal/socket + /run/systemd/journal/stdout + + Sockets and other file node paths that systemd-journald will + listen on and are visible in the file system. In addition to these, + systemd-journald can listen for audit events using netlink7. + + + + If journal namespacing is used these paths are slightly altered to include a namespace identifier, see above. + + + + See Also + + systemd1, + journalctl1, + journald.conf5, + systemd.journal-fields7, + sd-journal3, + systemd-coredump8, + setfacl1, + sd_journal_print3, + pydoc systemd.journal + + + + diff --git a/man/systemd-localed.service.xml b/man/systemd-localed.service.xml new file mode 100644 index 0000000..b0a4a9f --- /dev/null +++ b/man/systemd-localed.service.xml @@ -0,0 +1,61 @@ + + + + + + + + systemd-localed.service + systemd + + + + systemd-localed.service + 8 + + + + systemd-localed.service + systemd-localed + Locale bus mechanism + + + + systemd-localed.service + /usr/lib/systemd/systemd-localed + + + + Description + + systemd-localed.service is a system service + that may be used as mechanism to change the system locale + settings, as well as the console key mapping and default X11 key + mapping. systemd-localed is automatically + activated on request and terminates itself when it is + unused. + + The tool + localectl1 + is a command line client to this service. + + See + org.freedesktop.locale15 + and + org.freedesktop.LogControl15 + for a description of the D-Bus API. + + + + See Also + + systemd1, + locale.conf5, + vconsole.conf5, + localectl1, + loadkeys1 + + + + diff --git a/man/systemd-logind.service.xml b/man/systemd-logind.service.xml new file mode 100644 index 0000000..622ad95 --- /dev/null +++ b/man/systemd-logind.service.xml @@ -0,0 +1,111 @@ + + + + + + + + systemd-logind.service + systemd + + + + systemd-logind.service + 8 + + + + systemd-logind.service + systemd-logind + Login manager + + + + systemd-logind.service + /usr/lib/systemd/systemd-logind + + + + Description + + systemd-logind is a system service that + manages user logins. It is responsible for: + + + Keeping track of users and sessions, their processes and their idle state. This is implemented by + allocating a systemd slice unit for each user below user.slice, and a scope unit below it + for each concurrent session of a user. Also, a per-user service manager is started as system service instance of + user@.service for each logged in user. + + Generating and managing session IDs. If auditing is available and an audit session ID is already set for + a session, then this ID is reused as the session ID. Otherwise, an independent session counter is + used. + + Providing polkit-based access for users for + operations such as system shutdown or sleep + + + Implementing a shutdown/sleep inhibition logic for applications + + Handling of power/sleep hardware keys + + Multi-seat management + + Session switch management + + Device access management for users + + Automatic spawning of text logins (gettys) on virtual console activation and user + runtime directory management + + Scheduled shutdown + + Sending "wall" messages + + + User sessions are registered with logind via the + pam_systemd8 + PAM module. + + See + logind.conf5 + for information about the configuration of this service. + + See + sd-login3 + for information about the basic concepts of logind + such as users, sessions and seats. + + See + org.freedesktop.login15 + and + org.freedesktop.LogControl15 + for information about the D-Bus APIs systemd-logind provides. + + For more information on the inhibition logic see the Inhibitor + Lock Developer Documentation. + + If you are interested in writing a display manager that makes use of logind, please have look at + Writing Display + Managers. + If you are interested in writing a desktop environment that makes use of logind, please have look at + Writing + Desktop Environments. + + + + See Also + + systemd1, + systemd-user-sessions.service8, + loginctl1, + logind.conf5, + pam_systemd8, + sd-login3 + + + + diff --git a/man/systemd-machine-id-commit.service.xml b/man/systemd-machine-id-commit.service.xml new file mode 100644 index 0000000..cffc3e5 --- /dev/null +++ b/man/systemd-machine-id-commit.service.xml @@ -0,0 +1,74 @@ + + + + + + + + systemd-machine-id-commit.service + systemd + + + + systemd-machine-id-commit.service + 8 + + + + systemd-machine-id-commit.service + Commit a transient machine ID to disk + + + + systemd-machine-id-commit.service + + + + Description + + systemd-machine-id-commit.service is an + early boot service responsible for committing transient + /etc/machine-id files to a writable disk file + system. See + machine-id5 + for more information about machine IDs. + + This service is started after + local-fs.target in case + /etc/machine-id is a mount point of its own + (usually from a memory file system such as + tmpfs) and /etc is writable. The service will + invoke systemd-machine-id-setup --commit, which + writes the current transient machine ID to disk and unmount the + /etc/machine-id file in a race-free manner to + ensure that file is always valid and accessible for other + processes. See + systemd-machine-id-setup1 + for details. + + The main use case of this service are systems where + /etc/machine-id is read-only and initially + not initialized. In this case, the system manager will generate a + transient machine ID file on a memory file system, and mount it + over /etc/machine-id, during the early boot + phase. This service is then invoked in a later boot phase, as soon + as /etc/ has been remounted writable and the + ID may thus be committed to disk to make it permanent. + + + + See Also + + systemd1, + systemd-machine-id-setup1, + machine-id5, + systemd-firstboot1 + + + + diff --git a/man/systemd-machine-id-setup.xml b/man/systemd-machine-id-setup.xml new file mode 100644 index 0000000..f1695b6 --- /dev/null +++ b/man/systemd-machine-id-setup.xml @@ -0,0 +1,154 @@ + + + + + + + + systemd-machine-id-setup + systemd + + + + systemd-machine-id-setup + 1 + + + + systemd-machine-id-setup + Initialize the machine ID in /etc/machine-id + + + + + systemd-machine-id-setup + + + + + Description + + systemd-machine-id-setup may be used by + system installer tools to initialize the machine ID stored in + /etc/machine-id at install time, with a + provisioned or randomly generated ID. See + machine-id5 + for more information about this file. + + If the tool is invoked without the + switch, /etc/machine-id is initialized with a + valid, new machine ID if it is missing or empty. The new machine + ID will be acquired in the following fashion: + + + If a valid D-Bus machine ID is already + configured for the system, the D-Bus machine ID is copied and + used to initialize the machine ID in + /etc/machine-id. + + If run inside a KVM virtual machine and a UUID + is configured (via the + option), this UUID is used to initialize the machine ID. The + caller must ensure that the UUID passed is sufficiently unique + and is different for every booted instance of the + VM. + + Similarly, if run inside a Linux container environment and a UUID is configured for the + container, this is used to initialize the machine ID. For details, see the documentation of the Container Interface. + + Otherwise, a new ID is randomly + generated. + + + The switch may be used to commit a + transient machined ID to disk, making it persistent. For details, + see below. + + Use + systemd-firstboot1 + to initialize the machine ID on mounted (but not booted) system + images. + + + + + Options + + The following options are understood: + + + + + + Takes a directory path as argument. All paths operated on will be prefixed with the + given alternate root path, including the path for + /etc/machine-id itself. + + + + + Takes a path to a device node or regular file as argument. This is similar to + as described above, but operates on a disk image instead of a directory + tree. + + + + + Commit a transient machine ID to disk. This + command may be used to convert a transient machine ID into a + persistent one. A transient machine ID file is one that was + bind mounted from a memory file system (usually + tmpfs) to + /etc/machine-id during the early phase of + the boot process. This may happen because + /etc/ is initially read-only and was + missing a valid machine ID file at that point. + + This command will execute no operation if + /etc/machine-id is not mounted from a + memory file system, or if /etc/ is + read-only. The command will write the current transient + machine ID to disk and unmount the + /etc/machine-id mount point in a + race-free manner to ensure that this file is always valid and + accessible for other processes. + + This command is primarily used by the + systemd-machine-id-commit.service8 + early boot service. + + + + + + Print the machine ID generated or committed after the operation is complete. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + machine-id5, + systemd-machine-id-commit.service8, + dbus-uuidgen1, + systemd-firstboot1 + + + + diff --git a/man/systemd-machined.service.xml b/man/systemd-machined.service.xml new file mode 100644 index 0000000..48bf6c5 --- /dev/null +++ b/man/systemd-machined.service.xml @@ -0,0 +1,139 @@ + + + + + + + + systemd-machined.service + systemd + + + + systemd-machined.service + 8 + + + + systemd-machined.service + systemd-machined + Virtual machine and container registration manager + + + + systemd-machined.service + /usr/lib/systemd/systemd-machined + + + + Description + + systemd-machined is a system service that keeps track of locally running virtual + machines and containers. + + systemd-machined is useful for registering and keeping track of both OS + containers (containers that share the host kernel but run a full init system of their own and behave in + most regards like a full virtual operating system rather than just one virtualized app) and full virtual + machines (virtualized hardware running normal operating systems and possibly different kernels). + + systemd-machined should not be used for registering/keeping + track of application sandbox containers. A machine in the context of + systemd-machined is supposed to be an abstract term covering both OS containers and + full virtual machines, but not application sandboxes. + + Machines registered with machined are exposed in various ways in the system. For example: + + Tools like + ps1 + will show to which machine a specific process belongs in a column of + its own, and so will + gnome-system-monitor or + systemd-cgls1. + + + systemd's various tools + (systemctl1, + journalctl1, + loginctl1, + hostnamectl1, + timedatectl1, + localectl1, + machinectl1, ...) + support the switch to operate on local containers instead of the host system. + + + systemctl list-machines will show the system state of all local + containers, connecting to the container's init system for that. + + systemctl's switch has the effect of not only showing the + locally running services, but recursively showing the services of all registered containers. + + The machinectl command provides access to a number of useful + operations on registered containers, such as introspecting them, rebooting, shutting them down, and + getting a login prompt on them. + + The + sd-bus3 library + exposes the + sd_bus_open_system_machine3 + call to connect to the system bus of any registered container. + + The + nss-mymachines8 + module makes sure all registered containers can be resolved via normal glibc + gethostbyname3 + or + getaddrinfo3 + calls. + + + See + systemd-nspawn1 + for some examples on how to run containers with OS tools. + + If you are interested in writing a VM or container manager that makes use of machined, please have + look at Writing + Virtual Machine or Container Managers. Also see the New Control Group + Interfaces. + + The daemon provides both a C library interface + (which is shared with systemd-logind.service8) + as well as a D-Bus interface. + The library interface may be used to introspect and watch the state of virtual machines/containers. + The bus interface provides the same but in addition may also be used to register or terminate + machines. + For more information please consult + sd-login3 + and + org.freedesktop.machine15 + and + org.freedesktop.LogControl15. + + + A small companion daemon + systemd-importd.service8 + is also available, which implements importing, exporting, and downloading of container and VM images. + + + For each container registered with systemd-machined.service that employs user + namespacing, users/groups are synthesized for the used UIDs/GIDs. These are made available to the system + using the User/Group Record Lookup API via + Varlink, and thus may be resolved with + userdbctl1 or the + usual glibc NSS calls. + + + + See Also + + systemd1, + machinectl1, + systemd-nspawn1, + nss-mymachines8, + systemd.special7 + + + + diff --git a/man/systemd-makefs@.service.xml b/man/systemd-makefs@.service.xml new file mode 100644 index 0000000..1eedb77 --- /dev/null +++ b/man/systemd-makefs@.service.xml @@ -0,0 +1,103 @@ + + + + + + + + systemd-makefs@.service + systemd + + + + systemd-makefs@.service + 8 + + + + systemd-makefs@.service + systemd-mkswap@.service + systemd-growfs@.service + systemd-growfs-root.service + systemd-makefs + systemd-growfs + Creating and growing file systems on demand + + + + systemd-makefs@device.service + systemd-mkswap@device.service + systemd-growfs@mountpoint.service + systemd-growfs-root.service + /usr/lib/systemd/systemd-makefs + /usr/lib/systemd/systemd-growfs + + + + Description + + systemd-makefs@.service, + systemd-mkswap@.service, + systemd-growfs@.service, and + systemd-growfs-root.service are used to implement the + and options + in fstab5, + see systemd.mount5. + They are instantiated for each device for which the file system or swap structure + needs to be initialized, and for each mount point where the file system needs to + be grown. + + These services are started at boot, either right before or right after the + mount point or swap device are used. + + systemd-makefs knows very little about specific file + systems and swap devices, and after checking that the block device does not already + contain a file system or other content, it will execute binaries specific to + each filesystem type (/sbin/mkfs.type + or /sbin/mkswap). For certain file system types (currently + ext2/ext3/ext45, + btrfs5, + xfs5, + f2fs, vfat) and for swap devices, it will configure reasonable defaults and set + the file system label and UUID based on the device name. + + systemd-growfs knows very little about specific file + systems and swap devices, and will instruct the kernel to grow the mounted + filesystem to full size of the underlying block device. Nevertheless, it needs + to know the + ioctl2 + number specific to each file system, so only certain types are supported. + Currently: + ext45, + btrfs5, + xfs5, + + and dm-crypt partitions (see + cryptsetup8). + + + If the creation of a file system or swap device fails, the mount point or + swap is failed too. If the growing of a file system fails, a warning is emitted. + + + + + See Also + + systemd1, + systemd.mount8, + systemd-fstab-generator8, + systemd-repart8, + mkfs.btrfs8, + mkfs.cramfs8, + mkfs.ext48, + mkfs.fat8, + mkfs.hfsplus8, + mkfs.minix8, + mkfs.ntfs8, + mkfs.xfs8 + + + + diff --git a/man/systemd-measure.xml b/man/systemd-measure.xml new file mode 100644 index 0000000..3e5ab25 --- /dev/null +++ b/man/systemd-measure.xml @@ -0,0 +1,284 @@ + + + + + + + + systemd-measure + systemd + + + + systemd-measure + 1 + + + + systemd-measure + Pre-calculate and sign expected TPM2 PCR values for booted unified kernel images + + + + + /usr/lib/systemd/systemd-measure OPTIONS + + + + + Description + + Note: this command is experimental for now. While it is likely to become a regular component of + systemd, it might still change in behaviour and interface. + + systemd-measure is a tool that may be used to pre-calculate and sign the + expected TPM2 PCR 11 values that should be seen when a unified Linux kernel image based on + systemd-stub7 is + booted up. It accepts paths to the ELF kernel image file, initrd image file, devicetree file, kernel + command line file, + os-release5 file, boot + splash file, and TPM2 PCR PEM public key file that make up the unified kernel image, and determines the + PCR values expected to be in place after booting the image. Calculation starts with a zero-initialized + PCR 11, and is executed in a fashion compatible with what systemd-stub does at + boot. The result may optionally be signed cryptographically, to allow TPM2 policies that can only be + unlocked if a certain set of kernels is booted, for which such a PCR signature can be provided. + + + + Commands + + The following commands are understood: + + + + status + + This is the default command if none is specified. This queries the local system's + TPM2 PCR 11+12+13 values and displays them. The data is written in a similar format as the + calculate command below, and may be used to quickly compare expectation with + reality. + + + + calculate + + Pre-calculate the expected values seen in PCR register 11 after boot-up of a unified + kernel image consisting of the components specified with , + , , , + , , see below. Only + is mandatory. (Alternatively, specify to use the + current values of PCR register 11 instead.) + + + + sign + + As with the calculate command, pre-calculate the expected value + seen in TPM2 PCR register 11 after boot-up of a unified kernel image. Then, cryptographically sign + the resulting values with the private/public key pair (RSA) configured via + and . This will write a JSON object to + standard output that contains signatures for all specified PCR banks (see + ) below, which may be used to unlock encrypted credentials (see + systemd-creds1) or + LUKS volumes (see + systemd-cryptsetup@.service8). This + allows binding secrets to a set of kernels for which such PCR 11 signatures can be provided. + + Note that a TPM2 device must be available for this signing to take place, even though the + result is not tied to any TPM2 device or its state. + + + + + + Options + + The following options are understood: + + + + + + + + + + + + When used with the calculate or sign verb, + configures the files to read the unified kernel image components from. Each option corresponds with + the equally named section in the unified kernel PE file. The switch expects + the path to the ELF kernel file that the unified PE kernel will wrap. All switches except + are optional. Each option may be used at most once. + + + + + When used with the calculate or sign verb, + takes the PCR 11 values currently in effect for the system (which should typically reflect the hashes + of the currently booted kernel). This can be used in place of and the other + switches listed above. + + + + + + Controls the PCR banks to pre-calculate the PCR values for – in case + calculate or sign is invoked –, or the banks to show in the + status output. May be used more then once to specify multiple banks. If not + specified, defaults to the four banks sha1, sha256, + sha384, sha512. + + + + + + + These switches take paths to a pair of PEM encoded RSA key files, for use with + the sign command. + + Note the difference between the and + switches. The former selects the data to include in the .pcrpkey PE section of the + unified kernel image, the latter picks the public key of the key pair used to sign the resulting PCR + 11 values. The former is the key that the booted system will likely use to lock disk and credential + encryption to, the latter is the key used for unlocking such resources again. Hence, typically the + same PEM key should be supplied in both cases. + + If the is not specified but is + specified the public key is automatically derived from the private key. + + + + PATH + + Controls which TPM2 device to use. Expects a device node path referring to the TPM2 + chip (e.g. /dev/tpmrm0). Alternatively the special value auto + may be specified, in order to automatically determine the device node of a suitable TPM2 device (of + which there must be exactly one). The special value list may be used to enumerate + all suitable TPM2 devices currently discovered. + + + + PHASE + + Controls which boot phases to calculate expected PCR 11 values for. This takes a + series of colon-separated strings that encode boot "paths" for entering a specific phase of the boot + process. Each of the specified strings is measured by the + systemd-pcrphase-initrd.service and + systemd-pcrphase.service8 + into PCR 11 during different milestones of the boot process. This switch may be specified multiple + times to calculate PCR values for multiple boot phases at once. If not used defaults to + enter-initrd, enter-initrd:leave-initrd, + enter-initrd:leave-initrd:sysinit, + enter-initrd:leave-initrd:sysinit:ready, i.e. calculates expected PCR values for + the boot phase in the initrd, during early boot, during later boot, and during system runtime, but + excluding the phases before the initrd or when shutting down. This setting is honoured both by + calculate and sign. When used with the latter it's particularly + useful for generating PCR signatures that can only be used for unlocking resources during specific + parts of the boot process. + + For further details about PCR boot phases, see + systemd-pcrphase.service8. + + + + + + + + + + + Examples + + + Generate a unified kernel image, and calculate the expected TPM PCR 11 value + + # objcopy \ + --add-section .linux=vmlinux --change-section-vma .linux=0x2000000 \ + --add-section .osrel=os-release.txt --change-section-vma .osrel=0x20000 \ + --add-section .cmdline=cmdline.txt --change-section-vma .cmdline=0x30000 \ + --add-section .initrd=initrd.cpio --change-section-vma .initrd=0x3000000 \ + --add-section .splash=splash.bmp --change-section-vma .splash=0x100000 \ + --add-section .dtb=devicetree.dtb --change-section-vma .dtb=0x40000 \ + /usr/lib/systemd/boot/efi/linuxx64.efi.stub \ + foo.efi +# systemd-measure calculate \ + --linux=vmlinux \ + --osrel=os-release.txt \ + --cmdline=cmdline.txt \ + --initrd=initrd.cpio \ + --splash=splash.bmp \ + --dtb=devicetree.dtb +11:sha1=d775a7b4482450ac77e03ee19bda90bd792d6ec7 +11:sha256=bc6170f9ce28eb051ab465cd62be8cf63985276766cf9faf527ffefb66f45651 +11:sha384=1cf67dff4757e61e5a73d2a21a6694d668629bbc3761747d493f7f49ad720be02fd07263e1f93061243aec599d1ee4b4 +11:sha512=8e79acd3ddbbc8282e98091849c3530f996303c8ac8e87a3b2378b71c8b3a6e86d5c4f41ecea9e1517090c3e8ec0c714821032038f525f744960bcd082d937da + + + + + Generate a private/public key pair, and a unified kernel image, and a TPM PCR 11 signature for + it, and embed the signature and the public key in the image + + # openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out tpm2-pcr-private.pem +# openssl rsa -pubout -in tpm2-pcr-private.pem -out tpm2-pcr-public.pem +# systemd-measure sign \ + --linux=vmlinux \ + --osrel=os-release.txt \ + --cmdline=cmdline.txt \ + --initrd=initrd.cpio \ + --splash=splash.bmp \ + --dtb=devicetree.dtb \ + --pcrpkey=tpm2-pcr-public.pem \ + --bank=sha1 \ + --bank=sha256 \ + --private-key=tpm2-pcr-private.pem \ + --public-key=tpm2-pcr-public.pem > tpm2-pcr-signature.json +# objcopy \ + --add-section .linux=vmlinux --change-section-vma .linux=0x2000000 \ + --add-section .osrel=os-release.txt --change-section-vma .osrel=0x20000 \ + --add-section .cmdline=cmdline.txt --change-section-vma .cmdline=0x30000 \ + --add-section .initrd=initrd.cpio --change-section-vma .initrd=0x3000000 \ + --add-section .splash=splash.bmp --change-section-vma .splash=0x100000 \ + --add-section .dtb=devicetree.dtb --change-section-vma .dtb=0x40000 \ + --add-section .pcrsig=tpm2-pcr-signature.json --change-section-vma .splash=0x80000 \ + --add-section .pcrpkey=tpm2-pcr-public.pem --change-section-vma .splash=0x90000 \ + /usr/lib/systemd/boot/efi/linuxx64.efi.stub \ + foo.efi + + Later on, enroll the signed PCR policy on a LUKS volume: + + # systemd-cryptenroll --tpm2-device=auto --tpm2-public-key=tpm2-pcr-public.pem --tpm2-signature=tpm2-pcr-signature.json /dev/sda5 + + And then unlock the device with the signature: + + # /usr/lib/systemd/systemd-cryptsetup attach myvolume /dev/sda5 - tpm2-device=auto,tpm2-signature=/path/to/tpm2-pcr-signature.json + + Note that when the generated unified kernel image foo.efi is booted the + signature and public key files will be placed at locations systemd-cryptenroll and + systemd-cryptsetup will look for anyway, and thus these paths do not actually need to + be specified. + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + See Also + + systemd1, + systemd-stub7, + objcopy1, + systemd-creds1, + systemd-cryptsetup@.service8, + systemd-pcrphase.service8 + + + + diff --git a/man/systemd-modules-load.service.xml b/man/systemd-modules-load.service.xml new file mode 100644 index 0000000..6911948 --- /dev/null +++ b/man/systemd-modules-load.service.xml @@ -0,0 +1,70 @@ + + + + + + + + systemd-modules-load.service + systemd + + + + systemd-modules-load.service + 8 + + + + systemd-modules-load.service + systemd-modules-load + Load kernel modules at boot + + + + systemd-modules-load.service + /usr/lib/systemd/systemd-modules-load + + + + Description + + systemd-modules-load.service is an early boot service that loads kernel + modules. It reads static configuration from files in /usr/ and + /etc/, but also runtime configuration from /run/ and the kernel + command line (see below). + + See + modules-load.d5 for + information about the configuration format of this service and paths where configuration files can be + created. + + + + Kernel Command Line + + systemd-modules-load.service + understands the following kernel command line parameters: + + + + + modules_load= + rd.modules_load= + + Takes a comma-separated list of kernel modules to statically load during early boot. + The option prefixed with rd. is read in the initrd only. + + + + + + + See Also + + systemd1, + modules-load.d5, + + + + diff --git a/man/systemd-mount.xml b/man/systemd-mount.xml new file mode 100644 index 0000000..e25d5c4 --- /dev/null +++ b/man/systemd-mount.xml @@ -0,0 +1,338 @@ + + + + + + + + systemd-mount + systemd + + + + systemd-mount + 1 + + + + systemd-mount + systemd-umount + Establish and destroy transient mount or auto-mount points + + + + + systemd-mount + OPTIONS + WHAT + WHERE + + + systemd-mount + OPTIONS + + + + systemd-mount + OPTIONS + + WHAT|WHERE + + + + + Description + + systemd-mount may be used to create and start a transient .mount or + .automount unit of the file system WHAT on the mount point + WHERE. + + In many ways, systemd-mount is similar to the lower-level + mount8 + command, however instead of executing the mount operation directly and immediately, + systemd-mount schedules it through the service manager job queue, so that it may pull + in further dependencies (such as parent mounts, or a file system checker to execute a priori), and may + make use of the auto-mounting logic. + + The command takes either one or two arguments. If only one argument is specified it should refer to + a block device or regular file containing a file system (e.g. /dev/sdb1 or + /path/to/disk.img). The block device or image file is then probed for a file system + label and other metadata, and is mounted to a directory below /run/media/system/ + whose name is generated from the file system label. In this mode the block device or image file must + exist at the time of invocation of the command, so that it may be probed. If the device is found to be a + removable block device (e.g. a USB stick), an automount point is created instead of a regular mount point + (i.e. the option is implied, see below). + + If two arguments are specified, the first indicates the mount source (the + WHAT) and the second indicates the path to mount it on (the + WHERE). In this mode no probing of the source is attempted, and a backing + device node doesn't have to exist. However, if this mode is combined with , + device node probing for additional metadata is enabled, and – much like in the single-argument case + discussed above – the specified device has to exist at the time of invocation of the command. + + Use the command to show a terse table of all local, known block devices with file + systems that may be mounted with this command. + + systemd-umount can be used to unmount a mount or automount point. It is the same + as systemd-mount . + + + + Options + + The following options are understood: + + + + + + + + Do not synchronously wait for the requested operation to finish. If this is not specified, the job will + be verified, enqueued and systemd-mount will wait until the mount or automount unit's + start-up is completed. By passing this argument, it is only verified and enqueued. + + + + + + + + + Do not ellipsize the output when is specified. + + + + + + + + + + + + Suppresses additional informational output while running. + + + + + + Enable probing of the mount source. This switch is implied if a single argument is specified on + the command line. If passed, additional metadata is read from the device to enhance the unit to create. For + example, a descriptive string for the transient units is generated from the file system label and device + model. Moreover if a removable block device (e.g. USB stick) is detected an automount unit instead of a regular + mount unit is created, with a short idle timeout, in order to ensure the file-system is placed in a clean + state quickly after each access. + + + + + + + Specifies the file system type to mount (e.g. vfat or + ext4). If omitted or set to auto, the file system type is + determined automatically. + + + + + + + Additional mount options for the mount point. + + + + + + Let the specified user USER own the mounted file system. + This is done by appending and options to the list + of mount options. Only certain file systems support this option. + + + + + + Takes a boolean argument, defaults to on. Controls whether to run a file system check + immediately before the mount operation. In the automount case (see below) the + check will be run the moment the first access to the device is made, which might slightly delay the + access. + + + + + + Provide a description for the mount or automount unit. See Description= in + systemd.unit5. + + + + + + + + Sets a unit property for the mount unit that is created. This takes an assignment in the same + format as systemctl1's + set-property command. + + + + + + + Takes a boolean argument. Controls whether to create an automount point or a regular mount + point. If true an automount point is created that is backed by the actual file system at the time of first + access. If false a plain mount point is created that is backed by the actual file system immediately. Automount + points have the benefit that the file system stays unmounted and hence in clean state until it is first + accessed. In automount mode the switch (see below) may be used to ensure + the mount point is unmounted automatically after the last access and an idle period passed. + + If this switch is not specified it defaults to false. If not specified and is + used (or only a single argument passed, which implies , see above), and the file + system block device is detected to be removable, it is set to true, in order to increase the chance that the + file system is in a fully clean state if the device is unplugged abruptly. + + + + + + Equivalent to . + + + + + + Takes a time value that controls the idle timeout in automount mode. If set to + infinity (the default) no automatic unmounts are done. Otherwise the file system backing the + automount point is detached after the last access and the idle timeout passed. See + systemd.time7 for details on + the time syntax supported. This option has no effect if only a regular mount is established, and automounting + is not used. + + Note that if is used (or only a single argument passed, which implies + , see above), and the file system block device is detected to be removable, + is implied. + + + + + + Similar to , but applies additional properties to the automount + unit created, instead of the mount unit. + + + + + + This option only has an effect in automount mode, + and controls whether the automount unit shall be bound to the backing device's lifetime. If set, the + automount unit will be stopped automatically when the backing device vanishes. By default the automount unit + stays around, and subsequent accesses will block until backing device is replugged. This option has no effect + in case of non-device mounts, such as network or virtual file system mounts. + + Note that if is used (or only a single argument passed, which implies + , see above), and the file system block device is detected to be removable, this + option is implied. + + + + + + Instead of establishing a mount or automount point, print a terse list of block devices + containing file systems that may be mounted with systemd-mount, along with useful metadata + such as labels, etc. + + + + + + + Stop the mount and automount units corresponding to the specified mount points + WHERE or the devices WHAT. + systemd-mount with this option or systemd-umount can take multiple arguments + which can be mount points, devices, /etc/fstab style node names, or backing files + corresponding to loop devices, like + systemd-mount --umount /path/to/umount /dev/sda1 UUID=xxxxxx-xxxx LABEL=xxxxx /path/to/disk.img. + Note that when or is specified, only absolute paths to mount points are + supported. + + + + + + + Unload the transient unit after it completed, even if it failed. Normally, without this option, + all mount units that mount and failed are kept in memory until the user explicitly resets their failure state with + systemctl reset-failed or an equivalent command. On the other hand, units that stopped + successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more + aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for + --property=CollectMode=inactive-or-failed, see the explanation for + CollectMode= in + systemd.unit5 for further + information. + + + + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure + code otherwise. + + + + The udev Database + + If is used, systemd-mount honors a couple of additional udev + properties of block devices: + + + + SYSTEMD_MOUNT_OPTIONS= + + The mount options to use, if is not used. + + + + SYSTEMD_MOUNT_WHERE= + + The file system path to place the mount point at, instead of the automatically generated + one. + + + + + + Example + + Use a udev rule like the following to automatically mount all USB storage plugged in: + + ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", \ + RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --collect $devnode" + + + + See Also + + systemd1, + mount8, + systemctl1, + systemd.unit5, + systemd.mount5, + systemd.automount5, + systemd-run1 + + + + diff --git a/man/systemd-network-generator.service.xml b/man/systemd-network-generator.service.xml new file mode 100644 index 0000000..13f0936 --- /dev/null +++ b/man/systemd-network-generator.service.xml @@ -0,0 +1,113 @@ + + + + + + + + systemd-network-generator.service + systemd + + + + systemd-network-generator.service + 8 + + + + systemd-network-generator.service + systemd-network-generator + Generate network configuration from the kernel command line + + + + systemd-network-generator.service + /usr/lib/systemd/systemd-network-generator + + + + Description + + systemd-network-generator.service is a system service that translates + ip= and the related settings on the kernel command line (see below) into + systemd.network5, + systemd.netdev5, and + systemd.link5 + configuration files understood by + systemd-networkd.service8 + and + systemd-udevd.service8. + + + Files are generated in /run/systemd/network/. + + Note: despite the name, this generator executes as a normal systemd service and is + not an implementation of the + systemd.generator7 + concept. + + + + Kernel command line options + + This tool understands the following options: + + + + ip= + rd.route= + rd.peerdns= + + — translated into + systemd.network5 files. + + + + + ifname= + net.ifname-policy= + + — translated into + systemd.link5 files. + + + + + vlan= + bond= + bridge= + bootdev= + + — translated into + systemd.netdev5 files. + + + + + + + See + dracut.cmdline7 + and + systemd-udevd.service8 + for option syntax and details. + + + + See Also + + systemd1, + systemd-networkd.service8, + dracut8 + + + + diff --git a/man/systemd-networkd-wait-online.service.xml b/man/systemd-networkd-wait-online.service.xml new file mode 100644 index 0000000..a3a70db --- /dev/null +++ b/man/systemd-networkd-wait-online.service.xml @@ -0,0 +1,178 @@ + + + + + + + + systemd-networkd-wait-online.service + systemd + + + + systemd-networkd-wait-online.service + 8 + + + + systemd-networkd-wait-online.service + systemd-networkd-wait-online@.service + systemd-networkd-wait-online + Wait for network to come online + + + + systemd-networkd-wait-online.service + systemd-networkd-wait-online@.service + /usr/lib/systemd/systemd-networkd-wait-online + + + + Description + + systemd-networkd-wait-online is a + oneshot system service (see systemd.service5), that waits for the network to be + configured. By default, it will wait for all links it is aware of + and which are managed by + systemd-networkd.service8 + to be fully configured or failed, and for at least one link to be online. Here, online means that + the link's operational state is equal or higher than degraded. The threshold + can be configured by option. + + The service systemd-networkd-wait-online.service invokes + systemd-networkd-wait-online without any options. Thus, it waits for all managed + interfaces to be configured or failed, and for at least one to be online. + + The service systemd-networkd-wait-online@.service takes an interface + name, and invokes systemd-networkd-wait-online with and the + specified interface name. Thus, wait for the specified interface to be configured and online. For + example, systemd-networkd-wait-online@eth0.service waits for + eth0 to be configured by systemd-networkd and online. + + + + + Options + + The following options are understood: + + + + INTERFACE:MIN_OPERSTATE:MAX_OPERSTATE + INTERFACE:MIN_OPERSTATE:MAX_OPERSTATE + + Network interface to wait for before deciding if the system is online. This + is useful when a system has several interfaces which will be configured, but a particular + one is necessary to access some network resources. When used, all other interfaces are ignored. + This option may be used more than once to wait for multiple network interfaces. When this + option is specified multiple times, then systemd-networkd-wait-online waits + for all specified interfaces to be online. Optionally, required minimum and maximum operational + states can be specified after a colon :. Please see + networkctl1 + for possible operational states. If the operational state is not specified here, then + the value from RequiredForOnline= in the corresponding + .network file is used if present, and degraded otherwise. + + + + + INTERFACE + + Network interfaces to be ignored when deciding + if the system is online. By default, only the loopback + interface is ignored. This option may be used more than once + to ignore multiple network interfaces. + + + + MIN_OPERSTATE:MAX_OPERSTATE + MIN_OPERSTATE:MAX_OPERSTATE + + Takes a minimum operational state and an optional maximum operational state. + Please see networkctl1 + for possible operational states. If set, the specified value overrides + RequiredForOnline= settings in .network files. + But this does not override operational states specified in option. + + + + + + + + Waiting for an IPv4 address of each network interface to be configured. If this + option is specified with , then + systemd-networkd-wait-online exits with success when at least one interface + becomes online and has an IPv4 address. If the required minimum operational state is + below routable, then each link (or at least one link with + ) must have an IPv4 link-local or routable address. If the required + minimum operational state is routable, then each link must have an IPv4 + routable address. + If neither nor + is specified, then the value from + RequiredFamilyForOnline= in the corresponding .network + file is used if present. + + + + + + + Waiting for an IPv6 address of each network interface to be configured. If this + option is specified with , then + systemd-networkd-wait-online exits with success when at least one interface + becomes online and has an IPv6 address. If the required minimum operational state is + below routable, then each link (or at least one link with + ) must have an IPv6 link-local or routable address. If the required + minimum operational state is routable, then each link must have an IPv6 + routable address. + If neither nor + is specified, then the value from + RequiredFamilyForOnline= in the corresponding .network + file is used if present. + + + + + + Even if several interfaces are in configuring state, + systemd-networkd-wait-online exits with success when at least one interface + becomes online. When this option is specified with , then + systemd-networkd-wait-online waits for one of the specified interfaces to be + online. This option is useful when some interfaces may not have carrier on boot. + + + + + SECS + + Fail the service if the network is not online + by the time the timeout elapses. A timeout of 0 disables the + timeout. Defaults to 120 seconds. + + + + + + + Suppress log messages. + + + + + + + + + See Also + + systemd1, + systemd.service5, + systemd-networkd.service8, + networkctl1 + + + + diff --git a/man/systemd-networkd.service.xml b/man/systemd-networkd.service.xml new file mode 100644 index 0000000..12cd4c3 --- /dev/null +++ b/man/systemd-networkd.service.xml @@ -0,0 +1,97 @@ + + + + + + + + systemd-networkd.service + systemd + + + + systemd-networkd.service + 8 + + + + systemd-networkd.service + systemd-networkd + Network manager + + + + systemd-networkd.service + /usr/lib/systemd/systemd-networkd + + + + Description + + systemd-networkd is a system service that + manages networks. It detects and configures network devices as + they appear, as well as creating virtual network devices. + + To configure low-level link settings independently of + networks, see + systemd.link5. + + systemd-networkd will create network devices based + on the configuration in + systemd.netdev5 + files, respecting the [Match] sections in those files. + + systemd-networkd will manage network addresses and + routes for any link for which it finds a .network file + with an appropriate [Match] section, see + systemd.network5. + For those links, it will flush existing network addresses and routes when + bringing up the device. Any links not matched by one of the + .network files will be ignored. It is also possible to + explicitly tell systemd-networkd to ignore a link by + using Unmanaged=yes option, see + systemd.network5. + + + When systemd-networkd exits, it generally leaves existing network devices and + configuration intact. This makes it possible to transition from the initrd and to restart the service + without breaking connectivity. This also means that when configuration is updated and + systemd-networkd is restarted, netdev interfaces for which configuration was removed + will not be dropped, and may need to be cleaned up manually. + + systemd-networkd may be introspected and controlled at runtime using + networkctl1. + + + + Configuration Files + The configuration files are read from the files located in the + system network directory /usr/lib/systemd/network, + the volatile runtime network directory + /run/systemd/network and the local administration + network directory /etc/systemd/network. + + Networks are configured in .network + files, see + systemd.network5, + and virtual network devices are configured in + .netdev files, see + systemd.netdev5. + + + + + See Also + + networkctl1, + systemd1, + systemd.link5, + systemd.network5, + systemd.netdev5, + systemd-networkd-wait-online.service8, + systemd-network-generator.service8 + + + + diff --git a/man/systemd-notify.xml b/man/systemd-notify.xml new file mode 100644 index 0000000..1327d23 --- /dev/null +++ b/man/systemd-notify.xml @@ -0,0 +1,196 @@ + + + + + + + + systemd-notify + systemd + + + + systemd-notify + 1 + + + + systemd-notify + Notify service manager about start-up completion and other daemon status changes + + + + + systemd-notify OPTIONS VARIABLE=VALUE + + + + + Description + + systemd-notify may be called by daemon + scripts to notify the init system about status changes. It can be + used to send arbitrary information, encoded in an + environment-block-like list of strings. Most importantly, it can be + used for start-up completion notification. + + This is mostly just a wrapper around + sd_notify() and makes this functionality + available to shell scripts. For details see + sd_notify3. + + + The command line may carry a list of environment variables + to send as part of the status update. + + Note that systemd will refuse reception of status updates from this command unless + NotifyAccess= is set for the service unit this command is called from. + + Note that sd_notify() notifications may be attributed to units correctly only if either + the sending process is still around at the time PID 1 processes the message, or if the sending process is + explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally forked + off the process, i.e. on all processes that match NotifyAccess= or + NotifyAccess=. Conversely, if an auxiliary process of the unit sends an + sd_notify() message and immediately exits, the service manager might not be able to properly + attribute the message to the unit, and thus will ignore it, even if NotifyAccess= is set for it. When is used, all synchronization for reception of notifications + is disabled, and hence the aforementioned race may occur if the invoking process is not the service manager or spawned + by the service manager. + + Hence, systemd-notify will first attempt to invoke sd_notify() + pretending to have the PID of the invoking process. This will only succeed when invoked with sufficient privileges. + On failure, it will then fall back to invoking it under its own PID. This behaviour is useful in order that when + the tool is invoked from a shell script the shell process — and not the systemd-notify process + — appears as sender of the message, which in turn is helpful if the shell process is the main process of a service, + due to the limitations of NotifyAccess=. Use the + switch to tweak this behaviour. + + + + + Options + + The following options are understood: + + + + + + Inform the init system about service start-up + completion. This is equivalent to systemd-notify + READY=1. For details about the semantics of this + option see + sd_notify3. + + + + + + Inform the service manager about the main PID of the daemon. Takes a PID as + argument. If the argument is specified as auto or omitted, the PID of the process + that invoked systemd-notify is used, except if that's the service manager. If the + argument is specified as self, the PID of the systemd-notify + command itself is used, and if parent is specified the calling process' PID is + used — even if it is the service manager. This is equivalent to systemd-notify + MAINPID=$PID. For details about the semantics of this option see + sd_notify3. + + + + USER + + Set the user ID to send the notification from. Takes a UNIX user name or numeric UID. When + specified the notification message will be sent with the specified UID as sender, in place of the user the + command was invoked as. This option requires sufficient privileges in order to be able manipulate the user + identity of the process. + + + + + + Send a free-form status string for the daemon + to the init systemd. This option takes the status string as + argument. This is equivalent to systemd-notify + STATUS=…. For details about the semantics of this + option see + sd_notify3. + + + + + + Returns 0 if the system was booted up with + systemd, non-zero otherwise. If this option is passed, no + message is sent. This option is hence unrelated to the other + options. For details about the semantics of this option, see + sd_booted3. An + alternate way to check for this state is to call + systemctl1 + with the is-system-running command. It will + return offline if the system was not booted + with systemd. + + + + + + Do not synchronously wait for the requested operation to finish. Use of this option + is only recommended when systemd-notify is spawned by the service manager, or when + the invoking process is directly spawned by the service manager and has enough privileges to allow + systemd-notify to send the notification on its behalf. Sending notifications with + this option set is prone to race conditions in all other cases. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + Example + + + Start-up Notification and Status Updates + + A simple shell daemon that sends start-up notifications + after having set up its communication channel. During runtime it + sends further status updates to the init system: + + #!/bin/sh + +mkfifo /tmp/waldo +systemd-notify --ready --status="Waiting for data…" + +while : ; do + read -r a < /tmp/waldo + systemd-notify --status="Processing $a" + + # Do something with $a … + + systemd-notify --status="Waiting for data…" +done + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + sd_notify3, + sd_booted3 + + + + diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml new file mode 100644 index 0000000..fc471c3 --- /dev/null +++ b/man/systemd-nspawn.xml @@ -0,0 +1,1767 @@ + + +%entities; +]> + + + + + + systemd-nspawn + systemd + + + + systemd-nspawn + 1 + + + + systemd-nspawn + Spawn a command or OS in a light-weight container + + + + + systemd-nspawn + OPTIONS + COMMAND + ARGS + + + + systemd-nspawn + --boot + OPTIONS + ARGS + + + + + Description + + systemd-nspawn may be used to run a command or OS in a light-weight namespace + container. In many ways it is similar to chroot1, but more powerful + since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and + the host and domain name. + + systemd-nspawn may be invoked on any directory tree containing an operating system tree, + using the command line option. By using the option an OS + tree is automatically searched for in a couple of locations, most importantly in + /var/lib/machines/, the suggested directory to place OS container images installed on the + system. + + In contrast to chroot1 systemd-nspawn + may be used to boot full Linux-based operating systems in a container. + + systemd-nspawn limits access to various kernel interfaces in the container to read-only, + such as /sys/, /proc/sys/ or /sys/fs/selinux/. The + host's network interfaces and the system clock may not be changed from within the container. Device nodes may not + be created. The host system cannot be rebooted and kernel modules may not be loaded from within the + container. + + Use a tool like dnf8, debootstrap8, or + pacman8 to + set up an OS directory tree suitable as file system hierarchy for systemd-nspawn containers. See + the Examples section below for details on suitable invocation of these commands. + + As a safety check systemd-nspawn will verify the existence of + /usr/lib/os-release or /etc/os-release in the container tree before + booting a container (see + os-release5). It might be + necessary to add this file to the container tree manually if the OS of the container is too old to contain this + file out-of-the-box. + + systemd-nspawn may be invoked directly from the interactive command line or run as system + service in the background. In this mode each container instance runs as its own service instance; a default + template unit file systemd-nspawn@.service is provided to make this easy, taking the container + name as instance identifier. Note that different default options apply when systemd-nspawn is + invoked by the template unit file than interactively on the command line. Most importantly the template unit file + makes use of the option which is not the default in case systemd-nspawn + is invoked from the interactive command line. Further differences with the defaults are documented along with the + various supported options below. + + The machinectl1 tool may + be used to execute a number of operations on containers. In particular it provides easy-to-use commands to run + containers as system services using the systemd-nspawn@.service template unit + file. + + Along with each container a settings file with the .nspawn suffix may exist, containing + additional settings to apply when running the container. See + systemd.nspawn5 for + details. Settings files override the default options used by the systemd-nspawn@.service + template unit file, making it usually unnecessary to alter this template file directly. + + Note that systemd-nspawn will mount file systems private to the container to + /dev/, /run/ and similar. These will not be visible outside of the + container, and their contents will be lost when the container exits. + + Note that running two systemd-nspawn containers from the same directory tree will not make + processes in them see each other. The PID namespace separation of the two containers is complete and the containers + will share very few runtime objects except for the underlying file system. Rather use + machinectl1's + login or shell commands to request an additional login session in a running + container. + + systemd-nspawn implements the Container Interface specification. + + While running, containers invoked with systemd-nspawn are registered with the + systemd-machined8 service that + keeps track of running containers, and provides programming interfaces to interact with them. + + + + Options + + If option is specified, the arguments + are used as arguments for the init program. Otherwise, + COMMAND specifies the program to launch + in the container, and the remaining arguments are used as + arguments for this program. If is not used and + no arguments are specified, a shell is launched in the + container. + + The following options are understood: + + + + + + + + Turns off any status output by the tool + itself. When this switch is used, the only output from nspawn + will be the console output of the container OS + itself. + + + + MODE + + Controls whether + systemd-nspawn shall search for and use + additional per-container settings from + .nspawn files. Takes a boolean or the + special values or + . + + If enabled (the default), a settings file named after the + machine (as specified with the + setting, or derived from the directory or image file name) + with the suffix .nspawn is searched in + /etc/systemd/nspawn/ and + /run/systemd/nspawn/. If it is found + there, its settings are read and used. If it is not found + there, it is subsequently searched in the same directory as the + image file or in the immediate parent of the root directory of + the container. In this case, if the file is found, its settings + will be also read and used, but potentially unsafe settings + are ignored. Note that in both these cases, settings on the + command line take precedence over the corresponding settings + from loaded .nspawn files, if both are + specified. Unsafe settings are considered all settings that + elevate the container's privileges or grant access to + additional resources such as files or directories of the + host. For details about the format and contents of + .nspawn files, consult + systemd.nspawn5. + + If this option is set to , the + file is searched, read and used the same way, however, the order of + precedence is reversed: settings read from the + .nspawn file will take precedence over + the corresponding command line options, if both are + specified. + + If this option is set to , the + file is searched, read and used the same way, but regardless + of being found in /etc/systemd/nspawn/, + /run/systemd/nspawn/ or next to the image + file or container root directory, all settings will take + effect, however, command line arguments still take precedence + over corresponding settings. + + If disabled, no .nspawn file is read + and no settings except the ones on the command line are in + effect. + + + + + + Image Options + + + + + + + + Directory to use as file system root for the + container. + + If neither , nor + is specified the directory is + determined by searching for a directory named the same as the + machine name specified with . See + machinectl1 + section "Files and Directories" for the precise search path. + + If neither , + , nor + are specified, the current directory will + be used. May not be specified together with + . + + + + + + Directory or btrfs subvolume to use as template for the + container's root directory. If this is specified and the container's root directory (as configured by + ) does not yet exist it is created as btrfs snapshot + (if supported) or plain directory (otherwise) and populated from this template tree. Ideally, the + specified template path refers to the root of a btrfs subvolume, in which case a + simple copy-on-write snapshot is taken, and populating the root directory is instant. If the + specified template path does not refer to the root of a btrfs subvolume (or not + even to a btrfs file system at all), the tree is copied (though possibly in a + 'reflink' copy-on-write scheme — if the file system supports that), which can be substantially more + time-consuming. Note that the snapshot taken is of the specified directory or subvolume, including + all subdirectories and subvolumes below it, but excluding any sub-mounts. May not be specified + together with or . + + Note that this switch leaves hostname, machine ID and + all other settings that could identify the instance + unmodified. + + + + + + + If specified, the container is run with a temporary snapshot of its file system that is removed + immediately when the container terminates. May not be specified together with + . + Note that this switch leaves hostname, machine ID and all other settings that could identify + the instance unmodified. Please note that — as with — taking the + temporary snapshot is more efficient on file systems that support subvolume snapshots or 'reflinks' + natively (btrfs or new xfs) than on more traditional file + systems that do not (ext4). Note that the snapshot taken is of the specified + directory or subvolume, including all subdirectories and subvolumes below it, but excluding any + sub-mounts. + + With this option no modifications of the container image are retained. Use + (described below) for other mechanisms to restrict persistency of + container images during runtime. + + + + + + + + Disk image to mount the root directory for the + container from. Takes a path to a regular file or to a block + device node. The file or block device must contain + either: + + + An MBR partition table with a single + partition of type 0x83 that is marked + bootable. + + A GUID partition table (GPT) with a single + partition of type + 0fc63daf-8483-4772-8e79-3d69d8477de4. + + A GUID partition table (GPT) with a marked + root partition which is mounted as the root directory of the + container. Optionally, GPT images may contain a home and/or + a server data partition which are mounted to the appropriate + places in the container. All these partitions must be + identified by the partition types defined by the Discoverable + Partitions Specification. + + No partition table, and a single file system spanning the whole image. + + + On GPT images, if an EFI System Partition (ESP) is discovered, it is automatically mounted to + /efi (or /boot as fallback) in case a directory by this name exists + and is empty. + + Partitions encrypted with LUKS are automatically decrypted. Also, on GPT images dm-verity data integrity + hash partitions are set up if the root hash for them is specified using the + option. + + Single file system images (i.e. file systems without a surrounding partition table) can be opened using + dm-verity if the integrity data is passed using the and + (and optionally ) options. + + Any other partitions, such as foreign partitions or swap partitions are not mounted. May not be specified + together with , . + + + + + + Takes the path to an OCI runtime bundle to invoke, as specified in the OCI Runtime Specification. In + this case no .nspawn file is loaded, and the root directory and various settings are read + from the OCI runtime JSON data (but data passed on the command line takes precedence). + + + + + + Mount the container's root file system (and any other file systems container in the container + image) read-only. This has no effect on additional mounts made with , + and similar options. This mode is implied if the container image file or directory is + marked read-only itself. It is also implied if is used. In this case the container + image on disk is strictly read-only, while changes are permitted but kept non-persistently in memory only. For + further details, see below. + + + + + MODE + + Boots the container in volatile mode. When no mode parameter is passed or when mode is + specified as , full volatile mode is enabled. This means the root directory is mounted as a + mostly unpopulated tmpfs instance, and /usr/ from the OS tree is + mounted into it in read-only mode (the system thus starts up with read-only OS image, but pristine state and + configuration, any changes are lost on shutdown). When the mode parameter is specified as + , the OS tree is mounted read-only, but /var/ is mounted as a + writable tmpfs instance into it (the system thus starts up with read-only OS resources and + configuration, but pristine state, and any changes to the latter are lost on shutdown). When the mode parameter + is specified as the read-only root file system is combined with a writable + tmpfs instance through overlayfs, so that it appears at it normally + would, but any changes are applied to the temporary file system only and lost when the container is + terminated. When the mode parameter is specified as (the default), the whole OS tree is + made available writable (unless is specified, see above). + + Note that if one of the volatile modes is chosen, its effect is limited to the root file system + (or /var/ in case of ), and any other mounts placed in the + hierarchy are unaffected — regardless if they are established automatically (e.g. the EFI system + partition that might be mounted to /efi/ or /boot/) or + explicitly (e.g. through an additional command line option such as , see + below). This means, even if is used changes to + /efi/ or /boot/ are prohibited in case such a partition + exists in the container image operated on, and even if is used the + hypothetical file /etc/foobar is potentially writable if + if used to mount it from outside the read-only container + /etc/ directory. + + The option is closely related to this setting, and provides similar + behaviour by making a temporary, ephemeral copy of the whole OS image and executing that. For further details, + see above. + + The and options provide similar functionality, but + for specific sub-directories of the OS image only. For details, see below. + + This option provides similar functionality for containers as the systemd.volatile= + kernel command line switch provides for host systems. See + kernel-command-line7 for + details. + + Note that setting this option to or will only work + correctly with operating systems in the container that can boot up with only + /usr/ mounted, and are able to automatically populate /var/ + (and /etc/ in case of --volatile=yes). Specifically, this + means that operating systems that follow the historic split of /bin/ and + /lib/ (and related directories) from /usr/ (i.e. where the + former are not symlinks into the latter) are not supported by --volatile=yes as + container payload. The option does not require any particular preparations + in the OS, but do note that overlayfs behaviour differs from regular file systems + in a number of ways, and hence compatibility is limited. + + + + + + Takes a data integrity (dm-verity) root hash specified in hexadecimal. This option enables data + integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above). The + specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64 + formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but + the image file carries the user.verity.roothash extended file attribute (see xattr7), then the root + hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or + is not supported by the underlying file system), but a file with the .roothash suffix is + found next to the image file, bearing otherwise the same name (except if the image has the + .raw suffix, in which case the root hash file must not have it in its name), the root hash + is read from it and automatically used, also as formatted hexadecimal characters. + + Note that this configures the root hash for the root file system. Disk images may also contain + separate file systems for the /usr/ hierarchy, which may be Verity protected as + well. The root hash for this protection may be configured via the + user.verity.usrhash extended file attribute or via a .usrhash + file adjacent to the disk image, following the same format and logic as for the root hash for the + root file system described here. Note that there's currently no switch to configure the root hash for + the /usr/ from the command line. + + Also see the RootHash= option in + systemd.exec5. + + + + + + + Takes a PKCS7 signature of the option. + The semantics are the same as for the RootHashSignature= option, see + systemd.exec5. + + + + + + + Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks + using dm-verity, if a root-hash is passed and if the used image itself does not contains the integrity data. + The integrity data must be matched by the root hash. If this option is not specified, but a file with the + .verity suffix is found next to the image file, bearing otherwise the same name (except if + the image has the .raw suffix, in which case the verity data file must not have it in its name), + the verity data is read from it and automatically used. + + + + + + Pivot the specified directory to / inside the container, and either unmount the + container's old root, or pivot it to another specified directory. Takes one of: a path argument — in which case the + specified path will be pivoted to / and the old root will be unmounted; or a colon-separated pair + of new root path and pivot destination for the old root. The new root path will be pivoted to /, + and the old / will be pivoted to the other directory. Both paths must be absolute, and are resolved + in the container's file system namespace. + + This is for containers which have several bootable directories in them; for example, several + OSTree deployments. It emulates the + behavior of the boot loader and the initrd which normally select which directory to mount as the root + and start the container's PID 1 in. + + + + + Execution Options + + + + + + + Invoke the shell or specified program as process ID (PID) 2 instead of PID 1 (init). By + default, if neither this option nor is used, the selected program is run as the process + with PID 1, a mode only suitable for programs that are aware of the special semantics that the process with + PID 1 has on UNIX. For example, it needs to reap all processes reparented to it, and should implement + sysvinit compatible signal handling (specifically: it needs to reboot on SIGINT, reexecute + on SIGTERM, reload configuration on SIGHUP, and so on). With a minimal stub init + process is run as PID 1 and the selected program is executed as PID 2 (and hence does not need to implement any + special semantics). The stub init process will reap processes as necessary and react appropriately to + signals. It is recommended to use this mode to invoke arbitrary commands in containers, unless they have been + modified to run correctly as PID 1. Or in other words: this switch should be used for pretty much all commands, + except when the command refers to an init or shell implementation, as these are generally capable of running + correctly as PID 1. This option may not be combined with . + + + + + + + + Automatically search for an init program and invoke it as PID 1, instead of a shell or a user + supplied program. If this option is used, arguments specified on the command line are used as arguments for the + init program. This option may not be combined with . + + The following table explains the different modes of invocation and relationship to + (see above): + + + Invocation Mode + + + + + + Switch + Explanation + + + + + Neither nor specified + The passed parameters are interpreted as the command line, which is executed as PID 1 in the container. + + + + specified + The passed parameters are interpreted as the command line, which is executed as PID 2 in the container. A stub init process is run as PID 1. + + + + specified + An init program is automatically searched for and run as PID 1 in the container. The passed parameters are used as invocation parameters for this process. + + + + +
+ + Note that is the default mode of operation if the + systemd-nspawn@.service template unit file is used. + + + + + + + Change to the specified working directory before invoking the process in the container. Expects + an absolute path in the container's file system namespace. + + + + + + + Specifies an environment variable to pass to the init process in the container. This + may be used to override the default variables or to set additional variables. It may be used more + than once to set multiple variables. When = and VALUE + are omitted, the value of the variable with the same name in the program environment will be used. + + + + + + + + After transitioning into the container, change to the specified user defined in the + container's user database. Like all other systemd-nspawn features, this is not a security feature and + provides protection against accidental destructive operations only. + + + + + + Specify the process signal to send to the container's PID 1 when nspawn itself receives + SIGTERM, in order to trigger an orderly shutdown of the container. Defaults to + SIGRTMIN+3 if is used (on systemd-compatible init systems + SIGRTMIN+3 triggers an orderly shutdown). If is not used and this + option is not specified the container's processes are terminated abruptly via SIGKILL. For + a list of valid signals, see signal7. + + + + + + Configures support for notifications from the container's init process. + takes a boolean ( and ). + With option systemd-nspawn notifies systemd + with a READY=1 message when the init process is created. + With option systemd-nspawn waits for the + READY=1 message from the init process in the container + before sending its own to systemd. For more details about notifications + see sd_notify3. + + + + + + Expects a boolean argument. If true, turns off any form of on-disk file system + synchronization for the container payload. This means all system calls such as sync2, + fsync(), syncfs(), … will execute no operation, and the + O_SYNC/O_DSYNC flags to open2 and + related calls will be made unavailable. This is potentially dangerous, as assumed data integrity + guarantees to the container payload are not actually enforced (i.e. data assumed to have been written + to disk might be lost if the system is shut down abnormally). However, this can dramatically improve + container runtime performance – as long as these guarantees are not required or desirable, for + example because any data written by the container is of temporary, redundant nature, or just an + intermediary artifact that will be further processed and finalized by a later step in a + pipeline. Defaults to false. + + + + + System Identity Options + + + + + + + Sets the machine name for this container. This + name may be used to identify this container during its runtime + (for example in tools like + machinectl1 + and similar), and is used to initialize the container's + hostname (which the container can choose to override, + however). If not specified, the last component of the root + directory path of the container is used, possibly suffixed + with a random identifier in case + mode is selected. If the root directory selected is the host's + root directory the host's hostname is used as default + instead. + + + + + + Controls the hostname to set within the container, if different from the machine name. Expects + a valid hostname as argument. If this option is used, the kernel hostname of the container will be set to this + value, otherwise it will be initialized to the machine name as controlled by the + option described above. The machine name is used for various aspect of identification of the container from the + outside, the kernel hostname configurable with this option is useful for the container to identify itself from + the inside. It is usually a good idea to keep both forms of identification synchronized, in order to avoid + confusion. It is hence recommended to avoid usage of this option, and use + exclusively. Note that regardless whether the container's hostname is initialized from the name set with + or the one set with , the container can later override + its kernel hostname freely on its own as well. + + + + + + + Set the specified UUID for the container. The + init system will initialize + /etc/machine-id from this if this file is + not set yet. Note that this option takes effect only if + /etc/machine-id in the container is + unpopulated. + + + + + Property Options + + + + + + + Make the container part of the specified slice, instead of the default + machine.slice. This applies only if the machine is run in its own scope unit, i.e. if + isn't used. + + + + + + + Set a unit property on the scope unit to register for the machine. This applies only if the + machine is run in its own scope unit, i.e. if isn't used. Takes unit property + assignments in the same format as systemctl set-property. This is useful to set memory + limits and similar for the container. + + + + + + + Controls whether the container is registered with + systemd-machined8. Takes a + boolean argument, which defaults to yes. This option should be enabled when the container + runs a full Operating System (more specifically: a system and service manager as PID 1), and is useful to + ensure that the container is accessible via + machinectl1 and shown by + tools such as ps1. If the container + does not run a service manager, it is recommended to set this option to + no. + + + + + + Instead of creating a transient scope unit to run the container in, simply use the service or + scope unit systemd-nspawn has been invoked in. If is set + this unit is registered with + systemd-machined8. This + switch should be used if systemd-nspawn is invoked from within a service unit, and the + service unit's sole purpose is to run a single systemd-nspawn container. This option is not + available if run from a user session. + Note that passing disables the effect of and + . Use and in + combination to disable any kind of unit allocation or registration with + systemd-machined. + + + + + User Namespacing Options + + + + + + Controls user namespacing. If enabled, the container will run with its own private set of UNIX + user and group ids (UIDs and GIDs). This involves mapping the private UIDs/GIDs used in the container (starting + with the container's root user 0 and up) to a range of UIDs/GIDs on the host that are not used for other + purposes (usually in the range beyond the host's UID/GID 65536). The parameter may be specified as follows: + + + If one or two colon-separated numbers are specified, user namespacing is turned on. The first + parameter specifies the first host UID/GID to assign to the container, the second parameter specifies the + number of host UIDs/GIDs to assign to the container. If the second parameter is omitted, 65536 UIDs/GIDs are + assigned. + + If the parameter is yes, user namespacing is turned on. The + UID/GID range to use is determined automatically from the file ownership of the root directory of + the container's directory tree. To use this option, make sure to prepare the directory tree in + advance, and ensure that all files and directories in it are owned by UIDs/GIDs in the range you'd + like to use. Also, make sure that used file ACLs exclusively reference UIDs/GIDs in the appropriate + range. In this mode, the number of UIDs/GIDs assigned to the container is 65536, and the owner + UID/GID of the root directory must be a multiple of 65536. + + If the parameter is no, user namespacing is turned off. This is + the default. + + + If the parameter is identity, user namespacing is employed with + an identity mapping for the first 65536 UIDs/GIDs. This is mostly equivalent to + . While it does not provide UID/GID isolation, since all + host and container UIDs/GIDs are chosen identically it does provide process capability isolation, + and hence is often a good choice if proper user namespacing with distinct UID maps is not + appropriate. + + The special value pick turns on user namespacing. In this case + the UID/GID range is automatically chosen. As first step, the file owner UID/GID of the root + directory of the container's directory tree is read, and it is checked that no other container is + currently using it. If this check is successful, the UID/GID range determined this way is used, + similarly to the behavior if yes is specified. If the check is not successful + (and thus the UID/GID range indicated in the root directory's file owner is already used elsewhere) + a new – currently unused – UID/GID range of 65536 UIDs/GIDs is randomly chosen between the host + UID/GIDs of 524288 and 1878982656, always starting at a multiple of 65536, and, if possible, + consistently hashed from the machine name. This setting implies + (see below), which possibly has the effect that the + files and directories in the container's directory tree will be owned by the appropriate users of + the range picked. Using this option makes user namespace behavior fully automatic. Note that the + first invocation of a previously unused container image might result in picking a new UID/GID range + for it, and thus in the (possibly expensive) file ownership adjustment operation. However, + subsequent invocations of the container will be cheap (unless of course the picked UID/GID range is + assigned to a different use by then). + + + It is recommended to assign at least 65536 UIDs/GIDs to each container, so that the usable UID/GID range in the + container covers 16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is + hence a good idea to use the upper 16 bit of the host 32-bit UIDs/GIDs as container identifier, while the lower 16 + bit encode the container UID/GID used. This is in fact the behavior enforced by the + option. + + When user namespaces are used, the GID range assigned to each container is always chosen identical to the + UID range. + + In most cases, using is the recommended option as it enhances + container security massively and operates fully automatically in most cases. + + Note that the picked UID/GID range is not written to /etc/passwd or + /etc/group. In fact, the allocation of the range is not stored persistently anywhere, + except in the file ownership of the files and directories of the container. + + Note that when user namespacing is used file ownership on disk reflects this, and all of the container's + files and directories are owned by the container's effective user and group IDs. This means that copying files + from and to the container image requires correction of the numeric UID/GID values, according to the UID/GID + shift applied. + + + + + + Controls how to adjust the container image's UIDs and GIDs to match the UID/GID range + chosen with , see above. Takes one of off (to + leave the image as is), chown (to recursively chown() the + container's directory tree as needed), map (in order to use transparent ID mapping + mounts) or auto for automatically using map where available and + chown where not. + + If chown is selected, all files and directories in the container's directory + tree will be adjusted so that they are owned by the appropriate UIDs/GIDs selected for the container + (see above). This operation is potentially expensive, as it involves iterating through the full + directory tree of the container. Besides actual file ownership, file ACLs are adjusted as + well. + + Typically map is the best choice, since it transparently maps UIDs/GIDs in + memory as needed without modifying the image, and without requiring an expensive recursive adjustment + operation. However, it is not available for all file systems, currently. + + The option is implied if + is used. This option has no effect if user namespacing is not + used. + + + + + + If the kernel supports the user namespaces feature, equivalent to + , otherwise equivalent to + . + + Note that is the default if the + systemd-nspawn@.service template unit file is used. + + Note: it is possible to undo the effect of (or + ) on the file system by redoing the operation with the first UID of 0: + + systemd-nspawn … --private-users=0 --private-users-ownership=chown + + + + + + + Networking Options + + + + + + + Disconnect networking of the container from + the host. This makes all network interfaces unavailable in the + container, with the exception of the loopback device and those + specified with and + configured with . If this + option is specified, the CAP_NET_ADMIN capability will be + added to the set of capabilities the container retains. The + latter may be disabled by using . + If this option is not specified (or implied by one of the options + listed below), the container will have full access to the host network. + + + + + + + Assign the specified network interface to the container. This will remove the + specified interface from the calling namespace and place it in the container. When the container + terminates, it is moved back to the calling namespace. Note that + implies . This option may be + used more than once to add multiple network interfaces to the container. + + Note that any network interface specified this way must already exist at the time the container + is started. If the container shall be started automatically at boot via a + systemd-nspawn@.service unit file instance, it might hence make sense to add a + unit file drop-in to the service instance + (e.g. /etc/systemd/system/systemd-nspawn@foobar.service.d/50-network.conf) with + contents like the following: + + [Unit] +Wants=sys-subsystem-net-devices-ens1.device +After=sys-subsystem-net-devices-ens1.device + + This will make sure that activation of the container service will be delayed until the + ens1 network interface has shown up. This is required since hardware probing is + fully asynchronous, and network interfaces might be discovered only later during the boot process, + after the container would normally be started without these explicit dependencies. + + + + + + + Create a macvlan interface of the specified Ethernet network + interface and add it to the container. A macvlan interface is a virtual interface + that adds a second MAC address to an existing physical Ethernet link. The interface in the container + will be named after the interface on the host, prefixed with mv-. Note that + implies . This option may be + used more than once to add multiple network interfaces to the container. + + As with , the underlying Ethernet network interface must + already exist at the time the container is started, and thus similar unit file drop-ins as described + above might be useful. + + + + + + Create an ipvlan interface of the specified Ethernet network + interface and add it to the container. An ipvlan interface is a virtual interface, + similar to a macvlan interface, which uses the same MAC address as the underlying + interface. The interface in the container will be named after the interface on the host, prefixed + with iv-. Note that implies + . This option may be used more than once to add multiple network + interfaces to the container. + + As with , the underlying Ethernet network interface must + already exist at the time the container is started, and thus similar unit file drop-ins as described + above might be useful. + + + + + + + Create a virtual Ethernet link (veth) between host and container. The host + side of the Ethernet link will be available as a network interface named after the container's name (as + specified with ), prefixed with ve-. The container side of the + Ethernet link will be named host0. The option implies + . + + Note that + systemd-networkd.service8 + includes by default a network file /usr/lib/systemd/network/80-container-ve.network + matching the host-side interfaces created this way, which contains settings to enable automatic address + provisioning on the created virtual link via DHCP, as well as automatic IP routing onto the host's external + network interfaces. It also contains /usr/lib/systemd/network/80-container-host0.network + matching the container-side interface created this way, containing settings to enable client side address + assignment via DHCP. In case systemd-networkd is running on both the host and inside the + container, automatic IP communication from the container to the host is thus available, with further + connectivity to the external network. + + Note that is the default if the + systemd-nspawn@.service template unit file is used. + + Note that on Linux network interface names may have a length of 15 characters at maximum, while + container names may have a length up to 64 characters. As this option derives the host-side interface + name from the container name the name is possibly truncated. Thus, care needs to be taken to ensure + that interface names remain unique in this case, or even better container names are generally not + chosen longer than 12 characters, to avoid the truncation. If the name is truncated, + systemd-nspawn will automatically append a 4-digit hash value to the name to + reduce the chance of collisions. However, the hash algorithm is not collision-free. (See + systemd.net-naming-scheme7 + for details on older naming algorithms for this interface). Alternatively, the + option may be used, which allows free configuration of the + host-side interface name independently of the container name — but might require a bit more + additional configuration in case bridging in a fashion similar to + is desired. + + + + + + + Adds an additional virtual Ethernet link + between host and container. Takes a colon-separated pair of + host interface name and container interface name. The latter + may be omitted in which case the container and host sides will + be assigned the same name. This switch is independent of + , and — in contrast — may be + used multiple times, and allows configuration of the network + interface names. Note that + has no effect on interfaces created with + . + + + + + + Adds the host side of the Ethernet link created with + to the specified Ethernet bridge interface. Expects a valid network interface name of a bridge device + as argument. Note that implies . If + this option is used, the host side of the Ethernet link will use the vb- prefix + instead of ve-. Regardless of the used naming prefix the same network interface + name length limits imposed by Linux apply, along with the complications this creates (for details see + above). + + As with , the underlying bridge network interface must + already exist at the time the container is started, and thus similar unit file drop-ins as described + above might be useful. + + + + + + Creates a virtual Ethernet link (veth) to the container and adds it to an + automatically managed Ethernet bridge interface. The bridge interface is named after the passed argument, + prefixed with vz-. The bridge interface is automatically created when the first container + configured for its name is started, and is automatically removed when the last container configured for its + name exits. Hence, each bridge interface configured this way exists only as long as there's at least one + container referencing it running. This option is very similar to , besides + this automatic creation/removal of the bridge device. + + This setting makes it easy to place multiple related containers on a common, virtual Ethernet-based + broadcast domain, here called a "zone". Each container may only be part of one zone, but each zone may contain + any number of containers. Each zone is referenced by its name. Names may be chosen freely (as long as they form + valid network interface names when prefixed with vz-), and it is sufficient to pass the same + name to the switch of the various concurrently running containers to join + them in one zone. + + Note that + systemd-networkd.service8 + includes by default a network file /usr/lib/systemd/network/80-container-vz.network + matching the bridge interfaces created this way, which contains settings to enable automatic address + provisioning on the created virtual network via DHCP, as well as automatic IP routing onto the host's external + network interfaces. Using is hence in most cases fully automatic and + sufficient to connect multiple local containers in a joined broadcast domain to the host, with further + connectivity to the external network. + + + + + + + Takes the path to a file representing a kernel + network namespace that the container shall run in. The specified path + should refer to a (possibly bind-mounted) network namespace file, as + exposed by the kernel below /proc/$PID/ns/net. + This makes the container enter the given network namespace. One of the + typical use cases is to give a network namespace under + /run/netns created by ip-netns8, + for example, . + Note that this option cannot be used together with other + network-related options, such as + or . + + + + + + + If private networking is enabled, maps an IP + port on the host onto an IP port on the container. Takes a + protocol specifier (either tcp or + udp), separated by a colon from a host port + number in the range 1 to 65535, separated by a colon from a + container port number in the range from 1 to 65535. The + protocol specifier and its separating colon may be omitted, in + which case tcp is assumed. The container + port number and its colon may be omitted, in which case the + same port as the host port is implied. This option is only + supported if private networking is used, such as with + , + . + + + + + Security Options + + + + + + List one or more additional capabilities to grant the container. Takes a + comma-separated list of capability names, see capabilities7 + for more information. Note that the following capabilities will be granted in any way: + CAP_AUDIT_CONTROL, CAP_AUDIT_WRITE, + CAP_CHOWN, CAP_DAC_OVERRIDE, + CAP_DAC_READ_SEARCH, CAP_FOWNER, + CAP_FSETID, CAP_IPC_OWNER, CAP_KILL, + CAP_LEASE, CAP_LINUX_IMMUTABLE, + CAP_MKNOD, CAP_NET_BIND_SERVICE, + CAP_NET_BROADCAST, CAP_NET_RAW, + CAP_SETFCAP, CAP_SETGID, CAP_SETPCAP, + CAP_SETUID, CAP_SYS_ADMIN, + CAP_SYS_BOOT, CAP_SYS_CHROOT, + CAP_SYS_NICE, CAP_SYS_PTRACE, + CAP_SYS_RESOURCE, CAP_SYS_TTY_CONFIG. Also + CAP_NET_ADMIN is retained if is specified. + If the special value all is passed, all capabilities are retained. + + If the special value of help is passed, the program will print known + capability names and exit. + + This option sets the bounding set of capabilities which + also limits the ambient capabilities as given with the + . + + + + + + Specify one or more additional capabilities to + drop for the container. This allows running the container with + fewer capabilities than the default (see + above). + + If the special value of help is passed, the program will print known + capability names and exit. + + This option sets the bounding set of capabilities which + also limits the ambient capabilities as given with the + . + + + + + + Specify one or more additional capabilities to + pass in the inheritable and ambient set to the program started + within the container. The value all is not + supported for this setting. + + All capabilities specified here must be in the set + allowed with the and + options. Otherwise, an + error message will be shown. + + This option cannot be combined with the boot mode of the + container (as requested via ). + + If the special value of help is + passed, the program will print known capability names and + exit. + + + + + + Takes a boolean argument. Specifies the value of the + PR_SET_NO_NEW_PRIVS flag for the container payload. Defaults to off. When turned + on the payload code of the container cannot acquire new privileges, i.e. the "setuid" file bit as + well as file system capabilities will not have an effect anymore. See prctl2 for + details about this flag. + + + + Alter the system call filter + applied to containers. Takes a space-separated list of system call names or group names (the latter + prefixed with @, as listed by the syscall-filter command of + systemd-analyze1). Passed + system calls will be permitted. The list may optionally be prefixed by ~, in which + case all listed system calls are prohibited. If this command line option is used multiple times the + configured lists are combined. If both a positive and a negative list (that is one system call list + without and one with the ~ prefix) are configured, the negative list takes + precedence over the positive list. Note that systemd-nspawn always implements a + system call allow list (as opposed to a deny list!), and this command line option hence adds or + removes entries from the default allow list, depending on the ~ prefix. Note that + the applied system call filter is also altered implicitly if additional capabilities are passed using + the --capabilities=. + + + + + + + Sets the SELinux security context to be used + to label processes in the container. + + + + + + + + Sets the SELinux security context to be used + to label files in the virtual API file systems in the + container. + + + + + + Resource Options + + + + + + + Sets the specified POSIX resource limit for the container payload. Expects an assignment of the + form + LIMIT=SOFT:HARD + or LIMIT=VALUE, where + LIMIT should refer to a resource limit type, such as + RLIMIT_NOFILE or RLIMIT_NICE. The SOFT and + HARD fields should refer to the numeric soft and hard resource limit values. If the + second form is used, VALUE may specify a value that is used both as soft and hard + limit. In place of a numeric value the special string infinity may be used to turn off + resource limiting for the specific type of resource. This command line option may be used multiple times to + control limits on multiple limit types. If used multiple times for the same limit type, the last use + wins. For details about resource limits see setrlimit2. By default + resource limits for the container's init process (PID 1) are set to the same values the Linux kernel originally + passed to the host init system. Note that some resource limits are enforced on resources counted per user, in + particular RLIMIT_NPROC. This means that unless user namespacing is deployed + (i.e. is used, see above), any limits set will be applied to the resource + usage of the same user on all local containers as well as the host. This means particular care needs to be + taken with these limits as they might be triggered by possibly less trusted code. Example: + --rlimit=RLIMIT_NOFILE=8192:16384. + + + + + + Changes the OOM ("Out Of Memory") score adjustment value for the container payload. This controls + /proc/self/oom_score_adj which influences the preference with which this container is + terminated when memory becomes scarce. For details see proc5. Takes an + integer in the range -1000…1000. + + + + + + Controls the CPU affinity of the container payload. Takes a comma separated list of CPU numbers + or number ranges (the latter's start and end value separated by dashes). See sched_setaffinity2 for + details. + + + + + + Control the architecture ("personality") + reported by + uname2 + in the container. Currently, only x86 and + x86-64 are supported. This is useful when + running a 32-bit container on a 64-bit host. If this setting + is not used, the personality reported in the container is the + same as the one reported on the host. + + + + + Integration Options + + + + + + Configures how /etc/resolv.conf inside of the container shall be + handled (i.e. DNS configuration synchronization from host to container). Takes one of + off, copy-host, copy-static, + copy-uplink, copy-stub, replace-host, + replace-static, replace-uplink, + replace-stub, bind-host, bind-static, + bind-uplink, bind-stub, delete or + auto. + + If set to off the /etc/resolv.conf file in the + container is left as it is included in the image, and neither modified nor bind mounted over. + + If set to copy-host, the /etc/resolv.conf file from the + host is copied into the container, unless the file exists already and is not a regular file (e.g. a + symlink). Similarly, if replace-host is used the file is copied, replacing any + existing inode, including symlinks. Similarly, if bind-host is used, the file is + bind mounted from the host into the container. + + If set to copy-static, replace-static or + bind-static the static resolv.conf file supplied with + systemd-resolved.service8 + (specifically: /usr/lib/systemd/resolv.conf) is copied or bind mounted into the + container. + + If set to copy-uplink, replace-uplink or + bind-uplink the uplink resolv.conf file managed by + systemd-resolved.service (specifically: + /run/systemd/resolve/resolv.conf) is copied or bind mounted into the + container. + + If set to copy-stub, replace-stub or + bind-stub the stub resolv.conf file managed by + systemd-resolved.service (specifically: + /run/systemd/resolve/stub-resolv.conf) is copied or bind mounted into the + container. + + If set to delete the /etc/resolv.conf file in the + container is deleted if it exists. + + Finally, if set to auto the file is left as it is if private networking is + turned on (see ). Otherwise, if + systemd-resolved.service is running its stub resolv.conf + file is used, and if not the host's /etc/resolv.conf file. In the latter cases + the file is copied if the image is writable, and bind mounted otherwise. + + It's recommended to use copy-… or replace-… if the + container shall be able to make changes to the DNS configuration on its own, deviating from the + host's settings. Otherwise bind is preferable, as it means direct changes to + /etc/resolv.conf in the container are not allowed, as it is a read-only bind + mount (but note that if the container has enough privileges, it might simply go ahead and unmount the + bind mount anyway). Note that both if the file is bind mounted and if it is copied no further + propagation of configuration is generally done after the one-time early initialization (this is + because the file is usually updated through copying and renaming). Defaults to + auto. + + + + + + Configures how /etc/localtime inside of the container + (i.e. local timezone synchronization from host to container) shall be handled. Takes one of + off, copy, bind, symlink, + delete or auto. If set to off the + /etc/localtime file in the container is left as it is included in the image, and + neither modified nor bind mounted over. If set to copy the + /etc/localtime file of the host is copied into the container. Similarly, if + bind is used, the file is bind mounted from the host into the container. If set to + symlink, a symlink is created pointing from /etc/localtime in + the container to the timezone file in the container that matches the timezone setting on the host. If + set to delete, the file in the container is deleted, should it exist. If set to + auto and the /etc/localtime file of the host is a symlink, + then symlink mode is used, and copy otherwise, except if the + image is read-only in which case bind is used instead. Defaults to + auto. + + + + + + Control whether the container's journal shall + be made visible to the host system. If enabled, allows viewing + the container's journal files from the host (but not vice + versa). Takes one of no, + host, try-host, + guest, try-guest, + auto. If no, the journal + is not linked. If host, the journal files + are stored on the host file system (beneath + /var/log/journal/machine-id) + and the subdirectory is bind-mounted into the container at the + same location. If guest, the journal files + are stored on the guest file system (beneath + /var/log/journal/machine-id) + and the subdirectory is symlinked into the host at the same + location. try-host and + try-guest do the same but do not fail if + the host does not have persistent journaling enabled. If + auto (the default), and the right + subdirectory of /var/log/journal exists, + it will be bind mounted into the container. If the + subdirectory does not exist, no linking is performed. + Effectively, booting a container once with + guest or host will link + the journal persistently if further on the default of + auto is used. + + Note that is the default if the + systemd-nspawn@.service template unit file is used. + + + + + + Equivalent to + . + + + + + + Mount Options + + + + + + + + Bind mount a file or directory from the host into the container. Takes one of: a path + argument — in which case the specified path will be mounted from the host to the same path in the container, or + a colon-separated pair of paths — in which case the first specified path is the source in the host, and the + second path is the destination in the container, or a colon-separated triple of source path, destination path + and mount options. The source path may optionally be prefixed with a + character. If so, the + source path is taken relative to the image's root directory. This permits setting up bind mounts within the + container image. The source path may be specified as empty string, in which case a temporary directory below + the host's /var/tmp/ directory is used. It is automatically removed when the container is + shut down. If the source path is not absolute, it is resolved relative to the current working directory. + The option creates read-only bind mounts. Backslash escapes are interpreted, + so \: may be used to embed colons in either path. This option may be specified + multiple times for creating multiple independent bind mount points. + + Mount options are comma-separated. and control whether + to create a recursive or a regular bind mount. Defaults to "rbind". , + , and control ID mapping. + + Using or requires support by the source filesystem + for user/group ID mapped mounts. Defaults to "noidmap". With being the container's UID range + offset, being the length of the container's UID range, and being the + owner UID of the bind mount source inode on the host: + + + If is used, any user in the range + seen from inside of the container is mapped to in the + range on the host. All host users outside of that range are mapped to + inside the container. + If is used, any user in the UID range + as seen from inside the container is mapped to the same + in the same range on the host. All host users outside of that range are + mapped to inside the container. + If is used, the user seen from inside + of the container is mapped to on the host. All host users outside of that range + are mapped to inside the container. + + + Whichever ID mapping option is used, the same mapping will be used for users and groups IDs. If + is used, the group owning the bind mounted directory will have no effect + + Note that when this option is used in combination with , the resulting + mount points will be owned by the nobody user. That's because the mount and its files and + directories continue to be owned by the relevant host users and groups, which do not exist in the container, + and thus show up under the wildcard UID 65534 (nobody). If such bind mounts are created, it is recommended to + make them read-only, using . Alternatively you can use the "idmap" mount option to + map the filesystem IDs. + + + + + + Binds the home directory of the specified user on the host into the container. Takes + the name of an existing user on the host as argument. May be used multiple times to bind multiple + users into the container. This does three things: + + + The user's home directory is bind mounted from the host into + /run/host/home/. + + An additional UID/GID mapping is added that maps the host user's UID/GID to a + container UID/GID, allocated from the 60514…60577 range. + + A JSON user and group record is generated in /run/userdb/ that + describes the mapped user. It contains a minimized representation of the host's user record, + adjusted to the UID/GID and home directory path assigned to the user in the container. The + nss-systemd8 + glibc NSS module will pick up these records from there and make them available in the container's + user/group databases. + + + The combination of the three operations above ensures that it is possible to log into the + container using the same account information as on the host. The user is only mapped transiently, + while the container is running, and the mapping itself does not result in persistent changes to the + container (except maybe for log messages generated at login time, and similar). Note that in + particular the UID/GID assignment in the container is not made persistently. If the user is mapped + transiently, it is best to not allow the user to make persistent changes to the container. If the + user leaves files or directories owned by the user, and those UIDs/GIDs are reused during later + container invocations (possibly with a different mapping), those files + and directories will be accessible to the "new" user. + + The user/group record mapping only works if the container contains systemd 249 or newer, with + nss-systemd properly configured in nsswitch.conf. See + nss-systemd8 for + details. + + Note that the user record propagated from the host into the container will contain the UNIX + password hash of the user, so that seamless logins in the container are possible. If the container is + less trusted than the host it's hence important to use a strong UNIX password hash function + (e.g. yescrypt or similar, with the $y$ hash prefix). + + When binding a user from the host into the container checks are executed to ensure that the + username is not yet known in the container. Moreover, it is checked that the UID/GID allocated for it + is not currently defined in the user/group databases of the container. Both checks directly access + the container's /etc/passwd and /etc/group, and thus might + not detect existing accounts in other databases. + + This operation is only supported in combination with + /. + + + + + + Make the specified path inaccessible in the container. This over-mounts the specified path + (which must exist in the container) with a file node of the same type that is empty and has the most + restrictive access mode supported. This is an effective way to mask files, directories and other file system + objects from the container payload. This option may be used more than once in case all specified paths are + masked. + + + + + + Mount a tmpfs file system into the container. Takes a single absolute path argument that + specifies where to mount the tmpfs instance to (in which case the directory access mode will be chosen as 0755, + owned by root/root), or optionally a colon-separated pair of path and mount option string that is used for + mounting (in which case the kernel default for access mode and owner will be chosen, unless otherwise + specified). Backslash escapes are interpreted in the path, so \: may be used to embed colons + in the path. + + Note that this option cannot be used to replace the root file system of the container with a temporary + file system. However, the option described below provides similar + functionality, with a focus on implementing stateless operating system images. + + + + + + + Combine multiple directory trees into one overlay file system and mount it into the + container. Takes a list of colon-separated paths to the directory trees to combine and the + destination mount point. + + Backslash escapes are interpreted in the paths, so \: may be used to embed + colons in the paths. + + If three or more paths are specified, then the last specified path is the destination mount + point in the container, all paths specified before refer to directory trees on the host and are + combined in the specified order into one overlay file system. The left-most path is hence the lowest + directory tree, the second-to-last path the highest directory tree in the stacking order. If + is used instead of , a read-only overlay + file system is created. If a writable overlay file system is created, all changes made to it are + written to the highest directory tree in the stacking order, i.e. the second-to-last specified. + + + If only two paths are specified, then the second specified path is used both as the top-level + directory tree in the stacking order as seen from the host, as well as the mount point for the + overlay file system in the container. At least two paths have to be specified. + + The source paths may optionally be prefixed with + character. If so they are + taken relative to the image's root directory. The uppermost source path may also be specified as an + empty string, in which case a temporary directory below the host's /var/tmp/ is + used. The directory is removed automatically when the container is shut down. This behaviour is + useful in order to make read-only container directories writable while the container is running. For + example, use --overlay=+/var::/var in order to automatically overlay a writable + temporary directory on a read-only /var/ directory. If a source path is not + absolute, it is resolved relative to the current working directory. + + For details about overlay file systems, see Overlay Filesystem. + Note that the semantics of overlay file systems are substantially different from normal file systems, + in particular regarding reported device and inode information. Device and inode information may + change for a file while it is being written to, and processes might see out-of-date versions of files + at times. Note that this switch automatically derives the workdir= mount option + for the overlay file system from the top-level directory tree, making it a sibling of it. It is hence + essential that the top-level directory tree is not a mount point itself (since the working directory + must be on the same file system as the top-most directory tree). Also note that the + lowerdir= mount option receives the paths to stack in the opposite order of this + switch. + + Note that this option cannot be used to replace the root file system of the container with an overlay + file system. However, the option described above provides similar functionality, + with a focus on implementing stateless operating system images. + + + + + + Input/Output Options + + + + MODE + + Configures how to set up standard input, output and error output for the container + payload, as well as the /dev/console device for the container. Takes one of + , , , + or . If , a pseudo-TTY is + allocated and made available as /dev/console in the container. It is then + bi-directionally connected to the standard input and output passed to + systemd-nspawn. is similar but only the output of the + container is propagated and no input from the caller is read. If , a pseudo + TTY is allocated, but it is not connected anywhere. In mode no pseudo TTY is + allocated, but the standard input, output and error output file descriptors passed to + systemd-nspawn are passed on — as they are — to the container payload, see the + following paragraph. Finally, mode operates like + when systemd-nspawn is invoked on a terminal, and + like otherwise. Defaults to if + systemd-nspawn is invoked from a terminal, and + otherwise. + + In mode, /dev/console will not exist in the + container. This means that the container payload generally cannot be a full init system as init + systems tend to require /dev/console to be available. On the other hand, in this + mode container invocations can be used within shell pipelines. This is because intermediary pseudo + TTYs do not permit independent bidirectional propagation of the end-of-file (EOF) condition, which is + necessary for shell pipelines to work correctly. Note that the mode + should be used carefully, as passing arbitrary file descriptors to less trusted container + payloads might open up unwanted interfaces for access by the container payload. For example, if a + passed file descriptor refers to a TTY of some form, APIs such as TIOCSTI may be + used to synthesize input that might be used for escaping the container. Hence + mode should only be used if the payload is sufficiently trusted or when the standard + input/output/error output file descriptors are known safe, for example pipes. + + + + + + + Equivalent to . + + + + + + Credentials + + + + ID:PATH + ID:VALUE + + Pass a credential to the container. These two options correspond to the + LoadCredential= and SetCredential= settings in unit files. See + systemd.exec5 for + details about these concepts, as well as the syntax of the option's arguments. + + Note: when systemd-nspawn runs as systemd system service it can propagate + the credentials it received via LoadCredential=/SetCredential= + to the container payload. A systemd service manager running as PID 1 in the container can further + propagate them to the services it itself starts. It is thus possible to easily propagate credentials + from a parent service manager to a container manager service and from there into its payload. This + can even be done recursively. + + In order to embed binary data into the credential data for , + use C-style escaping (i.e. \n to embed a newline, or \x00 to + embed a NUL byte). Note that the invoking shell might already apply unescaping + once, hence this might require double escaping!. + + The + systemd-sysusers.service8 + and + systemd-firstboot1 + services read credentials configured this way for the purpose of configuring the container's root + user's password and shell, as well as system locale, keymap and timezone during the first boot + process of the container. This is particularly useful in combination with + where every single boot appears as first boot, since configuration + applied to /etc/ is lost on container reboot cycles. See the respective man + pages for details. Example: + + # systemd-nspawn -i image.raw \ + --volatile=yes \ + --set-credential=firstboot.locale:de_DE.UTF-8 \ + --set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' \ + -b + + The above command line will invoke the specified image file image.raw in + volatile mode, i.e. with empty /etc/ and /var/. The + container payload will recognize this as a first boot, and will invoke + systemd-firstboot.service, which then reads the two passed credentials to + configure the system's initial locale and root password. + + + + + + Other + + + + + + + + + + + + + Examples + + + Download a + <ulink url="https://getfedora.org">Fedora</ulink> image and start a shell in it + + # machinectl pull-raw --verify=no \ + https://download.fedoraproject.org/pub/fedora/linux/releases/&fedora_latest_version;/Cloud/x86_64/images/Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw.xz \ + Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 +# systemd-nspawn -M Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64 + + This downloads an image using + machinectl1 + and opens a shell in it. + + + + Build and boot a minimal Fedora distribution in a container + + # dnf -y --releasever=&fedora_latest_version; --installroot=/var/lib/machines/f&fedora_latest_version; \ + --repo=fedora --repo=updates --setopt=install_weak_deps=False install \ + passwd dnf fedora-release vim-minimal util-linux systemd systemd-networkd +# systemd-nspawn -bD /var/lib/machines/f&fedora_latest_version; + + This installs a minimal Fedora distribution into the + directory /var/lib/machines/f&fedora_latest_version; + and then boots that OS in a namespace container. Because the installation + is located underneath the standard /var/lib/machines/ + directory, it is also possible to start the machine using + systemd-nspawn -M f&fedora_latest_version;. + + + + Spawn a shell in a container of a minimal Debian unstable distribution + + # debootstrap unstable ~/debian-tree/ +# systemd-nspawn -D ~/debian-tree/ + + This installs a minimal Debian unstable distribution into + the directory ~/debian-tree/ and then + spawns a shell from this image in a namespace container. + + debootstrap supports + Debian, + Ubuntu, + and Tanglu + out of the box, so the same command can be used to install any of those. For other + distributions from the Debian family, a mirror has to be specified, see + debootstrap8. + + + + + Boot a minimal + <ulink url="https://www.archlinux.org">Arch Linux</ulink> distribution in a container + + # pacstrap -c ~/arch-tree/ base +# systemd-nspawn -bD ~/arch-tree/ + + This installs a minimal Arch Linux distribution into the + directory ~/arch-tree/ and then boots an OS + in a namespace container in it. + + + + Install the + <ulink url="https://software.opensuse.org/distributions/tumbleweed">OpenSUSE Tumbleweed</ulink> + rolling distribution + + # zypper --root=/var/lib/machines/tumbleweed ar -c \ + https://download.opensuse.org/tumbleweed/repo/oss tumbleweed +# zypper --root=/var/lib/machines/tumbleweed refresh +# zypper --root=/var/lib/machines/tumbleweed install --no-recommends \ + systemd shadow zypper openSUSE-release vim +# systemd-nspawn -M tumbleweed passwd root +# systemd-nspawn -M tumbleweed -b + + + + Boot into an ephemeral snapshot of the host system + + # systemd-nspawn -D / -xb + + This runs a copy of the host system in a snapshot which is removed immediately when the container + exits. All file system changes made during runtime will be lost on shutdown, hence. + + + + Run a container with SELinux sandbox security contexts + + # chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container +# systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \ + -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh + + + + Run a container with an OSTree deployment + + # systemd-nspawn -b -i ~/image.raw \ + --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \ + --bind=+/sysroot/ostree/deploy/$OS/var:/var + + + + + Exit status + + The exit code of the program executed in the container is + returned. + + + + See Also + + systemd1, + systemd.nspawn5, + chroot1, + dnf8, + debootstrap8, + pacman8, + zypper8, + systemd.slice5, + machinectl1, + btrfs8 + + + + diff --git a/man/systemd-oomd.service.xml b/man/systemd-oomd.service.xml new file mode 100644 index 0000000..11c9237 --- /dev/null +++ b/man/systemd-oomd.service.xml @@ -0,0 +1,114 @@ + + + + + + + + systemd-oomd.service + systemd + + + + systemd-oomd.service + 8 + + + + systemd-oomd.service + systemd-oomd + A userspace out-of-memory (OOM) killer + + + + systemd-oomd.service + /usr/lib/systemd/systemd-oomd + + + + Description + + systemd-oomd is a system service that uses cgroups-v2 and pressure stall + information (PSI) to monitor and take corrective action before an OOM occurs in the kernel space. + + You can enable monitoring and actions on units by setting ManagedOOMSwap= and + ManagedOOMMemoryPressure= in the unit configuration, see + systemd.resource-control5. + systemd-oomd retrieves information about such units from systemd + when it starts and watches for subsequent changes. + + Cgroups of units with ManagedOOMSwap= or + ManagedOOMMemoryPressure= set to will be monitored. + systemd-oomd periodically polls PSI statistics for the system and those cgroups to + decide when to take action. If the configured limits are exceeded, systemd-oomd will + select a cgroup to terminate, and send SIGKILL to all processes in it. Note that + only descendant cgroups are eligible candidates for killing; the unit with its property set to + is not a candidate (unless one of its ancestors set their property to + ). Also only leaf cgroups and cgroups with memory.oom.group set + to 1 are eligible candidates; see OOMPolicy= in + systemd.service5. + + + oomctl1 can + be used to list monitored cgroups and pressure information. + + See oomd.conf5 + for more information about the configuration of this service. + + + + System requirements and configuration + + The system must be running systemd with a full unified cgroup hierarchy for the expected cgroups-v2 features. + Furthermore, memory accounting must be turned on for all units monitored by systemd-oomd. + The easiest way to turn on memory accounting is by ensuring the value for DefaultMemoryAccounting= + is set to true in + systemd-system.conf5. + + The kernel must be compiled with PSI support. This is available in Linux 4.20 and above. + + It is highly recommended for the system to have swap enabled for systemd-oomd to + function optimally. With swap enabled, the system spends enough time swapping pages to let + systemd-oomd react. Without swap, the system enters a livelocked state much more + quickly and may prevent systemd-oomd from responding in a reasonable amount of + time. See "In defence of swap: + common misconceptions" for more details on swap. Any swap-based actions on systems without swap + will be ignored. While systemd-oomd can perform pressure-based actions on such a + system, the pressure increases will be more abrupt and may require more tuning to get the desired + thresholds and behavior. + + Be aware that if you intend to enable monitoring and actions on user.slice, + user-$UID.slice, or their ancestor cgroups, it is highly recommended that your + programs be managed by the systemd user manager to prevent running too many processes under the same + session scope (and thus avoid a situation where memory intensive tasks trigger + systemd-oomd to kill everything under the cgroup). If you're using a desktop + environment like GNOME or KDE, it already spawns many session components with the systemd user manager. + + + + + Usage Recommendations + + ManagedOOMSwap= works with the system-wide swap values, so setting it on the root slice + -.slice, and allowing all descendant cgroups to be eligible candidates may make the most + sense. + + ManagedOOMMemoryPressure= tends to work better on the cgroups below the root + slice. For units which tend to have processes that are less latency sensitive (e.g. + system.slice), a higher limit like the default of 60% may be acceptable, as those + processes can usually ride out slowdowns caused by lack of memory without serious consequences. However, + something like user@$UID.service may prefer a much lower value like 40%. + + + + See Also + + systemd1, + systemd-system.conf5, + systemd.resource-control5, + oomd.conf5, + oomctl1 + + + diff --git a/man/systemd-path.xml b/man/systemd-path.xml new file mode 100644 index 0000000..f2ca87d --- /dev/null +++ b/man/systemd-path.xml @@ -0,0 +1,81 @@ + + + + + + + + systemd-path + systemd + + + + systemd-path + 1 + + + + systemd-path + List and query system and user paths + + + + + systemd-path + OPTIONS + NAME + + + + + Description + + systemd-path may be used to query system + and user paths. The tool makes many of the paths described in + file-hierarchy7 + available for querying. + + When invoked without arguments, a list of known paths and + their current values is shown. When at least one argument is + passed, the path with this name is queried and its value shown. + The variables whose name begins with search- + do not refer to individual paths, but instead to a list of + colon-separated search paths, in their order of precedence. + + + + Options + + The following options are understood: + + + + + + Printed paths are suffixed by the specified string. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + file-hierarchy7 + + + + diff --git a/man/systemd-pcrphase.service.xml b/man/systemd-pcrphase.service.xml new file mode 100644 index 0000000..9b7cc80 --- /dev/null +++ b/man/systemd-pcrphase.service.xml @@ -0,0 +1,157 @@ + + + + + + + + systemd-pcrphase.service + systemd + + + + systemd-pcrphase.service + 8 + + + + systemd-pcrphase.service + systemd-pcrphase-sysinit.service + systemd-pcrphase-initrd.service + systemd-pcrphase + Measure boot phase into TPM2 PCR 11 + + + + systemd-pcrphase.service + systemd-pcrphase-sysinit.service + systemd-pcrphase-initrd.service + /usr/lib/systemd/system-pcrphase STRING + + + + Description + + systemd-pcrphase.service, + systemd-pcrphase-sysinit.service and + systemd-pcrphase-initrd.service are system services that measure specific strings + into TPM2 PCR 11 during boot at various milestones of the boot process. + + These services require + systemd-stub7 to be + used in a unified kernel image (UKI) setup. They execute no operation when invoked when the stub has not + been used to invoke the kernel. The stub will measure the invoked kernel and associated vendor resources + into PCR 11 before handing control to it; once userspace is invoked these services then will extend + certain literal strings indicating various phases of the boot process into TPM2 PCR 11. During a regular + boot process the following strings are extended into PCR 11. + + + enter-initrd is extended into PCR 11 early when the initrd + initializes, before activating system extension images for the initrd. It is supposed to act as barrier + between the time where the kernel initializes, and where the initrd starts operating and enables + system extension images, i.e. code shipped outside of the UKI. (This string is extended at start of + systemd-pcrphase-initrd.service.) + + leave-initrd is extended into PCR 11 when the initrd is about to + transition into the host file system, i.e. when it achieved its purpose. It is supposed to act as + barrier between kernel/initrd code and host OS code. (This string is extended at stop of + systemd-pcrphase-initrd.service.) + + sysinit is extended into PCR 11 when basic system initialization is + complete (which includes local file systems have been mounted), and the system begins starting regular + system services. (This string is extended at start of + systemd-pcrphase-sysinit.service.) + + ready is extended into PCR 11 during later boot-up, after remote + file systems have been activated (i.e. after remote-fs.target), but before users + are permitted to log in (i.e. before systemd-user-sessions.service). It is + supposed to act as barrier between the time where unprivileged regular users are still prohibited to + log in and where they are allowed to log in. (This string is extended at start of + systemd-pcrphase.service.) + + shutdown is extended into PCR 11 when system shutdown begins. It is + supposed to act as barrier between the time the system is fully up and running and where it is about to + shut down. (This string is extended at stop of + systemd-pcrphase.service.) + + final is extended into PCR 11 at the end of system shutdown. It is + supposed to act as barrier between the time the service manager still runs and when it transitions into + the final boot phase where service management is not available anymore. (This string is extended at + stop of systemd-pcrphase-sysinit.service.) + + + + During a regular system lifecycle, the strings enter-initrd → + leave-initrd → sysinit → ready → + shutdown → final are extended into PCR 11, one after the + other. + + Specific phases of the boot process may be referenced via the series of strings measured, separated + by colons (the "boot path"). For example, the boot path for the regular system runtime is + enter-initrd:leave-initrd:sysinit:ready, while the one for the initrd is just + enter-initrd. The boot path for the the boot phase before the initrd, is an empty + string; because that's hard to pass around a single colon (:) may be used + instead. Note that the aforementioned six strings are just the default strings and individual systems + might measure other strings at other times, and thus implement different and more fine-grained boot + phases to bind policy to. + + By binding policy of TPM2 objects to a specific boot path it is possible to restrict access to them + to specific phases of the boot process, for example making it impossible to access the root file system's + encryption key after the system transitioned from the initrd into the host root file system. + + Use + systemd-measure1 to + pre-calculate expected PCR 11 values for specific boot phases (via the switch). + + + + Options + + The /usr/lib/systemd/system-pcrphase executable may also be invoked from the + command line, where it expects the word to extend into PCR 11, as well as the following switches: + + + + + + Takes the PCR banks to extend the specified word into. If not specified the tool + automatically determines all enabled PCR banks and measures the word into all of + them. + + + + PATH + + Controls which TPM2 device to use. Expects a device node path referring to the TPM2 + chip (e.g. /dev/tpmrm0). Alternatively the special value auto + may be specified, in order to automatically determine the device node of a suitable TPM2 device (of + which there must be exactly one). The special value list may be used to enumerate + all suitable TPM2 devices currently discovered. + + + + + + If no TPM2 firmware, kernel subsystem, kernel driver or device support is found, exit + with exit status 0 (i.e. indicate success). If this is not specified any attempt to measure without a + TPM2 device will cause the invocation to fail. + + + + + + + + + + See Also + + systemd1, + systemd-stub7, + systemd-measure1 + + + + diff --git a/man/systemd-portabled.service.xml b/man/systemd-portabled.service.xml new file mode 100644 index 0000000..61f2c5c --- /dev/null +++ b/man/systemd-portabled.service.xml @@ -0,0 +1,51 @@ + + + + + + + + systemd-portabled.service + systemd + + + + systemd-portabled.service + 8 + + + + systemd-portabled.service + systemd-portabled + Portable service manager + + + + systemd-portabled.service + /usr/lib/systemd/systemd-portabled + + + + Description + + systemd-portabled is a system service that may be used to attach, detach and inspect + portable service images. + + Most of systemd-portabled's functionality is accessible through the + portablectl1 command. + + See Portable Services for details about + the concepts this service implements. + + + + See Also + + systemd1, + portablectl1, + org.freedesktop.portable15 + + + + diff --git a/man/systemd-pstore.service.xml b/man/systemd-pstore.service.xml new file mode 100644 index 0000000..66ad557 --- /dev/null +++ b/man/systemd-pstore.service.xml @@ -0,0 +1,114 @@ + + + + + + + + systemd-pstore.service + systemd + + + + systemd-pstore.service + 8 + + + + systemd-pstore.service + systemd-pstore + A service to archive contents of pstore + + + + /usr/lib/systemd/systemd-pstore + systemd-pstore.service + + + + Description + systemd-pstore.service is a system service that archives the + contents of the Linux persistent storage filesystem, pstore, to other storage, + thus preserving the existing information contained in the pstore, and clearing + pstore storage for future error events. + + Linux provides a persistent storage file system, pstore, that can store error records when the + kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems + (currently the kernel stores the tail of the kernel log, which also contains a stack backtrace, into + pstore). + + The pstore file system supports a variety of backends that map onto persistent + storage, such as the ACPI ERST and UEFI variables. The pstore backends + typically offer a relatively small amount of persistent storage, e.g. 64KiB, + which can quickly fill up and thus prevent subsequent kernel crashes from + recording errors. Thus there is a need to monitor and extract the pstore + contents so that future kernel problems can also record information in the + pstore. + + The pstore service is independent of the kdump service. In cloud environments + specifically, host and guest filesystems are on remote filesystems (e.g. iSCSI + or NFS), thus kdump relies (implicitly and/or explicitly) upon proper operation + of networking software *and* hardware *and* infrastructure. Thus it may not be + possible to capture a kernel coredump to a file since writes over the network + may not be possible. + + The pstore backend, on the other hand, is completely local and provides a path + to store error records which will survive a reboot and aid in post-mortem + debugging. + + The systemd-pstore executable does the actual work. Upon starting, + the pstore.conf file is read and the /sys/fs/pstore/ + directory contents are processed according to the options. Pstore files are written to the + journal, and optionally saved into /var/lib/systemd/pstore/. + + + + Configuration + + The behavior of systemd-pstore is configured through the configuration file + /etc/systemd/pstore.conf and corresponding snippets + /etc/systemd/pstore.conf.d/*.conf, see + pstore.conf5. + + + + Disabling pstore processing + + To disable pstore processing by systemd-pstore, + set Storage=none in + pstore.conf5. + + + + + Kernel parameters + + The kernel has two parameters, + /sys/module/kernel/parameters/crash_kexec_post_notifiers and + /sys/module/printk/parameters/always_kmsg_dump, that control writes into pstore. + The first enables storing of the kernel log (including stack trace) into pstore upon a panic or crash, + and the second enables storing of the kernel log upon a normal shutdown (shutdown, reboot, halt). These + parameters can be managed via the + tmpfiles.d5 + mechanism, specifically the file /usr/lib/tmpfiles/systemd-pstore.conf. + + + + + + + Usage + Data stored in the journal can be viewed with + journalctl1 + as usual. + + + + See Also + + pstore.conf5 + + + diff --git a/man/systemd-quotacheck.service.xml b/man/systemd-quotacheck.service.xml new file mode 100644 index 0000000..4e2a5a4 --- /dev/null +++ b/man/systemd-quotacheck.service.xml @@ -0,0 +1,69 @@ + + + + + + + + systemd-quotacheck.service + systemd + + + + systemd-quotacheck.service + 8 + + + + systemd-quotacheck.service + systemd-quotacheck + File system quota checker logic + + + + systemd-quotacheck.service + /usr/lib/systemd/systemd-quotacheck + + + + Description + + systemd-quotacheck.service is a service + responsible for file system quota checks. It is run once at boot + after all necessary file systems are mounted. It is pulled in only + if at least one file system has quotas enabled. + + + + Kernel Command Line + + systemd-quotacheck understands one + kernel command line parameter: + + + + quotacheck.mode= + + One of auto, + force, skip. Controls + the mode of operation. The default is auto, + and ensures that file system quota checks are done when the + file system quota checker deems them necessary. + force unconditionally results in full file + system quota checks. skip skips any file + system quota checks. + + + + + + See Also + + systemd1, + quotacheck8, + systemd-fsck@.service8 + + + + diff --git a/man/systemd-random-seed.service.xml b/man/systemd-random-seed.service.xml new file mode 100644 index 0000000..9f41332 --- /dev/null +++ b/man/systemd-random-seed.service.xml @@ -0,0 +1,93 @@ + + + + + + + + systemd-random-seed.service + systemd + + + + systemd-random-seed.service + 8 + + + + systemd-random-seed.service + systemd-random-seed + Load and save the system random seed at boot and shutdown + + + + systemd-random-seed.service + /usr/lib/systemd/systemd-random-seed + + + + Description + + systemd-random-seed.service is a service that loads an on-disk random seed + into the kernel entropy pool during boot and saves it at shutdown. See + random4 for + details. By default, no entropy is credited when the random seed is written into the kernel entropy pool, + but this may be changed with $SYSTEMD_RANDOM_SEED_CREDIT, see below. On disk the random + seed is stored in /var/lib/systemd/random-seed. + + Note that this service runs relatively late during the early boot phase, i.e. generally after the + initrd phase has finished and the /var/ file system has been mounted. Many system + services require entropy much earlier than this — this service is hence of limited use for complex + system. It is recommended to use a boot loader that can pass an initial random seed to the kernel to + ensure that entropy is available from earliest boot on, for example + systemd-boot7, with + its bootctl random-seed functionality. + + When loading the random seed from disk, the file is immediately updated with a new seed retrieved + from the kernel, in order to ensure no two boots operate with the same random seed. This new seed is + retrieved synchronously from the kernel, which means the service will not complete start-up until the + random pool is fully initialized. On entropy-starved systems this may take a while. This functionality is + intended to be used as synchronization point for ordering services that require an initialized entropy + pool to function securely (i.e. services that access /dev/urandom without any + further precautions). + + Care should be taken when creating OS images that are replicated to multiple systems: if the random + seed file is included unmodified each system will initialize its entropy pool with the same data, and + thus — if otherwise entropy-starved — generate the same or at least guessable random seed streams. As a + safety precaution crediting entropy is thus disabled by default. It is recommended to remove the random + seed from OS images intended for replication on multiple systems, in which case it is safe to enable + entropy crediting, see below. Also see Safely Building + Images. + + See Random Seeds for further + information. + + + + Environment + + + + $SYSTEMD_RANDOM_SEED_CREDIT + By default, systemd-random-seed.service does not credit any + entropy when loading the random seed. With this option this behaviour may be changed: it either takes + a boolean parameter or the special string force. Defaults to false, in which case + no entropy is credited. If true, entropy is credited if the random seed file and system state pass + various superficial concisistency checks. If set to force entropy is credited, + regardless of these checks, as long as the random seed file exists. + + + + + + See Also + + systemd1, + random4, + systemd-boot7, + bootctl4 + + + + diff --git a/man/systemd-rc-local-generator.xml b/man/systemd-rc-local-generator.xml new file mode 100644 index 0000000..f0e38ea --- /dev/null +++ b/man/systemd-rc-local-generator.xml @@ -0,0 +1,72 @@ + + +%entities; +]> + + + + + systemd-rc-local-generator + systemd + + + + systemd-rc-local-generator + 8 + + + + systemd-rc-local-generator + rc-local.service + Compatibility generator and service to start &RC_LOCAL_PATH; during boot + + + + /usr/lib/systemd/system-generators/systemd-rc-local-generator + rc-local.service + + + + Description + + systemd-rc-local-generator is a generator that checks whether + &RC_LOCAL_PATH; exists and is executable, and if it is, pulls the + rc-local.service unit into the boot process. This unit is responsible for running + this script during late boot. The script is run after network.target, but in + parallel with most other regular system services. + + Note that rc-local.service runs with slightly different semantics than the + original System V version, which was executed "last" in the boot process, which is a concept that does + not translate to systemd. + + Also note that rc-local.service is ordered after + network.target, which does not mean that the network is functional, see + systemd.special7. + If the script requires a configured network connection, it may be desirable to pull in and order it after + network-online.target with a drop-in: + + # /etc/systemd/system/rc-local.service.d/network.conf +[Unit] +Wants=network-online.target +After=network-online.target + + + Support for &RC_LOCAL_PATH; is provided for compatibility with specific System + V systems only. However, it is strongly recommended to avoid making use of this script today, and instead + provide proper unit files with appropriate dependencies for any scripts to run during the boot process. + Note that the path to the script is set at compile time and varies between distributions. + + systemd-rc-local-generator implements + systemd.generator7. + + + + See Also + + systemd1, + systemctl1 + + + diff --git a/man/systemd-remount-fs.service.xml b/man/systemd-remount-fs.service.xml new file mode 100644 index 0000000..266db88 --- /dev/null +++ b/man/systemd-remount-fs.service.xml @@ -0,0 +1,70 @@ + + + + + + + + systemd-remount-fs.service + systemd + + + + systemd-remount-fs.service + 8 + + + + systemd-remount-fs.service + systemd-remount-fs + Remount root and kernel file systems + + + + systemd-remount-fs.service + /usr/lib/systemd/systemd-remount-fs + + + + Description + + systemd-remount-fs.service is an early boot service that applies mount options + listed in fstab5, or + gathered from the partition table (when + systemd-gpt-auto-generator8 + is active) to the root file system, the /usr/ file system, and the kernel API file + systems. This is required so that the mount options of these file systems — which are pre-mounted by the + kernel, the initrd, container environments or system manager code — are updated to those + configured in /etc/fstab and the other sources. This service ignores normal file + systems and only changes the root file system (i.e. /), /usr/, + and the virtual kernel API file systems such as /proc/, /sys/ or + /dev/. This service executes no operation if no configuration is found + (/etc/fstab does not exist or lists no entries for the mentioned file systems, or + the partition table does not contain relevant entries). + + For a longer discussion of kernel API file systems see + API + File Systems. + + Note: systemd-remount-fs.service is usually pulled in by + systemd-fstab-generator8, + hence it is also affected by the kernel command line option fstab=, which may be used + to disable the generator. It may also pulled in by + systemd-gpt-auto-generator8, + which is affected by systemd.gpt_auto and other options. + + + + See Also + + systemd1, + fstab5, + mount8, + systemd-fstab-generator8, + systemd-gpt-auto-generator8 + + + + diff --git a/man/systemd-repart.xml b/man/systemd-repart.xml new file mode 100644 index 0000000..3585cbf --- /dev/null +++ b/man/systemd-repart.xml @@ -0,0 +1,390 @@ + + + + + + + + systemd-repart + systemd + + + + systemd-repart + 8 + + + + systemd-repart + systemd-repart.service + Automatically grow and add partitions + + + + + systemd-repart + OPTIONS + BLOCKDEVICE + + + systemd-repart.service + + + + Description + + systemd-repart grows and adds partitions to a partition table, based on the + configuration files described in + repart.d5. + + + If invoked with no arguments, it operates on the block device backing the root file system + partition of the running OS, thus growing and adding partitions of the booted OS image itself. If + --image= is used it will operate on the specified image file. When called in the + initrd it operates on the block device backing /sysroot/ instead, i.e. on the block + device the system will soon transition into. The systemd-repart.service service is + generally run at boot in the initrd, in order to augment the partition table of the OS before its + partitions are mounted. systemd-repart (mostly) operates in a purely incremental mode: + it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions. + The service is intended to be run on every boot, but when it detects that the partition table already + matches the installed repart.d/*.conf configuration files, it executes no + operation. + + systemd-repart is intended to be used when deploying OS images, to automatically + adjust them to the system they are running on, during first boot. This way the deployed image can be + minimal in size and may be augmented automatically at boot when needed, taking possession of disk space + available but not yet used. Specifically the following use cases are among those covered: + + + The root partition may be grown to cover the whole available disk space. + A /home/, swap or /srv/ partition can be + added. + A second (or third, …) root partition may be added, to cover A/B style setups + where a second version of the root file system is alternatingly used for implementing update + schemes. The deployed image would carry only a single partition ("A") but on first boot a second + partition ("B") for this purpose is automatically created. + + + The algorithm executed by systemd-repart is roughly as follows: + + + The repart.d/*.conf configuration files are loaded and parsed, + and ordered by filename (without the directory prefix). For each configuration file, + drop-in files are looked for in directories with same name as the configuration file + with a suffix ".d" added. + + The partition table already existing on the block device is loaded and + parsed. + + The existing partitions in the partition table are matched up with the + repart.d/*.conf files by GPT partition type UUID. The first existing partition + of a specific type is assigned the first configuration file declaring the same type. The second + existing partition of a specific type is then assigned the second configuration file declaring the same + type, and so on. After this iterative assigning is complete any left-over existing partitions that have + no matching configuration file are considered "foreign" and left as they are. And any configuration + files for which no partition currently exists are understood as a request to create such a + partition. + + Taking the size constraints and weights declared in the configuration files into + account, all partitions that shall be created are now allocated to the disk, taking up all free space, + always respecting the size and padding requests. Similarly, existing partitions that should be grown + are grown. New partitions are always appended to the end of the partition table, taking the first + partition table slot whose index is greater than the indexes of all existing partitions. Partition + table slots are never reordered and thus partition numbers are ensured to remain stable. Note that this + allocation happens in memory only, the partition table on disk is not updated yet. + + All existing partitions for which configuration files exist and which currently have no + GPT partition label set will be assigned a label, either explicitly configured in the configuration or + — if that's missing — derived automatically from the partition type. The same is done for all + partitions that are newly created. These assignments are done in memory only, too, the disk is not + updated yet. + + Similarly, all existing partitions for which configuration files exist and which + currently have an all-zero identifying UUID will be assigned a new UUID. This UUID is cryptographically + hashed from a common seed value together with the partition type UUID (and a counter in case multiple + partitions of the same type are defined), see below. The same is done for all partitions that are + created anew. These assignments are done in memory only, too, the disk is not updated yet. + + + Similarly, if the disk's volume UUID is all zeroes it is also initialized, also + cryptographically hashed from the same common seed value. This is done in memory only too. + + + The disk space assigned to new partitions (i.e. what was previously free space) is now + erased. Specifically, all file system signatures are removed, and if the device supports it, the + BLKDISCARD I/O control command is issued to inform the hardware that the space is + now empty. In addition any "padding" between partitions and at the end of the device is similarly + erased. + + The new partition table is finally written to disk. The kernel is asked to reread the + partition table. + + + As exception to the normally strictly incremental operation, when called in a special "factory + reset" mode, systemd-repart may also be used to erase existing partitions to + reset an installation back to vendor defaults. This mode of operation is used when either the + switch is passed on the tool's command line, or the + option specified on the kernel command line, or the + FactoryReset EFI variable (vendor UUID + 8cf2644b-4b0b-428f-9387-6d876050dc67) is set to "yes". It alters the algorithm above + slightly: between the 3rd and the 4th step above any partition marked explicitly via the + FactoryReset= boolean is deleted, and the algorithm restarted, thus immediately + re-creating these partitions anew empty. + + Note that systemd-repart only changes partition tables, it does not create or + resize any file systems within these partitions. A separate mechanism should be used for that, for + example + systemd-growfs8 and + systemd-makefs. + + The UUIDs identifying the new partitions created (or assigned to existing partitions that have no + UUID yet), as well as the disk as a whole are hashed cryptographically from a common seed value. This + seed value is usually the + machine-id5 of the + system, so that the machine ID reproducibly determines the UUIDs assigned to all partitions. If the + machine ID cannot be read (or the user passes , see below) the seed is + generated randomly instead, so that the partition UUIDs are also effectively random. The seed value may + also be set explicitly, formatted as UUID via the option. By hashing these UUIDs + from a common seed images prepared with this tool become reproducible and the result of the algorithm + above deterministic. + + The positional argument should specify the block device to operate on. Instead of a block device + node path a regular file may be specified too, in which case the command operates on it like it would if + a loopback block device node was specified with the file attached. If is + specified the specified path is created as regular file, which is useful for generating disk images from + scratch. + + + + Options + + The following options are understood: + + + + + Takes a boolean. If this switch is not specified is + the implied default. Controls whether systemd-repart executes the requested + re-partition operations or whether it should only show what it would do. Unless + is specified systemd-repart will not actually + touch the device's partition table. + + + + + Takes one of refuse, allow, + require, force or create. Controls how to + operate on block devices that are entirely empty, i.e. carry no partition table/disk label yet. If + this switch is not specified the implied default is refuse. + + If refuse systemd-repart requires that the block device + it shall operate on already carries a partition table and refuses operation if none is found. If + allow the command will extend an existing partition table or create a new one if + none exists. If require the command will create a new partition table if none + exists so far, and refuse operation if one already exists. If force it will create + a fresh partition table unconditionally, erasing the disk fully in effect. If + force no existing partitions will be taken into account or survive the + operation. Hence: use with care, this is a great way to lose all your data. If + create a new loopback file is create under the path passed via the device node + parameter, of the size indicated with , see below. + + + + + + Takes a boolean. If this switch is not specified is + the implied default. Controls whether to issue the BLKDISCARD I/O control + command on the space taken up by any added partitions or on the space in between them. Usually, it's + a good idea to issue this request since it tells the underlying hardware that the covered blocks + shall be considered empty, improving performance. If operating on a regular file instead of a block + device node, a sparse file is generated. + + + + + + Takes a size in bytes, using the usual K, M, G, T suffixes, or the special value + auto. If used the specified device node path must refer to a regular file, which + is then grown to the specified size if smaller, before any change is made to the partition table. If + specified as auto the minimal size for the disk image is automatically determined + (i.e. the minimal sizes of all partitions are summed up, taking space for additional metadata into + account). This switch is not supported if the specified node is a block device. This switch has no + effect if the file is already as large as the specified size or larger. The specified size is + implicitly rounded up to multiples of 4096. When used with this + specifies the initial size of the loopback file to create. + + The option takes the sizes of pre-existing partitions into + account. However, it does not accommodate for partition tables that are not tightly packed: the + configured partitions might still not fit into the backing device if empty space exists between + pre-existing partitions (or before the first partition) that cannot be fully filled by partitions to + grow or create. + + Also note that the automatic size determination does not take files or directories specified + with into account: operation might fail if the specified files or + directories require more disk space then the configured per-partition minimal size + limit. + + + + + + Takes boolean. If this switch is not specified is + the implied default. Controls whether to operate in "factory reset" mode, see above. If set to true + this will remove all existing partitions marked with FactoryReset= set to yes + early while executing the re-partitioning algorithm. Use with care, this is a great way to lose all + your data. Note that partition files need to explicitly turn FactoryReset= on, as + the option defaults to off. If no partitions are marked for factory reset this switch has no + effect. Note that there are two other methods to request factory reset operation: via the kernel + command line and via an EFI variable, see above. + + + + + + If this switch is specified the disk is not re-partitioned. Instead it is determined + if any existing partitions are marked with FactoryReset=. If there are the tool + will exit with exit status zero, otherwise non-zero. This switch may be used to quickly determine + whether the running system supports a factory reset mechanism built on + systemd-repart. + + + + + + Takes a path to a directory to use as root file system when searching for + repart.d/*.conf files, for the machine ID file to use as seed and for the + CopyFiles= and CopyBlocks= source files and directories. By + default when invoked on the regular system this defaults to the host's root file system + /. If invoked from the initrd this defaults to /sysroot/, + so that the tool operates on the configuration and machine ID stored in the root file system later + transitioned into itself. + + + + + + Takes a path to a disk image file or device to mount and use in a similar fashion to + , see above. + + + + + + Takes a UUID as argument or the special value random. If a UUID + is specified the UUIDs to assign to partitions and the partition table itself are derived via + cryptographic hashing from it. If not specified it is attempted to read the machine ID from the host + (or more precisely, the root directory configured via ) and use it as seed + instead, falling back to a randomized seed otherwise. Use to force a + randomized seed. Explicitly specifying the seed may be used to generated strictly reproducible + partition tables. + + + + + + Takes a boolean argument. If this switch is not specified, it defaults to on when + called from an interactive terminal and off otherwise. Controls whether to show a user friendly table + and graphic illustrating the changes applied. + + + + + + Takes a file system path. If specified the *.conf files are read + from the specified directory instead of searching in /usr/lib/repart.d/*.conf, + /etc/repart.d/*.conf, + /run/repart.d/*.conf. + + This parameter can be specified multiple times. + + + + + + Takes a file system path. Configures the encryption key to use when setting up LUKS2 + volumes configured with the Encrypt=key-file setting in partition files. Should + refer to a regular file containing the key, or an AF_UNIX stream socket in the + file system. In the latter case a connection is made to it and the key read from it. If this switch + is not specified the empty key (i.e. zero length key) is used. This behaviour is useful for setting + up encrypted partitions during early first boot that receive their user-supplied password only in a + later setup step. + + + + + + Takes a file system path. Configures the signing key to use when creating verity + signature partitions with the Verity=signature setting in partition files. + + + + + + + Takes a file system path. Configures the PEM encoded X.509 certificate to use when + creating verity signature partitions with the Verity=signature setting in + partition files. + + + + + + + Configures the TPM2 device and list of PCRs to use for LUKS2 volumes configured with + the Encrypt=tpm2 option. These options take the same parameters as the identically + named options to + systemd-cryptenroll1 + and have the same effect on partitions where TPM2 enrollment is requested. + + + + PATH + PCR + + Configures a TPM2 signed PCR policy to bind encryption to. See + systemd-cryptenroll1 + for details on these two options. + + + + BOOL + + Enables generation of split artifacts from partitions configured with + SplitName=. If enabled, for each partition with SplitName= set, + a separate output file containing just the contents of that partition is generated. The output + filename consists of the loopback filename suffixed with the name configured with + SplitName=. If the loopback filename ends with .raw, the suffix + is inserted before the .raw extension instead. + + Note that is independent from . Even if + is enabled, split artifacts will still be generated from an existing image + if is enabled. + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + See Also + + systemd1, + repart.d5, + machine-id5, + systemd-cryptenroll1 + + + + diff --git a/man/systemd-resolved.service.xml b/man/systemd-resolved.service.xml new file mode 100644 index 0000000..ee796d7 --- /dev/null +++ b/man/systemd-resolved.service.xml @@ -0,0 +1,424 @@ + + + + + + + + systemd-resolved.service + systemd + + + + systemd-resolved.service + 8 + + + + systemd-resolved.service + systemd-resolved + Network Name Resolution manager + + + + systemd-resolved.service + /usr/lib/systemd/systemd-resolved + + + + Description + + systemd-resolved is a system service that provides network name resolution to + local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR + and MulticastDNS resolver and responder. Local applications may submit network name resolution requests + via three interfaces: + + + The native, fully-featured API systemd-resolved exposes on the bus, + see + org.freedesktop.resolve15 + and + org.freedesktop.LogControl15 + for details. Usage of this API is generally recommended to clients as it is asynchronous and fully + featured (for example, properly returns DNSSEC validation status and interface scope for addresses as + necessary for supporting link-local networking). + + The glibc + getaddrinfo3 + API as defined by RFC3493 and its related + resolver functions, including + gethostbyname3. + This API is widely supported, including beyond the Linux platform. In its current form it does not + expose DNSSEC validation status information however, and is synchronous only. This API is backed by the + glibc Name Service Switch + (nss5). + Usage of the glibc NSS module + nss-resolve8 is + required in order to allow glibc's NSS resolver functions to resolve hostnames via + systemd-resolved. + + Additionally, systemd-resolved provides a local DNS stub listener on + the IP addresses 127.0.0.53 and 127.0.0.54 on the local loopback interface. Programs issuing DNS + requests directly, bypassing any local API may be directed to this stub, in order to connect them to + systemd-resolved. Note however that it is strongly recommended that local programs + use the glibc NSS or bus APIs instead (as described above), as various network resolution concepts + (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS + protocol. + + The DNS stub resolver on 127.0.0.53 provides the full feature set of the local + resolver, which includes offering LLMNR/MulticastDNS resolution. The DNS stub resolver on 127.0.0.54 + provides a more limited resolver, that operates in "proxy" mode only, i.e. it will pass most DNS + messages relatively unmodified to the current upstream DNS servers and back, but not try to process the + messages locally, and hence does not validate DNSSEC, or offer up LLMNR/MulticastDNS. (It will + translate to DNS-over-TLS communication if needed however.) + + + The DNS servers contacted are determined from the global settings in + /etc/systemd/resolved.conf, the per-link static settings in + /etc/systemd/network/*.network files (in case + systemd-networkd.service8 + is used), the per-link dynamic settings received over DHCP, information provided via + resolvectl1, and any + DNS server information made available by other system services. See + resolved.conf5 and + systemd.network5 for + details about systemd's own configuration files for DNS servers. To improve compatibility, + /etc/resolv.conf is read in order to discover configured system DNS servers, but + only if it is not a symlink to /run/systemd/resolve/stub-resolv.conf, + /usr/lib/systemd/resolv.conf or + /run/systemd/resolve/resolv.conf (see below). + + + + + Synthetic Records + + systemd-resolved synthesizes DNS resource records (RRs) for the following + cases: + + + The local, configured hostname is resolved to all locally configured IP addresses + ordered by their scope, or — if none are configured — the IPv4 address 127.0.0.2 (which is on the local + loopback interface) and the IPv6 address ::1 (which is the local host). + + The hostnames localhost and localhost.localdomain + as well as any hostname ending in .localhost or + .localhost.localdomain are resolved to the IP addresses 127.0.0.1 and ::1. + + + The hostname _gateway is resolved to all current default routing + gateway addresses, ordered by their metric. This assigns a stable hostname to the current gateway, + useful for referencing it independently of the current network configuration state. + + The hostname _outbound is resolved to the local IPv4 and IPv6 + addresses that are most likely used for communication with other hosts. This is determined by + requesting a routing decision to the configured default gateways from the kernel and then using the + local IP addresses selected by this decision. This hostname is only available if there is at least one + local default gateway configured. This assigns a stable hostname to the local outbound IP addresses, + useful for referencing them independently of the current network configuration state. + + The mappings defined in /etc/hosts are resolved to their + configured addresses and back, but they will not affect lookups for non-address types (like MX). + Support for /etc/hosts may be disabled with ReadEtcHosts=no, + see resolved.conf5. + + + + + + Protocols and Routing + + The lookup requests that systemd-resolved.service receives are routed to the + available DNS servers, LLMNR, and MulticastDNS interfaces according to the following rules: + + + Names for which synthetic records are generated (the local hostname, + localhost and localdomain, local gateway, as listed in the + previous section) and addresses configured in /etc/hosts are never routed to the + network and a reply is sent immediately. + + Single-label names are resolved using LLMNR on all local interfaces where LLMNR is + enabled. Lookups for IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are + only sent via LLMNR on IPv6. Note that lookups for single-label synthesized names are not routed to + LLMNR, MulticastDNS or unicast DNS. + + Queries for the address records (A and AAAA) of single-label non-synthesized names are + resolved via unicast DNS using search domains. For any interface which defines search domains, such + look-ups are routed to the servers defined for that interface, suffixed with each of those search + domains. When global search domains are defined, such look-ups are routed to the global servers. For + each search domain, queries are performed by suffixing the name with each of the search domains in + turn. Additionally, lookup of single-label names via unicast DNS may be enabled with the + ResolveUnicastSingleLabel=yes setting. The details of which servers are queried and + how the final reply is chosen are described below. Note that this means that address queries for + single-label names are never sent out to remote DNS servers by default, and resolution is only + possible if search domains are defined. + + Multi-label names with the domain suffix .local are resolved using + MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups + are sent via IPv4 and IPv6 address lookups are sent via IPv6. + + Queries for multi-label names are routed via unicast DNS on local interfaces that have + a DNS server configured, plus the globally configured DNS servers if there are any. Which interfaces + are used is determined by the routing logic based on search and route-only domains, described below. + Note that by default, lookups for domains with the .local suffix are not routed to + DNS servers, unless the domain is specified explicitly as routing or search domain for the DNS server + and interface. This means that on networks where the .local domain is defined in a + site-specific DNS server, explicit search or routing domains need to be configured to make lookups work + within this DNS domain. Note that these days, it's generally recommended to avoid defining + .local in a DNS server, as RFC6762 reserves this domain for exclusive + MulticastDNS use. + + Address lookups (reverse lookups) are routed similarly to multi-label names, with the + exception that addresses from the link-local address range are never routed to unicast DNS and are only + resolved using LLMNR and MulticastDNS (when enabled). + + + If lookups are routed to multiple interfaces, the first successful response is returned (thus + effectively merging the lookup zones on all matching interfaces). If the lookup failed on all interfaces, + the last failing response is returned. + + Routing of lookups is determined by the per-interface routing domains (search and route-only) and + global search domains. See + systemd.network5 and + resolvectl1 for a + description how those settings are set dynamically and the discussion of Domains= in + resolved.conf5 for a + description of globally configured DNS settings. + + The following query routing logic applies for unicast DNS lookups initiated by + systemd-resolved.service: + + + If a name to look up matches (that is: is equal to or has as suffix) any of the + configured routing domains (search or route-only) of any link, or the globally configured DNS settings, + "best matching" routing domain is determined: the matching one with the most labels. The query is then + sent to all DNS servers of any links or the globally configured DNS servers associated with this "best + matching" routing domain. (Note that more than one link might have this same "best matching" routing + domain configured, in which case the query is sent to all of them in parallel). + + In case of single-label names, when search domains are defined, the same logic applies, except + that the name is first suffixed by each of the search domains in turn. Note that this search logic + doesn't apply to any names with at least one dot. Also see the discussion about compatibility with + the traditional glibc resolver below. + + If a query does not match any configured routing domain (either per-link or global), it + is sent to all DNS servers that are configured on links with the DefaultRoute= + option set, as well as the globally configured DNS server. + + If there is no link configured as DefaultRoute= and no global DNS + server configured, one of the compiled-in fallback DNS servers is used. + + Otherwise the unicast DNS query fails, as no suitable DNS servers can be determined. + + + + The DefaultRoute= option is a boolean setting configurable with + resolvectl or in .network files. If not set, it is implicitly + determined based on the configured DNS domains for a link: if there's a route-only domain other than + ~., it defaults to false, otherwise to true. + + Effectively this means: in order to support single-label non-synthesized names, define appropriate + search domains. In order to preferably route all DNS queries not explicitly matched by routing domain + configuration to a specific link, configure a ~. route-only domain on it. This will + ensure that other links will not be considered for these queries (unless they too carry such a routing + domain). In order to route all such DNS queries to a specific link only if no other link is preferred, + set the DefaultRoute= option for the link to true and do not configure a + ~. route-only domain on it. Finally, in order to ensure that a specific link never + receives any DNS traffic not matching any of its configured routing domains, set the + DefaultRoute= option for it to false. + + See + org.freedesktop.resolve15 + for information about the D-Bus APIs systemd-resolved provides. + + + + Compatibility with the traditional glibc stub resolver + + This section provides a short summary of differences in the resolver implemented by + nss-resolve8 together + with systemd-resolved and the traditional stub resolver implemented in + nss-dns. + + + Some names are always resolved internally (see Synthetic Records above). Traditionally + they would be resolved by nss-files if provided in + /etc/hosts. But note that the details of how a query is constructed are under the + control of the client library. nss-dns will first try to resolve names using + search domains and even if those queries are routed to systemd-resolved, it will + send them out over the network using the usual rules for multi-label name routing For + example, if /etc/resolv.conf has nameserver 127.0.0.53 +search foobar.com barbar.com + and we look up localhost, nss-dns will send + the following queries to systemd-resolved listening on 127.0.0.53:53: first + localhost.foobar.com, then localhost.barbar.com, and finally + localhost. If (hopefully) the first two queries fail, + systemd-resolved will synthesize an answer for the third query. + + When using nss-dns with any search domains, it is thus crucial to always + configure nss-files with higher priority and provide mappings for names that + should not be resolved using search domains.. + + Single-label names are not resolved for A and AAAA records using unicast DNS (unless + overridden with ResolveUnicastSingleLabel=, see + resolved.conf5). + This is similar to the option being set in + resolv.conf5. + + + Search domains are not used for suffixing of multi-label names. + (Search domains are nevertheless used for lookup routing, for names that were + originally specified as single-label or multi-label.) Any name with at least one dot is always + interpreted as a FQDN. nss-dns would resolve names both as relative (using search + domains) and absolute FQDN names. Some names would be resolved as relative first, and after that query + has failed, as absolute, while other names would be resolved in opposite order. The + ndots option in /etc/resolv.conf was used to control how many + dots the name needs to have to be resolved as relative first. This stub resolver does not implement + this at all: multi-label names are only resolved as FQDNs.There are currently more than + 1500 top-level domain names defined, and new ones are added regularly, often using "attractive" names + that are also likely to be used locally. Not looking up multi-label names in this fashion avoids + fragility in both directions: a valid global name could be obscured by a local name, and resolution of + a relative local name could suddenly break when a new top-level domain is created, or when a new + subdomain of a top-level domain in registered. Resolving any given name as either relative or absolute + avoids this ambiguity. + + This resolver has a notion of the special .local domain used for + MulticastDNS, and will not route queries with that suffix to unicast DNS servers unless explicitly + configured, see above. Also, reverse lookups for link-local addresses are not sent to unicast DNS + servers. + + This resolver reads and caches /etc/hosts internally. (In other + words, nss-resolve replaces nss-files in addition to + nss-dns). Entries in /etc/hosts have highest priority. + + + This resolver also implements LLMNR and MulticastDNS in addition to the classic unicast + DNS protocol, and will resolve single-label names using LLMNR (when enabled) and names ending in + .local using MulticastDNS (when enabled). + + Environment variables $LOCALDOMAIN and + $RES_OPTIONS described in + resolv.conf5 + are not supported currently. + + The nss-dns resolver maintains little state between subsequent DNS + queries, and for each query always talks to the first listed DNS server from + /etc/resolv.conf first, and on failure continues with the next until reaching the + end of the list which is when the query fails. The resolver in + systemd-resolved.service however maintains state, and will continuously talk to + the same server for all queries on a particular lookup scope until some form of error is seen at which + point it switches to the next, and then continuously stays with it for all queries on the scope until + the next failure, and so on, eventually returning to the first configured server. This is done to + optimize lookup times, in particular given that the resolver typically must first probe server feature + sets when talking to a server, which is time consuming. This different behaviour implies that listed + DNS servers per lookup scope must be equivalent in the zones they serve, so that sending a query to one + of them will yield the same results as sending it to another configured DNS server. + + + + + <filename>/etc/resolv.conf</filename> + + Four modes of handling /etc/resolv.conf (see + resolv.conf5) are + supported: + + + systemd-resolved maintains the + /run/systemd/resolve/stub-resolv.conf file for compatibility with traditional + Linux programs. This file lists the 127.0.0.53 DNS stub (see above) as the only DNS server. It also + contains a list of search domains that are in use by systemd-resolved. The list of search domains is + always kept up-to-date. Note that /run/systemd/resolve/stub-resolv.conf should not + be used directly by applications, but only through a symlink from + /etc/resolv.conf. This file may be symlinked from + /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs + to systemd-resolved with correct search domains settings. This mode of operation is + recommended. + + A static file /usr/lib/systemd/resolv.conf is provided that lists + the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from + /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs + to systemd-resolved. This file does not contain any search domains. + + + systemd-resolved maintains the + /run/systemd/resolve/resolv.conf file for compatibility with traditional Linux + programs. This file may be symlinked from /etc/resolv.conf and is always kept + up-to-date, containing information about all known DNS servers. Note the file format's limitations: it + does not know a concept of per-interface DNS servers and hence only contains system-wide DNS server + definitions. Note that /run/systemd/resolve/resolv.conf should not be used + directly by applications, but only through a symlink from /etc/resolv.conf. If + this mode of operation is used local clients that bypass any local DNS API will also bypass + systemd-resolved and will talk directly to the known DNS servers. + + Alternatively, /etc/resolv.conf may be managed by other packages, + in which case systemd-resolved will read it for DNS configuration data. In this mode + of operation systemd-resolved is consumer rather than provider of this configuration + file. + + + Note that the selected mode of operation for this file is detected fully automatically, depending + on whether /etc/resolv.conf is a symlink to + /run/systemd/resolve/resolv.conf or lists 127.0.0.53 as DNS server. + + + + Signals + + + + SIGUSR1 + + Upon reception of the SIGUSR1 process signal + systemd-resolved will dump the contents of all DNS resource record caches it + maintains, as well as all feature level information it learnt about configured DNS servers into the + system logs. + + + + SIGUSR2 + + Upon reception of the SIGUSR2 process signal + systemd-resolved will flush all caches it maintains. Note that it should normally + not be necessary to request this explicitly – except for debugging purposes – as + systemd-resolved flushes the caches automatically anyway any time the host's + network configuration changes. Sending this signal to systemd-resolved is + equivalent to the resolvectl flush-caches command, however the latter is + recommended since it operates in a synchronous way. + + + + SIGRTMIN+1 + + Upon reception of the SIGRTMIN+1 process signal + systemd-resolved will forget everything it learnt about the configured DNS + servers. Specifically any information about server feature support is flushed out, and the server + feature probing logic is restarted on the next request, starting with the most fully featured + level. Note that it should normally not be necessary to request this explicitly – except for + debugging purposes – as systemd-resolved automatically forgets learnt information + any time the DNS server configuration changes. Sending this signal to + systemd-resolved is equivalent to the resolvectl + reset-server-features command, however the latter is recommended since it operates in a + synchronous way. + + + + + + See Also + + systemd1, + resolved.conf5, + dnssec-trust-anchors.d5, + nss-resolve8, + resolvectl1, + resolv.conf5, + hosts5, + systemd.network5, + systemd-networkd.service8 + + + + diff --git a/man/systemd-rfkill.service.xml b/man/systemd-rfkill.service.xml new file mode 100644 index 0000000..d89eb91 --- /dev/null +++ b/man/systemd-rfkill.service.xml @@ -0,0 +1,65 @@ + + + + + + + + systemd-rfkill.service + systemd + + + + systemd-rfkill.service + 8 + + + + systemd-rfkill.service + systemd-rfkill.socket + systemd-rfkill + Load and save the RF kill switch state at boot and change + + + + systemd-rfkill.service + systemd-rfkill.socket + /usr/lib/systemd/systemd-rfkill + + + + Description + + systemd-rfkill.service is a service + that restores the RF kill switch state at early boot and saves it + on each change. On disk, the RF kill switch state is stored in + /var/lib/systemd/rfkill/. + + + + Kernel Command Line + + systemd-rfkill understands the + following kernel command line parameter: + + + + systemd.restore_state= + + Takes a boolean argument. Defaults to + 1. If 0, does not + restore the rfkill settings on boot. However, settings will + still be stored on shutdown. + + + + + + See Also + + systemd1 + + + + diff --git a/man/systemd-run-generator.xml b/man/systemd-run-generator.xml new file mode 100644 index 0000000..02924b4 --- /dev/null +++ b/man/systemd-run-generator.xml @@ -0,0 +1,81 @@ + + + + + + + + systemd-run-generator + systemd + + + + systemd-run-generator + 8 + + + + systemd-run-generator + Generator for invoking commands specified on the kernel command line as system service + + + + /usr/lib/systemd/system-generators/systemd-run-generator + + + + Description + + systemd-run-generator is a generator + that reads the kernel command line and understands three + options: + + If the option is specified and followed by a command line, a unit named + kernel-command-line.service is generated for it and booted into. The service has + Type=oneshot set, and has SuccessAction=exit and + FailureAction=exit configured by default, thus ensuring that the system is shut down as soon as + the command completes. The exit status of the command line is propagated to the invoking container manager, if + this applies (which might propagate this further, to the calling shell — e.g. + systemd-nspawn7 does this). If + this option is used multiple times the unit file will contain multiple ExecStart= lines, to + execute all commands in order. The command is started as regular service, i.e. with + DefaultDependencies= on. + + Use and to tweak + how to react to the process completing. In particular assigning none will leave the system + running after the command completes. For further details on supported arguments, see + systemd.unit5. + + systemd-run-generator implements + systemd.generator7. + + + + Example + + Use a command like the following to add a user to the user database inside a container run with + systemd-nspawn7: + + # systemd-nspawn -D mycontainer -b systemd.run='"adduser test"' + (Note the requirement for double quoting in the command line above. The first level of quoting ('') is + processed and removed by the command shell used to invoke systemd-nspawn. The second level of + quoting ("") is propagated to the kernel command line of the container and processed and removed by + systemd-run-generator. Both together make sure both words of the specified command line + adduser test end up in the generated unit file together and are neither split apart by the + command shell nor by the generator.) + + + + See Also + + systemd1, + systemctl1, + kernel-command-line7, + systemd-nspawn7, + systemd.unit5, + systemd.service5 + + + + diff --git a/man/systemd-run.xml b/man/systemd-run.xml new file mode 100644 index 0000000..0c91d61 --- /dev/null +++ b/man/systemd-run.xml @@ -0,0 +1,559 @@ + + + + + + + + systemd-run + systemd + + + + systemd-run + 1 + + + + systemd-run + Run programs in transient scope units, service units, or path-, socket-, or timer-triggered service units + + + + + systemd-run + OPTIONS + COMMAND + ARGS + + + + systemd-run + OPTIONS + PATH OPTIONS + COMMAND + ARGS + + + systemd-run + OPTIONS + SOCKET OPTIONS + COMMAND + ARGS + + + systemd-run + OPTIONS + TIMER OPTIONS + COMMAND + ARGS + + + + + Description + + systemd-run may be used to create and start a transient .service or + .scope unit and run the specified COMMAND in it. It may also be + used to create and start a transient .path, .socket, or + .timer unit, that activates a .service unit when elapsing. + + If a command is run as transient service unit, it will be started and managed by the service manager like any + other service, and thus shows up in the output of systemctl list-units like any other unit. It + will run in a clean and detached execution environment, with the service manager as its parent process. In this + mode, systemd-run will start the service asynchronously in the background and return after the + command has begun execution (unless or are specified, see + below). + + If a command is run as transient scope unit, it will be executed by systemd-run + itself as parent process and will thus inherit the execution environment of the caller. However, the + processes of the command are managed by the service manager similarly to normal services, and will show + up in the output of systemctl list-units. Execution in this case is synchronous, and + will return only when the command finishes. This mode is enabled via the switch + (see below). + + If a command is run with path, socket, or timer options such as (see below), + a transient path, socket, or timer unit is created alongside the service unit for the specified command. Only the + transient path, socket, or timer unit is started immediately, the transient service unit will be triggered by the + path, socket, or timer unit. If the option is specified, the + COMMAND may be omitted. In this case, systemd-run creates only a + .path, .socket, or .timer unit that triggers the + specified unit. + + By default, services created with systemd-run default to the + type, see the description of Type= in + systemd.service5 for + details. Note that when this type is used, the service manager (and thus the + systemd-run command) considers service start-up successful as soon as the + fork() for the main service process succeeded, i.e. before the + execve() is invoked, and thus even if the specified command cannot be started. + Consider using the service type (i.e. ) to + ensure that systemd-run returns successfully only if the specified command line has + been successfully started. + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + + Create a transient .scope unit instead of the default transient + .service unit (see above). + + + + + + + + + Use this unit name instead of an automatically + generated one. + + + + + + + Sets a property on the scope or service unit that is created. This option takes an assignment + in the same format as + systemctl1's + set-property command. + + + + + + + Provide a description for the service, scope, path, socket, or timer unit. If not specified, + the command itself will be used as a description. See Description= in + systemd.unit5. + + + + + + + Make the new .service or .scope unit part + of the specified slice, instead of system.slice (when running in + mode) or the root slice (when running in + mode). + + + + + + + Make the new .service or .scope unit part + of the inherited slice. This option can be combined with . + + An inherited slice is located within systemd-run slice. Example: if + systemd-run slice is foo.slice, and the + argument is bar, the unit will be placed under the + foo-bar.slice. + + + + + + + + + After the service process has terminated, keep the service around until it is explicitly + stopped. This is useful to collect runtime information about the service after it finished running. Also see + RemainAfterExit= in + systemd.service5. + + + + + + + + When terminating the scope or service unit, send a SIGHUP immediately after SIGTERM. This is + useful to indicate to shells and shell-like processes that the connection has been severed. Also see + SendSIGHUP= in + systemd.kill5. + + + + + + + + Sets the service type. Also see + Type= in + systemd.service5. This + option has no effect in conjunction with + . Defaults to + simple. + + + + + + + + Runs the service process under the specified UNIX user and group. Also see + User= and Group= in + systemd.exec5. + + + + + + + Runs the service process with the specified + nice level. Also see Nice= in + systemd.exec5. + + + + + + + Runs the service process with the specified working directory. Also see + WorkingDirectory= in + systemd.exec5. + + + + + + + + Similar to , but uses the current working + directory of the caller for the service to execute. + + + + + + + Runs the service process with the specified environment variable set. This parameter + may be used more than once to set multiple variables. When = and + VALUE are omitted, the value of the variable with the same name in the + program environment will be used. + + Also see Environment= in + systemd.exec5. + + + + + + + + When invoking the command, the transient service connects its standard input, output and error + to the terminal systemd-run is invoked on, via a pseudo TTY device. This allows running + programs that expect interactive user input/output as services, such as interactive command shells. + + Note that + machinectl1's + shell command is usually a better alternative for requesting a new, interactive login + session on the local host or a local container. + + See below for details on how this switch combines with . + + + + + + + If specified, standard input, output, and error of the transient service are inherited from the + systemd-run command itself. This allows systemd-run + to be used within shell pipelines. + Note that this mode is not suitable for interactive command shells and similar, as the + service process will not become a TTY controller when invoked on a terminal. Use instead + in that case. + + When both and are used in combination the more appropriate + option is automatically determined and used. Specifically, when invoked with standard input, output and error + connected to a TTY is used, and otherwise . + + When this option is used the original file descriptors systemd-run receives are passed + to the service processes as-is. If the service runs with different privileges than + systemd-run, this means the service might not be able to re-open the passed file + descriptors, due to normal file descriptor access restrictions. If the invoked process is a shell script that + uses the echo "hello" > /dev/stderr construct for writing messages to stderr, this might + cause problems, as this only works if stderr can be re-opened. To mitigate this use the construct echo + "hello" >&2 instead, which is mostly equivalent and avoids this pitfall. + + + + + + + A shortcut for --pty --same-dir --wait --collect --service-type=exec $SHELL, + i.e. requests an interactive shell in the current working directory, running in service context, accessible + with a single switch. + + + + + + + Suppresses additional informational output + while running. This is particularly useful in combination with + when it will suppress the initial + message explaining how to terminate the TTY connection. + + + + + + + + + + Defines a monotonic timer relative to different starting points for starting the specified + command. See OnActiveSec=, OnBootSec=, OnStartupSec=, + OnUnitActiveSec= and OnUnitInactiveSec= in + systemd.timer5 for + details. These options are shortcuts for --timer-property= with the relevant properties. + These options may not be combined with or . + + + + + + + Defines a calendar timer for starting the specified command. See OnCalendar= + in systemd.timer5. This + option is a shortcut for --timer-property=OnCalendar=. This option may not be combined with + or . + + + + + + + + Defines a trigger based on system clock jumps or timezone changes for starting the + specified command. See OnClockChange= and OnTimezoneChange= in + systemd.timer5. These + options are shortcuts for --timer-property=OnClockChange=yes and + --timer-property=OnTimezoneChange=yes. These options may not be combined with + or . + + + + + + + + Sets a property on the path, socket, or timer unit that is created. This option is + similar to , but applies to the transient path, socket, or timer unit + rather than the transient service unit created. This option takes an assignment in the same format as + systemctl1's + set-property command. These options may not be combined with + or . + + + + + + + + Do not synchronously wait for the unit start operation to finish. If this option is not specified, the + start request for the transient unit will be verified, enqueued and systemd-run will wait + until the unit's start-up is completed. By passing this argument, it is only verified and enqueued. This + option may not be combined with . + + + + + + + Synchronously wait for the transient service to terminate. If this option is specified, the + start request for the transient unit is verified, enqueued, and waited for. Subsequently the invoked unit is + monitored, and it is waited until it is deactivated again (most likely because the specified command + completed). On exit, terse information about the unit's runtime is shown, including total runtime (as well as + CPU usage, if was set) and the exit code and status of the main + process. This output may be suppressed with . This option may not be combined with + , or the various path, socket, or timer options. + + + + + + + Unload the transient unit after it completed, even if it failed. Normally, without this option, + all units that ran and failed are kept in memory until the user explicitly resets their failure state with + systemctl reset-failed or an equivalent command. On the other hand, units that ran + successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more + aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for + --property=CollectMode=inactive-or-failed, see the explanation for + CollectMode= in + systemd.unit5 for further + information. + + + + + + + + + + + + All command line arguments after the first non-option argument become part of the command line of + the launched process. + + + + Exit status + + On success, 0 is returned. If systemd-run failed to start the service, a + non-zero return value will be returned. If systemd-run waits for the service to + terminate, the return value will be propagated from the service. 0 will be returned on success, including + all the cases where systemd considers a service to have exited cleanly, see the discussion of + SuccessExitStatus= in + systemd.service5. + + + + + Examples + + + Logging environment variables provided by systemd to services + + # systemd-run env +Running as unit: run-19945.service +# journalctl -u run-19945.service +Sep 08 07:37:21 bupkis systemd[1]: Starting /usr/bin/env... +Sep 08 07:37:21 bupkis systemd[1]: Started /usr/bin/env. +Sep 08 07:37:21 bupkis env[19948]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +Sep 08 07:37:21 bupkis env[19948]: LANG=en_US.UTF-8 +Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64 + + + + Limiting resources available to a command + + # systemd-run -p IOWeight=10 updatedb + + This command invokes the updatedb8 + tool, but lowers the block I/O weight for it to 10. See + systemd.resource-control5 + for more information on the IOWeight= property. + + + + Running commands at a specified time + + The following command will touch a file after 30 seconds. + + # date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo +Mon Dec 8 20:44:24 KST 2014 +Running as unit: run-71.timer +Will run service as unit: run-71.service +# journalctl -b -u run-71.timer +-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. -- +Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo. +Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo. +# journalctl -b -u run-71.service +-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. -- +Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo... +Dec 08 20:44:48 container systemd[1]: Started /bin/touch /tmp/foo. + + + + Allowing access to the tty + + The following command invokes bash1 + as a service passing its standard input, output and error to the calling TTY. + + # systemd-run -t --send-sighup bash + + + + Start <command>screen</command> as a user service + + $ systemd-run --scope --user screen +Running scope as unit run-r14b0047ab6df45bfb45e7786cc839e76.scope. + +$ screen -ls +There is a screen on: + 492..laptop (Detached) +1 Socket in /var/run/screen/S-fatima. + + + This starts the screen process as a child of the + systemd --user process that was started by + user@.service, in a scope unit. A + systemd.scope5 + unit is used instead of a + systemd.service5 + unit, because screen will exit when detaching from the terminal, + and a service unit would be terminated. Running screen + as a user unit has the advantage that it is not part of the session scope. + If KillUserProcesses=yes is configured in + logind.conf5, + the default, the session scope will be terminated when the user logs + out of that session. + + The user@.service is started automatically + when the user first logs in, and stays around as long as at least one + login session is open. After the user logs out of the last session, + user@.service and all services underneath it + are terminated. This behavior is the default, when "lingering" is + not enabled for that user. Enabling lingering means that + user@.service is started automatically during + boot, even if the user is not logged in, and that the service is + not terminated when the user logs out. + + Enabling lingering allows the user to run processes without being logged in, + for example to allow screen to persist after the user logs out, + even if the session scope is terminated. In the default configuration, users can + enable lingering for themselves: + + $ loginctl enable-linger + + + + Return value + + $ systemd-run --user --wait true +$ systemd-run --user --wait -p SuccessExitStatus=11 bash -c 'exit 11' +$ systemd-run --user --wait -p SuccessExitStatus=SIGUSR1 bash -c 'kill -SIGUSR1 $$$$' + + Those three invocations will succeed, i.e. terminate with an exit code of 0. + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.service5, + systemd.scope5, + systemd.slice5, + systemd.exec5, + systemd.resource-control5, + systemd.timer5, + systemd-mount1, + machinectl1 + + + + diff --git a/man/systemd-sleep.conf.xml b/man/systemd-sleep.conf.xml new file mode 100644 index 0000000..bdc4c3c --- /dev/null +++ b/man/systemd-sleep.conf.xml @@ -0,0 +1,235 @@ + + + + + + + systemd-sleep.conf + systemd + + + + systemd-sleep.conf + 5 + + + + systemd-sleep.conf + sleep.conf.d + Suspend and hibernation configuration file + + + + /etc/systemd/sleep.conf + /etc/systemd/sleep.conf.d/*.conf + /run/systemd/sleep.conf.d/*.conf + /usr/lib/systemd/sleep.conf.d/*.conf + + + + Description + + systemd supports four general + power-saving modes: + + + + suspend + + a low-power state + where execution of the OS is paused, + and complete power loss might result + in lost data, and which is fast to + enter and exit. This corresponds to + suspend, standby, or freeze states as + understood by the kernel. + + + + + hibernate + + a low-power state + where execution of the OS is paused, + and complete power loss does not + result in lost data, and which might + be slow to enter and exit. This + corresponds to the hibernation as + understood by the kernel. + + + + + hybrid-sleep + + a low-power state + where execution of the OS is paused, + which might be slow to enter, and on + complete power loss does not result in + lost data but might be slower to exit + in that case. This mode is called + suspend-to-both by the kernel. + + + + + suspend-then-hibernate + + + A low power state where the system is initially suspended (the state is stored in + RAM). If the system supports low-battery alarms (ACPI _BTP), then the system will be woken up by + the ACPI low-battery signal and hibernated (the state is then stored on disk). Also, if not + interrupted within the timespan specified by HibernateDelaySec= or the estimated + timespan until the system battery charge level goes down to 5%, then the system will be woken up by the + RTC alarm and hibernated. The estimated timespan is calculated from the change of the battery + capacity level after the time specified by SuspendEstimationSec= or when + the system is woken up from the suspend. + + + + + + Settings in these files determine what strings + will be written to + /sys/power/disk and + /sys/power/state by + systemd-sleep8 + when + systemd1 + attempts to suspend or hibernate the machine. + See + systemd.syntax7 + for a general description of the syntax. + + + + + + Options + + The following options can be configured in the + [Sleep] section of + /etc/systemd/sleep.conf or a + sleep.conf.d file: + + + + AllowSuspend= + AllowHibernation= + AllowSuspendThenHibernate= + AllowHybridSleep= + + By default any power-saving mode is advertised if possible (i.e. + the kernel supports that mode, the necessary resources are available). Those + switches can be used to disable specific modes. + + If AllowHibernation=no or AllowSuspend=no is + used, this implies AllowSuspendThenHibernate=no and + AllowHybridSleep=no, since those methods use both suspend and hibernation + internally. AllowSuspendThenHibernate=yes and + AllowHybridSleep=yes can be used to override and enable those specific + modes. + + + + SuspendMode= + HibernateMode= + HybridSleepMode= + + The string to be written to /sys/power/disk by, respectively, + systemd-suspend.service8, + systemd-hibernate.service8, + or + systemd-hybrid-sleep.service8. + More than one value can be specified by separating multiple values with whitespace. They will be + tried in turn, until one is written without error. If none of the writes succeed, the operation will + be aborted. + + The allowed set of values is determined by the kernel and is shown in the file itself (use + cat /sys/power/disk to display). See the + kernel documentation for more details. + + + systemd-suspend-then-hibernate.service8 + uses the value of SuspendMode= when suspending and the value of + HibernateMode= when hibernating. + + + + SuspendState= + HibernateState= + HybridSleepState= + + The string to be written to /sys/power/state by, respectively, + systemd-suspend.service8, + systemd-hibernate.service8, + or + systemd-hybrid-sleep.service8. + More than one value can be specified by separating multiple values with whitespace. They will be + tried in turn, until one is written without error. If none of the writes succeed, the operation will + be aborted. + + + The allowed set of values is determined by the kernel and is shown in the file itself (use + cat /sys/power/state to display). See the + kernel documentation for more details. + + + systemd-suspend-then-hibernate.service8 + uses the value of SuspendState= when suspending and the value of + HibernateState= when hibernating. + + + + HibernateDelaySec= + + + The amount of time the system spends in suspend mode before the system is + automatically put into hibernate mode. Only used by + systemd-suspend-then-hibernate.service8. + If the system has a battery, then defaults to the estimated timespan until the system battery charge level goes down to 5%. + If the system has no battery, then defaults to 2h. + + + + + SuspendEstimationSec= + + + The RTC alarm will wake the system after the specified timespan to measure the system battery + capacity level and estimate battery discharging rate, which is used for estimating timespan until the system battery charge + level goes down to 5%. Only used by + systemd-suspend-then-hibernate.service8. + Defaults to 1h. + + + + + + Example: freeze + + Example: to exploit the freeze mode added + in Linux 3.9, one can use systemctl suspend + with + [Sleep] +SuspendState=freeze + + + + See Also + + systemd-sleep8, + systemd-suspend.service8, + systemd-hibernate.service8, + systemd-hybrid-sleep.service8, + systemd-suspend-then-hibernate.service8, + systemd1, + systemd.directives7 + + + + diff --git a/man/systemd-socket-activate.xml b/man/systemd-socket-activate.xml new file mode 100644 index 0000000..a9d00dc --- /dev/null +++ b/man/systemd-socket-activate.xml @@ -0,0 +1,182 @@ + + + + + + + + systemd-socket-activate + systemd + + + + systemd-socket-activate + 1 + + + + systemd-socket-activate + Test socket activation of daemons + + + + + systemd-socket-activate + OPTIONS + daemon + OPTIONS + + + + + Description + + systemd-socket-activate may be used to launch a socket-activated service program from the + command line for testing purposes. It may also be used to launch individual instances of the service program per + connection. + + + The daemon to launch and its options should be specified + after options intended for systemd-socket-activate. + + + If the option is given, the socket file descriptor will be used as the standard + input and output of the launched process. Otherwise, standard input and output will be inherited, and sockets will + be passed through file descriptors 3 and higher. Sockets passed through $LISTEN_FDS to + systemd-socket-activate will be passed through to the daemon, in the original positions. Other sockets + specified with will use consecutive descriptors. By default, + systemd-socket-activate listens on a stream socket, use and + to listen on datagram or sequential packet sockets instead (see below). + + + + + Options + + + + + + Listen on this address. + Takes a string like 2000 or + 127.0.0.1:2001. + + + + + + + + Launch an instance of the service program for each connection and pass the connection + socket. + + + + + + + Listen on a datagram socket (SOCK_DGRAM), instead of a stream socket + (SOCK_STREAM). May not be combined with . + + + + + + Listen on a sequential packet socket (SOCK_SEQPACKET), instead of a stream + socket (SOCK_STREAM). May not be combined with + . + + + + + + Use the inetd protocol for passing file descriptors, i.e. as standard input and standard + output, instead of the new-style protocol for passing file descriptors using $LISTEN_FDS + (see above). + + + + + + + Add this variable to the environment of the + launched process. If VAR is + followed by =, assume that it is a + variable–value pair. Otherwise, obtain the value from the + environment of systemd-socket-activate itself. + + + + + NAME:NAME… + + Specify names for the file descriptors passed. This is equivalent to setting + FileDescriptorName= in socket unit files, and enables use of + sd_listen_fds_with_names3. + Multiple entries may be specifies using separate options or by separating names with colons + (:) in one option. In case more names are given than descriptors, superfluous ones will be + ignored. In case less names are given than descriptors, the remaining file descriptors will be unnamed. + + + + + + + + + + Environment variables + + + $LISTEN_FDS + $LISTEN_PID + $LISTEN_FDNAMES + + See + sd_listen_fds3. + + + + $SYSTEMD_LOG_TARGET + $SYSTEMD_LOG_LEVEL + $SYSTEMD_LOG_TIME + $SYSTEMD_LOG_COLOR + $SYSTEMD_LOG_LOCATION + + Same as in + systemd1. + + + + + + Examples + + + Run an echo server on port 2000 + + $ systemd-socket-activate -l 2000 --inetd -a cat + + + + Run a socket-activated instance of <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + $ systemd-socket-activate -l 19531 /usr/lib/systemd/systemd-journal-gatewayd + + + + + See Also + + systemd1, + systemd.socket5, + systemd.service5, + systemd-run1, + sd_listen_fds3, + sd_listen_fds_with_names3, + cat1 + + + diff --git a/man/systemd-socket-proxyd.xml b/man/systemd-socket-proxyd.xml new file mode 100644 index 0000000..e512a43 --- /dev/null +++ b/man/systemd-socket-proxyd.xml @@ -0,0 +1,184 @@ + + + + + + + + systemd-socket-proxyd + systemd + + + systemd-socket-proxyd + 8 + + + systemd-socket-proxyd + Bidirectionally proxy local sockets to another (possibly remote) socket + + + + systemd-socket-proxyd + OPTIONS + HOST:PORT + + + systemd-socket-proxyd + OPTIONS + UNIX-DOMAIN-SOCKET-PATH + + + + + Description + + systemd-socket-proxyd is a generic + socket-activated network socket forwarder proxy daemon for IPv4, + IPv6 and UNIX stream sockets. It may be used to bi-directionally + forward traffic from a local listening socket to a local or remote + destination socket. + + One use of this tool is to provide socket activation support + for services that do not natively support socket activation. On + behalf of the service to activate, the proxy inherits the socket + from systemd, accepts each client connection, opens a connection + to a configured server for each client, and then bidirectionally + forwards data between the two. + This utility's behavior is similar to + socat1. + The main differences for systemd-socket-proxyd + are support for socket activation with + Accept=no and an event-driven + design that scales better with the number of + connections. + + + Options + The following options are understood: + + + + + + + + Sets the maximum number of simultaneous connections, defaults to 256. + If the limit of concurrent connections is reached further connections will be refused. + + + + + Sets the time before exiting when there are no connections, defaults to + infinity. Takes a unit-less value in seconds, or a time span value such + as 5min 20s. + + + + + Exit status + On success, 0 is returned, a non-zero failure + code otherwise. + + + Examples + + Simple Example + Use two services with a dependency and no namespace + isolation. + + proxy-to-nginx.socket + + + + proxy-to-nginx.service + + + + nginx.conf + + + + + + Enabling the proxy + + + If nginx.service has StopWhenUnneeded= set, then + passing to systemd-socket-proxyd allows + both services to stop during idle periods. + + + Namespace Example + Similar as above, but runs the socket proxy and the main + service in the same private namespace, assuming that + nginx.service has + PrivateTmp= and + PrivateNetwork= set, too. + + proxy-to-nginx.socket + + + + proxy-to-nginx.service + + + + nginx.conf + + + + Enabling the proxy + + + + + + See Also + + systemd1, + systemd.socket5, + systemd.service5, + systemctl1, + socat1, + nginx1, + curl1 + + + diff --git a/man/systemd-stdio-bridge.xml b/man/systemd-stdio-bridge.xml new file mode 100644 index 0000000..0dce565 --- /dev/null +++ b/man/systemd-stdio-bridge.xml @@ -0,0 +1,91 @@ + + + + + + + + systemd-stdio-bridge + systemd + + + + systemd-stdio-bridge + 1 + + + + systemd-stdio-bridge + D-Bus proxy + + + + + systemd-stdio-bridge + OPTIONS + + + + + Description + + systemd-stdio-bridge implements a proxy between STDIN/STDOUT and a D-Bus bus. It + expects to receive an open connection via STDIN/STDOUT when started, and will create a new connection to + the specified bus. It will then forward messages between the two connections. This program is suitable + for socket activation: the first connection may be a pipe or a socket and must be passed as either + standard input, or as an open file descriptor according to the protocol described in + sd_listen_fds3. The + second connection will be made by default to the local system bus, but this can be influenced by the + , , , and + options described below. + + sd-bus3 uses + systemd-stdio-bridge to forward D-Bus connections over + ssh1, + or to connect to the bus of a different user, see + sd_bus_set_address3. + + + + + Options + + The following options are understood: + + + + + + + + + + + Path to the bus address. Default: unix:path=/run/dbus/system_bus_socket + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + See Also + + dbus-daemon1, + dbus-broker1, + D-Bus, + systemd1 + + + + diff --git a/man/systemd-stub.xml b/man/systemd-stub.xml new file mode 100644 index 0000000..415d663 --- /dev/null +++ b/man/systemd-stub.xml @@ -0,0 +1,440 @@ + + + + + + + systemd-stub + systemd + + + + systemd-stub + 7 + + + + systemd-stub + sd-stub + linuxx64.efi.stub + linuxia32.efi.stub + linuxaa64.efi.stub + A simple UEFI kernel boot stub + + + + /usr/lib/systemd/boot/efi/linuxx64.efi.stub + /usr/lib/systemd/boot/efi/linuxia32.efi.stub + /usr/lib/systemd/boot/efi/linuxaa64.efi.stub + ESP/.../foo.efi.extra.d/*.cred + ESP/.../foo.efi.extra.d/*.raw + ESP/loader/credentials/*.cred + + + + Description + + systemd-stub (stored in per-architecture files + linuxx64.efi.stub, linuxia32.efi.stub, + linuxaa64.efi.stub on disk) is a simple UEFI boot stub. An UEFI boot stub is + attached to a Linux kernel binary image, and is a piece of code that runs in the UEFI firmware + environment before transitioning into the Linux kernel environment. The UEFI boot stub ensures a Linux + kernel is executable as regular UEFI binary, and is able to do various preparations before switching the + system into the Linux world. + + The UEFI boot stub looks for various resources for the kernel invocation inside the UEFI PE binary + itself. This allows combining various resources inside a single PE binary image (usually called "Unified + Kernel Image", or "UKI" for short), which may then be signed via UEFI SecureBoot as a whole, covering all + individual resources at once. Specifically it may include: + + + The ELF Linux kernel images will be looked for in the .linux PE + section of the executed image. + + OS release information, i.e. the + os-release5 file of + the OS the kernel belongs to, in the .osrel PE section. + + The initrd will be loaded from the .initrd PE section. + + + A compiled binary DeviceTree will be looked for in the .dtb PE + section. + + The kernel command line to pass to the invoked kernel will be looked for in the + .cmdline PE section. + + A boot splash (in Windows .BMP format) to show on screen before + invoking the kernel will be looked for in the .splash PE section. + + A set of cryptographic signatures for expected TPM2 PCR values when this kernel is + booted, in JSON format, in the .pcrsig section. This is useful for implementing TPM2 + policies that bind disk encryption and similar to kernels that are signed by a specific + key. + + A public key in PEM format matching this TPM2 PCR signature data in the + .pcrpkey section. + + + If UEFI SecureBoot is enabled and the .cmdline section is present in the executed + image, any attempts to override the kernel command line by passing one as invocation parameters to the + EFI binary are ignored. Thus, in order to allow overriding the kernel command line, either disable UEFI + SecureBoot, or don't include a kernel command line PE section in the kernel image file. If a command line + is accepted via EFI invocation parameters to the EFI binary it is measured into TPM PCR 12 (if a TPM is + present). + + If a DeviceTree is embedded in the .dtb section, it replaces an existing + DeviceTree in the corresponding EFI configuration table. systemd-stub will ask the firmware via the + EFI_DT_FIXUP_PROTOCOL for hardware specific fixups to the DeviceTree. + + The contents of seven of these eight PE sections are measured into TPM PCR 11, that is otherwise + not used. Thus, it can be pre-calculated without too much effort. The .pcrsig section + is not included in this PCR measurement, since it's supposed to contain signatures for the expected + results for these measurements, i.e. of the outputs of the measurement operation, and thus cannot also be + input to it. + + When .pcrsig and/or .pcrpkey are present in a unified kernel + image their contents are passed to the booted kernel in an synthetic initrd cpio archive that places them in the + /.extra/tpm2-pcr-signature.json and + /.extra/tpm2-pcr-public-key.pem files. Typically, a + tmpfiles.d5 line then + ensures they are copied into /run/systemd/tpm2-pcr-signature.json and + /run/systemd/tpm2-pcr-public-key.pem where they remain accessible even after the + system transitions out of the initrd environment into the host file system. Tools such + systemd-cryptsetup@.service8, + systemd-cryptenroll1 + and systemd-creds1 + will automatically use files present under these paths to unlock protected resources (encrypted storage + or credentials) or bind encryption to booted kernels. + + + + Companion Files + + The systemd-stub UEFI boot stub automatically collects two types of auxiliary + companion files optionally placed in drop-in directories on the same partition as the EFI binary, + dynamically generates cpio initrd archives from them, and passes them to the kernel. + Specifically: + + + For a kernel binary called foo.efi, it + will look for files with the .cred suffix in a directory named + foo.efi.extra.d/ next to it. A cpio + archive is generated from all files found that way, placing them in the + /.extra/credentials/ directory of the initrd file hierarchy. The main initrd may + then access them in this directory. This is supposed to be used to store auxiliary, encrypted, + authenticated credentials for use with LoadCredentialEncrypted= in the UEFI System + Partition. See + systemd.exec5 + and + systemd-creds1 + for + details on encrypted credentials. The generated cpio archive is measured into TPM + PCR 12 (if a TPM is present). + + Similarly, files foo.efi.extra.d/*.raw + are packed up in a cpio archive and placed in the /.extra/sysext/ + directory in the initrd file hierarchy. This is supposed to be used to pass additional system extension + images to the initrd. See + systemd-sysext8 for + details on system extension images. The generated cpio archive containing these + system extension images is measured into TPM PCR 13 (if a TPM is present). + + Files /loader/credentials/*.cred are packed up in a + cpio archive and placed in the /.extra/global_credentials/ + directory of the initrd file hierarchy. This is supposed to be used to pass additional credentials to + the initrd, regardless of the kernel being booted. The generated cpio archive is + measured into TPM PCR 12 (if a TPM is present) + + + These mechanisms may be used to parameterize and extend trusted (i.e. signed), immutable initrd + images in a reasonably safe way: all data they contain is measured into TPM PCRs. On access they should be + further validated: in case of the credentials case by encrypting/authenticating them via TPM, as exposed + by systemd-creds encrypt -T (see + systemd-creds1 for + details); in case of the system extension images by using signed Verity images. + + + + TPM PCR Notes + + Note that when a unified kernel using systemd-stub is invoked the firmware will + measure it as a whole to TPM PCR 4, covering all embedded resources, such as the stub code itself, the + core kernel, the embedded initrd and kernel command line (see above for a full list). + + Also note that the Linux kernel will measure all initrds it receives into TPM PCR 9. This means + every type of initrd will be measured two or three times: the initrd embedded in the kernel image will be + measured to PCR 4, PCR 9 and PCR 11; the initrd synthesized from credentials will be measured to both PCR + 9 and PCR 12; the initrd synthesized from system extensions will be measured to both PCR 4 and PCR + 9. Let's summarize the OS resources and the PCRs they are measured to: + + + OS Resource PCR Summary + + + + + + + + OS Resource + Measurement PCR + + + + + + systemd-stub code (the entry point of the unified PE binary) + 4 + + + + Core kernel code (embedded in unified PE binary) + 4 + 11 + + + + OS release information (embedded in the unified PE binary) + 4 + 11 + + + + Main initrd (embedded in unified PE binary) + 4 + 9 + 11 + + + + Default kernel command line (embedded in unified PE binary) + 4 + 11 + + + + Overridden kernel command line + 12 + + + + Boot splash (embedded in the unified PE binary) + 4 + 11 + + + + TPM2 PCR signature JSON (embedded in unified PE binary, synthesized into initrd) + 4 + 9 + + + + TPM2 PCR PEM public key (embedded in unified PE binary, synthesized into initrd) + 4 + 9 + 11 + + + + Credentials (synthesized initrd from companion files) + 9 + 12 + + + + System Extensions (synthesized initrd from companion files) + 9 + 13 + + + +
+ + + + EFI Variables + + The following EFI variables are defined, set and read by systemd-stub, under the + vendor UUID 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f, for communication between the boot + stub and the OS: + + + + LoaderDevicePartUUID + + Contains the partition UUID of the EFI System Partition the EFI image was run + from. systemd-gpt-auto-generator8 + uses this information to automatically find the disk booted from, in order to discover various other + partitions on the same disk automatically. + + + + LoaderFirmwareInfo + LoaderFirmwareType + + Brief firmware information. Use + bootctl1 to view this + data. + + + + LoaderImageIdentifier + + The path of EFI executable, relative to the EFI System Partition's root + directory. Use + bootctl1 to view + this data. + + + + StubInfo + + Brief stub information. Use + bootctl1 to view + this data. + + + + StubPcrKernelImage + + The PCR register index the kernel image, initrd image, boot splash, devicetree + database, and the embedded command line are measured into, formatted as decimal ASCII string (e.g. + 11). This variable is set if a measurement was successfully completed, and remains + unset otherwise. + + + + StubPcrKernelParameters + + The PCR register index the kernel command line and credentials are measured into, + formatted as decimal ASCII string (e.g. 12). This variable is set if a measurement + was successfully completed, and remains unset otherwise. + + + + StubPcrInitRDSysExts + + The PCR register index the systemd extensions for the initrd, which are picked up + from the file system the kernel image is located on. Formatted as decimal ASCII string (e.g. + 13). This variable is set if a measurement was successfully completed, and remains + unset otherwise. + + + + Note that some of the variables above may also be set by the boot loader. The stub will only set + them if they aren't set already. Some of these variables are defined by the Boot Loader Interface. + + + + initrd Resources + + The following resources are passed as initrd cpio archives to the booted kernel, and thus make up + the initial file system hierarchy in the initrd execution environment: + + + + / + + The main initrd from the .initrd PE section of the unified kernel image. + + + + /.extra/credentials/*.cred + Credential files (suffix .cred) that are placed next to the + unified kernel image (as described above) are copied into the + /.extra/credentials/ directory in the initrd execution + environment. + + + + /.extra/global_credentials/*.cred + Similar, credential files in the /loader/credentials/ directory + in the file system the unified kernel image is placed in are copied into the + /.extra/global_credentials/ directory in the initrd execution + environment. + + + + /.extra/sysext/*.raw + System extension image files (suffix .raw) that are placed next to + the unified kernel image (as described above) are copied into the + /.extra/sysext/ directory in the initrd execution environment. + + + + /.extra/tpm2-pcr-signature.json + The TPM2 PCR signature JSON object included in the .pcrsig PE + section of the unified kernel image is copied into the + /.extra/tpm2-pcr-signature.json file in the initrd execution + environment. + + + + /.extra/tpm2-pcr-pkey.pem + The PEM public key included in the .pcrpkey PE section of the + unified kernel image is copied into the /.extra/tpm2-pcr-public-key.pem file in + the initrd execution environment. + + + + Note that all these files are located in the tmpfs file system the kernel sets + up for the initrd file hierarchy and are thus lost when the system transitions from the initrd execution + environment into the host file system. If these resources shall be kept around over this transition they + need to be copied to a place that survives the transition first, for example via a suitable + tmpfiles.d5 line. By + default, this is done for the TPM2 PCR signature and public key files. + + + + Assembling Kernel Images + + In order to assemble an UEFI PE kernel image from various components as described above, use an + objcopy1 command line + like this: + + objcopy \ + --add-section .osrel=os-release --change-section-vma .osrel=0x20000 \ + --add-section .cmdline=cmdline.txt --change-section-vma .cmdline=0x30000 \ + --add-section .dtb=devicetree.dtb --change-section-vma .dtb=0x40000 \ + --add-section .splash=splash.bmp --change-section-vma .splash=0x100000 \ + --add-section .linux=vmlinux --change-section-vma .linux=0x2000000 \ + --add-section .initrd=initrd.cpio --change-section-vma .initrd=0x3000000 \ + /usr/lib/systemd/boot/efi/linuxx64.efi.stub \ + foo-unsigned.efi + + Note that these PE section offsets are example values and a properly assembled image must not + contain any overlapping sections (this includes already existing sections inside the stub before + assembly) or boot may fail. + + This generates one PE executable file foo-unsigned.efi from the six individual + files for OS release information, kernel command line, boot splash image, kernel image, main initrd and + UEFI boot stub. + + To then sign the resulting image for UEFI SecureBoot use an + sbsign1 command like + the following: + + sbsign \ + --key mykey.pem \ + --cert mykey.crt \ + --output foo.efi \ + foo-unsigned.efi + + This expects a pair of X.509 private key and certificate as parameters and then signs the UEFI PE + executable we generated above for UEFI SecureBoot and generates a signed UEFI PE executable as + result. + + See + systemd-measure1 for + an example involving the .pcrsig and .pcrpkey sections. + + + + See Also + + systemd-boot7, + systemd.exec5, + systemd-creds1, + systemd-sysext8, + Boot Loader Specification, + Boot Loader Interface, + objcopy1, + sbsign1, + systemd-measure1 + + + diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml new file mode 100644 index 0000000..2924936 --- /dev/null +++ b/man/systemd-suspend.service.xml @@ -0,0 +1,127 @@ + + + + + + + + systemd-suspend.service + systemd + + + + systemd-suspend.service + 8 + + + + systemd-suspend.service + systemd-hibernate.service + systemd-hybrid-sleep.service + systemd-suspend-then-hibernate.service + systemd-sleep + System sleep state logic + + + + systemd-suspend.service + systemd-hibernate.service + systemd-hybrid-sleep.service + systemd-suspend-then-hibernate.service + /usr/lib/systemd/system-sleep + + + + Description + + systemd-suspend.service is a system + service that is pulled in by suspend.target + and is responsible for the actual system suspend. Similarly, + systemd-hibernate.service is pulled in by + hibernate.target to execute the actual + hibernation. Finally, + systemd-hybrid-sleep.service is pulled in by + hybrid-sleep.target to execute hybrid + hibernation with system suspend and pulled in by + suspend-then-hibernate.target to execute system suspend + with a timeout that will activate hibernate later. + + Immediately before entering system suspend and/or + hibernation systemd-suspend.service (and the + other mentioned units, respectively) will run all executables in + /usr/lib/systemd/system-sleep/ and pass two + arguments to them. The first argument will be + pre, the second either + suspend, hibernate, + hybrid-sleep, or suspend-then-hibernate + depending on the chosen action. An environment variable called SYSTEMD_SLEEP_ACTION + will be set and contain the sleep action that is processing. This is primarily helpful for + suspend-then-hibernate where the value of the variable will be suspend, hibernate, + or suspend-after-failed-hibernate in cases where hibernation has failed. + Immediately after leaving system suspend and/or hibernation the + same executables are run, but the first argument is now + post. All executables in this directory are + executed in parallel, and execution of the action is not continued + until all executables have finished. + + Note that scripts or binaries dropped in + /usr/lib/systemd/system-sleep/ are intended + for local use only and should be considered hacks. If applications + want to react to system suspend/hibernation and resume, + they should rather use the Inhibitor + interface. + + Note that systemd-suspend.service, + systemd-hibernate.service, systemd-hybrid-sleep.service, and + systemd-suspend-then-hibernate.service should never be executed directly. Instead, + trigger system sleep with a command such as systemctl suspend or systemctl + hibernate. + + Internally, this service will echo a string like + mem into /sys/power/state, + to trigger the actual system suspend. What exactly is written + where can be configured in the [Sleep] section + of /etc/systemd/sleep.conf or a + sleep.conf.d file. See + systemd-sleep.conf5. + + + + + Options + + systemd-sleep understands the + following commands: + + + + + + + + + + + + Suspend, hibernate, suspend then hibernate, or put the + system to hybrid sleep. + + + + + + + See Also + + systemd-sleep.conf5, + systemd1, + systemctl1, + systemd.special7, + systemd-halt.service8 + + + + diff --git a/man/systemd-sysctl.service.xml b/man/systemd-sysctl.service.xml new file mode 100644 index 0000000..fede8b0 --- /dev/null +++ b/man/systemd-sysctl.service.xml @@ -0,0 +1,161 @@ + + + + + + + + systemd-sysctl.service + systemd + + + + systemd-sysctl.service + 8 + + + + systemd-sysctl.service + systemd-sysctl + Configure kernel parameters at boot + + + + + /usr/lib/systemd/systemd-sysctl + OPTIONS + CONFIGFILE + + systemd-sysctl.service + + + + Description + + systemd-sysctl.service is an early boot + service that configures + sysctl8 + kernel parameters by invoking /usr/lib/systemd/systemd-sysctl. + + When invoked with no arguments, /usr/lib/systemd/systemd-sysctl applies + all directives from configuration files listed in + sysctl.d5. + If one or more filenames are passed on the command line, only the directives in these files are + applied. + + In addition, option may be used to limit which sysctl + settings are applied. + + See + sysctl.d5 + for information about the configuration of sysctl settings. After sysctl configuration is + changed on disk, it must be written to the files in /proc/sys/ before it + takes effect. It is possible to update specific settings, or simply to reload all configuration, + see Examples below. + + + Options + + + + + Only apply rules with the specified prefix. + + + + + + Always return non-zero exit code on failure (including invalid sysctl variable + name and insufficient permissions), unless the sysctl variable name is prefixed with a "-" + character. + + + + + + + + + + + + + Credentials + + systemd-sysctl supports the service credentials logic as implemented by + LoadCredential=/SetCredential= (see + systemd.exec1 for + details). The following credentials are used when passed in: + + + + sysctl.extra + + The contents of this credential may contain additional lines to operate on. The + credential contents should follow the same format as any other sysctl.d/ drop-in + configuration file. If this credential is passed it is processed after all of the drop-in files read + from the file system. The settings configured in the credential hence take precedence over those in + the file system. + + + + Note that by default the systemd-sysctl.service unit file is set up to inherit + the sysctl.extra credential from the service manager. + + + + Examples + + + Reset all sysctl settings + + systemctl restart systemd-sysctl + + + + View coredump handler configuration + + # sysctl kernel.core_pattern +kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I + + + + + Update coredump handler configuration + + # /usr/lib/systemd/systemd-sysctl --prefix kernel.core_pattern + + This searches all the directories listed in + sysctl.d5 + for configuration files and writes /proc/sys/kernel/core_pattern. + + + + Update coredump handler configuration according to a specific file + + # /usr/lib/systemd/systemd-sysctl 50-coredump.conf + + This applies all the settings found in 50-coredump.conf. + Either /etc/sysctl.d/50-coredump.conf, or + /run/sysctl.d/50-coredump.conf, or + /usr/lib/sysctl.d/50-coredump.conf will be used, in the order + of preference. + + + See + sysctl8 + for various ways to directly apply sysctl settings. + + + + See Also + + systemd1, + sysctl.d5, + sysctl8 + + + + diff --git a/man/systemd-sysext.xml b/man/systemd-sysext.xml new file mode 100644 index 0000000..aa0d42d --- /dev/null +++ b/man/systemd-sysext.xml @@ -0,0 +1,253 @@ + + + + + + + + systemd-sysext + systemd + + + + systemd-sysext + 8 + + + + systemd-sysext + systemd-sysext.service + Activates System Extension Images + + + + + systemd-sysext + OPTIONS + COMMAND + + + systemd-sysext.service + + + + + Description + + systemd-sysext activates/deactivates system extension images. System extension + images may – dynamically at runtime — extend the /usr/ and + /opt/ directory hierarchies with additional files. This is particularly useful on + immutable system images where a /usr/ and/or /opt/ hierarchy + residing on a read-only file system shall be extended temporarily at runtime without making any + persistent modifications. + + System extension images should contain files and directories similar in fashion to regular + operating system tree. When one or more system extension images are activated, their + /usr/ and /opt/ hierarchies are combined via + overlayfs with the same hierarchies of the host OS, and the host + /usr/ and /opt/ overmounted with it ("merging"). When they are + deactivated, the mount point is disassembled — again revealing the unmodified original host version of + the hierarchy ("unmerging"). Merging thus makes the extension's resources suddenly appear below the + /usr/ and /opt/ hierarchies as if they were included in the + base OS image itself. Unmerging makes them disappear again, leaving in place only the files that were + shipped with the base OS image itself. + + Files and directories contained in the extension images outside of the /usr/ + and /opt/ hierarchies are not merged, and hence have no effect + when included in a system extension image. In particular, files in the /etc/ and + /var/ included in a system extension image will not appear in + the respective hierarchies after activation. + + System extension images are strictly read-only, and the host /usr/ and + /opt/ hierarchies become read-only too while they are activated. + + System extensions are supposed to be purely additive, i.e. they are supposed to include only files + that do not exist in the underlying basic OS image. However, the underlying mechanism (overlayfs) also + allows overlaying or removing files, but it is recommended not to make use of this. + + System extension images may be provided in the following formats: + + + Plain directories or btrfs subvolumes containing the OS tree + Disk images with a GPT disk label, following the Discoverable Partitions Specification + Disk images lacking a partition table, with a naked Linux file system (e.g. squashfs or ext4) + + + These image formats are the same ones that + systemd-nspawn1 + supports via its / switches and those that the + service manager supports via /. Similar to + them they may optionally carry Verity authentication information. + + System extensions are automatically looked for in the directories + /etc/extensions/, /run/extensions/, + /var/lib/extensions/, /usr/lib/extensions/ and + /usr/local/lib/extensions/. The first two listed directories are not suitable for + carrying large binary images, however are still useful for carrying symlinks to them. The primary place + for installing system extensions is /var/lib/extensions/. Any directories found in + these search directories are considered directory based extension images, any files with the + .raw suffix are considered disk image based extension images. + + During boot OS extension images are activated automatically, if the + systemd-sysext.service is enabled. Note that this service runs only after the + underlying file systems where system extensions may be located have been mounted. This means they are not + suitable for shipping resources that are processed by subsystems running in earliest boot. Specifically, + OS extension images are not suitable for shipping system services or + systemd-sysusers8 + definitions. See Portable Services for a simple + mechanism for shipping system services in disk images, in a similar fashion to OS extensions. Note the + different isolation on these two mechanisms: while system extension directly extend the underlying OS + image with additional files that appear in a way very similar to as if they were shipped in the OS image + itself and thus imply no security isolation, portable services imply service level sandboxing in one way + or another. The systemd-sysext.service service is guaranteed to finish start-up + before basic.target is reached; i.e. at the time regular services initialize (those + which do not use DefaultDependencies=no), the files and directories system extensions + provide are available in /usr/ and /opt/ and may be + accessed. + + Note that there is no concept of enabling/disabling installed system extension images: all + installed extension images are automatically activated at boot. However, you can place an empty directory + named like the extension (no .raw) in /etc/extensions/ to "mask" + an extension with the same name in a system folder with lower precedence. + + A simple mechanism for version compatibility is enforced: a system extension image must carry a + /usr/lib/extension-release.d/extension-release.$name + file, which must match its image name, that is compared with the host os-release + file: the contained ID= fields have to match unless _any is set + for the extension. If the extension ID= is not _any, the + SYSEXT_LEVEL= field (if defined) has to match. If the latter is not defined, the + VERSION_ID= field has to match instead. If the extension defines the + ARCHITECTURE= field and the value is not _any it has to match the kernel's + architecture reported by uname2 + but the used architecture identifiers are the same as for ConditionArchitecture= + described in systemd.unit5. + System extensions should not ship a /usr/lib/os-release file (as that would be merged + into the host /usr/ tree, overriding the host OS version data, which is not desirable). + The extension-release file follows the same format and semantics, and carries the same + content, as the os-release file of the OS, but it describes the resources carried + in the extension image. + + + + Uses + + The primary use case for system images are immutable environments where debugging and development + tools shall optionally be made available, but not included in the immutable base OS image itself (e.g. + strace1 + and + gdb1 + shall be an optionally installable addition in order to make debugging/development easier). System + extension images should not be misunderstood as a generic software packaging framework, as no dependency + scheme is available: system extensions should carry all files they need themselves, except for those + already shipped in the underlying host system image. Typically, system extension images are built at the + same time as the base OS image — within the same build system. + + Another use case for the system extension concept is temporarily overriding OS supplied resources + with newer ones, for example to install a locally compiled development version of some low-level + component over the immutable OS image without doing a full OS rebuild or modifying the nominally + immutable image. (e.g. "install" a locally built package with DESTDIR=/var/lib/extensions/mytest + make install && systemd-sysext refresh, making it available in + /usr/ as if it was installed in the OS image itself.) This case works regardless if + the underlying host /usr/ is managed as immutable disk image or is a traditional + package manager controlled (i.e. writable) tree. + + + + Commands + + The following commands are understood: + + + + + + When invoked without any command verb, or when is specified + the current merge status is shown, separately for both /usr/ and + /opt/. + + + + + Merges all currently installed system extension images into + /usr/ and /opt/, by overmounting these hierarchies with an + overlayfs file system combining the underlying hierarchies with those included in + the extension images. This command will fail if the hierarchies are already merged. + + + + + Unmerges all currently installed system extension images from + /usr/ and /opt/, by unmounting the + overlayfs file systems created by + prior. + + + + + A combination of and : if already + mounted the existing overlayfs instance is unmounted temporarily, and then + replaced by a new version. This command is useful after installing/removing system extension images, + in order to update the overlayfs file system accordingly. If no system extensions + are installed when this command is executed, the equivalent of is + executed, without establishing any new overlayfs instance. Note that currently + there's a brief moment where neither the old nor the new overlayfs file system is + mounted. This implies that all resources supplied by a system extension will briefly disappear — even + if it exists continuously during the refresh operation. + + + + + + A brief list of installed extension images is shown. + + + + + + + + + Options + + + + + + Operate relative to the specified root directory, i.e. establish the + overlayfs mount not on the top-level host /usr/ and + /opt/ hierarchies, but below some specified root directory. + + + + + + When merging system extensions into /usr/ and + /opt/, ignore version incompatibilities, i.e. force merging regardless of + whether the version information included in the extension images matches the host or + not. + + + + + + + + + + Exit status + + On success, 0 is returned. + + + + See Also + + systemd1, + systemd-nspawn1 + + + + diff --git a/man/systemd-system-update-generator.xml b/man/systemd-system-update-generator.xml new file mode 100644 index 0000000..8711be2 --- /dev/null +++ b/man/systemd-system-update-generator.xml @@ -0,0 +1,50 @@ + + + + + + + + systemd-system-update-generator + systemd + + + + systemd-system-update-generator + 8 + + + + systemd-system-update-generator + Generator for redirecting boot to offline update mode + + + + /usr/lib/systemd/system-generators/systemd-system-update-generator + + + + Description + + systemd-system-update-generator is a + generator that automatically redirects the boot process to + system-update.target, if + /system-update exists. This is required to + implement the logic explained in the + systemd.offline-updates7. + + + systemd-system-update-generator implements + systemd.generator7. + + + + See Also + + systemd1, + systemd.special7 + + + + diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml new file mode 100644 index 0000000..2bdfa1c --- /dev/null +++ b/man/systemd-system.conf.xml @@ -0,0 +1,619 @@ + + +%entities; +]> + + + + + systemd-system.conf + systemd + + + + systemd-system.conf + 5 + + + + systemd-system.conf + system.conf.d + systemd-user.conf + user.conf.d + System and session service manager configuration files + + + + /etc/systemd/system.conf, + /etc/systemd/system.conf.d/*.conf, + /run/systemd/system.conf.d/*.conf, + /usr/lib/systemd/system.conf.d/*.conf + + ~/.config/systemd/user.conf, + /etc/systemd/user.conf, + /etc/systemd/user.conf.d/*.conf, + /run/systemd/user.conf.d/*.conf, + /usr/lib/systemd/user.conf.d/*.conf + + + + Description + + When run as a system instance, systemd interprets the configuration file + system.conf and the files in system.conf.d directories; when + run as a user instance, it interprets the configuration file user.conf (either in + the home directory of the user, or if not found, under /etc/systemd/) and the files + in user.conf.d directories. These configuration files contain a few settings + controlling basic manager operations. + + See + systemd.syntax7 for a + general description of the syntax. + + + + + + Options + + All options are configured in the + [Manager] section: + + + + + LogColor= + LogLevel= + LogLocation= + LogTarget= + LogTime= + DumpCore=yes + CrashChangeVT=no + CrashShell=no + CrashReboot=no + ShowStatus=yes + DefaultStandardOutput=journal + DefaultStandardError=inherit + + Configures various parameters of basic manager operation. These options may be overridden by + the respective process and kernel command line arguments. See + systemd1 for + details. + + + + CtrlAltDelBurstAction= + + Defines what action will be performed + if user presses Ctrl-Alt-Delete more than 7 times in 2s. + Can be set to reboot-force, poweroff-force, + reboot-immediate, poweroff-immediate + or disabled with none. Defaults to + reboot-force. + + + + + CPUAffinity= + + Configures the CPU affinity for the service manager as well as the default CPU + affinity for all forked off processes. Takes a list of CPU indices or ranges separated by either + whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a + dash. This option may be specified more than once, in which case the specified CPU affinity masks are + merged. If the empty string is assigned, the mask is reset, all assignments prior to this will have + no effect. Individual services may override the CPU affinity for their processes with the + CPUAffinity= setting in unit files, see + systemd.exec5. + + + + NUMAPolicy= + + Configures the NUMA memory policy for the service manager and the default NUMA memory policy + for all forked off processes. Individual services may override the default policy with the + NUMAPolicy= setting in unit files, see + systemd.exec5. + + + + NUMAMask= + + Configures the NUMA node mask that will be associated with the selected NUMA policy. Note that + and NUMA policies don't require explicit NUMA node mask and + value of the option can be empty. Similarly to NUMAPolicy=, value can be overridden + by individual services in unit files, see + systemd.exec5. + + + + RuntimeWatchdogSec= + RebootWatchdogSec= + KExecWatchdogSec= + + Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in + seconds (or in other time units if suffixed with ms, min, + h, d, w), or the special strings + off or default. If set to off + (alternatively: 0) the watchdog logic is disabled: no watchdog device is opened, + configured, or pinged. If set to the special string default the watchdog is opened + and pinged in regular intervals, but the timeout is not changed from the default. If set to any other + time value the watchdog timeout is configured to the specified value (or a value close to it, + depending on hardware capabilities). + + If RuntimeWatchdogSec= is set to a non-zero value, the watchdog hardware + (/dev/watchdog0 or the path specified with WatchdogDevice= or + the kernel option systemd.watchdog-device=) will be programmed to automatically + reboot the system if it is not contacted within the specified timeout interval. The system manager + will ensure to contact it at least once in half the specified timeout interval. This feature requires + a hardware watchdog device to be present, as it is commonly the case in embedded and server + systems. Not all hardware watchdogs allow configuration of all possible reboot timeout values, in + which case the closest available timeout is picked. + + RebootWatchdogSec= may be used to configure the hardware watchdog when the + system is asked to reboot. It works as a safety net to ensure that the reboot takes place even if a + clean reboot attempt times out. Note that the RebootWatchdogSec= timeout applies + only to the second phase of the reboot, i.e. after all regular services are already terminated, and + after the system and service manager process (PID 1) got replaced by the + systemd-shutdown binary, see system + bootup7 for + details. During the first phase of the shutdown operation the system and service manager remains + running and hence RuntimeWatchdogSec= is still honoured. In order to define a + timeout on this first phase of system shutdown, configure JobTimeoutSec= and + JobTimeoutAction= in the [Unit] section of the + shutdown.target unit. By default RuntimeWatchdogSec= defaults + to 0 (off), and RebootWatchdogSec= to 10min. + + KExecWatchdogSec= may be used to additionally enable the watchdog when kexec + is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on + kexec (depending on the specific hardware and/or driver), in this case the watchdog might not get + disabled after kexec succeeds and thus the system might get rebooted, unless + RuntimeWatchdogSec= is also enabled at the same time. For this reason it is + recommended to enable KExecWatchdogSec= only if + RuntimeWatchdogSec= is also enabled. + + These settings have no effect if a hardware watchdog is not available. + + + + RuntimeWatchdogPreSec= + + Configure the hardware watchdog device pre-timeout value. + Takes a timeout value in seconds (or in other time units similar to + RuntimeWatchdogSec=). A watchdog pre-timeout is a + notification generated by the watchdog before the watchdog reset might + occur in the event the watchdog has not been serviced. This notification + is handled by the kernel and can be configured to take an action (i.e. + generate a kernel panic) using RuntimeWatchdogPreGovernor=. + Not all watchdog hardware or drivers support generating a pre-timeout and + depending on the state of the system, the kernel may be unable to take the + configured action before the watchdog reboot. The watchdog will be configured + to generate the pre-timeout event at the amount of time specified by + RuntimeWatchdogPreSec= before the runtime watchdog timeout + (set by RuntimeWatchdogSec=). For example, if the we have + RuntimeWatchdogSec=30 and + RuntimeWatchdogPreSec=10, then the pre-timeout event + will occur if the watchdog has not pinged for 20s (10s before the + watchdog would fire). By default, RuntimeWatchdogPreSec= + defaults to 0 (off). The value set for RuntimeWatchdogPreSec= + must be smaller than the timeout value for RuntimeWatchdogSec=. + This setting has no effect if a hardware watchdog is not available or the + hardware watchdog does not support a pre-timeout and will be ignored by the + kernel if the setting is greater than the actual watchdog timeout. + + + + RuntimeWatchdogPreGovernor= + + Configure the action taken by the hardware watchdog device + when the pre-timeout expires. The default action for the pre-timeout event + depends on the kernel configuration, but it is usually to log a kernel + message. For a list of valid actions available for a given watchdog device, + check the content of the + /sys/class/watchdog/watchdogX/pretimeout_available_governors + file. Typically, available governor types are noop and panic. + Availability, names and functionality might vary depending on the specific device driver + in use. If the pretimeout_available_governors sysfs file is empty, + the governor might be built as a kernel module and might need to be manually loaded + (e.g. pretimeout_noop.ko), or the watchdog device might not support + pre-timeouts. + + + + WatchdogDevice= + + Configure the hardware watchdog device that the + runtime and shutdown watchdog timers will open and use. Defaults + to /dev/watchdog0. This setting has no + effect if a hardware watchdog is not available. + + + + CapabilityBoundingSet= + + Controls which capabilities to include in the + capability bounding set for PID 1 and its children. See + capabilities7 + for details. Takes a whitespace-separated list of capability + names as read by + cap_from_name3. + Capabilities listed will be included in the bounding set, all + others are removed. If the list of capabilities is prefixed + with ~, all but the listed capabilities will be included, the + effect of the assignment inverted. Note that this option also + affects the respective capabilities in the effective, + permitted and inheritable capability sets. The capability + bounding set may also be individually configured for units + using the CapabilityBoundingSet= directive + for units, but note that capabilities dropped for PID 1 cannot + be regained in individual units, they are lost for + good. + + + + NoNewPrivileges= + + Takes a boolean argument. If true, ensures that PID 1 + and all its children can never gain new privileges through + execve2 + (e.g. via setuid or setgid bits, or filesystem capabilities). + Defaults to false. General purpose distributions commonly rely + on executables with setuid or setgid bits and will thus not + function properly with this option enabled. Individual units + cannot disable this option. + Also see No New Privileges Flag. + + + + + SystemCallArchitectures= + + Takes a space-separated list of architecture + identifiers. Selects from which architectures system calls may + be invoked on this system. This may be used as an effective + way to disable invocation of non-native binaries system-wide, + for example to prohibit execution of 32-bit x86 binaries on + 64-bit x86-64 systems. This option operates system-wide, and + acts similar to the + SystemCallArchitectures= setting of unit + files, see + systemd.exec5 + for details. This setting defaults to the empty list, in which + case no filtering of system calls based on architecture is + applied. Known architecture identifiers are + x86, x86-64, + x32, arm and the special + identifier native. The latter implicitly + maps to the native architecture of the system (or more + specifically, the architecture the system manager was compiled + for). Set this setting to native to + prohibit execution of any non-native binaries. When a binary + executes a system call of an architecture that is not listed + in this setting, it will be immediately terminated with the + SIGSYS signal. + + + + TimerSlackNSec= + + Sets the timer slack in nanoseconds for PID 1, + which is inherited by all executed processes, unless + overridden individually, for example with the + TimerSlackNSec= setting in service units + (for details see + systemd.exec5). + The timer slack controls the accuracy of wake-ups triggered by + system timers. See + prctl2 + for more information. Note that in contrast to most other time + span definitions this parameter takes an integer value in + nano-seconds if no unit is specified. The usual time units are + understood too. + + + + StatusUnitFormat= + + Takes , or + as the value. If , the system manager will use unit + names in status messages (e.g. systemd-journald.service), instead of the longer + and more informative descriptions set with Description= (e.g. Journal + Logging Service). If , the system manager will use both unit names + and descriptions in status messages (e.g. systemd-journald.service - Journal Logging + Service). + + See + systemd.unit5 for + details about unit names and Description=. + + + + DefaultTimerAccuracySec= + + Sets the default accuracy of timer units. This + controls the global default for the + AccuracySec= setting of timer units, see + systemd.timer5 + for details. AccuracySec= set in individual + units override the global default for the specific unit. + Defaults to 1min. Note that the accuracy of timer units is + also affected by the configured timer slack for PID 1, see + TimerSlackNSec= above. + + + + DefaultTimeoutStartSec= + DefaultTimeoutStopSec= + DefaultTimeoutAbortSec= + DefaultRestartSec= + + Configures the default timeouts for starting, + stopping and aborting of units, as well as the default time to sleep + between automatic restarts of units, as configured per-unit in + TimeoutStartSec=, + TimeoutStopSec=, + TimeoutAbortSec= and + RestartSec= (for services, see + systemd.service5 + for details on the per-unit settings). Disabled by default, when + service with Type=oneshot is used. + For non-service units, + DefaultTimeoutStartSec= sets the default + TimeoutSec= + value. DefaultTimeoutStartSec= and + DefaultTimeoutStopSec= default to + 90s. DefaultTimeoutAbortSec= is not set by default + so that all units fall back to TimeoutStopSec=. + DefaultRestartSec= defaults to + 100ms. + + + + DefaultDeviceTimeoutSec= + + Configures the default timeout for waiting for devices. It can be changed per + device via the x-systemd.device-timeout= option in /etc/fstab + and /etc/crypttab (see + systemd.mount5, + crypttab5). + Defaults to 90s. + + + + DefaultStartLimitIntervalSec= + DefaultStartLimitBurst= + + Configure the default unit start rate + limiting, as configured per-service by + StartLimitIntervalSec= and + StartLimitBurst=. See + systemd.service5 + for details on the per-service settings. + DefaultStartLimitIntervalSec= defaults to + 10s. DefaultStartLimitBurst= defaults to + 5. + + + + DefaultEnvironment= + + Configures environment variables passed to all executed processes. Takes a + space-separated list of variable assignments. See environ7 for + details about environment variables. + + Simple %-specifier expansion is supported, see below for a list of supported + specifiers. + + Example: + + DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6" + + Sets three variables + VAR1, + VAR2, + VAR3. + + + + ManagerEnvironment= + + Takes the same arguments as DefaultEnvironment=, see above. Sets + environment variables just for the manager process itself. In contrast to user managers, these variables + are not inherited by processes spawned by the system manager, use DefaultEnvironment= + for that. Note that these variables are merged into the existing environment block. In particular, in + case of the system manager, this includes variables set by the kernel based on the kernel command line. + + Setting environment variables for the manager process may be useful to modify its behaviour. + See ENVIRONMENT for a descriptions of some + variables understood by systemd. + + Simple %-specifier expansion is supported, see below for a list of supported + specifiers. + + + + + DefaultCPUAccounting= + DefaultMemoryAccounting= + DefaultTasksAccounting= + DefaultIOAccounting= + DefaultIPAccounting= + + Configure the default resource accounting settings, as configured per-unit by + CPUAccounting=, MemoryAccounting=, + TasksAccounting=, IOAccounting= and + IPAccounting=. See + systemd.resource-control5 + for details on the per-unit settings. DefaultTasksAccounting= defaults to yes, + DefaultMemoryAccounting= to &MEMORY_ACCOUNTING_DEFAULT;. + DefaultCPUAccounting= defaults to yes, but really has no effect if enabling CPU + accounting doesn't require the controller to be enabled (Linux 4.15+ using the + unified hierarchy for resource control), otherwise it defaults to no. The other three settings + default to no. + + + + DefaultTasksMax= + + Configure the default value for the per-unit TasksMax= setting. See + systemd.resource-control5 + for details. This setting applies to all unit types that support resource control settings, with the exception + of slice units. Defaults to 15% of the minimum of kernel.pid_max=, kernel.threads-max= + and root cgroup pids.max. + Kernel has a default value for kernel.pid_max= and an algorithm of counting in case of more than 32 cores. + For example with the default kernel.pid_max=, DefaultTasksMax= defaults to 4915, + but might be greater in other systems or smaller in OS containers. + + + + DefaultLimitCPU= + DefaultLimitFSIZE= + DefaultLimitDATA= + DefaultLimitSTACK= + DefaultLimitCORE= + DefaultLimitRSS= + DefaultLimitNOFILE= + DefaultLimitAS= + DefaultLimitNPROC= + DefaultLimitMEMLOCK= + DefaultLimitLOCKS= + DefaultLimitSIGPENDING= + DefaultLimitMSGQUEUE= + DefaultLimitNICE= + DefaultLimitRTPRIO= + DefaultLimitRTTIME= + + These settings control various default resource limits for processes executed by + units. See + setrlimit2 for + details. These settings may be overridden in individual units using the corresponding + LimitXXX= directives and they accept the same parameter syntax, + see systemd.exec5 + for details. Note that these resource limits are only defaults + for units, they are not applied to the service manager process (i.e. PID 1) itself. + + Most of these settings are unset, which means the resource limits are inherited from the kernel or, if + invoked in a container, from the container manager. However, the following have defaults: + + DefaultLimitNOFILE= defaults to 1024:&HIGH_RLIMIT_NOFILE;. + + + DefaultLimitMEMLOCK= defaults to 8M. + + DefaultLimitCORE= does not have a default but it is worth mentioning that + RLIMIT_CORE is set to infinity by PID 1 which is inherited by its + children. + + + Note that the service manager internally in PID 1 bumps RLIMIT_NOFILE and + RLIMIT_MEMLOCK to higher values, however the limit is reverted to the mentioned + defaults for all child processes forked off. + + + + + DefaultOOMPolicy= + + Configure the default policy for reacting to processes being killed by the Linux + Out-Of-Memory (OOM) killer or systemd-oomd. This may be used to pick a global default for the per-unit + OOMPolicy= setting. See + systemd.service5 + for details. Note that this default is not used for services that have Delegate= + turned on. + + + + DefaultOOMScoreAdjust= + + Configures the default OOM score adjustments of processes run by the service + manager. This defaults to unset (meaning the forked off processes inherit the service manager's OOM + score adjustment value), except if the service manager is run for an unprivileged user, in which case + this defaults to the service manager's OOM adjustment value plus 100 (this makes service processes + slightly more likely to be killed under memory pressure than the manager itself). This may be used to + pick a global default for the per-unit OOMScoreAdjust= setting. See + systemd.exec5 for + details. Note that this setting has no effect on the OOM score adjustment value of the service + manager process itself, it retains the original value set during its invocation. + + + + DefaultSmackProcessLabel= + + Takes a security label as the argument. The process executed + by a unit will be started under this label if SmackProcessLabel= is not set in the + unit. See systemd.exec5 + for the details. + + If the value is /, only labels specified with SmackProcessLabel= + are assigned and the compile-time default is ignored. + + + + + + Specifiers + + Specifiers may be used in the DefaultEnvironment= and + ManagerEnvironment= settings. The following expansions are understood: + + Specifiers available + + + + + + + Specifier + Meaning + Details + + + + + + + + + + + + + + + + + + + + +
+ + + + History + + + + systemd 252 + Option DefaultBlockIOAccounting= was deprecated. Please switch + to the unified cgroup hierarchy. + + + + + + See Also + + systemd1, + systemd.directives7, + systemd.exec5, + systemd.service5, + environ7, + capabilities7 + + + + diff --git a/man/systemd-sysupdate.xml b/man/systemd-sysupdate.xml new file mode 100644 index 0000000..77c1635 --- /dev/null +++ b/man/systemd-sysupdate.xml @@ -0,0 +1,287 @@ + + + + + + + + systemd-sysupdate + systemd + + + + systemd-sysupdate + 8 + + + + systemd-sysupdate + systemd-sysupdate.service + systemd-sysupdate.timer + systemd-sysupdate-reboot.service + systemd-sysupdate-reboot.timer + Automatically Update OS or Other Resources + + + + + systemd-sysupdate + OPTIONS + + + systemd-sysupdate.service + + + + Description + + systemd-sysupdate atomically updates the host OS, container images, portable + service images or other sources, based on the transfer configuration files described in + sysupdate.d5. + + This tool implements file, directory, or partition based update schemes, supporting multiple + parallel installed versions of specific resources in an A/B (or even: A/B/C, A/B/C/D/, …) style. A/B + updating means that when one version of a resource is currently being used, the next version can be + downloaded, unpacked, and prepared in an entirely separate location, independently of the first, and — once + complete — be activated, swapping the roles so that it becomes the used one and the previously used one + becomes the one that is replaced by the next update, and so on. The resources to update are defined + in transfer files, one for each resource to be updated. For example, resources that may be updated with + this tool could be: a root file system partition, a matching Verity partition plus one kernel image. The + combination of the three would be considered a complete OS update. + + The tool updates partitions, files or directory trees always in whole, and operates with at least + two versions of each of these resources: the current version, plus the + next version: the one that is being updated to, and which is initially incomplete as + the downloaded data is written to it; plus optionally more versions. Once the download of a newer version + is complete it becomes the current version, releasing the version previously considered current for + deletion/replacement/updating. + + When installing new versions the tool will directly download, decompress, unpack and write the new + version into the destination. This is done in a robust fashion so that an incomplete download can be + recognized on next invocation, and flushed out before a new attempt is initiated. + + Note that when writing updates to a partition, the partition has to exist already, as + systemd-sysupdate will not automatically create new partitions. Use a tool such as + systemd-repart8 to + automatically create additional partitions to be used with systemd-sysupdate on + boot. + + The tool can both be used on the running OS, to update the OS in "online" state from within itself, + and on "offline" disk images, to update them from the outside based on transfer files + embedded in the disk images. For the latter, see below. The latter is + particularly interesting to update container images or portable service images. + + The systemd-sysupdate.service system service will automatically update the + host OS based on the installed transfer files. It is triggered in regular intervals via + systemd-sysupdate.timer. The systemd-sysupdate-reboot.service + will automatically reboot the system after a new version is installed. It is triggered via + systemd-sysupdate-reboot.timer. The two services are separate from each other as it + is typically advisable to download updates regularly while the system is up, but delay reboots until the + appropriate time (i.e. typically at night). The two sets of service/timer units may be enabled + separately. + + For details about transfer files and examples see + sysupdate.d5. + + + + Command + + The following commands are understood: + + + + VERSION + + If invoked without an argument, enumerates downloadable and installed versions, and + shows a summarizing table with the discovered versions and their properties, including whether + there's a newer candidate version to update to. If a version argument is specified, shows details + about the specific version, including the individual files that need to be transferred to acquire the + version. + + If no command is explicitly specified this command is implied. + + + + + + Checks if there's a new version available. This internally enumerates downloadable and + installed versions and returns exit status 0 if there's a new version to update to, non-zero + otherwise. If there is a new version to update to, its version identifier is written to standard + output. + + + + VERSION + + Installs (updates to) the specified version, or if none is specified to the newest + version available. If the version is already installed or no newer version available, no operation is + executed. + + If a new version to install/update to is found, old installed versions are deleted until at + least one new version can be installed, as configured via InstanceMax= in + sysupdate.d5, or + via the available partition slots of the right type. This implicit operation can also be invoked + explicitly via the vacuum command described below. + + + + + + Deletes old installed versions until the limits configured via + InstanceMax= in + sysupdate.d5 are + met again. Normally, it should not be necessary to invoke this command explicitly, since it is + implicitly invoked whenever a new update is initiated. + + + + + + Checks whether a newer version of the OS is installed than the one currently + running. Returns zero if so, non-zero otherwise. This compares the newest installed version's + identifier with the OS image version as reported by the IMAGE_VERSION= field in + /etc/os-release. If the former is newer than the latter, an update was + apparently completed but not activated (i.e. rebooted into) yet. + + + + + + Similar to the command but immediately reboots in case a + newer version of the OS has been installed than the one currently running. This operation can be done + implicitly together with the update command, after a completed update via the + switch, see below. This command will execute no operation (and return + success) if no update has been installed, and thus the system was not rebooted. + + + + + + Lists components that can be updated. This enumerates the + /etc/sysupdate.*.d/, /run/sysupdate.*.d/ and + /usr/lib/sysupdate.*.d/ directories that contain transfer files. This command is + useful to list possible parameters for (see below). + + + + + + + + + Options + + The following options are understood: + + + + + + + + Selects the component to update. Takes a component name as argument. This has the + effect of slightly altering the search logic for transfer files. If this switch is not used, the + transfer files are loaded from /etc/sysupdate.d/*.conf, + /run/sysupdate.d/*.conf and /usr/lib/sysupdate.d/*.conf. If + this switch is used, the specified component name is used to alter the directories to look in to be + /etc/sysupdate.component.d/*.conf, + /run/sysupdate.component.d/*.conf and + /usr/lib/sysupdate.component.d/*.conf, each time with + the component string replaced with the specified + component name. + + Use the components command to list available components to update. This enumerates + the directories matching this naming rule. + + Components may be used to define a separate set of transfer files for different components of + the OS that shall be updated separately. Do not use this concept for resources that shall always be + updated together in a synchronous fashion. Simply define multiple transfer files within the same + sysupdate.d/ directory for these cases. + + This option may not be combined with . + + + + + + A path to a directory. If specified, the transfer *.conf files + are read from this directory instead of /usr/lib/sysupdate.d/*.conf, + /etc/sysupdate.d/*.conf, and /run/sysupdate.d/*.conf. + + This option may not be combined with . + + + + + + Takes a path to a directory to use as root file system when searching for + sysupdate.d/*.conf files. + + + + + + Takes a path to a disk image file or device to mount and use in a similar fashion to + , see above. If this is used and partition resources are updated this is done + inside the specified disk image. + + + + + + + Takes a decimal integer greater than or equal to 2. Controls how many versions to + keep at any time. This option may also be configured inside the transfer files, via the + InstancesMax= setting, see + sysupdate.d5 for + details. + + + + + + Takes a boolean argument, defaults to yes. This may be used to specify whether the + newly updated resource versions shall be synchronized to disk when appropriate (i.e. after the + download is complete, before it is finalized, and again after finalization). This should not be + turned off, except to improve runtime performance in testing environments. + + + + + + Takes a boolean argument, defaults to yes. Controls whether to cryptographically + verify downloads. Do not turn this off, except in testing environments. + + + + + + When used in combination with the update command and a new version is + installed, automatically reboots the system immediately afterwards. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + See Also + + systemd1, + sysupdate.d5, + systemd-repart8 + + + + diff --git a/man/systemd-sysusers.xml b/man/systemd-sysusers.xml new file mode 100644 index 0000000..b399b3b --- /dev/null +++ b/man/systemd-sysusers.xml @@ -0,0 +1,217 @@ + + + + + + + + systemd-sysusers + systemd + + + + systemd-sysusers + 8 + + + + systemd-sysusers + systemd-sysusers.service + Allocate system users and groups + + + + + systemd-sysusers + OPTIONS + CONFIGFILE + + + systemd-sysusers.service + + + + Description + + systemd-sysusers creates system users and groups, based on files in the format + described in + sysusers.d5. + + + If invoked with no arguments, it applies all directives from all files found in the directories + specified by + sysusers.d5. When + invoked with positional arguments, if option + is specified, arguments specified on the command line are used instead of the configuration file + PATH. Otherwise, just the configuration specified by the command line + arguments is executed. The string - may be specified instead of a filename to instruct + systemd-sysusers to read the configuration from standard input. If the argument is a + relative path, all configuration directories are searched for a matching file and the file found that has + the highest priority is executed. If the argument is an absolute path, that file is used directly without + searching of the configuration directories. + + + + Options + + The following options are understood: + + + + + Takes a directory path as an argument. All + paths will be prefixed with the given alternate + root path, including config search + paths. + + + + + + Takes a path to a disk image file or block device node. If specified all operations + are applied to file system in the indicated disk image. This is similar to + but operates on file systems stored in disk images or block devices. The disk image should either + contain just a file system or a set of file systems within a GPT partition table, following the + Discoverable Partitions + Specification. For further information on supported disk images, see + systemd-nspawn1's + switch of the same name. + + + + + When this option is given, one or more positional arguments + must be specified. All configuration files found in the directories listed in + sysusers.d5 + will be read, and the configuration given on the command line will be + handled instead of and with the same priority as the configuration file + PATH. + + This option is intended to be used when package installation scripts + are running and files belonging to that package are not yet available on + disk, so their contents must be given on the command line, but the admin + configuration might already exist and should be given higher priority. + + + + RPM installation script for radvd + + echo 'u radvd - "radvd daemon"' | \ + systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf - + + This will create the radvd user as if + /usr/lib/sysusers.d/radvd.conf was already on disk. + An admin might override the configuration specified on the command line by + placing /etc/sysusers.d/radvd.conf or even + /etc/sysusers.d/00-overrides.conf. + + Note that this is the expanded form, and when used in a package, this + would be written using a macro with "radvd" and a file containing the + configuration line as arguments. + + + + + + + Process the configuration and figure out what entries would be created, but don't + actually write anything. + + + + + Treat each positional argument as a separate configuration + line instead of a file name. + + + + + + + + + + + Credentials + + systemd-sysusers supports the service credentials logic as implemented by + LoadCredential=/SetCredential= (see + systemd.exec1 for + details). The following credentials are used when passed in: + + + + passwd.hashed-password.user + A UNIX hashed password string to use for the specified user, when creating an entry + for it. This is particularly useful for the root user as it allows provisioning + the default root password to use via a unit file drop-in or from a container manager passing in this + credential. Note that setting this credential has no effect if the specified user account already + exists. This credential is hence primarily useful in first boot scenarios or systems that are fully + stateless and come up with an empty /etc/ on every boot. + + + + passwd.plaintext-password.user + + Similar to passwd.hashed-password.user + but expect a literal, plaintext password, which is then automatically hashed before used for the user + account. If both the hashed and the plaintext credential are specified for the same user the + former takes precedence. It's generally recommended to specify the hashed version; however in test + environments with weaker requirements on security it might be easier to pass passwords in plaintext + instead. + + + + passwd.shell.user + + Specifies the shell binary to use for the specified account when creating it. + + + + sysusers.extra + + The contents of this credential may contain additional lines to operate on. The + credential contents should follow the same format as any other sysusers.d/ + drop-in. If this credential is passed it is processed after all of the drop-in files read from the + file system. + + + + Note that by default the systemd-sysusers.service unit file is set up to + inherit the passwd.hashed-password.root, + passwd.plaintext-password.root, passwd.shell.root and + sysusers.extra credentials from the service manager. Thus, when invoking a container + with an unpopulated /etc/ for the first time it is possible to configure the root + user's password to be systemd like this: + + # systemd-nspawn --image=… --set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' … + + Note again that the data specified in this credential is consulted only when creating an account + for the first time, it may not be used for changing the password or shell of an account that already + exists. + + Use mkpasswd1 + for generating UNIX password hashes from the command line. + + + + Exit status + + On success, 0 is returned, a non-zero failure code + otherwise. + + + + See Also + + systemd1, + sysusers.d5, + Users, Groups, UIDs and GIDs on systemd systems, + systemd.exec1, + mkpasswd1 + + + + diff --git a/man/systemd-sysv-generator.xml b/man/systemd-sysv-generator.xml new file mode 100644 index 0000000..e9f318b --- /dev/null +++ b/man/systemd-sysv-generator.xml @@ -0,0 +1,76 @@ + + + + + + + + systemd-sysv-generator + systemd + + + + systemd-sysv-generator + 8 + + + + systemd-sysv-generator + Unit generator for SysV init scripts + + + + /usr/lib/systemd/system-generators/systemd-sysv-generator + + + + Description + + systemd-sysv-generator is a generator + that creates wrapper .service units for + SysV init + scripts in /etc/init.d/* at boot and when + configuration of the system manager is reloaded. This allows + systemd1 + to support them similarly to native units. + + LSB headers + in SysV init scripts are interpreted, and the ordering specified + in the header is turned into dependencies between the generated + unit and other units. The LSB facilities + $remote_fs, $network, + $named, $portmap, + $time are supported and will be turned into + dependencies on specific native systemd targets. See + systemd.special7 + for more details. + + Note that compatibility is quite comprehensive but not 100%, for more details see Incompatibilities with + SysV. + + SysV runlevels have corresponding systemd targets + (runlevelX.target). + The wrapper unit that is generated will be wanted by those targets + which correspond to runlevels for which the script is + enabled. + + systemd does not support SysV scripts as + part of early boot, so all wrapper units are ordered after + basic.target. + + systemd-sysv-generator implements + systemd.generator7. + + + + See Also + + systemd1, + systemd.service5, + systemd.target5 + + + + diff --git a/man/systemd-time-wait-sync.service.xml b/man/systemd-time-wait-sync.service.xml new file mode 100644 index 0000000..cd26ae4 --- /dev/null +++ b/man/systemd-time-wait-sync.service.xml @@ -0,0 +1,70 @@ + + + + + + + + systemd-time-wait-sync.service + systemd + + + + systemd-time-wait-sync.service + 8 + + + + systemd-time-wait-sync.service + systemd-time-wait-sync + Wait until kernel time is synchronized + + + + systemd-time-wait-sync.service + /usr/lib/systemd/systemd-time-wait-sync + + + + Description + + systemd-time-wait-sync is a system service that delays the start of units that + are ordered after time-sync.target (see + systemd.special7 for + details) until the system time has been synchronized with an accurate remote reference time source by + systemd-timesyncd.service. + + systemd-timesyncd.service notifies systemd-time-wait-sync + about successful synchronization. systemd-time-wait-sync also tries to detect when + the kernel marks the system clock as synchronized, but this detection is not reliable and is intended + only as a fallback for compatibility with alternative NTP services that can be used to synchronize time + (e.g., ntpd, chronyd). + + + + Files + + + + /run/systemd/timesync/synchronized + + + The presence of this file indicates to this service that the system clock has been synchronized. + + + + + + + + + See Also + + systemd1, + systemd.special7, + systemd-timesyncd.service8, + + + + diff --git a/man/systemd-timedated.service.xml b/man/systemd-timedated.service.xml new file mode 100644 index 0000000..112bdf3 --- /dev/null +++ b/man/systemd-timedated.service.xml @@ -0,0 +1,105 @@ + + + + + + + + systemd-timedated.service + systemd + + + + systemd-timedated.service + 8 + + + + systemd-timedated.service + systemd-timedated + Time and date bus mechanism + + + + systemd-timedated.service + /usr/lib/systemd/systemd-timedated + + + + Description + + systemd-timedated.service is a system service + that may be used as a mechanism to change the system clock and + timezone, as well as to enable/disable network time synchronization. + systemd-timedated is automatically activated + on request and terminates itself when it is unused. + + The tool + timedatectl1 + is a command line client to this service. + + systemd-timedated currently offers access to + the following four settings: + + The system time + + The system timezone + + A boolean controlling whether the system RTC is in local or UTC + timezone + + Whether the time synchronization service is enabled/started or + disabled/stopped, see next section. + + + See + org.freedesktop.timedate15 + and + org.freedesktop.LogControl15 + for information about the D-Bus API. + + + + List of network time synchronization services + + systemd-timesyncd will look for files with a .list extension + in ntp-units.d/ directories. Each file is parsed as a list of unit names, one per + line. Empty lines and lines with comments (#) are ignored. Files are read from + /usr/lib/systemd/ntp-units.d/ and the corresponding directories under + /etc/, /run/, /usr/local/lib/. Files in + /etc/ override files with the same name in /run/, + /usr/local/lib/, and /usr/lib/. Files in + /run/ override files with the same name under /usr/. Packages + should install their configuration files in /usr/lib/ (distribution packages) or + /usr/local/lib/ (local installs). + + + <filename>ntp-units.d/</filename> entry for <command>systemd-timesyncd</command> + # /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list +systemd-timesyncd.service + + + + If the environment variable $SYSTEMD_TIMEDATED_NTP_SERVICES is set, + systemd-timesyncd will parse the contents of that variable as a colon-separated list + of unit names. When set, this variable overrides the file-based list described above. + + + An override that specifies that <command>chronyd</command> should be used if available + SYSTEMD_TIMEDATED_NTP_SERVICES=chronyd.service:systemd-timesyncd.service + + + + + See Also + + systemd1, + timedatectl1, + localtime5, + hwclock8, + systemd-timesyncd8 + + + + diff --git a/man/systemd-timesyncd.service.xml b/man/systemd-timesyncd.service.xml new file mode 100644 index 0000000..45fb6b7 --- /dev/null +++ b/man/systemd-timesyncd.service.xml @@ -0,0 +1,127 @@ + + + + + + + + systemd-timesyncd.service + systemd + + + + systemd-timesyncd.service + 8 + + + + systemd-timesyncd.service + systemd-timesyncd + Network Time Synchronization + + + + systemd-timesyncd.service + /usr/lib/systemd/systemd-timesyncd + + + + Description + + systemd-timesyncd is a system service that may be used to synchronize the + local system clock with a remote Network Time Protocol (NTP) server. It also saves the local time to disk + every time the clock has been synchronized and uses this to possibly advance the system realtime clock on + subsequent reboots to ensure it (roughly) monotonically advances even if the system lacks a + battery-buffered RTC chip. + + The systemd-timesyncd service implements SNTP only. This minimalistic service + will step the system clock for large offsets or slowly adjust it for smaller deltas. Complex use cases + that require full NTP support (and where SNTP is not sufficient) are not covered by + systemd-timesyncd. + + The NTP servers contacted are determined from the global settings in + timesyncd.conf5, the + per-link static settings in .network files, and the per-link dynamic settings + received over DHCP. See + systemd.network5 for + further details. + + timedatectl1's + set-ntp command may be used to enable and start, or disable and stop this + service. + + timedatectl1's + timesync-status or show-timesync command can be used to show the + current status of this service. + + systemd-timesyncd initialization delays the start of units that are ordered + after time-set.target (see + systemd.special7 for + details) until the local time has been updated from /var/lib/systemd/timesync/clock + (see below) in order to make it roughly monotonic. It does not delay other units until synchronization + with an accurate reference time sources has been reached. Use + systemd-time-wait-sync.service8 + to achieve that, which will delay start of units that are ordered after + time-sync.target until synchronization to an accurate reference clock is + reached. + + + + Files + + + + /var/lib/systemd/timesync/clock + + + The modification time ("mtime") of this file is updated on each successful NTP + synchronization or after each SaveIntervalSec= time interval, as specified in + timesyncd.conf5. + + When initializing, the local clock is advanced to the modification time of this file (if the + file timestamp is in the past this adjustment is not made). If the file does not exist yet, the + clock is instead advanced to the modification time of /usr/lib/clock-epoch – + if it exists – or to a time derived from the source tree at build time. This mechanism is used to + ensure that the system clock remains somewhat reasonably initialized and roughly monotonic across + reboots, in case no battery-buffered local RTC is available. + + + + + /usr/lib/clock-epoch + + The modification time ("mtime") of this file is used for advancing the system clock + in case /var/lib/systemd/timesync/clock does not exist yet, see + above. + + + + /run/systemd/timesync/synchronized + + + A file that is touched on each successful synchronization, to assist + systemd-time-wait-sync and other applications to detecting synchronization + with accurate reference clocks. + + + + + + + + See Also + + systemd1, + timesyncd.conf5, + systemd.network5, + systemd-networkd.service8, + systemd-time-wait-sync.service8, + systemd.special7, + timedatectl1, + localtime5, + hwclock8 + + + + diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml new file mode 100644 index 0000000..5fd3248 --- /dev/null +++ b/man/systemd-tmpfiles.xml @@ -0,0 +1,315 @@ + + + + + + + + systemd-tmpfiles + systemd + + + + systemd-tmpfiles + 8 + + + + systemd-tmpfiles + systemd-tmpfiles-setup.service + systemd-tmpfiles-setup-dev.service + systemd-tmpfiles-clean.service + systemd-tmpfiles-clean.timer + Creates, deletes and cleans up volatile + and temporary files and directories + + + + + systemd-tmpfiles + OPTIONS + CONFIGFILE + + + System units: +systemd-tmpfiles-setup.service +systemd-tmpfiles-setup-dev.service +systemd-tmpfiles-clean.service +systemd-tmpfiles-clean.timer + + User units: +systemd-tmpfiles-setup.service +systemd-tmpfiles-clean.service +systemd-tmpfiles-clean.timer + + + + Description + + systemd-tmpfiles creates, deletes, and cleans up volatile and temporary files + and directories, using the configuration file format and location specified in + tmpfiles.d5. It must + be invoked with one or more options , , and + , to select the respective subset of operations. + + By default, directives from all configuration files are applied. When invoked with + , arguments specified on the command line are + used instead of the configuration file PATH. Otherwise, if one or more + absolute filenames are passed on the command line, only the directives in these files are applied. If + - is specified instead of a filename, directives are read from standard input. If only + the basename of a configuration file is specified, all configuration directories as specified in + tmpfiles.d5 are + searched for a matching file and the file found that has the highest priority is executed. + + System services (systemd-tmpfiles-setup.service, + systemd-tmpfiles-setup-dev.service, + systemd-tmpfiles-clean.service) invoke systemd-tmpfiles to create + system files and to perform system wide cleanup. Those services read administrator-controlled + configuration files in tmpfiles.d/ directories. User services + (systemd-tmpfiles-setup.service, + systemd-tmpfiles-clean.service) also invoke systemd-tmpfiles, but + it reads a separate set of files, which includes user-controlled files under + ~/.config/user-tmpfiles.d/ and ~/.local/share/user-tmpfiles.d/, + and administrator-controlled files under /usr/share/user-tmpfiles.d/. Users may use + this to create and clean up files under their control, but the system instance performs global cleanup + and is not influenced by user configuration. Note that this means a time-based cleanup configured in the + system instance, such as the one typically configured for /tmp/, will thus also + affect files created by the user instance if they are placed in /tmp/, even if the + user instance's time-based cleanup is turned off. + + To re-apply settings after configuration has been modified, simply restart + systemd-tmpfiles-clean.service, which will apply any settings which can be safely + executed at runtime. To debug systemd-tmpfiles, it may be useful to invoke it + directly from the command line with increased log level (see $SYSTEMD_LOG_LEVEL + below). + + + + Options + + The following options are understood: + + + + + If this option is passed, all files and + directories marked with + f, + F, + w, + d, + D, + v, + p, + L, + c, + b, + m + in the configuration files are created or written to. Files + and directories marked with + z, + Z, + t, + T, + a, and + A have their ownership, access mode and + security labels set. + + + + + If this option is passed, all files and + directories with an age parameter configured will be cleaned + up. + + + + + If this option is passed, the contents of + directories marked with D or + R, and files or directories themselves + marked with r or R are + removed. + + + + + Execute "user" configuration, i.e. tmpfiles.d + files in user configuration directories. + + + + + Also execute lines with an exclamation mark. Lines that are not safe to be executed + on a running system may be marked in this way. systemd-tmpfiles is executed in + early boot with specified and will execute those lines. When invoked again + later, it should be called without . + + + + + Only apply rules with paths that start with + the specified prefix. This option can be specified multiple + times. + + + + + Ignore rules with paths that start with the + specified prefix. This option can be specified multiple + times. + + + + + A shortcut for --exclude-prefix=/dev --exclude-prefix=/proc + --exclude-prefix=/run --exclude-prefix=/sys, i.e. exclude the hierarchies typically backed + by virtual or memory file systems. This is useful in combination with , if + the specified directory tree contains an OS tree without these virtual/memory file systems mounted + in, as it is typically not desirable to create any files and directories below these subdirectories + if they are supposed to be overmounted during runtime. + + + + + Takes a directory path as an argument. All paths will be prefixed with the given alternate + root path, including config search paths. + + When this option is used, the libc Name Service Switch (NSS) is bypassed for resolving users + and groups. Instead the files /etc/passwd and /etc/group + inside the alternate root are read directly. This means that users/groups not listed in these files + will not be resolved, i.e. LDAP NIS and other complex databases are not considered. + + Consider combining this with to ensure the invocation does not create files + or directories below mount points in the OS image operated on that are typically overmounted during + runtime. + + + + + + Takes a path to a disk image file or block device node. If specified all operations + are applied to file system in the indicated disk image. This is similar to + but operates on file systems stored in disk images or block devices. The disk image should either + contain just a file system or a set of file systems within a GPT partition table, following the + Discoverable Partitions + Specification. For further information on supported disk images, see + systemd-nspawn1's + switch of the same name. + + Implies . + + + + + When this option is given, one or more positional arguments + must be specified. All configuration files found in the directories listed in + tmpfiles.d5 + will be read, and the configuration given on the command line will be + handled instead of and with the same priority as the configuration file + PATH. + + This option is intended to be used when package installation scripts + are running and files belonging to that package are not yet available on + disk, so their contents must be given on the command line, but the admin + configuration might already exist and should be given higher priority. + + + + + + + + + + It is possible to combine , , and + in one invocation (in which case removal and cleanup are executed before creation of new files). For example, + during boot the following command line is executed to ensure that all temporary and volatile directories are + removed and created according to the configuration file: + + systemd-tmpfiles --remove --create + + + + Credentials + + systemd-tmpfiles supports the service credentials logic as implemented by + LoadCredential=/SetCredential= (see + systemd.exec1 for + details). The following credentials are used when passed in: + + + + tmpfiles.extra + + The contents of this credential may contain additional lines to operate on. The + credential contents should follow the same format as any other tmpfiles.d/ + drop-in configuration file. If this credential is passed it is processed after all of the drop-in + files read from the file system. The lines in the credential can hence augment existing lines of the + OS, but not override them. + + + + Note that by default the systemd-tmpfiles-setup.service unit file (and related + unit files) is set up to inherit the tmpfiles.extra credential from the service + manager. + + + + Environment + + + + + + + + + + + + + + + + + + Unprivileged --cleanup operation + + systemd-tmpfiles tries to avoid changing + the access and modification times on the directories it accesses, + which requires CAP_FOWNER privileges. When + running as non-root, directories which are checked for files to + clean up will have their access time bumped, which might prevent + their cleanup. + + + + + Exit status + + On success, 0 is returned. If the configuration was syntactically invalid (syntax errors, missing + arguments, …), so some lines had to be ignored, but no other errors occurred, 65 is + returned (EX_DATAERR from /usr/include/sysexits.h). If the + configuration was syntactically valid, but could not be executed (lack of permissions, creation of files + in missing directories, invalid contents when writing to /sys/ values, …), + 73 is returned (EX_CANTCREAT from + /usr/include/sysexits.h). Otherwise, 1 is returned + (EXIT_FAILURE from /usr/include/stdlib.h). + + Note: when creating items, if the target already exists, but is of the wrong type or otherwise does + not match the requested state, and forced operation has not been requested with +, + a message is emitted, but the failure is otherwise ignored. + + + + See Also + + systemd1, + tmpfiles.d5 + + + + diff --git a/man/systemd-tty-ask-password-agent.xml b/man/systemd-tty-ask-password-agent.xml new file mode 100644 index 0000000..5c0011e --- /dev/null +++ b/man/systemd-tty-ask-password-agent.xml @@ -0,0 +1,126 @@ + + + + + + + + systemd-tty-ask-password-agent + systemd + + + + systemd-tty-ask-password-agent + 1 + + + + systemd-tty-ask-password-agent + List or process pending systemd password requests + + + + + systemd-tty-ask-password-agent + OPTIONS + VARIABLE=VALUE + + + + + Description + + systemd-tty-ask-password-agent is a + password agent that handles password requests of the system, for + example for hard disk encryption passwords or SSL certificate + passwords that need to be queried at boot-time or during + runtime. + + systemd-tty-ask-password-agent implements + the Password Agents + Specification, and is one of many possible response agents which + answer to queries formulated with + systemd-ask-password1. + + + + + Options + + The following options are understood: + + + + + + Lists all currently pending system password requests. + + + + + + Process all currently pending system password + requests by querying the user on the calling + TTY. + + + + + + Continuously process password + requests. + + + + + + Forward password requests to + wall1 + instead of querying the user on the calling + TTY. + + + + + + Ask question with + plymouth8 + instead of querying the user on the calling + TTY. + + + + =DEVICE + + Ask question on TTY DEVICE instead of querying the user on + the calling TTY. If DEVICE is not specified, + /dev/console will be used. + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure + code otherwise. + + + + See Also + + systemd1, + systemctl1, + systemd-ask-password-console.service8, + wall1, + plymouth8 + + + + diff --git a/man/systemd-udev-settle.service.xml b/man/systemd-udev-settle.service.xml new file mode 100644 index 0000000..2852f31 --- /dev/null +++ b/man/systemd-udev-settle.service.xml @@ -0,0 +1,51 @@ + + + + + + + + systemd-udev-settle.service + systemd + + + + systemd-udev-settle.service + 8 + + + + systemd-udev-settle.service + Wait for all pending udev events to be handled + + + + systemd-udev-settle.service + + + Description + This service calls udevadm settle to wait until all events that have been queued + by udev7 have been + processed. It is a crude way to wait until "all" hardware has been discovered. Services may pull in this + service and order themselves after it to wait for the udev queue to be empty. + + Using this service is not recommended. There can be no guarantee that hardware + is fully discovered at any specific time, because the kernel does hardware detection asynchronously, and + certain buses and devices take a very long time to become ready, and also additional hardware may be + plugged in at any time. Instead, services should subscribe to udev events and react to any new hardware as + it is discovered. Services that, based on configuration, expect certain devices to appear, may warn or + report failure after a timeout. This timeout should be tailored to the hardware type. Waiting for + systemd-udev-settle.service usually slows boot significantly, because it means waiting + for all unrelated events too. + + + + See Also + + udev7, + udevadm8 + + + diff --git a/man/systemd-udevd.service.xml b/man/systemd-udevd.service.xml new file mode 100644 index 0000000..3107fb7 --- /dev/null +++ b/man/systemd-udevd.service.xml @@ -0,0 +1,279 @@ + + + + + + + + systemd-udevd.service + systemd + + + + systemd-udevd.service + 8 + + + + systemd-udevd.service + systemd-udevd-control.socket + systemd-udevd-kernel.socket + systemd-udevd + Device event managing daemon + + + + systemd-udevd.service + systemd-udevd-control.socket + systemd-udevd-kernel.socket + + + /usr/lib/systemd/systemd-udevd + + + + + + + + + + + + + Description + systemd-udevd listens to kernel uevents. + For every event, systemd-udevd executes matching instructions + specified in udev rules. See + udev7 + . + + The behavior of the daemon can be configured using + udev.conf5, + its command line options, environment variables, and on the kernel + command line, or changed dynamically with udevadm + control. + + + + Options + + + + + + Detach and run in the background. + + + + + + + + Print debug messages to standard error. + + + + + + + + Limit the number of events executed in parallel. + + + + + + + + Delay the execution of each RUN{program} + parameter by the given number of seconds. This option + might be useful when debugging system crashes during + coldplug caused by loading non-working kernel + modules. + + + + + + + + Set the number of seconds to wait for events to finish. After + this time, the event will be terminated. The default is 180 seconds. + + + + + + + + Set the signal which systemd-udevd will send to + forked off processes after reaching event timeout. The setting can be overridden + at boot time with the kernel command line option + udev.timeout_signal=. Setting to SIGABRT + may be helpful in order to debug worker timeouts. Defaults to + SIGKILL. Note that setting the option on the command line + overrides the setting from the configuration file. + + + + + + + + + Specify when systemd-udevd should resolve names of users and groups. + When set to (the default), names will be + resolved when the rules are parsed. When set to + , names will be resolved for every event. + When set to , names will never be resolved + and all devices will be owned by root. + + + + + + + + + Kernel command line + + Parameters prefixed with "rd." will be read when systemd-udevd is used in an + initrd, those without will be processed both in the initrd and on the host. + + udev.log_level= + rd.udev.log_level= + + Set the log level. + + + + udev.children_max= + rd.udev.children_max= + + Limit the number of events executed in parallel. + + + + udev.exec_delay= + rd.udev.exec_delay= + + Delay the execution of each RUN{program} parameter by the given + number of seconds. This option might be useful when + debugging system crashes during coldplug caused by loading + non-working kernel modules. + + + + udev.event_timeout= + rd.udev.event_timeout= + + Wait for events to finish up to the given number + of seconds. This option might be useful if events are + terminated due to kernel drivers taking too long to initialize. + + + + udev.timeout_signal= + rd.udev.timeout_signal= + + Specifies a signal that systemd-udevd will send to + workers on timeout. Note that kernel command line option overrides both the + setting in the configuration file and the one on the program command line. + + + + udev.blockdev_read_only + rd.udev.blockdev_read_only + + If specified, mark all physical block devices read-only as they appear. Synthetic block + devices (such as loopback block devices or device mapper devices) are left as they are. This is + useful to guarantee that the contents of physical block devices remains unmodified during runtime, + for example to implement fully stateless systems, for testing or for recovery situations where + corrupted file systems shall not be corrupted further through accidental modification. + + A block device may be marked writable again by issuing the blockdev + --setrw command, see blockdev8 + for details. + + + + net.ifnames= + + Network interfaces are renamed to give them predictable names + when possible. It is enabled by default; specifying 0 disables it. + + + + net.naming-scheme= + + Network interfaces are renamed to give them predictable names when possible (unless + net.ifnames=0 is specified, see above). With this kernel command line option it + is possible to pick a specific version of this algorithm and override the default chosen at + compilation time. Expects one of the naming scheme identifiers listed in + systemd.net-naming-scheme7, + or latest to select the latest scheme known (to this particular version of + systemd-udevd.service). + + Note that selecting a specific scheme is not sufficient to fully stabilize interface naming: + the naming is generally derived from driver attributes exposed by the kernel. As the kernel is + updated, previously missing attributes systemd-udevd.service is checking might + appear, which affects older name derivation algorithms, too. + + + + net.ifname-policy=policy1[,policy2,…][,MAC] + + Specifies naming policies applied when renaming network interfaces. Takes a list of + policies and an optional MAC address separated with comma. Each policy value must be one of + the policies understood by the NamePolicy= setting in .link files, e.g. + onboard or path. See + systemd.link5 + for more details. When the MAC address is specified, the policies are applied to the + interface which has the address. When no MAC address is specified, the policies are applied + to all interfaces. This kernel command line argument can be specified multiple times. + + This argument is not directly read by systemd-udevd, but is instead + converted to a .link file by + systemd-network-generator.service8. + For this argument to take effect, systemd-network-generator.service must be + enabled. + + Example: + net.ifname-policy=keep,kernel,path,slot,onboard,01:23:45:67:89:ab +net.ifname-policy=keep,kernel,path,slot,onboard,mac + This is mostly equivalent to creating the following .link files: + # 91-name-policy-with-mac.link +[Match] +MACAddress=01:23:45:67:89:ab + +[Link] +NamePolicy=keep kernel path slot onboard +AlternativeNamePolicy=path slot onboard + and + # 92-name-policy-for-all.link +[Match] +OriginalName=* + +[Link] +NamePolicy=keep kernel path slot onboard mac +AlternativeNamePolicy=path slot onboard mac + + + + + + + + + See Also + + udev.conf5, + udev7, + udevadm8 + + + diff --git a/man/systemd-update-done.service.xml b/man/systemd-update-done.service.xml new file mode 100644 index 0000000..3393010 --- /dev/null +++ b/man/systemd-update-done.service.xml @@ -0,0 +1,76 @@ + + + + + + + + systemd-update-done.service + systemd + + + + systemd-update-done.service + 8 + + + + systemd-update-done.service + systemd-update-done + Mark /etc/ and /var/ fully updated + + + + systemd-update-done.service + /usr/lib/systemd/systemd-update-done + + + + Description + + systemd-update-done.service is a + service that is invoked as part of the first boot after the vendor + operating system resources in /usr/ have been + updated. This is useful to implement offline updates of + /usr/ which might require updates to + /etc/ or /var/ on the + following boot. + + systemd-update-done.service updates the + file modification time (mtime) of the stamp files + /etc/.updated and + /var/.updated to the modification time of the + /usr/ directory, unless the stamp files are + already newer. + + Services that shall run after offline upgrades of + /usr/ should order themselves before + systemd-update-done.service, and use the + ConditionNeedsUpdate= (see + systemd.unit5) + condition to make sure to run when /etc/ or + /var/ are older than /usr/ + according to the modification times of the files described above. + This requires that updates to /usr/ are always + followed by an update of the modification time of + /usr/, for example by invoking + touch1 + on it. + + Note that if the systemd.condition-needs-update= kernel command line option is + used it overrides the ConditionNeedsUpdate= unit condition checks. In that case + systemd-update-done.service will not reset the condition state until a follow-up + reboot where the kernel switch is not specified anymore. + + + + See Also + + systemd1, + systemd.unit5, + touch1 + + + + diff --git a/man/systemd-update-utmp.service.xml b/man/systemd-update-utmp.service.xml new file mode 100644 index 0000000..ff01893 --- /dev/null +++ b/man/systemd-update-utmp.service.xml @@ -0,0 +1,51 @@ + + + + + + + + systemd-update-utmp.service + systemd + + + + systemd-update-utmp.service + 8 + + + + systemd-update-utmp.service + systemd-update-utmp-runlevel.service + systemd-update-utmp + Write audit and utmp updates at bootup, runlevel + changes and shutdown + + + + systemd-update-utmp.service + systemd-update-utmp-runlevel.service + /usr/lib/systemd/systemd-update-utmp + + + + Description + + systemd-update-utmp-runlevel.service is + a service that writes SysV runlevel changes to utmp and wtmp, as + well as the audit logs, as they occur. + systemd-update-utmp.service does the same for + system reboots and shutdown requests. + + + + See Also + + systemd1, + utmp5, + auditd8 + + + + diff --git a/man/systemd-user-sessions.service.xml b/man/systemd-user-sessions.service.xml new file mode 100644 index 0000000..f05e4e3 --- /dev/null +++ b/man/systemd-user-sessions.service.xml @@ -0,0 +1,50 @@ + + + + + + + + systemd-user-sessions.service + systemd + + + + systemd-user-sessions.service + 8 + + + + systemd-user-sessions.service + systemd-user-sessions + Permit user logins after boot, prohibit user logins at shutdown + + + + systemd-user-sessions.service + /usr/lib/systemd/systemd-user-sessions + + + + Description + + systemd-user-sessions.service is a + service that controls user logins through + pam_nologin8. + After basic system initialization is complete, it removes + /run/nologin, thus permitting logins. Before + system shutdown, it creates /run/nologin, thus + prohibiting further logins. + + + + See Also + + systemd1, + systemd-logind.service8, + pam_nologin8 + + + + diff --git a/man/systemd-userdbd.service.xml b/man/systemd-userdbd.service.xml new file mode 100644 index 0000000..63673d9 --- /dev/null +++ b/man/systemd-userdbd.service.xml @@ -0,0 +1,73 @@ + + + + + + + + systemd-userdbd.service + systemd + + + + systemd-userdbd.service + 8 + + + + systemd-userdbd.service + systemd-userdbd + JSON User/Group Record Query Multiplexer/NSS Compatibility + + + + systemd-userdbd.service + /usr/lib/systemd/systemd-userdbd + + + + Description + + systemd-userdbd is a system service that multiplexes user/group lookups to all + local services that provide JSON user/group record definitions to the system. In addition it synthesizes + JSON user/group records from classic UNIX/glibc NSS user/group records in order to provide full backwards + compatibility. It may also pick up statically defined JSON user/group records from drop-in files in + /etc/userdb/, /run/userdb/, + /run/host/userdb/ and /usr/lib/userdb/. + + Most of systemd-userdbd's functionality is accessible through the + userdbctl1 + command. + + The user and group records this service provides access to follow the JSON User Records and JSON Group Record definitions. This service implements the + User/Group Record Lookup API via Varlink, and + multiplexes access other services implementing this API, too. It is thus both server and client of this + API. + + This service provides three distinct Varlink services: + io.systemd.Multiplexer provides a single, unified API for querying JSON user and + group records. Internally it talks to all other user/group record services running on the system in + parallel and forwards any information discovered. This simplifies clients substantially since they need + to talk to a single service only instead of all of them in + parallel. io.systemd.NameServiceSwitch provides compatibility with classic + UNIX/glibc NSS user records, i.e. converts struct passwd and struct group + records as acquired with APIs such as getpwnam1 to + JSON user/group records, thus hiding the differences between the services as much as + possible. io.systemd.DropIn makes JSON user/group records from the aforementioned + drop-in directories available. + + + + See Also + + systemd1, + nss-systemd8, + userdbctl1, + systemd-homed.service8 + + + diff --git a/man/systemd-vconsole-setup.service.xml b/man/systemd-vconsole-setup.service.xml new file mode 100644 index 0000000..80577ed --- /dev/null +++ b/man/systemd-vconsole-setup.service.xml @@ -0,0 +1,63 @@ + + + + + + + + systemd-vconsole-setup.service + systemd + + + + systemd-vconsole-setup.service + 8 + + + + systemd-vconsole-setup.service + systemd-vconsole-setup + Configure the virtual consoles + + + + systemd-vconsole-setup.service + + /usr/lib/systemd/systemd-vconsole-setup + TTY + + + + + Description + + systemd-vconsole-setup sets up and configures either all virtual consoles, or — if the + optional TTY parameter is provided — a specific one. When the system is booting up, it's + called by systemd-udevd8 during + VT console subsystem initialization. Also, + systemd-localed.service8 invokes + it as needed when language or console changes are made. Internally, this program calls loadkeys1 and setfont8. + + + Execute systemctl restart systemd-vconsole-setup.service in order to apply any manual + changes made to /etc/vconsole.conf. + + See vconsole.conf5 for + information about the configuration files and kernel command line options understood by this program. + + + + See Also + + systemd1, + vconsole.conf5, + loadkeys1, + setfont8, + systemd-localed.service8 + + + + diff --git a/man/systemd-veritysetup-generator.xml b/man/systemd-veritysetup-generator.xml new file mode 100644 index 0000000..331b5c0 --- /dev/null +++ b/man/systemd-veritysetup-generator.xml @@ -0,0 +1,116 @@ + + + + + + + + systemd-veritysetup-generator + systemd + + + + systemd-veritysetup-generator + 8 + + + + systemd-veritysetup-generator + Unit generator for verity protected block devices + + + + /usr/lib/systemd/system-generators/systemd-veritysetup-generator + + + + Description + + systemd-veritysetup-generator is a generator that translates kernel command line options + configuring verity protected block devices into native systemd units early at boot and when + configuration of the system manager is reloaded. This will create + systemd-veritysetup@.service8 + units as necessary. + + Currently, only two verity devices may be set up with this generator, backing the root and /usr file systems of the + OS. + + systemd-veritysetup-generator implements + systemd.generator7. + + + + Kernel Command Line + + systemd-veritysetup-generator + understands the following kernel command line parameters: + + + + systemd.verity= + rd.systemd.verity= + + Takes a boolean argument. Defaults to yes. If + no, disables the generator entirely. rd.systemd.verity= is + honored only by the initrd while systemd.verity= is honored by both the host + system and the initrd. + + + + roothash= + + Takes a root hash value for the root file system. Expects a hash value formatted in hexadecimal + characters of the appropriate length (i.e. most likely 256 bit/64 characters, or longer). If not specified via + systemd.verity_root_data= and systemd.verity_root_hash=, the hash and + data devices to use are automatically derived from the specified hash value. Specifically, the data partition + device is looked for under a GPT partition UUID derived from the first 128bit of the root hash, the hash + partition device is looked for under a GPT partition UUID derived from the last 128bit of the root hash. Hence + it is usually sufficient to specify the root hash to boot from a verity protected root file system, as + device paths are automatically determined from it — as long as the partition table is properly set up. + + + + + systemd.verity_root_data= + systemd.verity_root_hash= + + These two settings take block device paths as arguments and may be used to explicitly + configure the data partition and hash partition to use for setting up the verity protection for the root file + system. If not specified, these paths are automatically derived from the roothash= argument + (see above). + + + + systemd.verity_root_options= + + Takes a comma-separated list of dm-verity options. Expects the following options + , , , + , and + . See + veritysetup8 for more + details. + + + + usrhash= + systemd.verity_usr_data= + systemd.verity_usr_hash= + systemd.verity_usr_options= + + Equivalent to their counterparts for the root file system as described above, but apply to the /usr/ file system instead. + + + + + + See Also + + systemd1, + systemd-veritysetup@.service8, + veritysetup8, + systemd-fstab-generator8 + + + + diff --git a/man/systemd-veritysetup@.service.xml b/man/systemd-veritysetup@.service.xml new file mode 100644 index 0000000..423db91 --- /dev/null +++ b/man/systemd-veritysetup@.service.xml @@ -0,0 +1,97 @@ + + + + + + + + systemd-veritysetup@.service + systemd + + + + systemd-veritysetup@.service + 8 + + + + systemd-veritysetup@.service + systemd-veritysetup + Disk verity protection logic + + + + systemd-veritysetup@.service + /usr/lib/systemd/systemd-veritysetup + + + + Description + + systemd-veritysetup@.service is a service responsible for setting up verity + protection block devices. It should be instantiated for each device that requires verity + protection. + + At early boot and when the system manager configuration is reloaded kernel command line configuration for + verity protected block devices is translated into systemd-veritysetup@.service units by + systemd-veritysetup-generator8. + + systemd-veritysetup@.service calls systemd-veritysetup. + + + + Commands + + The following commands are understood by systemd-veritysetup: + + + + + + volume + datadevice + hashdevice + roothash + [option...] + + + Create a block device volume using + datadevice and hashdevice as the backing + devices. roothash forms the root of the tree of hashes stored on + hashdevice. See + + Kernel dm-verity documentation for details. + + + + + + + volume + + + Detach (destroy) the block device + volume. + + + + + + + + Print short information about command syntax. + + + + + + See Also + + systemd1, + systemd-veritysetup-generator8, + veritysetup8 + + + + diff --git a/man/systemd-volatile-root.service.xml b/man/systemd-volatile-root.service.xml new file mode 100644 index 0000000..e555260 --- /dev/null +++ b/man/systemd-volatile-root.service.xml @@ -0,0 +1,55 @@ + + + + + + + + systemd-volatile-root.service + systemd + + + + systemd-volatile-root.service + 8 + + + + systemd-volatile-root.service + systemd-volatile-root + Make the root file system volatile + + + + systemd-volatile-root.service + /usr/lib/systemd/systemd-volatile-root + + + + Description + + systemd-volatile-root.service is a service that replaces the root directory with a + volatile memory file system (tmpfs), mounting the original (non-volatile) + /usr/ inside it read-only. This way, vendor data from /usr/ is available as + usual, but all configuration data in /etc/, all state data in /var/ and all + other resources stored directly under the root directory are reset on boot and lost at shutdown, enabling fully + stateless systems. + + This service is only enabled if full volatile mode is selected, for example by specifying + systemd.volatile=yes on the kernel command line. This service runs only in the initrdyes, + before the system transitions to the host's root directory. Note that this service is not used if + systemd.volatile=state is used, as in that mode the root directory is + non-volatile. + + + + See Also + + systemd1, + systemd-fstab-generator8, + kernel-command-line7 + + + + diff --git a/man/systemd-xdg-autostart-generator.xml b/man/systemd-xdg-autostart-generator.xml new file mode 100644 index 0000000..bafe6e9 --- /dev/null +++ b/man/systemd-xdg-autostart-generator.xml @@ -0,0 +1,106 @@ + + + + + + + + systemd-xdg-autostart-generator + systemd + + + + systemd-xdg-autostart-generator + 8 + + + + systemd-xdg-autostart-generator + User unit generator for XDG autostart files + + + + /usr/lib/systemd/user-generators/systemd-xdg-autostart-generator + + + + Description + + systemd-xdg-autostart-generator is a generator + that creates .service units for + XDG autostart + files. + This permits desktop environments to delegate startup of these applications to + systemd1 + . + + Units created by systemd-xdg-autostart-generator + can be started by the desktop environment using xdg-desktop-autostart.target. + See + systemd.special7 + for more details. + + XDG autostart may be conditionalized using both standardized and non-standardized keys. + In order to handle these, the generator may create one or more ExecCondition= entries. + For non-standardized keys, well-known helper binaries provided by Desktop Environments are used. + All external helpers must detect their corresponding desktop environment and + must return success when run in a different environment. + This is important as all ExecCondition= directives must succeed for an application to be started. + + + + Special XDG desktop file entries that are processed + + + + + + + Entry + Handling + + + + + Hidden=, X-systemd-skip= + No service will be generated if set to true + + + OnlyShowIn=, NotShowIn= + ExecCondition= using systemd-xdg-autostart-condition + + + TryExec= + No service will be generated if the binary does not exist or cannot be executed + + + AutostartCondition= (GNOME extension) + ExecCondition= using gnome-systemd-autostart-condition + + + X-GNOME-Autostart-Phase= + No service will be generated if set to any value + + + X-KDE-autostart-condition= + ExecCondition= using kde-systemd-start-condition + + + +
+ + systemd-xdg-autostart-generator implements + systemd.generator7. + + + + See Also + + systemd1, + systemd.service5, + systemd.target5 + + + + diff --git a/man/systemd.automount.xml b/man/systemd.automount.xml new file mode 100644 index 0000000..67c59e1 --- /dev/null +++ b/man/systemd.automount.xml @@ -0,0 +1,190 @@ + + + + + + + systemd.automount + systemd + + + + systemd.automount + 5 + + + + systemd.automount + Automount unit configuration + + + + automount.automount + + + + Description + + A unit configuration file whose name ends in .automount encodes information + about a file system automount point controlled and supervised by systemd. Automount units may be used to + implement on-demand mounting as well as parallelized mounting of file systems. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The automount specific configuration options + are configured in the [Automount] section. + + Automount units must be named after the automount directories they control. Example: the automount + point /home/lennart must be configured in a unit file + home-lennart.automount. For details about the escaping logic used to convert a file + system path to a unit name see + systemd.unit5. Note + that automount units cannot be templated, nor is it possible to add multiple names to an automount unit + by creating symlinks to its unit file. + + For each automount unit file a matching mount unit file (see + systemd.mount5 + for details) must exist which is activated when the automount path + is accessed. Example: if an automount unit + home-lennart.automount is active and the user + accesses /home/lennart the mount unit + home-lennart.mount will be activated. + + Note that automount units are separate from the mount itself, so you + should not set After= or Requires= + for mount dependencies here. For example, you should not set + After=network-online.target or similar on network + filesystems. Doing so may result in an ordering cycle. + + Note that automount support on Linux is privileged, automount units are hence only available in the + system service manager (and root's user service manager), but not in unprivileged users' service + managers. + + Note that automount units should not be nested. (The establishment of the inner automount point + would unconditionally pin the outer mount point, defeating its purpose.) + + + + Automatic Dependencies + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + If an automount unit is beneath another mount unit in the file system hierarchy, a + requirement and ordering dependencies are created to the on the unit higher in the hierarchy. + + + An implicit Before= dependency is created between an automount + unit and the mount unit it activates. + + + + + Default Dependencies + + The following dependencies are added unless DefaultDependencies=no is set: + + + Automount units acquire automatic Before= and + Conflicts= on umount.target in order to be stopped during + shutdown. + + Automount units automatically gain an After= dependency + on local-fs-pre.target, and a Before= dependency on + local-fs.target. + + + + + + <filename>fstab</filename> + + Automount units may either be configured via unit files, or + via /etc/fstab (see + fstab5 + for details). + + For details how systemd parses + /etc/fstab see + systemd.mount5. + + If an automount point is configured in both + /etc/fstab and a unit file, the configuration + in the latter takes precedence. + + + + Options + + Automount unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + + + Automount unit files must include an [Automount] section, which + carries information about the file system automount points it + supervises. The options specific to the [Automount] section of + automount units are the following: + + + + + Where= + Takes an absolute path of a directory of the + automount point. If the automount point does not exist at time + that the automount point is installed, it is created. This + string must be reflected in the unit filename. (See above.) + This option is mandatory. + + + + ExtraOptions= + Extra mount options to use when creating the autofs + mountpoint. This takes a comma-separated list of options. This setting + is optional. Note that the usual specifier expansion is applied to this + setting, literal percent characters should hence be written as + %%. + + + + DirectoryMode= + Directories of automount points (and any + parent directories) are automatically created if needed. This + option specifies the file system access mode used when + creating these directories. Takes an access mode in octal + notation. Defaults to 0755. + + + + TimeoutIdleSec= + Configures an idle timeout. Once the mount has been + idle for the specified time, systemd will attempt to unmount. Takes a + unit-less value in seconds, or a time span value such as "5min 20s". + Pass 0 to disable the timeout logic. The timeout is disabled by + default. + + + + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.mount5, + mount8, + automount8, + systemd.directives7 + + + + diff --git a/man/systemd.device.xml b/man/systemd.device.xml new file mode 100644 index 0000000..529552e --- /dev/null +++ b/man/systemd.device.xml @@ -0,0 +1,171 @@ + + + + + + + systemd.device + systemd + + + + systemd.device + 5 + + + + systemd.device + Device unit configuration + + + + device.device + + + + Description + + A unit configuration file whose name ends in .device encodes information about a + device unit as exposed in the + sysfs/udev7 device + tree. This may be used to define dependencies between devices and other units. + + This unit type has no specific options. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic + [Unit] and [Install] + sections. A separate [Device] section does not + exist, since no device-specific options may be configured. + + systemd will dynamically create device units for all kernel devices that are marked with the + systemd udev tag (by default all block and network devices, and a few others). Note + that if systemd-udevd.service is not running, no device units will be + available (for example in a typical container). + + Device units are named after the /sys/ + and /dev/ paths they control. Example: the + device /dev/sda5 is exposed in + systemd as dev-sda5.device. For details about + the escaping logic used to convert a file system path to a unit + name see + systemd.unit5. + + To tag a udev device, use TAG+="systemd" in the udev rules file, see + udev7 for details. + + + Device units will be reloaded by systemd whenever the + corresponding device generates a changed event. + Other units can use ReloadPropagatedFrom= to react + to that event. + + + + Automatic Dependencies + + + Implicit Dependencies + + Many unit types automatically acquire dependencies on device + units of devices they require. For example, + .socket unit acquire dependencies on the + device units of the network interface specified in + BindToDevice=. Similar, swap and mount units + acquire dependencies on the units encapsulating their backing + block devices. + + + + Default Dependencies + + There are no default dependencies for device units. + + + + + The udev Database + + Unit settings of device units may either be configured via unit files, or directly from the udev + database. The following udev device properties are understood by the service manager: + + + + SYSTEMD_WANTS= + SYSTEMD_USER_WANTS= + Adds dependencies of type Wants= from the device unit to the specified + units. SYSTEMD_WANTS= is read by the system service manager, + SYSTEMD_USER_WANTS= by user service manager instances. These properties may be used to + activate arbitrary units when a specific device becomes available. + + Note that this and the other udev device properties are not taken into account unless the device is + tagged with the systemd tag in the udev database, because otherwise the device is not + exposed as a systemd unit (see above). + + Note that systemd will only act on Wants= dependencies when a device first becomes + active. It will not act on them if they are added to devices that are already active. Use + SYSTEMD_READY= (see below) to configure when a udev device shall be considered active, and + thus when to trigger the dependencies. + + + + The specified property value should be a space-separated list of valid unit names. If a unit template + name is specified (that is, a unit name containing an @ character indicating a unit name to + use for multiple instantiation, but with an empty instance name following the @), it will be + automatically instantiated by the device's sysfs path (that is: the path is escaped and + inserted as instance name into the template unit name). This is useful in order to instantiate a specific + template unit once for each device that appears and matches specific properties. + + + + SYSTEMD_ALIAS= + Adds an additional alias name to the device + unit. This must be an absolute path that is automatically + transformed into a unit name. (See above.) + + + + SYSTEMD_READY= + If set to 0, systemd will consider this device unplugged even if it shows up in the udev + tree. If this property is unset or set to 1, the device will be considered plugged if it is visible in the udev + tree. + + This option is useful for devices that initially show up in an uninitialized state in the tree, and for + which a changed event is generated the moment they are fully set up. Note that + SYSTEMD_WANTS= (see above) is not acted on as long as SYSTEMD_READY=0 is + set for a device. + + + + ID_MODEL_FROM_DATABASE= + ID_MODEL= + + If set, this property is used as description + string for the device unit. + + + + + + + Options + + Device unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. No + options specific to this file type are supported. + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + udev7, + systemd.directives7 + + + + diff --git a/man/systemd.dnssd.xml b/man/systemd.dnssd.xml new file mode 100644 index 0000000..c7d781b --- /dev/null +++ b/man/systemd.dnssd.xml @@ -0,0 +1,227 @@ + + + + + + + + systemd.dnssd + systemd + + + + systemd.dnssd + 5 + + + + systemd.dnssd + DNS-SD configuration + + + + network_service.dnssd + + + + Description + + DNS-SD setup is performed by + systemd-resolved8. + + + The main network service file must have the extension .dnssd; other + extensions are ignored. + + The .dnssd files are read from the files located in the system network + directories /usr/lib/systemd/dnssd and + /usr/local/lib/systemd/dnssd, the volatile runtime network directory + /run/systemd/dnssd and the local administration network directory + /etc/systemd/dnssd. All configuration files are collectively sorted and processed in + lexical order, regardless of the directories in which they live. However, files with identical filenames + replace each other. Files in /etc/ have the highest priority, files in + /run/ take precedence over files with the same name in + /usr/lib/. This can be used to override a system-supplied configuration file with a + local file if needed. + + Along with the network service file foo.dnssd, a "drop-in" directory + foo.dnssd.d/ may exist. All files with the suffix + .conf from this directory will be parsed after the file itself is + parsed. This is useful to alter or add configuration settings, without having to modify the main + configuration file. Each drop-in file must have appropriate section headers. + + In addition to /etc/systemd/dnssd, drop-in .d directories + can be placed in /usr/lib/systemd/dnssd or /run/systemd/dnssd + directories. Drop-in files in /etc/ take precedence over those in + /run/ which in turn take precedence over those in /usr/lib/ or + /usr/local/lib. Drop-in files under any of these directories take precedence over + the main network service file wherever located. + + + + [Service] Section Options + + The network service file contains a [Service] + section, which specifies a discoverable network service announced in a + local network with Multicast DNS broadcasts. + + + + Name= + + An instance name of the network service as defined in the section 4.1.1 of RFC 6763, e.g. webserver. + The option supports simple specifier expansion. The following expansions are understood: + + Specifiers available + + + + + + + Specifier + Meaning + Details + + + + + + + + + + + + + + + + + +
+ + + + Type= + + A type of the network service as defined in the section 4.1.2 of RFC 6763, e.g. _http._tcp. + + + + + Port= + + An IP port number of the network service. + + + + Priority= + + A priority number set in SRV resource records corresponding + to the network service. + + + + Weight= + + A weight number set in SRV resource records corresponding + to the network service. + + + + TxtText= + + A whitespace-separated list of arbitrary key/value pairs + conveying additional information about the named service in the corresponding TXT resource record, + e.g. path=/portal/index.html. Keys and values can contain C-style escape + sequences which get translated upon reading configuration files. + + This option together with TxtData= may be specified more than once, in which + case multiple TXT resource records will be created for the service. If the empty string is assigned to + this option, the list is reset and all prior assignments will have no effect. + + + + + TxtData= + + A whitespace-separated list of arbitrary key/value pairs + conveying additional information about the named service in the corresponding TXT resource record + where values are base64-encoded string representing any binary data, + e.g. data=YW55IGJpbmFyeSBkYXRhCg==. Keys can contain C-style escape + sequences which get translated upon reading configuration files. + + This option together with TxtText= may be specified more than once, in which + case multiple TXT resource records will be created for the service. If the empty string is assigned to + this option, the list is reset and all prior assignments will have no effect. + + + + + + + + + Examples + + HTTP service + + # /etc/systemd/dnssd/http.dnssd +[Service] +Name=%H +Type=_http._tcp +Port=80 +TxtText=path=/stats/index.html t=temperature_sensor + + This makes the http server running on the host discoverable in the local network + given MulticastDNS is enabled on the network interface. + + Now the utility resolvectl should be able to resolve the + service to the host's name: + + $ resolvectl service meteo._http._tcp.local +meteo._http._tcp.local: meteo.local:80 [priority=0, weight=0] + 169.254.208.106%senp0s21f0u2u4 + fe80::213:3bff:fe49:8aa%senp0s21f0u2u4 + path=/stats/index.html + t=temperature_sensor + (meteo/_http._tcp/local) + +-- Information acquired via protocol mDNS/IPv6 in 4.0ms. +-- Data is authenticated: yes + + Avahi running on a different host in the same local network should see the service as well: + + $ avahi-browse -a -r ++ enp3s0 IPv6 meteo Web Site local ++ enp3s0 IPv4 meteo Web Site local += enp3s0 IPv6 meteo Web Site local + hostname = [meteo.local] + address = [fe80::213:3bff:fe49:8aa] + port = [80] + txt = ["path=/stats/index.html" "t=temperature_sensor"] += enp3s0 IPv4 meteo Web Site local + hostname = [meteo.local] + address = [169.254.208.106] + port = [80] + txt = ["path=/stats/index.html" "t=temperature_sensor"] + + + + + + See Also + + systemd1, + systemd-resolved.service8, + resolvectl1 + + + + diff --git a/man/systemd.environment-generator.xml b/man/systemd.environment-generator.xml new file mode 100644 index 0000000..856f6a6 --- /dev/null +++ b/man/systemd.environment-generator.xml @@ -0,0 +1,134 @@ + + +%entities; +]> + + + + + systemd.environment-generator + systemd + + + + systemd.environment-generator + 7 + + + + systemd.environment-generator + systemd environment file generators + + + + + &SYSTEM_ENV_GENERATOR_DIR;/some-generator + + + &USER_ENV_GENERATOR_DIR;/some-generator + + + + /run/systemd/system-environment-generators/* +/etc/systemd/system-environment-generators/* +/usr/local/lib/systemd/system-environment-generators/* +&SYSTEM_ENV_GENERATOR_DIR;/* + + + + /run/systemd/user-environment-generators/* +/etc/systemd/user-environment-generators/* +/usr/local/lib/systemd/user-environment-generators/* +&USER_ENV_GENERATOR_DIR;/* + + + + + Description + Generators are small executables that live in + &SYSTEM_ENV_GENERATOR_DIR;/ and other directories listed above. + systemd1 will + execute those binaries very early at the startup of each manager and at configuration + reload time, before running the generators described in + systemd.generator7 + and before starting any units. Environment generators can override the environment that the + manager exports to services and other processes. + + Generators are loaded from a set of paths determined during compilation, as listed + above. System and user environment generators are loaded from directories with names ending in + system-environment-generators/ and + user-environment-generators/, respectively. Generators found in directories + listed earlier override the ones with the same name in directories lower in the list. A symlink + to /dev/null or an empty file can be used to mask a generator, thereby + preventing it from running. Please note that the order of the two directories with the highest + priority is reversed with respect to the unit load path, and generators in + /run/ overwrite those in /etc/. + + After installing new generators or updating the configuration, systemctl + daemon-reload may be executed. This will re-run all generators, updating environment + configuration. It will be used for any services that are started subsequently. + + Environment file generators are executed similarly to unit file generators described + in + systemd.generator7, + with the following differences: + + + + Generators are executed sequentially in the alphanumerical order of the final + component of their name. The output of each generator output is immediately parsed and used + to update the environment for generators that run after that. Thus, later generators can use + and/or modify the output of earlier generators. + + + + Generators are run by every manager instance, their output can be different for each + user. + + + + It is recommended to use numerical prefixes for generator names to simplify ordering. + + + + Examples + + + A simple generator that extends an environment variable if a directory exists in the file system + + # 50-xdg-data-dirs.sh + + + + + + A more complicated generator which reads existing configuration and mutates one variable + + # 90-rearrange-path.py + + + + + + Debugging a generator + + SYSTEMD_LOG_LEVEL=debug VAR_A=something VAR_B="something else" \ +&SYSTEM_ENV_GENERATOR_DIR;/path-to-generator + + + + + + See also + + + systemd-environment-d-generator8, + systemd.generator7, + systemd1, + systemctl1 + + + diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml new file mode 100644 index 0000000..6459b01 --- /dev/null +++ b/man/systemd.exec.xml @@ -0,0 +1,4259 @@ + + + + + + + systemd.exec + systemd + + + + systemd.exec + 5 + + + + systemd.exec + Execution environment configuration + + + + service.service, + socket.socket, + mount.mount, + swap.swap + + + + Description + + Unit configuration files for services, sockets, mount points, and swap devices share a subset of + configuration options which define the execution environment of spawned processes. + + This man page lists the configuration options shared by these four unit types. See + systemd.unit5 for the common + options of all unit configuration files, and + systemd.service5, + systemd.socket5, + systemd.swap5, and + systemd.mount5 for more + information on the specific unit configuration files. The execution specific configuration options are configured + in the [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type. + + In addition, options which control resources through Linux Control Groups (cgroups) are listed in + systemd.resource-control5. + Those options complement options listed here. + + + + Implicit Dependencies + + A few execution parameters result in additional, automatic dependencies to be added: + + + Units with WorkingDirectory=, RootDirectory=, + RootImage=, RuntimeDirectory=, StateDirectory=, + CacheDirectory=, LogsDirectory= or + ConfigurationDirectory= set automatically gain dependencies of type + Requires= and After= on all mount units required to access the specified + paths. This is equivalent to having them listed explicitly in + RequiresMountsFor=. + + Similarly, units with PrivateTmp= enabled automatically get mount + unit dependencies for all mounts required to access /tmp/ and + /var/tmp/. They will also gain an automatic After= dependency + on + systemd-tmpfiles-setup.service8. + + + Units whose standard output or error output is connected to or + (or their combinations with console output, see below) automatically acquire + dependencies of type After= on + systemd-journald.socket. + + Units using LogNamespace= will automatically gain ordering and + requirement dependencies on the two socket units associated with + systemd-journald@.service instances. + + + + + + + Paths + + The following settings may be used to change a service's view of the filesystem. Please note that the paths + must be absolute and must not contain a .. path component. + + + + + ExecSearchPath= + + Takes a colon separated list of absolute paths relative to which the executable + used by the Exec*= (e.g. ExecStart=, + ExecStop=, etc.) properties can be found. ExecSearchPath= + overrides $PATH if $PATH is not supplied by the user through + Environment=, EnvironmentFile= or + PassEnvironment=. Assigning an empty string removes previous assignments + and setting ExecSearchPath= to a value multiple times will append + to the previous setting. + + + + + WorkingDirectory= + + Takes a directory path relative to the service's root directory specified by + RootDirectory=, or the special value ~. Sets the working directory for + executed processes. If set to ~, the home directory of the user specified in + User= is used. If not set, defaults to the root directory when systemd is running as a + system instance and the respective user's home directory if run as user. If the setting is prefixed with the + - character, a missing working directory is not considered fatal. If + RootDirectory=/RootImage= is not set, then + WorkingDirectory= is relative to the root of the system running the service manager. Note + that setting this parameter might result in additional dependencies to be added to the unit (see + above). + + + + RootDirectory= + + Takes a directory path relative to the host's root directory (i.e. the root of the system + running the service manager). Sets the root directory for executed processes, with the chroot2 system + call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in + the chroot() jail. Note that setting this parameter might result in additional + dependencies to be added to the unit (see above). + + The MountAPIVFS= and PrivateUsers= settings are particularly useful + in conjunction with RootDirectory=. For details, see below. + + If RootDirectory=/RootImage= are used together with + NotifyAccess= the notification socket is automatically mounted from the host into + the root environment, to ensure the notification interface can work correctly. + + Note that services using RootDirectory=/RootImage= will + not be able to log via the syslog or journal protocols to the host logging infrastructure, unless the + relevant sockets are mounted from the host, specifically: + + + Mounting logging sockets into root environment + + BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout + + + + + + + RootImage= + + Takes a path to a block device node or regular file as argument. This call is similar + to RootDirectory= however mounts a file system hierarchy from a block device node + or loopback file instead of a directory. The device node or file system image file needs to contain a + file system without a partition table, or a file system within an MBR/MS-DOS or GPT partition table + with only a single Linux-compatible partition, or a set of file systems within a GPT partition table + that follows the Discoverable Partitions + Specification. + + When DevicePolicy= is set to closed or + strict, or set to auto and DeviceAllow= is + set, then this setting adds /dev/loop-control with rw mode, + block-loop and block-blkext with rwm mode + to DeviceAllow=. See + systemd.resource-control5 + for the details about DevicePolicy= or DeviceAllow=. Also, see + PrivateDevices= below, as it may change the setting of + DevicePolicy=. + + Units making use of RootImage= automatically gain an + After= dependency on systemd-udevd.service. + + + + + + RootImageOptions= + + Takes a comma-separated list of mount options that will be used on disk images specified by + RootImage=. Optionally a partition name can be prefixed, followed by colon, in + case the image has multiple partitions, otherwise partition name root is implied. + Options for multiple partitions can be specified in a single line with space separators. Assigning an empty + string removes previous assignments. Duplicated options are ignored. For a list of valid mount options, please + refer to + mount8. + + + Valid partition names follow the Discoverable Partitions Specification: + root, usr, home, srv, + esp, xbootldr, tmp, + var. + + + + + + RootHash= + + Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file + containing a root hash in ASCII hexadecimal format. This option enables data integrity checks using dm-verity, + if the used image contains the appropriate integrity data (see above) or if RootVerity= is used. + The specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64 + formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but + the image file carries the user.verity.roothash extended file attribute (see xattr7), then the root + hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or + is not supported by the underlying file system), but a file with the .roothash suffix is + found next to the image file, bearing otherwise the same name (except if the image has the + .raw suffix, in which case the root hash file must not have it in its name), the root hash + is read from it and automatically used, also as formatted hexadecimal characters. + + If the disk image contains a separate /usr/ partition it may also be + Verity protected, in which case the root hash may configured via an extended attribute + user.verity.usrhash or a .usrhash file adjacent to the disk + image. There's currently no option to configure the root hash for the /usr/ file + system via the unit file directly. + + + + + + RootHashSignature= + + Takes a PKCS7 signature of the RootHash= option as a path to a + DER-encoded signature file, or as an ASCII base64 string encoding of a DER-encoded signature prefixed + by base64:. The dm-verity volume will only be opened if the signature of the root + hash is valid and signed by a public key present in the kernel keyring. If this option is not + specified, but a file with the .roothash.p7s suffix is found next to the image + file, bearing otherwise the same name (except if the image has the .raw suffix, + in which case the signature file must not have it in its name), the signature is read from it and + automatically used. + + If the disk image contains a separate /usr/ partition it may also be + Verity protected, in which case the signature for the root hash may configured via a + .usrhash.p7s file adjacent to the disk image. There's currently no option to + configure the root hash signature for the /usr/ via the unit file + directly. + + + + + + RootVerity= + + Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks + using dm-verity, if RootImage= is used and a root-hash is passed and if the used image itself + does not contains the integrity data. The integrity data must be matched by the root hash. If this option is not + specified, but a file with the .verity suffix is found next to the image file, bearing otherwise + the same name (except if the image has the .raw suffix, in which case the verity data file must + not have it in its name), the verity data is read from it and automatically used. + + This option is supported only for disk images that contain a single file system, without an + enveloping partition table. Images that contain a GPT partition table should instead include both + root file system and matching Verity data in the same image, implementing the Discoverable Partitions Specification. + + + + + + MountAPIVFS= + + Takes a boolean argument. If on, a private mount namespace for the unit's processes is created + and the API file systems /proc/, /sys/, /dev/ and + /run/ (as an empty tmpfs) are mounted inside of it, unless they are + already mounted. Note that this option has no effect unless used in conjunction with + RootDirectory=/RootImage= as these four mounts are + generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace + will be a 1:1 copy of the host's, and include these four mounts. Note that the /dev/ file + system of the host is bind mounted if this option is used without PrivateDevices=. To run + the service with a private, minimal version of /dev/, combine this option with + PrivateDevices=. + + In order to allow propagating mounts at runtime in a safe manner, /run/systemd/propagate/ + on the host will be used to set up new mounts, and /run/host/incoming/ in the private namespace + will be used as an intermediate step to store them before being moved to the final mount point. + + + + ProtectProc= + + Takes one of noaccess, invisible, + ptraceable or default (which it defaults to). When set, this + controls the hidepid= mount option of the procfs instance for + the unit that controls which directories with process metainformation + (/proc/PID) are visible and accessible: when set to + noaccess the ability to access most of other users' process metadata in + /proc/ is taken away for processes of the service. When set to + invisible processes owned by other users are hidden from + /proc/. If ptraceable all processes that cannot be + ptrace()'ed by a process are hidden to it. If default no + restrictions on /proc/ access or visibility are made. For further details see + The /proc + Filesystem. It is generally recommended to run most system services with this option set to + invisible. This option is implemented via file system namespacing, and thus cannot + be used with services that shall be able to install mount points in the host file system + hierarchy. Note that the root user is unaffected by this option, so to be effective it has to be used + together with User= or DynamicUser=yes, and also without the + CAP_SYS_PTRACE capability, which also allows a process to bypass this feature. It + cannot be used for services that need to access metainformation about other users' processes. This + option implies MountAPIVFS=. + + If the kernel doesn't support per-mount point mount options this + setting remains without effect, and the unit's processes will be able to access and see other process + as if the option was not used. + + + + + + ProcSubset= + + Takes one of all (the default) and pid. If + pid, all files and directories not directly associated with process management and + introspection are made invisible in the /proc/ file system configured for the + unit's processes. This controls the subset= mount option of the + procfs instance for the unit. For further details see The /proc + Filesystem. Note that Linux exposes various kernel APIs via /proc/, + which are made unavailable with this setting. Since these APIs are used frequently this option is + useful only in a few, specific cases, and is not suitable for most non-trivial programs. + + Much like ProtectProc= above, this is implemented via file system mount + namespacing, and hence the same restrictions apply: it is only available to system services, it + disables mount propagation to the host mount table, and it implies + MountAPIVFS=. Also, like ProtectProc= this setting is gracefully + disabled if the used kernel does not support the subset= mount option of + procfs. + + + + BindPaths= + BindReadOnlyPaths= + + Configures unit-specific bind mounts. A bind mount makes a particular file or directory + available at an additional place in the unit's view of the file system. Any bind mounts created with this + option are specific to the unit, and are not visible in the host's mount table. This option expects a + whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of + source path, destination path and option string, where the latter two are optional. If only a source path is + specified the source and destination is taken to be the same. The option string may be either + rbind or norbind for configuring a recursive or non-recursive bind + mount. If the destination path is omitted, the option string must be omitted too. + Each bind mount definition may be prefixed with -, in which case it will be ignored + when its source path does not exist. + + BindPaths= creates regular writable bind mounts (unless the source file system mount + is already marked read-only), while BindReadOnlyPaths= creates read-only bind mounts. These + settings may be used more than once, each usage appends to the unit's list of bind mounts. If the empty string + is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note + that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is + used. + + This option is particularly useful when RootDirectory=/RootImage= + is used. In this case the source path refers to a path on the host file system, while the destination path + refers to a path below the root directory of the unit. + + Note that the destination directory must exist or systemd must be able to create it. Thus, it + is not possible to use those options for mount points nested underneath paths specified in + InaccessiblePaths=, or under /home/ and other protected + directories if ProtectHome=yes is + specified. TemporaryFileSystem= with :ro or + ProtectHome=tmpfs should be used instead. + + + + MountImages= + + This setting is similar to RootImage= in that it mounts a file + system hierarchy from a block device node or loopback file, but the destination directory can be + specified as well as mount options. This option expects a whitespace separated list of mount + definitions. Each definition consists of a colon-separated tuple of source path and destination + definitions, optionally followed by another colon and a list of mount options. + + Mount options may be defined as a single comma-separated list of options, in which case they + will be implicitly applied to the root partition on the image, or a series of colon-separated tuples + of partition name and mount options. Valid partition names and mount options are the same as for + RootImageOptions= setting described above. + + Each mount definition may be prefixed with -, in which case it will be + ignored when its source path does not exist. The source argument is a path to a block device node or + regular file. If source or destination contain a :, it needs to be escaped as + \:. The device node or file system image file needs to follow the same rules as + specified for RootImage=. Any mounts created with this option are specific to the + unit, and are not visible in the host's mount table. + + These settings may be used more than once, each usage appends to the unit's list of mount + paths. If the empty string is assigned, the entire list of mount paths defined prior to this is + reset. + + Note that the destination directory must exist or systemd must be able to create it. Thus, it + is not possible to use those options for mount points nested underneath paths specified in + InaccessiblePaths=, or under /home/ and other protected + directories if ProtectHome=yes is specified. + + When DevicePolicy= is set to closed or + strict, or set to auto and DeviceAllow= is + set, then this setting adds /dev/loop-control with rw mode, + block-loop and block-blkext with rwm mode + to DeviceAllow=. See + systemd.resource-control5 + for the details about DevicePolicy= or DeviceAllow=. Also, see + PrivateDevices= below, as it may change the setting of + DevicePolicy=. + + + + + + ExtensionImages= + + This setting is similar to MountImages= in that it mounts a file + system hierarchy from a block device node or loopback file, but instead of providing a destination + path, an overlay will be set up. This option expects a whitespace separated list of mount + definitions. Each definition consists of a source path, optionally followed by a colon and a list of + mount options. + + A read-only OverlayFS will be set up on top of /usr/ and + /opt/ hierarchies. The order in which the images are listed will determine the + order in which the overlay is laid down: images specified first to last will result in overlayfs + layers bottom to top. + + Mount options may be defined as a single comma-separated list of options, in which case they + will be implicitly applied to the root partition on the image, or a series of colon-separated tuples + of partition name and mount options. Valid partition names and mount options are the same as for + RootImageOptions= setting described above. + + Each mount definition may be prefixed with -, in which case it will be + ignored when its source path does not exist. The source argument is a path to a block device node or + regular file. If the source path contains a :, it needs to be escaped as + \:. The device node or file system image file needs to follow the same rules as + specified for RootImage=. Any mounts created with this option are specific to the + unit, and are not visible in the host's mount table. + + These settings may be used more than once, each usage appends to the unit's list of image + paths. If the empty string is assigned, the entire list of mount paths defined prior to this is + reset. + + Each image must carry a /usr/lib/extension-release.d/extension-release.IMAGE + file, with the appropriate metadata which matches RootImage=/RootDirectory= + or the host. See: + os-release5. + To disable the safety check that the extension-release file name matches the image file name, the + x-systemd.relax-extension-release-check mount option may be appended. + + When DevicePolicy= is set to closed or + strict, or set to auto and DeviceAllow= is + set, then this setting adds /dev/loop-control with rw mode, + block-loop and block-blkext with rwm mode + to DeviceAllow=. See + systemd.resource-control5 + for the details about DevicePolicy= or DeviceAllow=. Also, see + PrivateDevices= below, as it may change the setting of + DevicePolicy=. + + + + + + ExtensionDirectories= + + This setting is similar to BindReadOnlyPaths= in that it mounts a file + system hierarchy from a directory, but instead of providing a destination path, an overlay will be set + up. This option expects a whitespace separated list of source directories. + + A read-only OverlayFS will be set up on top of /usr/ and + /opt/ hierarchies. The order in which the directories are listed will determine + the order in which the overlay is laid down: directories specified first to last will result in overlayfs + layers bottom to top. + + Each directory listed in ExtensionDirectories= may be prefixed with -, + in which case it will be ignored when its source path does not exist. Any mounts created with this option are + specific to the unit, and are not visible in the host's mount table. + + These settings may be used more than once, each usage appends to the unit's list of directories + paths. If the empty string is assigned, the entire list of mount paths defined prior to this is + reset. + + Each directory must contain a /usr/lib/extension-release.d/extension-release.IMAGE + file, with the appropriate metadata which matches RootImage=/RootDirectory= + or the host. See: + os-release5. + + Note that usage from user units requires overlayfs support in unprivileged user namespaces, + which was first introduced in kernel v5.11. + + + + + + + + User/Group Identity + + + + + + + User= + Group= + + Set the UNIX user or group that the processes are executed as, respectively. Takes a single + user or group name, or a numeric ID as argument. For system services (services run by the system service + manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of + systemd --user), the default is root, but User= may be + used to specify a different user. For user services of any other user, switching user identity is not + permitted, hence the only valid setting is the same user the user's service manager is running as. If no group + is set, the default group of the user is used. This setting does not affect commands whose command line is + prefixed with +. + + Note that this enforces only weak restrictions on the user/group name syntax, but will generate + warnings in many cases where user/group names do not adhere to the following rules: the specified + name should consist only of the characters a-z, A-Z, 0-9, _ and + -, except for the first character which must be one of a-z, A-Z and + _ (i.e. digits and - are not permitted as first character). The + user/group name must have at least one character, and at most 31. These restrictions are made in + order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux + systems. For further details on the names accepted and the names warned about see User/Group Name Syntax. + + When used in conjunction with DynamicUser= the user/group name specified is + dynamically allocated at the time the service is started, and released at the time the service is + stopped — unless it is already allocated statically (see below). If DynamicUser= + is not used the specified user and group must have been created statically in the user database no + later than the moment the service is started, for example using the + sysusers.d5 + facility, which is applied at boot or package install time. If the user does not exist by then + program invocation will fail. + + If the User= setting is used the supplementary group list is initialized + from the specified user's default group list, as defined in the system's user and group + database. Additional groups may be configured through the SupplementaryGroups= + setting (see below). + + + + DynamicUser= + + Takes a boolean parameter. If set, a UNIX user and group pair is allocated + dynamically when the unit is started, and released as soon as it is stopped. The user and group will + not be added to /etc/passwd or /etc/group, but are managed + transiently during runtime. The + nss-systemd8 glibc + NSS module provides integration of these dynamic users/groups into the system's user and group + databases. The user and group name to use may be configured via User= and + Group= (see above). If these options are not used and dynamic user/group + allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived from the + unit name. If the unit name without the type suffix qualifies as valid user name it is used directly, + otherwise a name incorporating a hash of it is used. If a statically allocated user or group of the + configured name already exists, it is used and no dynamic user/group is allocated. Note that if + User= is specified and the static group with the name exists, then it is required + that the static user with the name already exists. Similarly, if Group= is + specified and the static user with the name exists, then it is required that the static group with + the name already exists. Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is + recommended to avoid this range for regular system or login users. At any point in time each UID/GID + from this range is only assigned to zero or one dynamically allocated users/groups in use. However, + UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as + part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by + these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus + gain access to these files or directories. If DynamicUser= is enabled, + RemoveIPC= and PrivateTmp= are implied (and cannot be turned + off). This ensures that the lifetime of IPC objects and temporary files created by the executed + processes is bound to the runtime of the service, and hence the lifetime of the dynamic + user/group. Since /tmp/ and /var/tmp/ are usually the only + world-writable directories on a system this ensures that a unit making use of dynamic user/group + allocation cannot leave files around after unit termination. Furthermore + NoNewPrivileges= and RestrictSUIDSGID= are implicitly enabled + (and cannot be disabled), to ensure that processes invoked cannot take benefit or create SUID/SGID + files or directories. Moreover ProtectSystem=strict and + ProtectHome=read-only are implied, thus prohibiting the service to write to + arbitrary file system locations. In order to allow the service to write to certain directories, they + have to be allow-listed using ReadWritePaths=, but care must be taken so that + UID/GID recycling doesn't create security issues involving files created by the service. Use + RuntimeDirectory= (see below) in order to assign a writable runtime directory to a + service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use + StateDirectory=, CacheDirectory= and + LogsDirectory= in order to assign a set of writable directories for specific + purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see + below). If this option is enabled, care should be taken that the unit's processes do not get access + to directories outside of these explicitly configured and managed ones. Specifically, do not use + BindPaths= and be careful with AF_UNIX file descriptor + passing for directory file descriptors, as this would permit processes to create files or directories + owned by the dynamic user/group that are not subject to the lifecycle and access guarantees of the + service. Defaults to off. + + + + SupplementaryGroups= + + Sets the supplementary Unix groups the processes are executed as. This takes a space-separated + list of group names or IDs. This option may be specified more than once, in which case all listed groups are + set as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset, and + all assignments prior to this one will have no effect. In any way, this option does not override, but extends + the list of supplementary groups configured in the system group database for the user. This does not affect + commands prefixed with +. + + + + PAMName= + + Sets the PAM service name to set up a session as. If set, the executed process will be + registered as a PAM session under the specified service name. This is only useful in conjunction with the + User= setting, and is otherwise ignored. If not set, no PAM session will be opened for the + executed processes. See pam8 for + details. + + Note that for each unit making use of this option a PAM session handler process will be maintained as + part of the unit and stays around as long as the unit is active, to ensure that appropriate actions can be + taken when the unit and hence the PAM session terminates. This process is named (sd-pam) and + is an immediate child process of the unit's main process. + + Note that when this option is used for a unit it is very likely (depending on PAM configuration) that the + main unit process will be migrated to its own session scope unit when it is activated. This process will hence + be associated with two units: the unit it was originally started from (and for which + PAMName= was configured), and the session scope unit. Any child processes of that process + will however be associated with the session scope unit only. This has implications when used in combination + with NotifyAccess=, as these child processes will not be able to affect + changes in the original unit through notification messages. These messages will be considered belonging to the + session scope unit and not the original unit. It is hence not recommended to use PAMName= in + combination with NotifyAccess=. + + + + + + + + Capabilities + + + + + + + CapabilityBoundingSet= + + Controls which capabilities to include in the capability bounding set for the + executed process. See capabilities7 + for details. Takes a whitespace-separated list of capability names, + e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, + CAP_SYS_PTRACE. Capabilities listed will be included in the bounding set, all + others are removed. If the list of capabilities is prefixed with ~, all but the + listed capabilities will be included, the effect of the assignment inverted. Note that this option + also affects the respective capabilities in the effective, permitted and inheritable capability + sets. If this option is not used, the capability bounding set is not modified on process execution, + hence no limits on the capabilities of the process are enforced. This option may appear more than + once, in which case the bounding sets are merged by OR, or by + AND if the lines are prefixed with ~ (see below). If the + empty string is assigned to this option, the bounding set is reset to the empty capability set, and + all prior settings have no effect. If set to ~ (without any further argument), + the bounding set is reset to the full set of available capabilities, also undoing any previous + settings. This does not affect commands prefixed with +. + + Use + systemd-analyze1's + capability command to retrieve a list of capabilities defined on the local + system. + + Example: if a unit has the following, + CapabilityBoundingSet=CAP_A CAP_B +CapabilityBoundingSet=CAP_B CAP_C + then CAP_A, CAP_B, and + CAP_C are set. If the second line is prefixed with + ~, e.g., + CapabilityBoundingSet=CAP_A CAP_B +CapabilityBoundingSet=~CAP_B CAP_C + then, only CAP_A is set. + + + + AmbientCapabilities= + + Controls which capabilities to include in the ambient capability set for the executed + process. Takes a whitespace-separated list of capability names, e.g. CAP_SYS_ADMIN, + CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. This option may appear more than + once, in which case the ambient capability sets are merged (see the above examples in + CapabilityBoundingSet=). If the list of capabilities is prefixed with ~, + all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is + assigned to this option, the ambient capability set is reset to the empty capability set, and all prior + settings have no effect. If set to ~ (without any further argument), the ambient capability + set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding + capabilities to the ambient capability set adds them to the process's inherited capability set. + Ambient capability sets are useful if you want to execute a process as a non-privileged user but still want to + give it some capabilities. Note that in this case option keep-caps is automatically added + to SecureBits= to retain the capabilities over the user + change. AmbientCapabilities= does not affect commands prefixed with + +. + + + + + + + Security + + + + + NoNewPrivileges= + + Takes a boolean argument. If true, ensures that the service process and all its + children can never gain new privileges through execve() (e.g. via setuid or + setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that + a process and its children can never elevate privileges again. Defaults to false, but certain + settings override this and ignore the value of this setting. This is the case when + DynamicUser=, LockPersonality=, + MemoryDenyWriteExecute=, PrivateDevices=, + ProtectClock=, ProtectHostname=, + ProtectKernelLogs=, ProtectKernelModules=, + ProtectKernelTunables=, RestrictAddressFamilies=, + RestrictNamespaces=, RestrictRealtime=, + RestrictSUIDSGID=, SystemCallArchitectures=, + SystemCallFilter=, or SystemCallLog= are specified. Note that + even if this setting is overridden by them, systemctl show shows the original + value of this setting. In case the service will be run in a new mount namespace anyway and SELinux is + disabled, all file systems are mounted with MS_NOSUID flag. Also see No New Privileges + Flag. + + Note that this setting only has an effect on the unit's processes themselves (or any processes + directly or indirectly forked off them). It has no effect on processes potentially invoked on request + of them through tools such as at1p, + crontab1p, + systemd-run1, or + arbitrary IPC services. + + + + SecureBits= + + Controls the secure bits set for the executed process. Takes a space-separated combination of + options from the following list: , , + , , , and + . This option may appear more than once, in which case the secure bits are + ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands + prefixed with +. See capabilities7 for + details. + + + + + + + Mandatory Access Control + + + + + + + SELinuxContext= + + Set the SELinux security context of the executed process. If set, this will override the + automated domain transition. However, the policy still needs to authorize the transition. This directive is + ignored if SELinux is disabled. If prefixed by -, failing to set the SELinux + security context will be ignored, but it's still possible that the subsequent + execve() may fail if the policy doesn't allow the transition for the + non-overridden context. This does not affect commands prefixed with +. See + setexeccon3 + for details. + + + + AppArmorProfile= + + Takes a profile name as argument. The process executed by the unit will switch to + this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If + prefixed by -, all errors will be ignored. This setting has no effect if AppArmor + is not enabled. This setting does not affect commands prefixed with +. + + + + + SmackProcessLabel= + + Takes a security label as argument. The process executed by the unit + will be started under this label and SMACK will decide whether the process is allowed to run or not, based on + it. The process will continue to run under the label specified here unless the executable has its own + label, in which case the process will transition to run under that label. When not + specified, the label that systemd is running under is used. This directive is ignored if SMACK is + disabled. + + The value may be prefixed by -, in which case all errors will be ignored. An empty + value may be specified to unset previous assignments. This does not affect commands prefixed with + +. + + + + + + + Process Properties + + + + + LimitCPU= + LimitFSIZE= + LimitDATA= + LimitSTACK= + LimitCORE= + LimitRSS= + LimitNOFILE= + LimitAS= + LimitNPROC= + LimitMEMLOCK= + LimitLOCKS= + LimitSIGPENDING= + LimitMSGQUEUE= + LimitNICE= + LimitRTPRIO= + LimitRTTIME= + + Set soft and hard limits on various resources for executed processes. See + setrlimit2 for + details on the process resource limit concept. Process resource limits may be specified in two formats: + either as single value to set a specific soft and hard limit to the same value, or as colon-separated + pair to set both limits individually + (e.g. LimitAS=4G:16G). Use the string to configure no + limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may + be used for resource limits measured in bytes (e.g. LimitAS=16G). For the limits + referring to time values, the usual time units ms, s, min, h and so on may be used (see + systemd.time7 for + details). Note that if no time unit is specified for LimitCPU= the default unit of + seconds is implied, while for LimitRTTIME= the default unit of microseconds is + implied. Also, note that the effective granularity of the limits might influence their + enforcement. For example, time limits specified for LimitCPU= will be rounded up + implicitly to multiples of 1s. For LimitNICE= the value may be specified in two + syntaxes: if prefixed with + or -, the value is understood as + regular Linux nice value in the range -20…19. If not prefixed like this the value is understood as + raw resource limit parameter in the range 0…40 (with 0 being equivalent to 1). + + Note that most process resource limits configured with these options are per-process, and + processes may fork in order to acquire a new set of resources that are accounted independently of the + original process, and may thus escape limits set. Also note that LimitRSS= is not + implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource + controls listed in + systemd.resource-control5 + over these per-process limits, as they apply to services as a whole, may be altered dynamically at + runtime, and are generally more expressive. For example, MemoryMax= is a more + powerful (and working) replacement for LimitRSS=. + + Note that LimitNPROC= will limit the number of processes from one (real) UID and + not the number of processes started (forked) by the service. Therefore the limit is cumulative for all + processes running under the same UID. Please also note that the LimitNPROC= will not be + enforced if the service is running as root (and not dropping privileges). Due to these limitations, + TasksMax= (see systemd.resource-control + 5) is typically a better choice than LimitNPROC=. + + + Resource limits not configured explicitly for a unit default to the value configured in the various + DefaultLimitCPU=, DefaultLimitFSIZE=, … options available in + systemd-system.conf5, and – + if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user + services, see below). + + For system units these resource limits may be chosen freely. When these settings are configured + in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be + used to raise the limits above those set for the user manager itself when it was first invoked, as + the user's service manager generally lacks the privileges to do so. In user context these + configuration options are hence only useful to lower the limits passed in or to raise the soft limit + to the maximum of the hard limit as configured for the user. To raise the user's limits further, the + available configuration mechanisms differ between operating systems, but typically require + privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by + setting limits on the system service encapsulating the user's service manager, i.e. the user's + instance of user@.service. After making such changes, make sure to restart the + user's service manager. + + + Resource limit directives, their equivalent <command>ulimit</command> shell commands and the unit used + + + + + + + + + Directive + ulimit equivalent + Unit + Notes + + + + + LimitCPU= + ulimit -t + Seconds + - + + + LimitFSIZE= + ulimit -f + Bytes + - + + + LimitDATA= + ulimit -d + Bytes + Don't use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see MemoryMax= in systemd.resource-control5. + + + LimitSTACK= + ulimit -s + Bytes + - + + + LimitCORE= + ulimit -c + Bytes + - + + + LimitRSS= + ulimit -m + Bytes + Don't use. No effect on Linux. + + + LimitNOFILE= + ulimit -n + Number of File Descriptors + Don't use. Be careful when raising the soft limit above 1024, since select() cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use select(). Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use MemoryMax= to control overall service memory use, including file descriptor memory. + + + LimitAS= + ulimit -v + Bytes + Don't use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see MemoryMax= in systemd.resource-control5. + + + LimitNPROC= + ulimit -u + Number of Processes + This limit is enforced based on the number of processes belonging to the user. Typically it's better to track processes per service, i.e. use TasksMax=, see systemd.resource-control5. + + + LimitMEMLOCK= + ulimit -l + Bytes + - + + + LimitLOCKS= + ulimit -x + Number of Locks + - + + + LimitSIGPENDING= + ulimit -i + Number of Queued Signals + - + + + LimitMSGQUEUE= + ulimit -q + Bytes + - + + + LimitNICE= + ulimit -e + Nice Level + - + + + LimitRTPRIO= + ulimit -r + Realtime Priority + - + + + LimitRTTIME= + ulimit -R + Microseconds + - + + + +
+ + + + UMask= + + Controls the file mode creation mask. Takes an access mode in octal notation. See + umask2 for + details. Defaults to 0022 for system units. For user units the default value is inherited from the + per-user service manager (whose default is in turn inherited from the system service manager, and + thus typically also is 0022 — unless overridden by a PAM module). In order to change the per-user mask + for all user services, consider setting the UMask= setting of the user's + user@.service system service instance. The per-user umask may also be set via + the umask field of a user's JSON User + Record (for users managed by + systemd-homed.service8 + this field may be controlled via homectl --umask=). It may also be set via a PAM + module, such as pam_umask8. + + + + CoredumpFilter= + + Controls which types of memory mappings will be saved if the process dumps core + (using the /proc/pid/coredump_filter file). Takes a + whitespace-separated combination of mapping type names or numbers (with the default base 16). Mapping + type names are private-anonymous, shared-anonymous, + private-file-backed, shared-file-backed, + elf-headers, private-huge, + shared-huge, private-dax, shared-dax, + and the special values all (all types) and default (the + kernel default of private-anonymous + shared-anonymous elf-headers + private-huge). See + core5 + for the meaning of the mapping types. When specified multiple times, all specified masks are + ORed. When not set, or if the empty value is assigned, the inherited value is not changed. + + + Add DAX pages to the dump filter + + CoredumpFilter=default private-dax shared-dax + + + + + + KeyringMode= + + Controls how the kernel session keyring is set up for the service (see session-keyring7 for + details on the session keyring). Takes one of , , + . If set to no special keyring setup is done, and the kernel's + default behaviour is applied. If is used a new session keyring is allocated when a + service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for + system services, as this ensures that multiple services running under the same system user ID (in particular + the root user) do not share their key material among each other. If is used a new + session keyring is allocated as for , but the user keyring of the user configured with + User= is linked into it, so that keys assigned to the user may be requested by the unit's + processes. In this modes multiple units running processes under the same user ID may share key material. Unless + is selected the unique invocation ID for the unit (see below) is added as a protected + key by the name invocation_id to the newly created session keyring. Defaults to + for services of the system service manager and to for + non-service units and for services of the user service manager. + + + + OOMScoreAdjust= + + Sets the adjustment value for the Linux kernel's Out-Of-Memory (OOM) killer score for + executed processes. Takes an integer between -1000 (to disable OOM killing of processes of this unit) + and 1000 (to make killing of processes of this unit under memory pressure very likely). See The /proc Filesystem for + details. If not specified defaults to the OOM score adjustment level of the service manager itself, + which is normally at 0. + + Use the OOMPolicy= setting of service units to configure how the service + manager shall react to the kernel OOM killer or systemd-oomd terminating a process of the service. See + systemd.service5 + for details. + + + + TimerSlackNSec= + Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the + accuracy of wake-ups triggered by timers. See + prctl2 for more + information. Note that in contrast to most other time span definitions this parameter takes an integer value in + nano-seconds if no unit is specified. The usual time units are understood too. + + + + Personality= + + Controls which kernel architecture uname2 shall report, + when invoked by unit processes. Takes one of the architecture identifiers x86, + x86-64, ppc, ppc-le, ppc64, + ppc64-le, s390 or s390x. Which personality + architectures are supported depends on the system architecture. Usually the 64bit versions of the various + system architectures support their immediate 32bit personality architecture counterpart, but no others. For + example, x86-64 systems support the x86-64 and + x86 personalities but no others. The personality feature is useful when running 32-bit + services on a 64-bit host system. If not specified, the personality is left unmodified and thus reflects the + personality of the host system's kernel. + + + + IgnoreSIGPIPE= + + Takes a boolean argument. If true, causes SIGPIPE to be ignored in the + executed process. Defaults to true because SIGPIPE generally is useful only in shell + pipelines. + + + + + + + Scheduling + + + + + Nice= + + Sets the default nice level (scheduling priority) for executed processes. Takes an + integer between -20 (highest priority) and 19 (lowest priority). In case of resource contention, + smaller values mean more resources will be made available to the unit's processes, larger values mean + less resources will be made available. See + setpriority2 for + details. + + + + CPUSchedulingPolicy= + + Sets the CPU scheduling policy for executed processes. Takes one of , + , , or . See + sched_setscheduler2 for + details. + + + + CPUSchedulingPriority= + + Sets the CPU scheduling priority for executed processes. The available priority range + depends on the selected CPU scheduling policy (see above). For real-time scheduling policies an + integer between 1 (lowest priority) and 99 (highest priority) can be used. In case of CPU resource + contention, smaller values mean less CPU time is made available to the service, larger values mean + more. See sched_setscheduler2 + for details. + + + + CPUSchedulingResetOnFork= + + Takes a boolean argument. If true, elevated CPU scheduling priorities and policies + will be reset when the executed processes call + fork2, + and can hence not leak into child processes. See + sched_setscheduler2 + for details. Defaults to false. + + + + CPUAffinity= + + Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges + separated by either whitespace or commas. Alternatively, takes a special "numa" value in which case systemd + automatically derives allowed CPU range based on the value of NUMAMask= option. CPU ranges + are specified by the lower and upper CPU indices separated by a dash. This option may be specified more than + once, in which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask + is reset, all assignments prior to this will have no effect. See + sched_setaffinity2 for + details. + + + + NUMAPolicy= + + Controls the NUMA memory policy of the executed processes. Takes a policy type, one of: + , , , and + . A list of NUMA nodes that should be associated with the policy must be specified + in NUMAMask=. For more details on each policy please see, + set_mempolicy2. For overall + overview of NUMA support in Linux see, + numa7. + + + + + NUMAMask= + + Controls the NUMA node list which will be applied alongside with selected NUMA policy. + Takes a list of NUMA nodes and has the same syntax as a list of CPUs for CPUAffinity= + option or special "all" value which will include all available NUMA nodes in the mask. Note that the list + of NUMA nodes is not required for and + policies and for policy we expect a single NUMA node. + + + + IOSchedulingClass= + + Sets the I/O scheduling class for executed processes. Takes one of the strings + , or . The kernel's + default scheduling class is at a priority of 4. If the empty string is + assigned to this option, all prior assignments to both IOSchedulingClass= and + IOSchedulingPriority= have no effect. See + ioprio_set2 for + details. + + + + IOSchedulingPriority= + + Sets the I/O scheduling priority for executed processes. Takes an integer between 0 + (highest priority) and 7 (lowest priority). In case of I/O contention, smaller values mean more I/O + bandwidth is made available to the unit's processes, larger values mean less bandwidth. The available + priorities depend on the selected I/O scheduling class (see above). If the empty string is assigned + to this option, all prior assignments to both IOSchedulingClass= and + IOSchedulingPriority= have no effect. For the kernel's default scheduling class + () this defaults to 4. See + ioprio_set2 for + details. + + + + + + + Sandboxing + + The following sandboxing options are an effective way to limit the exposure of the system towards the unit's + processes. It is recommended to turn on as many of these options for each unit as is possible without negatively + affecting the process' ability to operate. Note that many of these sandboxing features are gracefully turned off on + systems where the underlying security mechanism is not available. For example, ProtectSystem= + has no effect if the kernel is built without file system namespacing or if the service manager runs in a container + manager that makes file system namespacing unavailable to its payload. Similarly, + RestrictRealtime= has no effect on systems that lack support for SECCOMP system call filtering, + or in containers where support for this is turned off. + + Also note that some sandboxing functionality is generally not available in user services (i.e. services run + by the per-user service manager). Specifically, the various settings requiring file system namespacing support + (such as ProtectSystem=) are not available, as the underlying kernel functionality is only + accessible to privileged processes. However, most namespacing settings, that will not work on their own in user + services, will work when used in conjunction with PrivateUsers=. + + + + + ProtectSystem= + + Takes a boolean argument or the special values full or + strict. If true, mounts the /usr/ and the boot loader + directories (/boot and /efi) read-only for processes + invoked by this unit. If set to full, the /etc/ directory is + mounted read-only, too. If set to strict the entire file system hierarchy is + mounted read-only, except for the API file system subtrees /dev/, + /proc/ and /sys/ (protect these directories using + PrivateDevices=, ProtectKernelTunables=, + ProtectControlGroups=). This setting ensures that any modification of the vendor-supplied + operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is + recommended to enable this setting for all long-running services, unless they are involved with system updates + or need to modify the operating system in other ways. If this option is used, + ReadWritePaths= may be used to exclude specific directories from being made read-only. This + setting is implied if DynamicUser= is set. This setting cannot ensure protection in all + cases. In general it has the same limitations as ReadOnlyPaths=, see below. Defaults to + off. + + + + ProtectHome= + + Takes a boolean argument or the special values read-only or + tmpfs. If true, the directories /home/, + /root, and /run/user are made inaccessible and empty for + processes invoked by this unit. If set to read-only, the three directories are + made read-only instead. If set to tmpfs, temporary file systems are mounted on the + three directories in read-only mode. The value tmpfs is useful to hide home + directories not relevant to the processes invoked by the unit, while still allowing necessary + directories to be made visible when listed in BindPaths= or + BindReadOnlyPaths=. + + Setting this to yes is mostly equivalent to setting the three directories in + InaccessiblePaths=. Similarly, read-only is mostly equivalent to + ReadOnlyPaths=, and tmpfs is mostly equivalent to + TemporaryFileSystem= with :ro. + + It is recommended to enable this setting for all long-running services (in particular + network-facing ones), to ensure they cannot get access to private user data, unless the services + actually require access to the user's private data. This setting is implied if + DynamicUser= is set. This setting cannot ensure protection in all cases. In + general it has the same limitations as ReadOnlyPaths=, see below. + + + + + + RuntimeDirectory= + StateDirectory= + CacheDirectory= + LogsDirectory= + ConfigurationDirectory= + + These options take a whitespace-separated list of directory names. The specified + directory names must be relative, and may not include ... If set, when the unit is + started, one or more directories by the specified names will be created (including their parents) + below the locations defined in the following table. Also, the corresponding environment variable will + be defined with the full paths of the directories. If multiple directories are set, then in the + environment variable the paths are concatenated with colon (:). + + Automatic directory creation and environment variables + + + + Directory + Below path for system units + Below path for user units + Environment variable set + + + + + RuntimeDirectory= + /run/ + $XDG_RUNTIME_DIR + $RUNTIME_DIRECTORY + + + StateDirectory= + /var/lib/ + $XDG_CONFIG_HOME + $STATE_DIRECTORY + + + CacheDirectory= + /var/cache/ + $XDG_CACHE_HOME + $CACHE_DIRECTORY + + + LogsDirectory= + /var/log/ + $XDG_CONFIG_HOME/log/ + $LOGS_DIRECTORY + + + ConfigurationDirectory= + /etc/ + $XDG_CONFIG_HOME + $CONFIGURATION_DIRECTORY + + + +
+ + In case of RuntimeDirectory= the innermost subdirectories are removed when + the unit is stopped. It is possible to preserve the specified directories in this case if + RuntimeDirectoryPreserve= is configured to or + (see below). The directories specified with StateDirectory=, + CacheDirectory=, LogsDirectory=, + ConfigurationDirectory= are not removed when the unit is stopped. + + Except in case of ConfigurationDirectory=, the innermost specified directories will be + owned by the user and group specified in User= and Group=. If the + specified directories already exist and their owning user or group do not match the configured ones, all files + and directories below the specified directories as well as the directories themselves will have their file + ownership recursively changed to match what is configured. As an optimization, if the specified directories are + already owned by the right user and group, files and directories below of them are left as-is, even if they do + not match what is requested. The innermost specified directories will have their access mode adjusted to the + what is specified in RuntimeDirectoryMode=, StateDirectoryMode=, + CacheDirectoryMode=, LogsDirectoryMode= and + ConfigurationDirectoryMode=. + + These options imply BindPaths= for the specified paths. When combined with + RootDirectory= or RootImage= these paths always reside on the host and + are mounted from there into the unit's file system namespace. + + If DynamicUser= is used, the logic for CacheDirectory=, + LogsDirectory= and StateDirectory= is slightly altered: the directories are created below + /var/cache/private, /var/log/private and /var/lib/private, + respectively, which are host directories made inaccessible to + unprivileged users, which ensures that access to these directories cannot be gained through dynamic + user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from + perspective of the host and from inside the unit, the relevant directories hence always appear + directly below /var/cache, /var/log and + /var/lib. + + Use RuntimeDirectory= to manage one or more runtime directories for the unit and bind + their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create + runtime directories in /run/ due to lack of privileges, and to make sure the runtime + directory is cleaned up automatically after use. For runtime directories that require more complex or different + configuration or lifetime guarantees, please consider using + tmpfiles.d5. + + RuntimeDirectory=, StateDirectory=, CacheDirectory= + and LogsDirectory= optionally support a second parameter, separated by :. + The second parameter will be interpreted as a destination path that will be created as a symlink to the directory. + The symlinks will be created after any BindPaths= or TemporaryFileSystem= + options have been set up, to make ephemeral symlinking possible. The same source can have multiple symlinks, by + using the same first parameter, but a different second parameter. + + The directories defined by these options are always created under the standard paths used by systemd + (/var/, /run/, /etc/, …). If the service needs + directories in a different location, a different mechanism has to be used to create them. + + tmpfiles.d5 provides + functionality that overlaps with these options. Using these options is recommended, because the lifetime of + the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the + tmpfiles.d configuration is executed before the unit is started. + + To remove any of the directories created by these settings, use the systemctl clean + … command on the relevant units, see + systemctl1 for + details. + + Example: if a system service unit has the following, + RuntimeDirectory=foo/bar baz + the service manager creates /run/foo (if it does not exist), + + /run/foo/bar, and /run/baz. The + directories /run/foo/bar and + /run/baz except /run/foo are + owned by the user and group specified in User= and Group=, and removed + when the service is stopped. + + Example: if a system service unit has the following, + RuntimeDirectory=foo/bar +StateDirectory=aaa/bbb ccc + then the environment variable RUNTIME_DIRECTORY is set with /run/foo/bar, and + STATE_DIRECTORY is set with /var/lib/aaa/bbb:/var/lib/ccc. + + Example: if a system service unit has the following, + RuntimeDirectory=foo:bar foo:baz + the service manager creates /run/foo (if it does not exist), and + /run/bar plus /run/baz as symlinks to + /run/foo. + + + + RuntimeDirectoryMode= + StateDirectoryMode= + CacheDirectoryMode= + LogsDirectoryMode= + ConfigurationDirectoryMode= + + Specifies the access mode of the directories specified in RuntimeDirectory=, + StateDirectory=, CacheDirectory=, LogsDirectory=, or + ConfigurationDirectory=, respectively, as an octal number. Defaults to + 0755. See "Permissions" in path_resolution7 for a + discussion of the meaning of permission bits. + + + + RuntimeDirectoryPreserve= + + Takes a boolean argument or . If set to (the + default), the directories specified in RuntimeDirectory= are always removed when the service + stops. If set to the directories are preserved when the service is both automatically + and manually restarted. Here, the automatic restart means the operation specified in + Restart=, and manual restart means the one triggered by systemctl restart + foo.service. If set to , then the directories are not removed when the service is + stopped. Note that since the runtime directory /run/ is a mount point of + tmpfs, then for system services the directories specified in + RuntimeDirectory= are removed when the system is rebooted. + + + + TimeoutCleanSec= + Configures a timeout on the clean-up operation requested through systemctl + clean …, see + systemctl1 for + details. Takes the usual time values and defaults to infinity, i.e. by default + no timeout is applied. If a timeout is configured the clean operation will be aborted forcibly when + the timeout is reached, potentially leaving resources on disk. + + + + ReadWritePaths= + ReadOnlyPaths= + InaccessiblePaths= + ExecPaths= + NoExecPaths= + + Sets up a new file system namespace for executed processes. These options may be used + to limit access a process has to the file system. Each setting takes a space-separated list of paths + relative to the host's root directory (i.e. the system running the service manager). Note that if + paths contain symlinks, they are resolved relative to the root directory set with + RootDirectory=/RootImage=. + + Paths listed in ReadWritePaths= are accessible from within the namespace + with the same access modes as from outside of it. Paths listed in ReadOnlyPaths= + are accessible for reading only, writing will be refused even if the usual file access controls would + permit this. Nest ReadWritePaths= inside of ReadOnlyPaths= in + order to provide writable subdirectories within read-only directories. Use + ReadWritePaths= in order to allow-list specific paths for write access if + ProtectSystem=strict is used. Note that ReadWritePaths= cannot + be used to gain write access to a file system whose superblock is mounted read-only. On Linux, for + each mount point write access is granted only if the mount point itself and the + file system superblock backing it are not marked read-only. ReadWritePaths= only + controls the former, not the latter, hence a read-only file system superblock remains + protected. + + Paths listed in InaccessiblePaths= will be made inaccessible for processes inside + the namespace along with everything below them in the file system hierarchy. This may be more restrictive than + desired, because it is not possible to nest ReadWritePaths=, ReadOnlyPaths=, + BindPaths=, or BindReadOnlyPaths= inside it. For a more flexible option, + see TemporaryFileSystem=. + + Content in paths listed in NoExecPaths= are not executable even if the usual + file access controls would permit this. Nest ExecPaths= inside of + NoExecPaths= in order to provide executable content within non-executable + directories. + + Non-directory paths may be specified as well. These options may be specified more than once, + in which case all paths listed will have limited access from within the namespace. If the empty string is + assigned to this option, the specific list is reset, and all prior assignments have no effect. + + Paths in ReadWritePaths=, ReadOnlyPaths=, + InaccessiblePaths=, ExecPaths= and + NoExecPaths= may be prefixed with -, in which case they will be + ignored when they do not exist. If prefixed with + the paths are taken relative to the root + directory of the unit, as configured with RootDirectory=/RootImage=, + instead of relative to the root directory of the host (see above). When combining - and + + on the same path make sure to specify - first, and + + second. + + Note that these settings will disconnect propagation of mounts from the unit's processes to the + host. This means that this setting may not be used for services which shall be able to install mount points in + the main mount namespace. For ReadWritePaths= and ReadOnlyPaths=, + propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the + unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that + mount propagation from host to unit will result in unmodified mounts to be created in the unit's namespace, + i.e. writable mounts appearing on the host will be writable in the unit's namespace too, even when propagated + below a path marked with ReadOnlyPaths=! Restricting access with these options hence does + not extend to submounts of a directory that are created later on. This means the lock-down offered by that + setting is not complete, and does not offer full protection. + + Note that the effect of these settings may be undone by privileged processes. In order to set up an + effective sandboxed environment for a unit it is thus recommended to combine these settings with either + CapabilityBoundingSet=~CAP_SYS_ADMIN or SystemCallFilter=~@mount. + + Please be extra careful when applying these options to API file systems (a list of them could be + found in MountAPIVPS=), since they may be required for basic system functionalities. + Moreover, /run/ needs to be writable for setting up mount namespace and propagation. + + Simple allow-list example using these directives: + [Service] +ReadOnlyPaths=/ +ReadWritePaths=/var /run +InaccessiblePaths=-/lost+found +NoExecPaths=/ +ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64 + + + + + + + TemporaryFileSystem= + + Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file + system namespace is set up for executed processes, and a temporary file system is mounted on each mount point. + This option may be specified more than once, in which case temporary file systems are mounted on all listed mount + points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect. + Each mount point may optionally be suffixed with a colon (:) and mount options such as + size=10% or ro. By default, each temporary file system is mounted + with nodev,strictatime,mode=0755. These can be disabled by explicitly specifying the corresponding + mount options, e.g., dev or nostrictatime. + + This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary + files or directories can be still accessed by combining with BindPaths= or + BindReadOnlyPaths=: + + Example: if a unit has the following, + TemporaryFileSystem=/var:ro +BindReadOnlyPaths=/var/lib/systemd + then the invoked processes by the unit cannot see any files or directories under /var/ except for + /var/lib/systemd or its contents. + + + + + + PrivateTmp= + + Takes a boolean argument. If true, sets up a new file system namespace for the + executed processes and mounts private /tmp/ and /var/tmp/ + directories inside it that are not shared by processes outside of the namespace. This is useful to + secure access to temporary files of the process, but makes sharing between processes via + /tmp/ or /var/tmp/ impossible. If true, all temporary files + created by a service in these directories will be removed after the service is stopped. Defaults to + false. It is possible to run two or more units within the same private /tmp/ and + /var/tmp/ namespace by using the JoinsNamespaceOf= directive, + see systemd.unit5 + for details. This setting is implied if DynamicUser= is set. For this setting, the + same restrictions regarding mount propagation and privileges apply as for + ReadOnlyPaths= and related calls, see above. Enabling this setting has the side + effect of adding Requires= and After= dependencies on all mount + units necessary to access /tmp/ and /var/tmp/. Moreover an + implicitly After= ordering on + systemd-tmpfiles-setup.service8 + is added. + + Note that the implementation of this setting might be impossible (for example if mount namespaces are not + available), and the unit should be written in a way that does not solely rely on this setting for + security. + + + + + + PrivateDevices= + + Takes a boolean argument. If true, sets up a new /dev/ mount for + the executed processes and only adds API pseudo devices such as /dev/null, + /dev/zero or /dev/random (as well as the pseudo TTY + subsystem) to it, but no physical devices such as /dev/sda, system memory + /dev/mem, system ports /dev/port and others. This is useful + to turn off physical device access by the executed process. Defaults to false. + + Enabling this option will install a system call filter to block low-level I/O system calls that + are grouped in the @raw-io set, remove CAP_MKNOD and + CAP_SYS_RAWIO from the capability bounding set for the unit, and set + DevicePolicy=closed (see + systemd.resource-control5 + for details). Note that using this setting will disconnect propagation of mounts from the service to + the host (propagation in the opposite direction continues to work). This means that this setting may + not be used for services which shall be able to install mount points in the main mount namespace. The + new /dev/ will be mounted read-only and 'noexec'. The latter may break old + programs which try to set up executable memory by using + mmap2 of + /dev/zero instead of using MAP_ANON. For this setting the + same restrictions regarding mount propagation and privileges apply as for + ReadOnlyPaths= and related calls, see above. If turned on and if running in user + mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting + User=), NoNewPrivileges=yes is implied. + + Note that the implementation of this setting might be impossible (for example if mount + namespaces are not available), and the unit should be written in a way that does not solely rely on + this setting for security. + + + + When access to some but not all devices must be possible, the DeviceAllow= + setting might be used instead. See + systemd.resource-control5. + + + + + PrivateNetwork= + + Takes a boolean argument. If true, sets up a new network namespace for the executed processes + and configures only the loopback network device lo inside it. No other network devices will + be available to the executed process. This is useful to turn off network access by the executed process. + Defaults to false. It is possible to run two or more units within the same private network namespace by using + the JoinsNamespaceOf= directive, see + systemd.unit5 for + details. Note that this option will disconnect all socket families from the host, including + AF_NETLINK and AF_UNIX. Effectively, for + AF_NETLINK this means that device configuration events received from + systemd-udevd.service8 are + not delivered to the unit's processes. And for AF_UNIX this has the effect that + AF_UNIX sockets in the abstract socket namespace of the host will become unavailable to + the unit's processes (however, those located in the file system will continue to be accessible). + + Note that the implementation of this setting might be impossible (for example if network namespaces are + not available), and the unit should be written in a way that does not solely rely on this setting for + security. + + When this option is used on a socket unit any sockets bound on behalf of this unit will be + bound within a private network namespace. This may be combined with + JoinsNamespaceOf= to listen on sockets inside of network namespaces of other + services. + + + + + + NetworkNamespacePath= + + Takes an absolute file system path refererring to a Linux network namespace + pseudo-file (i.e. a file like /proc/$PID/ns/net or a bind mount or symlink to + one). When set the invoked processes are added to the network namespace referenced by that path. The + path has to point to a valid namespace file at the moment the processes are forked off. If this + option is used PrivateNetwork= has no effect. If this option is used together with + JoinsNamespaceOf= then it only has an effect if this unit is started before any of + the listed units that have PrivateNetwork= or + NetworkNamespacePath= configured, as otherwise the network namespace of those + units is reused. + + When this option is used on a socket unit any sockets bound on behalf of this unit will be + bound within the specified network namespace. + + + + + + PrivateIPC= + + Takes a boolean argument. If true, sets up a new IPC namespace for the executed processes. + Each IPC namespace has its own set of System V IPC identifiers and its own POSIX message queue file system. + This is useful to avoid name clash of IPC identifiers. Defaults to false. It is possible to run two or + more units within the same private IPC namespace by using the JoinsNamespaceOf= directive, + see systemd.unit5 for + details. + + Note that IPC namespacing does not have an effect on + AF_UNIX sockets, which are the most common + form of IPC used on Linux. Instead, AF_UNIX + sockets in the file system are subject to mount namespacing, and + those in the abstract namespace are subject to network namespacing. + IPC namespacing only has an effect on SysV IPC (which is mostly + legacy) as well as POSIX message queues (for which + AF_UNIX/SOCK_SEQPACKET + sockets are typically a better replacement). IPC namespacing also + has no effect on POSIX shared memory (which is subject to mount + namespacing) either. See + ipc_namespaces7 for + the details. + + Note that the implementation of this setting might be impossible (for example if IPC namespaces are + not available), and the unit should be written in a way that does not solely rely on this setting for + security. + + + + + + IPCNamespacePath= + + Takes an absolute file system path refererring to a Linux IPC namespace + pseudo-file (i.e. a file like /proc/$PID/ns/ipc or a bind mount or symlink to + one). When set the invoked processes are added to the network namespace referenced by that path. The + path has to point to a valid namespace file at the moment the processes are forked off. If this + option is used PrivateIPC= has no effect. If this option is used together with + JoinsNamespaceOf= then it only has an effect if this unit is started before any of + the listed units that have PrivateIPC= or + IPCNamespacePath= configured, as otherwise the network namespace of those + units is reused. + + + + + + PrivateUsers= + + Takes a boolean argument. If true, sets up a new user namespace for the executed processes and + configures a minimal user and group mapping, that maps the root user and group as well as + the unit's own user and group to themselves and everything else to the nobody user and + group. This is useful to securely detach the user and group databases used by the unit from the rest of the + system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and + other resources owned by users/groups not equaling root or the unit's own will stay visible + from within the unit but appear owned by the nobody user and group. If this mode is enabled, + all unit processes are run without privileges in the host user namespace (regardless if the unit's own + user/group is root or not). Specifically this means that the process will have zero process + capabilities on the host's user namespace, but full capabilities within the service's user namespace. Settings + such as CapabilityBoundingSet= will affect only the latter, and there's no way to acquire + additional capabilities in the host's user namespace. Defaults to off. + + When this setting is set up by a per-user instance of the service manager, the mapping of the + root user and group to itself is omitted (unless the user manager is root). + Additionally, in the per-user instance manager case, the + user namespace will be set up before most other namespaces. This means that combining + PrivateUsers= with other namespaces will enable use of features not + normally supported by the per-user instances of the service manager. + + This setting is particularly useful in conjunction with + RootDirectory=/RootImage=, as the need to synchronize the user and group + databases in the root directory and on the host is reduced, as the only users and groups who need to be matched + are root, nobody and the unit's own user and group. + + Note that the implementation of this setting might be impossible (for example if user namespaces are not + available), and the unit should be written in a way that does not solely rely on this setting for + security. + + + + ProtectHostname= + + Takes a boolean argument. When set, sets up a new UTS namespace for the executed + processes. In addition, changing hostname or domainname is prevented. Defaults to off. + + Note that the implementation of this setting might be impossible (for example if UTS namespaces + are not available), and the unit should be written in a way that does not solely rely on this setting + for security. + + Note that when this option is enabled for a service hostname changes no longer propagate from + the system into the service, it is hence not suitable for services that need to take notice of system + hostname changes dynamically. + + If this setting is on, but the unit doesn't have the CAP_SYS_ADMIN + capability (e.g. services for which User= is set), + NoNewPrivileges=yes is implied. + + + + + + ProtectClock= + + Takes a boolean argument. If set, writes to the hardware clock or system clock will + be denied. Defaults to off. Enabling this option removes CAP_SYS_TIME and + CAP_WAKE_ALARM from the capability bounding set for this unit, installs a system + call filter to block calls that can set the clock, and DeviceAllow=char-rtc r is + implied. Note that the system calls are blocked altogether, the filter does not take into account + that some of the calls can be used to read the clock state with some parameter combinations. + Effectively, /dev/rtc0, /dev/rtc1, etc. are made read-only + to the service. See + systemd.resource-control5 + for the details about DeviceAllow=. If this setting is on, but the unit doesn't + have the CAP_SYS_ADMIN capability (e.g. services for which + User= is set), NoNewPrivileges=yes is implied. + + It is recommended to turn this on for most services that do not need modify the clock or check + its state. + + + + + + ProtectKernelTunables= + + Takes a boolean argument. If true, kernel variables accessible through + /proc/sys/, /sys/, /proc/sysrq-trigger, + /proc/latency_stats, /proc/acpi, + /proc/timer_stats, /proc/fs and /proc/irq will + be made read-only to all processes of the unit. Usually, tunable kernel variables should be initialized only at + boot-time, for example with the + sysctl.d5 mechanism. Few + services need to write to these at runtime; it is hence recommended to turn this on for most services. For this + setting the same restrictions regarding mount propagation and privileges apply as for + ReadOnlyPaths= and related calls, see above. Defaults to off. If this + setting is on, but the unit doesn't have the CAP_SYS_ADMIN capability + (e.g. services for which User= is set), + NoNewPrivileges=yes is implied. Note that this option does not prevent + indirect changes to kernel tunables effected by IPC calls to other processes. However, + InaccessiblePaths= may be used to make relevant IPC file system objects + inaccessible. If ProtectKernelTunables= is set, + MountAPIVFS=yes is implied. + + + + + + ProtectKernelModules= + + Takes a boolean argument. If true, explicit module loading will be denied. This allows + module load and unload operations to be turned off on modular kernels. It is recommended to turn this on for most services + that do not need special file systems or extra kernel modules to work. Defaults to off. Enabling this option + removes CAP_SYS_MODULE from the capability bounding set for the unit, and installs a + system call filter to block module system calls, also /usr/lib/modules is made + inaccessible. For this setting the same restrictions regarding mount propagation and privileges apply as for + ReadOnlyPaths= and related calls, see above. Note that limited automatic module loading due + to user configuration or kernel mapping tables might still happen as side effect of requested user operations, + both privileged and unprivileged. To disable module auto-load feature please see + sysctl.d5 + kernel.modules_disabled mechanism and + /proc/sys/kernel/modules_disabled documentation. If this setting is on, + but the unit doesn't have the CAP_SYS_ADMIN capability (e.g. services for + which User= is set), NoNewPrivileges=yes is implied. + + + + + + ProtectKernelLogs= + + Takes a boolean argument. If true, access to the kernel log ring buffer will be denied. It is + recommended to turn this on for most services that do not need to read from or write to the kernel log ring + buffer. Enabling this option removes CAP_SYSLOG from the capability bounding set for this + unit, and installs a system call filter to block the + syslog2 + system call (not to be confused with the libc API + syslog3 + for userspace logging). The kernel exposes its log buffer to userspace via /dev/kmsg and + /proc/kmsg. If enabled, these are made inaccessible to all the processes in the unit. + If this setting is on, but the unit doesn't have the CAP_SYS_ADMIN + capability (e.g. services for which User= is set), + NoNewPrivileges=yes is implied. + + + + + + ProtectControlGroups= + + Takes a boolean argument. If true, the Linux Control Groups (cgroups7) hierarchies + accessible through /sys/fs/cgroup/ will be made read-only to all processes of the + unit. Except for container managers no services should require write access to the control groups hierarchies; + it is hence recommended to turn this on for most services. For this setting the same restrictions regarding + mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see + above. Defaults to off. If ProtectControlGroups= is set, MountAPIVFS=yes + is implied. + + + + + + RestrictAddressFamilies= + + Restricts the set of socket address families accessible to the processes of this + unit. Takes none, or a space-separated list of address family names to + allow-list, such as AF_UNIX, AF_INET or + AF_INET6. When none is specified, then all address + families will be denied. When prefixed with ~ the listed address + families will be applied as deny list, otherwise as allow list. Note that this restricts access + to the + socket2 + system call only. Sockets passed into the process by other means (for example, by using socket + activation with socket units, see + systemd.socket5) + are unaffected. Also, sockets created with socketpair() (which creates connected + AF_UNIX sockets only) are unaffected. Note that this option has no effect on 32-bit x86, s390, s390x, + mips, mips-le, ppc, ppc-le, ppc64, ppc64-le and is ignored (but works correctly on other ABIs, + including x86-64). Note that on systems supporting multiple ABIs (such as x86/x86-64) it is + recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the + restrictions of this option. Specifically, it is recommended to combine this option with + SystemCallArchitectures=native or similar. If running in user mode, or in system + mode, but without the CAP_SYS_ADMIN capability (e.g. setting + User=), NoNewPrivileges=yes is implied. By default, no + restrictions apply, all address families are accessible to processes. If assigned the empty string, + any previous address family restriction changes are undone. This setting does not affect commands + prefixed with +. + + Use this option to limit exposure of processes to remote access, in particular via exotic and sensitive + network protocols, such as AF_PACKET. Note that in most cases, the local + AF_UNIX address family should be included in the configured allow list as it is frequently + used for local communication, including for + syslog2 + logging. + + + + RestrictFileSystems= + + Restricts the set of filesystems processes of this unit can open files on. Takes a space-separated + list of filesystem names. Any filesystem listed is made accessible to the unit's processes, access to filesystem + types not listed is prohibited (allow-listing). If the first character of the list is ~, the + effect is inverted: access to the filesystems listed is prohibited (deny-listing). If the empty string is assigned, + access to filesystems is not restricted. + + If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered will take + precedence and will dictate the default action (allow access to the filesystem or deny it). Then the next occurrences + of this option will add or delete the listed filesystems from the set of the restricted filesystems, depending on its + type and the default action. + + Example: if a unit has the following, + RestrictFileSystems=ext4 tmpfs +RestrictFileSystems=ext2 ext4 + then access to ext4, tmpfs, and ext2 is allowed + and access to other filesystems is denied. + + Example: if a unit has the following, + RestrictFileSystems=ext4 tmpfs +RestrictFileSystems=~ext4 + then only access tmpfs is allowed. + + Example: if a unit has the following, + RestrictFileSystems=~ext4 tmpfs +RestrictFileSystems=ext4 + then only access to tmpfs is denied. + + As the number of possible filesystems is large, predefined sets of filesystems are provided. A set + starts with @ character, followed by name of the set. + + + Currently predefined filesystem sets + + + + + + + Set + Description + + + + + @basic-api + Basic filesystem API. + + + @auxiliary-api + Auxiliary filesystem API. + + + @common-block + Common block device filesystems. + + + @historical-block + Historical block device filesystems. + + + @network + Well-known network filesystems. + + + @privileged-api + Privileged filesystem API. + + + @temporary + Temporary filesystems: tmpfs, ramfs. + + + @known + All known filesystems defined by the kernel. This list is defined statically in systemd based on a kernel version that was available when this systemd version was released. It will become progressively more out-of-date as the kernel is updated. + + + +
+ + Use + systemd-analyze1's + filesystems command to retrieve a list of filesystems defined on the local + system. + + Note that this setting might not be supported on some systems (for example if the LSM eBPF hook is + not enabled in the underlying kernel or if not using the unified control group hierarchy). In that case this setting + has no effect. + + + + RestrictNamespaces= + + Restricts access to Linux namespace functionality for the processes of this unit. For details + about Linux namespaces, see namespaces7. Either + takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), no + restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is + prohibited. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of + any combination of: cgroup, ipc, net, + mnt, pid, user and uts. Any + namespace type listed is made accessible to the unit's processes, access to namespace types not listed is + prohibited (allow-listing). By prepending the list with a single tilde character (~) the + effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are + permitted (deny-listing). If the empty string is assigned, the default namespace restrictions are applied, + which is equivalent to false. This option may appear more than once, in which case the namespace types are + merged by OR, or by AND if the lines are prefixed with + ~ (see examples below). Internally, this setting limits access to the + unshare2, + clone2 and + setns2 system calls, taking + the specified flags parameters into account. Note that — if this option is used — in addition to restricting + creation and switching of the specified types of namespaces (or all of them, if true) access to the + setns() system call with a zero flags parameter is prohibited. This setting is only + supported on x86, x86-64, mips, mips-le, mips64, mips64-le, mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390 + and s390x, and enforces no restrictions on other architectures. If running in user mode, or in system mode, but + without the CAP_SYS_ADMIN capability (e.g. setting User=), + NoNewPrivileges=yes is implied. + + Example: if a unit has the following, + RestrictNamespaces=cgroup ipc +RestrictNamespaces=cgroup net + then cgroup, ipc, and net are set. + If the second line is prefixed with ~, e.g., + RestrictNamespaces=cgroup ipc +RestrictNamespaces=~cgroup net + then, only ipc is set. + + + + LockPersonality= + + Takes a boolean argument. If set, locks down the personality2 system + call so that the kernel execution domain may not be changed from the default or the personality selected with + Personality= directive. This may be useful to improve security, because odd personality + emulations may be poorly tested and source of vulnerabilities. If running in user mode, or in system mode, but + without the CAP_SYS_ADMIN capability (e.g. setting User=), + NoNewPrivileges=yes is implied. + + + + MemoryDenyWriteExecute= + + Takes a boolean argument. If set, attempts to create memory mappings that are writable and + executable at the same time, or to change existing memory mappings to become executable, or mapping shared + memory segments as executable, are prohibited. Specifically, a system call filter is added that rejects + mmap2 system calls with both + PROT_EXEC and PROT_WRITE set, + mprotect2 or + pkey_mprotect2 system calls + with PROT_EXEC set and + shmat2 system calls with + SHM_EXEC set. Note that this option is incompatible with programs and libraries that + generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code + "trampoline" feature of various C compilers. This option improves service security, as it makes harder for + software exploits to change running code dynamically. However, the protection can be circumvented, if + the service can write to a filesystem, which is not mounted with noexec (such as + /dev/shm), or it can use memfd_create(). This can be + prevented by making such file systems inaccessible to the service + (e.g. InaccessiblePaths=/dev/shm) and installing further system call filters + (SystemCallFilter=~memfd_create). Note that this feature is fully available on + x86-64, and partially on x86. Specifically, the shmat() protection is not + available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is + recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the + restrictions of this option. Specifically, it is recommended to combine this option with + SystemCallArchitectures=native or similar. If running in user mode, or in system + mode, but without the CAP_SYS_ADMIN capability (e.g. setting + User=), NoNewPrivileges=yes is implied. + + + + RestrictRealtime= + + Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of + the unit are refused. This restricts access to realtime task scheduling policies such as + SCHED_FIFO, SCHED_RR or SCHED_DEADLINE. See + sched7 + for details about these scheduling policies. If running in user mode, or in system mode, but without the + CAP_SYS_ADMIN capability (e.g. setting User=), + NoNewPrivileges=yes is implied. Realtime scheduling policies may be used to monopolize CPU + time for longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service + situations on the system. It is hence recommended to restrict access to realtime scheduling to the few programs + that actually require them. Defaults to off. + + + + RestrictSUIDSGID= + + Takes a boolean argument. If set, any attempts to set the set-user-ID (SUID) or + set-group-ID (SGID) bits on files or directories will be denied (for details on these bits see + inode7). If + running in user mode, or in system mode, but without the CAP_SYS_ADMIN + capability (e.g. setting User=), NoNewPrivileges=yes is + implied. As the SUID/SGID bits are mechanisms to elevate privileges, and allow users to acquire the + identity of other users, it is recommended to restrict creation of SUID/SGID files to the few + programs that actually require them. Note that this restricts marking of any type of file system + object with these bits, including both regular files and directories (where the SGID is a different + meaning than for files, see documentation). This option is implied if DynamicUser= + is enabled. Defaults to off. + + + + RemoveIPC= + + Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and + group the processes of this unit are run as are removed when the unit is stopped. This setting only has an + effect if at least one of User=, Group= and + DynamicUser= are used. It has no effect on IPC objects owned by the root user. Specifically, + this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If + multiple units use the same user or group the IPC objects are removed when the last of these units is + stopped. This setting is implied if DynamicUser= is set. + + + + + + PrivateMounts= + + Takes a boolean parameter. If set, the processes of this unit will be run in their own private + file system (mount) namespace with all mount propagation from the processes towards the host's main file system + namespace turned off. This means any file system mount points established or removed by the unit's processes + will be private to them and not be visible to the host. However, file system mount points established or + removed on the host will be propagated to the unit's processes. See mount_namespaces7 for + details on file system namespaces. Defaults to off. + + When turned on, this executes three operations for each invoked process: a new + CLONE_NEWNS namespace is created, after which all existing mounts are remounted to + MS_SLAVE to disable propagation from the unit's processes to the host (but leaving + propagation in the opposite direction in effect). Finally, the mounts are remounted again to the propagation + mode configured with MountFlags=, see below. + + File system namespaces are set up individually for each process forked off by the service manager. Mounts + established in the namespace of the process created by ExecStartPre= will hence be cleaned + up automatically as soon as that process exits and will not be available to subsequent processes forked off for + ExecStart= (and similar applies to the various other commands configured for + units). Similarly, JoinsNamespaceOf= does not permit sharing kernel mount namespaces between + units, it only enables sharing of the /tmp/ and /var/tmp/ + directories. + + Other file system namespace unit settings — PrivateMounts=, + PrivateTmp=, PrivateDevices=, ProtectSystem=, + ProtectHome=, ReadOnlyPaths=, InaccessiblePaths=, + ReadWritePaths=, … — also enable file system namespacing in a fashion equivalent to this + option. Hence it is primarily useful to explicitly request this behaviour if none of the other settings are + used. + + + + + + MountFlags= + + Takes a mount propagation setting: , or + , which controls whether file system mount points in the file system namespaces set up + for this unit's processes will receive or propagate mounts and unmounts from other file system namespaces. See + mount2 + for details on mount propagation, and the three propagation flags in particular. + + This setting only controls the final propagation setting in effect on all mount + points of the file system namespace created for each process of this unit. Other file system namespacing unit + settings (see the discussion in PrivateMounts= above) will implicitly disable mount and + unmount propagation from the unit's processes towards the host by changing the propagation setting of all mount + points in the unit's file system namespace to first. Setting this option to + does not reestablish propagation in that case. + + If not set – but file system namespaces are enabled through another file system namespace unit setting – + mount propagation is used, but — as mentioned — as is applied + first, propagation from the unit's processes to the host is still turned off. + + It is not recommended to use mount propagation for units, as this means + temporary mounts (such as removable media) of the host will stay mounted and thus indefinitely busy in forked + off processes, as unmount propagation events won't be received by the file system namespace of the unit. + + Usually, it is best to leave this setting unmodified, and use higher level file system namespacing + options instead, in particular PrivateMounts=, see above. + + + + + + + + + System Call Filtering + + + + SystemCallFilter= + + Takes a space-separated list of system call names. If this setting is used, all + system calls executed by the unit processes except for the listed ones will result in immediate + process termination with the SIGSYS signal (allow-listing). (See + SystemCallErrorNumber= below for changing the default action). If the first + character of the list is ~, the effect is inverted: only the listed system calls + will result in immediate process termination (deny-listing). Deny-listed system calls and system call + groups may optionally be suffixed with a colon (:) and errno + error number (between 0 and 4095) or errno name such as EPERM, + EACCES or EUCLEAN (see errno3 for a + full list). This value will be returned when a deny-listed system call is triggered, instead of + terminating the processes immediately. Special setting kill can be used to + explicitly specify killing. This value takes precedence over the one given in + SystemCallErrorNumber=, see below. If running in user mode, or in system mode, + but without the CAP_SYS_ADMIN capability (e.g. setting + User=), NoNewPrivileges=yes is implied. This feature + makes use of the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is useful + for enforcing a minimal sandboxing environment. Note that the execve(), + exit(), exit_group(), getrlimit(), + rt_sigreturn(), sigreturn() system calls and the system calls + for querying time and sleeping are implicitly allow-listed and do not need to be listed + explicitly. This option may be specified more than once, in which case the filter masks are + merged. If the empty string is assigned, the filter is reset, all prior assignments will have no + effect. This does not affect commands prefixed with +. + + Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off + alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this + option. Specifically, it is recommended to combine this option with + SystemCallArchitectures=native or similar. + + Note that strict system call filters may impact execution and error handling code paths of the service + invocation. Specifically, access to the execve() system call is required for the execution + of the service binary — if it is blocked service invocation will necessarily fail. Also, if execution of the + service binary fails for some reason (for example: missing service executable), the error handling logic might + require access to an additional set of system calls in order to process and log this failure correctly. It + might be necessary to temporarily disable system call filters in order to simplify debugging of such + failures. + + If you specify both types of this option (i.e. allow-listing and deny-listing), the first + encountered will take precedence and will dictate the default action (termination or approval of a + system call). Then the next occurrences of this option will add or delete the listed system calls + from the set of the filtered system calls, depending of its type and the default action. (For + example, if you have started with an allow list rule for read() and + write(), and right after it add a deny list rule for write(), + then write() will be removed from the set.) + + As the number of possible system calls is large, predefined sets of system calls are provided. A set + starts with @ character, followed by name of the set. + + + Currently predefined system call sets + + + + + + + Set + Description + + + + + @aio + Asynchronous I/O (io_setup2, io_submit2, and related calls) + + + @basic-io + System calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing (read2, write2, and related calls) + + + @chown + Changing file ownership (chown2, fchownat2, and related calls) + + + @clock + System calls for changing the system clock (adjtimex2, settimeofday2, and related calls) + + + @cpu-emulation + System calls for CPU emulation functionality (vm862 and related calls) + + + @debug + Debugging, performance monitoring and tracing functionality (ptrace2, perf_event_open2 and related calls) + + + @file-system + File system operations: opening, creating files and directories for read and write, renaming and removing them, reading file properties, or creating hard and symbolic links + + + @io-event + Event loop system calls (poll2, select2, epoll7, eventfd2 and related calls) + + + @ipc + Pipes, SysV IPC, POSIX Message Queues and other IPC (mq_overview7, svipc7) + + + @keyring + Kernel keyring access (keyctl2 and related calls) + + + @memlock + Locking of memory in RAM (mlock2, mlockall2 and related calls) + + + @module + Loading and unloading of kernel modules (init_module2, delete_module2 and related calls) + + + @mount + Mounting and unmounting of file systems (mount2, chroot2, and related calls) + + + @network-io + Socket I/O (including local AF_UNIX): socket7, unix7 + + + @obsolete + Unusual, obsolete or unimplemented (create_module2, gtty2, …) + + + @privileged + All system calls which need super-user capabilities (capabilities7) + + + @process + Process control, execution, namespacing operations (clone2, kill2, namespaces7, …) + + + @raw-io + Raw I/O port access (ioperm2, iopl2, pciconfig_read(), …) + + + @reboot + System calls for rebooting and reboot preparation (reboot2, kexec(), …) + + + @resources + System calls for changing resource limits, memory and scheduling parameters (setrlimit2, setpriority2, …) + + + @setuid + System calls for changing user ID and group ID credentials, (setuid2, setgid2, setresuid2, …) + + + @signal + System calls for manipulating and handling process signals (signal2, sigprocmask2, …) + + + @swap + System calls for enabling/disabling swap devices (swapon2, swapoff2) + + + @sync + Synchronizing files and memory to disk (fsync2, msync2, and related calls) + + + @system-service + A reasonable set of system calls used by common system services, excluding any special purpose calls. This is the recommended starting point for allow-listing system calls for system services, as it contains what is typically needed by system services, but excludes overly specific interfaces. For example, the following APIs are excluded: @clock, @mount, @swap, @reboot. + + + @timer + System calls for scheduling operations by time (alarm2, timer_create2, …) + + + @known + All system calls defined by the kernel. This list is defined statically in systemd based on a kernel version that was available when this systemd version was released. It will become progressively more out-of-date as the kernel is updated. + + + +
+ + Note, that as new system calls are added to the kernel, additional system calls might be added to the groups + above. Contents of the sets may also change between systemd versions. In addition, the list of system calls + depends on the kernel version and architecture for which systemd was compiled. Use + systemd-analyze syscall-filter to list the actual list of system calls in each + filter. + + Generally, allow-listing system calls (rather than deny-listing) is the safer mode of + operation. It is recommended to enforce system call allow lists for all long-running system + services. Specifically, the following lines are a relatively safe basic choice for the majority of + system services: + + [Service] +SystemCallFilter=@system-service +SystemCallErrorNumber=EPERM + + Note that various kernel system calls are defined redundantly: there are multiple system calls + for executing the same operation. For example, the pidfd_send_signal() system + call may be used to execute operations similar to what can be done with the older + kill() system call, hence blocking the latter without the former only provides + weak protection. Since new system calls are added regularly to the kernel as development progresses, + keeping system call deny lists comprehensive requires constant work. It is thus recommended to use + allow-listing instead, which offers the benefit that new system calls are by default implicitly + blocked until the allow list is updated. + + Also note that a number of system calls are required to be accessible for the dynamic linker to + work. The dynamic linker is required for running most regular programs (specifically: all dynamic ELF + binaries, which is how most distributions build packaged programs). This means that blocking these + system calls (which include open(), openat() or + mmap()) will make most programs typically shipped with generic distributions + unusable. + + It is recommended to combine the file system namespacing related options with + SystemCallFilter=~@mount, in order to prohibit the unit's processes to undo the + mappings. Specifically these are the options PrivateTmp=, + PrivateDevices=, ProtectSystem=, ProtectHome=, + ProtectKernelTunables=, ProtectControlGroups=, + ProtectKernelLogs=, ProtectClock=, ReadOnlyPaths=, + InaccessiblePaths= and ReadWritePaths=. + + + + SystemCallErrorNumber= + + Takes an errno error number (between 1 and 4095) or errno name + such as EPERM, EACCES or EUCLEAN, to + return when the system call filter configured with SystemCallFilter= is triggered, + instead of terminating the process immediately. See errno3 for a + full list of error codes. When this setting is not used, or when the empty string or the special + setting kill is assigned, the process will be terminated immediately when the + filter is triggered. + + + + SystemCallArchitectures= + + Takes a space-separated list of architecture identifiers to include in the system call + filter. The known architecture identifiers are the same as for ConditionArchitecture= + described in systemd.unit5, + as well as x32, mips64-n32, mips64-le-n32, and + the special identifier native. The special identifier native + implicitly maps to the native architecture of the system (or more precisely: to the architecture the system + manager is compiled for). If running in user mode, or in system mode, but without the + CAP_SYS_ADMIN capability (e.g. setting User=), + NoNewPrivileges=yes is implied. By default, this option is set to the empty list, i.e. no + filtering is applied. + + If this setting is used, processes of this unit will only be permitted to call native system calls, and + system calls of the specified architectures. For the purposes of this option, the x32 architecture is treated + as including x86-64 system calls. However, this setting still fulfills its purpose, as explained below, on + x32. + + System call filtering is not equally effective on all architectures. For example, on x86 + filtering of network socket-related calls is not possible, due to ABI limitations — a limitation that x86-64 + does not have, however. On systems supporting multiple ABIs at the same time — such as x86/x86-64 — it is hence + recommended to limit the set of permitted system call architectures so that secondary ABIs may not be used to + circumvent the restrictions applied to the native ABI of the system. In particular, setting + SystemCallArchitectures=native is a good choice for disabling non-native ABIs. + + System call architectures may also be restricted system-wide via the + SystemCallArchitectures= option in the global configuration. See + systemd-system.conf5 for + details. + + + + SystemCallLog= + + Takes a space-separated list of system call names. If this setting is used, all + system calls executed by the unit processes for the listed ones will be logged. If the first + character of the list is ~, the effect is inverted: all system calls except the + listed system calls will be logged. If running in user mode, or in system mode, but without the + CAP_SYS_ADMIN capability (e.g. setting User=), + NoNewPrivileges=yes is implied. This feature makes use of the Secure Computing + Mode 2 interfaces of the kernel ('seccomp filtering') and is useful for auditing or setting up a + minimal sandboxing environment. This option may be specified more than once, in which case the filter + masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will + have no effect. This does not affect commands prefixed with +. + + + + + + + Environment + + + + + Environment= + + Sets environment variables for executed processes. Each line is unquoted using the + rules described in "Quoting" section in + systemd.syntax7 + and becomes a list of variable assignments. If you need to assign a value containing spaces or the + equals sign to a variable, put quotes around the whole assignment. Variable expansion is not + performed inside the strings and the $ character has no special meaning. Specifier + expansion is performed, see the "Specifiers" section in + systemd.unit5. + + + This option may be specified more than once, in which case all listed variables will be set. If + the same variable is listed twice, the later setting will override the earlier setting. If the empty + string is assigned to this option, the list of environment variables is reset, all prior assignments + have no effect. + + The names of the variables can contain ASCII letters, digits, and the underscore character. + Variable names cannot be empty or start with a digit. In variable values, most characters are + allowed, but non-printable characters are currently rejected. + + Example: + Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6" + gives three variables VAR1, + VAR2, VAR3 + with the values word1 word2, + word3, $word 5 6. + + + See environ7 for + details about environment variables. + + Note that environment variables are not suitable for passing secrets (such as passwords, key + material, …) to service processes. Environment variables set for a unit are exposed to unprivileged + clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover, + environment variables are propagated down the process tree, including across security boundaries + (such as setuid/setgid executables), and hence might leak to processes that should not have access to + the secret data. Use LoadCredential=, LoadCredentialEncrypted= + or SetCredentialEncrypted= (see below) to pass data to unit processes + securely. + + + + EnvironmentFile= + + Similar to Environment=, but reads the environment variables from + a text file. The text file should contain newline-separated variable assignments. Empty lines, lines + without an = separator, or lines starting with ; or + # will be ignored, which may be used for commenting. The file must be UTF-8 + encoded. Valid characters are unicode scalar values other than + noncharacters, U+0000 NUL, and + U+FEFF byte order mark. + Control codes other than NUL are allowed. + + In the file, an unquoted value after the = is parsed with the same backslash-escape + rules as unquoted + text in a POSIX shell, but unlike in a shell, interior whitespace is preserved and quotes after the + first non-whitespace character are preserved. Leading and trailing whitespace (space, tab, carriage return) is + discarded, but interior whitespace within the line is preserved verbatim. A line ending with a backslash will be + continued to the following one, with the newline itself discarded. A backslash + \ followed by any character other than newline will preserve the following character, so that + \\ will become the value \. + + In the file, a '-quoted value after the = can span multiple lines + and contain any character verbatim other than single quote, like single-quoted + text in a POSIX shell. No backslash-escape sequences are recognized. Leading and trailing whitespace + outside of the single quotes is discarded. + + In the file, a "-quoted value after the = can span multiple lines, + and the same escape sequences are recognized as in double-quoted + text of a POSIX shell. Backslash (\) followed by any of "\`$ will + preserve that character. A backslash followed by newline is a line continuation, and the newline itself is + discarded. A backslash followed by any other character is ignored; both the backslash and the following + character are preserved verbatim. Leading and trailing whitespace outside of the double quotes is + discarded. + + The argument passed should be an absolute filename or wildcard expression, optionally prefixed with + -, which indicates that if the file does not exist, it will not be read and no error or + warning message is logged. This option may be specified more than once in which case all specified files are + read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments + have no effect. + + The files listed with this directive will be read shortly before the process is executed (more + specifically, after all processes from a previous unit state terminated. This means you can generate these + files in one unit state, and read it with this option in the next. The files are read from the file + system of the service manager, before any file system changes like bind mounts take place). + + Settings from these files override settings made with Environment=. If the same + variable is set twice from these files, the files will be read in the order they are specified and the later + setting will override the earlier setting. + + + + PassEnvironment= + + Pass environment variables set for the system service manager to executed processes. Takes a + space-separated list of variable names. This option may be specified more than once, in which case all listed + variables will be passed. If the empty string is assigned to this option, the list of environment variables to + pass is reset, all prior assignments have no effect. Variables specified that are not set for the system + manager will not be passed and will be silently ignored. Note that this option is only relevant for the system + service manager, as system services by default do not automatically inherit any environment variables set for + the service manager itself. However, in case of the user service manager all environment variables are passed + to the executed processes anyway, hence this option is without effect for the user service manager. + + Variables set for invoked processes due to this setting are subject to being overridden by those + configured with Environment= or EnvironmentFile=. + + Example: + PassEnvironment=VAR1 VAR2 VAR3 + passes three variables VAR1, + VAR2, VAR3 + with the values set for those variables in PID1. + + + See environ7 for details + about environment variables. + + + + UnsetEnvironment= + + Explicitly unset environment variable assignments that would normally be passed from the + service manager to invoked processes of this unit. Takes a space-separated list of variable names or variable + assignments. This option may be specified more than once, in which case all listed variables/assignments will + be unset. If the empty string is assigned to this option, the list of environment variables/assignments to + unset is reset. If a variable assignment is specified (that is: a variable name, followed by + =, followed by its value), then any environment variable matching this precise assignment is + removed. If a variable name is specified (that is a variable name without any following = or + value), then any assignment matching the variable name, regardless of its value is removed. Note that the + effect of UnsetEnvironment= is applied as final step when the environment list passed to + executed processes is compiled. That means it may undo assignments from any configuration source, including + assignments made through Environment= or EnvironmentFile=, inherited from + the system manager's global set of environment variables, inherited via PassEnvironment=, + set by the service manager itself (such as $NOTIFY_SOCKET and such), or set by a PAM module + (in case PAMName= is used). + + See "Environment Variables in Spawned Processes" below for a description of how those + settings combine to form the inherited environment. See environ7 for general + information about environment variables. + + + + + + + Logging and Standard Input/Output + + + + + StandardInput= + + Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one + of , , , , + , , or + . + + If is selected, standard input will be connected to /dev/null, + i.e. all read attempts by the process will result in immediate EOF. + + If is selected, standard input is connected to a TTY (as configured by + TTYPath=, see below) and the executed process becomes the controlling process of the + terminal. If the terminal is already being controlled by another process, the executed process waits until the + current controlling process releases the terminal. + + is similar to , but the executed process is forcefully and + immediately made the controlling process of the terminal, potentially removing previous controlling processes + from the terminal. + + is similar to , but if the terminal already has a + controlling process start-up of the executed process fails. + + The option may be used to configure arbitrary textual or binary data to pass via + standard input to the executed process. The data to pass is configured via + StandardInputText=/StandardInputData= (see below). Note that the actual + file descriptor type passed (memory file, regular file, UNIX pipe, …) might depend on the kernel and available + privileges. In any case, the file descriptor is read-only, and when read returns the specified data followed by + EOF. + + The option may be used to connect a specific file + system object to standard input. An absolute path following the : character is expected, + which may refer to a regular file, a FIFO or special file. If an AF_UNIX socket in the + file system is specified, a stream socket is connected to it. The latter is useful for connecting standard + input of processes to arbitrary system services. + + The option is valid in socket-activated services only, and requires the relevant + socket unit file (see + systemd.socket5 for details) + to have Accept=yes set, or to specify a single socket only. If this option is set, standard + input will be connected to the socket the service was activated from, which is primarily useful for + compatibility with daemons designed for use with the traditional inetd8 socket activation + daemon ($LISTEN_FDS (and related) environment variables are not passed when + value is configured). + + The option connects standard input to a specific, + named file descriptor provided by a socket unit. The name may be specified as part of this option, following a + : character (e.g. fd:foobar). If no name is specified, the name + stdin is implied (i.e. fd is equivalent to fd:stdin). + At least one socket unit defining the specified name must be provided via the Sockets= + option, and the file descriptor name may differ from the name of its containing socket unit. If multiple + matches are found, the first one will be used. See FileDescriptorName= in + systemd.socket5 for more + details about named file descriptors and their ordering. + + This setting defaults to , unless + StandardInputText=/StandardInputData= are set, in which case it + defaults to . + + + + StandardOutput= + + Controls where file descriptor 1 (stdout) of the executed processes is connected + to. Takes one of , , , + , , , + , , + , , + or . + + duplicates the file descriptor of standard input for standard output. + + connects standard output to /dev/null, i.e. everything written + to it will be lost. + + connects standard output to a tty (as configured via TTYPath=, + see below). If the TTY is used for output only, the executed process will not become the controlling process of + the terminal, and will not fail or wait for other processes to release the terminal. + + connects standard output with the journal, which is accessible via + journalctl1. Note + that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the + specific option listed below is hence a superset of this one. (Also note that any external, + additional syslog daemons receive their log data from the journal, too, hence this is the option to + use when logging shall be processed with such a daemon.) + + connects standard output with the kernel log buffer which is accessible via + dmesg1, + in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which + case this option is no different from . + + and work in a similar way as the + two options above but copy the output to the system console as well. + + The option may be used to connect a specific file + system object to standard output. The semantics are similar to the same option of + StandardInput=, see above. If path refers to a regular file + on the filesystem, it is opened (created if it doesn't exist yet) for writing at the beginning of the file, + but without truncating it. + If standard input and output are directed to the same file path, it is opened only once — for reading as well + as writing — and duplicated. This is particularly useful when the specified path refers to an + AF_UNIX socket in the file system, as in that case only a + single stream connection is created for both input and output. + + is similar to + above, but it opens the file in append mode. + + + is similar to + above, but it truncates the file when opening + it. For units with multiple command lines, e.g. Type=oneshot services with + multiple ExecStart=, or services with ExecCondition=, + ExecStartPre= or ExecStartPost=, the output file is reopened + and therefore re-truncated for each command line. If the output file is truncated while another + process still has the file open, e.g. by an ExecReload= running concurrently with + an ExecStart=, and the other process continues writing to the file without + adjusting its offset, then the space between the file pointers of the two processes may be filled + with NUL bytes, producing a sparse file. Thus, + is typically only useful for units where + only one process runs at a time, such as services with a single ExecStart= and no + ExecStartPost=, ExecReload=, ExecStop= or + similar. + + connects standard output to a socket acquired via socket activation. The + semantics are similar to the same option of StandardInput=, see above. + + The option connects standard output to a + specific, named file descriptor provided by a socket unit. A name may be specified as part of this + option, following a : character + (e.g. fd:foobar). If no name is specified, the name + stdout is implied (i.e. fd is equivalent to + fd:stdout). At least one socket unit defining the specified name must be provided + via the Sockets= option, and the file descriptor name may differ from the name of + its containing socket unit. If multiple matches are found, the first one will be used. See + FileDescriptorName= in + systemd.socket5 + for more details about named descriptors and their ordering. + + If the standard output (or error output, see below) of a unit is connected to the journal or + the kernel log buffer, the unit will implicitly gain a dependency of type After= + on systemd-journald.socket (also see the "Implicit Dependencies" section + above). Also note that in this case stdout (or stderr, see below) will be an + AF_UNIX stream socket, and not a pipe or FIFO that can be re-opened. This means + when executing shell scripts the construct echo "hello" > /dev/stderr for + writing text to stderr will not work. To mitigate this use the construct echo "hello" + >&2 instead, which is mostly equivalent and avoids this pitfall. + + If StandardInput= is set to one of , , + , , or , this + setting defaults to . + + In other cases, this setting defaults to the value set with DefaultStandardOutput= in + systemd-system.conf5, which + defaults to . Note that setting this parameter might result in additional dependencies + to be added to the unit (see above). + + + + StandardError= + + Controls where file descriptor 2 (stderr) of the executed processes is connected to. The + available options are identical to those of StandardOutput=, with some exceptions: if set to + the file descriptor used for standard output is duplicated for standard error, while + will use a default file descriptor name of + stderr. + + This setting defaults to the value set with DefaultStandardError= in + systemd-system.conf5, which + defaults to . Note that setting this parameter might result in additional dependencies + to be added to the unit (see above). + + + + StandardInputText= + StandardInputData= + + Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to + the executed processes. These settings have no effect unless StandardInput= is set + to (which is the default if StandardInput= is not set + otherwise, but StandardInputText=/StandardInputData= is). Use + this option to embed process input data directly in the unit file. + + StandardInputText= accepts arbitrary textual data. C-style escapes for special + characters as well as the usual %-specifiers are resolved. Each time this setting is used + the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use + appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured + with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an + empty line, add an additional \n to the end or beginning of a line). + + StandardInputData= accepts arbitrary binary data, encoded in Base64. No escape sequences or specifiers are + resolved. Any whitespace in the encoded version is ignored during decoding. + + Note that StandardInputText= and StandardInputData= operate on the + same data buffer, and may be mixed in order to configure both binary and textual data for the same input + stream. The textual or binary data is joined strictly in the order the settings appear in the unit + file. Assigning an empty string to either will reset the data buffer. + + Please keep in mind that in order to maintain readability long unit file settings may be split into + multiple lines, by suffixing each line (except for the last) with a \ character (see + systemd.unit5 for + details). This is particularly useful for large data configured with these two options. Example: + + … +StandardInput=data +StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \ + IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \ + dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \ + J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \ + dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \ + ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \ + eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK +… + + + + LogLevelMax= + + Configures filtering by log level of log messages generated by this unit. Takes a + syslog log level, one of (lowest log level, only highest priority + messages), , , , , + , , (highest log level, also lowest priority + messages). See syslog3 for + details. By default no filtering is applied (i.e. the default maximum log level is ). Use + this option to configure the logging system to drop log messages of a specific service above the specified + level. For example, set LogLevelMax= in order to turn off debug logging + of a particularly chatty unit. Note that the configured level is applied to any log messages written by any + of the processes belonging to this unit, as well as any log messages written by the system manager process + (PID 1) in reference to this unit, sent via any supported logging protocol. The filtering is applied + early in the logging pipeline, before any kind of further processing is done. Moreover, messages which pass + through this filter successfully might still be dropped by filters applied at a later stage in the logging + subsystem. For example, MaxLevelStore= configured in + journald.conf5 might + prohibit messages of higher log levels to be stored on disk, even though the per-unit + LogLevelMax= permitted it to be processed. + + + + LogExtraFields= + + Configures additional log metadata fields to include in all log records generated by + processes associated with this unit. This setting takes one or more journal field assignments in the + format FIELD=VALUE separated by whitespace. See + systemd.journal-fields7 + for details on the journal field concept. Even though the underlying journal implementation permits + binary field values, this setting accepts only valid UTF-8 values. To include space characters in a + journal field value, enclose the assignment in double quotes ("). + The usual specifiers are expanded in all assignments (see below). Note that this setting is not only + useful for attaching additional metadata to log records of a unit, but given that all fields and + values are indexed may also be used to implement cross-unit log record matching. Assign an empty + string to reset the list. + + + + LogRateLimitIntervalSec= + LogRateLimitBurst= + + Configures the rate limiting that is applied to messages generated by this unit. If, in the + time interval defined by LogRateLimitIntervalSec=, more messages than specified in + LogRateLimitBurst= are logged by a service, all further messages within the interval are + dropped until the interval is over. A message about the number of dropped messages is generated. The time + specification for LogRateLimitIntervalSec= may be specified in the following units: "s", + "min", "h", "ms", "us" (see + systemd.time7 for details). + The default settings are set by RateLimitIntervalSec= and RateLimitBurst= + configured in journald.conf5. + + + + + LogNamespace= + + Run the unit's processes in the specified journal namespace. Expects a short + user-defined string identifying the namespace. If not used the processes of the service are run in + the default journal namespace, i.e. their log stream is collected and processed by + systemd-journald.service. If this option is used any log data generated by + processes of this unit (regardless if via the syslog(), journal native logging + or stdout/stderr logging) is collected and processed by an instance of the + systemd-journald@.service template unit, which manages the specified + namespace. The log data is stored in a data store independent from the default log namespace's data + store. See + systemd-journald.service8 + for details about journal namespaces. + + Internally, journal namespaces are implemented through Linux mount namespacing and + over-mounting the directory that contains the relevant AF_UNIX sockets used for + logging in the unit's mount namespace. Since mount namespaces are used this setting disconnects + propagation of mounts from the unit's processes to the host, similarly to how + ReadOnlyPaths= and similar settings describe above work. Journal namespaces may hence + not be used for services that need to establish mount points on the host. + + When this option is used the unit will automatically gain ordering and requirement dependencies + on the two socket units associated with the systemd-journald@.service instance + so that they are automatically established prior to the unit starting up. Note that when this option + is used log output of this service does not appear in the regular + journalctl1 + output, unless the option is used. + + + + + + SyslogIdentifier= + + Sets the process name ("syslog tag") to prefix log lines sent to + the logging system or the kernel log buffer with. If not set, defaults to the process name of the + executed process. This option is only useful when StandardOutput= or + StandardError= are set to or (or to + the same settings in combination with ) and only applies to log messages + written to stdout or stderr. + + + + SyslogFacility= + + Sets the syslog facility identifier to use when logging. One of + , , , , + , , , , + , , , , + , , , , + , , or + . See syslog3 for + details. This option is only useful when StandardOutput= or + StandardError= are set to or (or to + the same settings in combination with ), and only applies to log messages + written to stdout or stderr. Defaults to . + + + + SyslogLevel= + + The default syslog log level to use when logging to the logging system or + the kernel log buffer. One of , , , + , , , , + . See syslog3 for + details. This option is only useful when StandardOutput= or + StandardError= are set to or + (or to the same settings in combination with ), and only applies + to log messages written to stdout or stderr. Note that individual lines output by executed processes may be + prefixed with a different log level which can be used to override the default log level specified here. The + interpretation of these prefixes may be disabled with SyslogLevelPrefix=, see below. For + details, see sd-daemon3. + Defaults to . + + + + SyslogLevelPrefix= + + Takes a boolean argument. If true and StandardOutput= or + StandardError= are set to or (or to + the same settings in combination with ), log lines written by the executed + process that are prefixed with a log level will be processed with this log level set but the prefix + removed. If set to false, the interpretation of these prefixes is disabled and the logged lines are + passed on as-is. This only applies to log messages written to stdout or stderr. For details about + this prefixing see + sd-daemon3. + Defaults to true. + + + + TTYPath= + + Sets the terminal device node to use if standard input, output, or error are connected to a TTY + (see above). Defaults to /dev/console. + + + + TTYReset= + + Reset the terminal device specified with TTYPath= before and after + execution. Defaults to no. + + + + TTYVHangup= + + Disconnect all clients which have opened the terminal device specified with + TTYPath= before and after execution. Defaults to no. + + + + TTYRows= + TTYColumns= + + Configure the size of the TTY specified with TTYPath=. If unset or + set to the empty string, the kernel default is used. + + + + TTYVTDisallocate= + + If the terminal device specified with TTYPath= is a virtual console + terminal, try to deallocate the TTY before and after execution. This ensures that the screen and scrollback + buffer is cleared. Defaults to no. + + + + + + Credentials + + + + + LoadCredential=ID:PATH + LoadCredentialEncrypted=ID:PATH + + Pass a credential to the unit. Credentials are limited-size binary or textual objects + that may be passed to unit processes. They are primarily used for passing cryptographic keys (both + public and private) or certificates, user account information or identity information from host to + services. The data is accessible from the unit's processes via the file system, at a read-only + location that (if possible and permitted) is backed by non-swappable memory. The data is only + accessible to the user associated with the unit, via the + User=/DynamicUser= settings (as well as the superuser). When + available, the location of credentials is exported as the $CREDENTIALS_DIRECTORY + environment variable to the unit's processes. + + The LoadCredential= setting takes a textual ID to use as name for a + credential plus a file system path, separated by a colon. The ID must be a short ASCII string + suitable as filename in the filesystem, and may be chosen freely by the user. If the specified path + is absolute it is opened as regular file and the credential data is read from it. If the absolute + path refers to an AF_UNIX stream socket in the file system a connection is made + to it (only once at unit start-up) and the credential data read from the connection, providing an + easy IPC integration point for dynamically transferring credentials from other services. + + If the specified path is not absolute and itself qualifies as valid credential identifier it is + attempted to find a credential that the service manager itself received under the specified name — + which may be used to propagate credentials from an invoking environment (e.g. a container manager + that invoked the service manager) into a service. If no matching system credential is found, the + directories /etc/credstore/, /run/credstore/ and + /usr/lib/credstore/ are searched for files under the credential's name — which + hence are recommended locations for credential data on disk. If + LoadCredentialEncrypted= is used /run/credstore.encrypted/, + /etc/credstore.encrypted/, and + /usr/lib/credstore.encrypted/ are searched as well. + + If the file system path is omitted it is chosen identical to the credential name, i.e. this is + a terse way to declare credentials to inherit from the service manager into a service. This option + may be used multiple times, each time defining an additional credential to pass to the unit. + + If an absolute path referring to a directory is specified, every file in that directory + (recursively) will be loaded as a separate credential. The ID for each credential will be the + provided ID suffixed with _$FILENAME (e.g., Key_file1). When + loading from a directory, symlinks will be ignored. + + The contents of the file/socket may be arbitrary binary or textual data, including newline + characters and NUL bytes. + + The LoadCredentialEncrypted= setting is identical to + LoadCredential=, except that the credential data is decrypted and authenticated + before being passed on to the executed processes. Specifically, the referenced path should refer to a + file or socket with an encrypted credential, as implemented by + systemd-creds1. This + credential is loaded, decrypted, authenticated and then passed to the application in plaintext form, + in the same way a regular credential specified via LoadCredential= would be. A + credential configured this way may be symmetrically encrypted/authenticated with a secret key derived + from the system's TPM2 security chip, or with a secret key stored in + /var/lib/systemd/credentials.secret, or with both. Using encrypted and + authenticated credentials improves security as credentials are not stored in plaintext and only + authenticated and decrypted into plaintext the moment a service requiring them is started. Moreover, + credentials may be bound to the local hardware and installations, so that they cannot easily be + analyzed offline, or be generated externally. When DevicePolicy= is set to + closed or strict, or set to auto and + DeviceAllow= is set, or PrivateDevices= is set, then this + setting adds /dev/tpmrm0 with rw mode to + DeviceAllow=. See + systemd.resource-control5 + for the details about DevicePolicy= or DeviceAllow=. + + The credential files/IPC sockets must be accessible to the service manager, but don't have to + be directly accessible to the unit's processes: the credential data is read and copied into separate, + read-only copies for the unit that are accessible to appropriately privileged processes. This is + particularly useful in combination with DynamicUser= as this way privileged data + can be made available to processes running under a dynamic UID (i.e. not a previously known one) + without having to open up access to all users. + + In order to reference the path a credential may be read from within a + ExecStart= command line use ${CREDENTIALS_DIRECTORY}/mycred, + e.g. ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred. In order to reference the path + a credential may be read from within a Environment= line use + %d/mycred, e.g. Environment=MYCREDPATH=%d/mycred. For system + services the path may also be referenced as + /run/credentials/UNITNAME in cases where no + interpolation is possible, e.g. configuration files of software that does not yet support credentials + natively. $CREDENTIALS_DIRECTORY is considered the primary interface to look for + credentials, though, since it also works for user services. + + Currently, an accumulated credential size limit of 1 MB per unit is enforced. + + The service manager itself may receive system credentials that can be propagated to services + from a hosting container manager or VM hypervisor. See the Container Interface documentation for details + about the former. For the latter, pass DMI/SMBIOS OEM string table entries (field type + 11) with a prefix of io.systemd.credential: or + io.systemd.credential.binary:. In both cases a key/value pair separated by + = is expected, in the latter case the right-hand side is Base64 decoded when + parsed (thus permitting binary data to be passed in). Example qemu switch: -smbios + type=11,value=io.systemd.credential:xx=yy, or -smbios + type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=. Alternatively, + use the qemu fw_cfg node + opt/io.systemd.credentials/. Example qemu switch: -fw_cfg + name=opt/io.systemd.credentials/mycred,string=supersecret. They may also be specified on + the kernel command line using the systemd.set_credential= switch (see + systemd1) and from + the UEFI firmware environment via + systemd-stub7. + + If referencing an AF_UNIX stream socket to connect to, the connection will + originate from an abstract namespace socket, that includes information about the unit and the + credential ID in its socket name. Use getpeername2 + to query this information. The returned socket name is formatted as NUL + RANDOM /unit/ UNIT + / ID, i.e. a NUL byte (as required + for abstract namespace socket names), followed by a random string (consisting of alphadecimal + characters), followed by the literal string /unit/, followed by the requesting + unit name, followed by the literal character /, followed by the textual credential + ID requested. Example: \0adf9d86b6eda275e/unit/foobar.service/credx in case the + credential credx is requested for a unit foobar.service. This + functionality is useful for using a single listening socket to serve credentials to multiple + consumers. + + For further information see System and Service + Credentials documentation. + + + + SetCredential=ID:VALUE + SetCredentialEncrypted=ID:VALUE + + The SetCredential= setting is similar to + LoadCredential= but accepts a literal value to use as data for the credential, + instead of a file system path to read the data from. Do not use this option for data that is supposed + to be secret, as it is accessible to unprivileged processes via IPC. It's only safe to use this for + user IDs, public key material and similar non-sensitive data. For everything else use + LoadCredential=. In order to embed binary data into the credential data use + C-style escaping (i.e. \n to embed a newline, or \x00 to embed + a NUL byte). + + The SetCredentialEncrypted= setting is identical to + SetCredential= but expects an encrypted credential in literal form as value. This + allows embedding confidential credentials securely directly in unit files. Use + systemd-creds1' + switch to generate suitable SetCredentialEncrypted= lines + directly from plaintext credentials. For further details see + LoadCredentialEncrypted= above. + + If a credential of the same ID is listed in both LoadCredential= and + SetCredential=, the latter will act as default if the former cannot be + retrieved. In this case not being able to retrieve the credential from the path specified in + LoadCredential= is not considered fatal. + + + + + + System V Compatibility + + + + UtmpIdentifier= + + Takes a four character identifier string for an utmp5 and wtmp entry + for this service. This should only be set for services such as getty implementations (such + as agetty8) where utmp/wtmp + entries must be created and cleared before and after execution, or for services that shall be executed as if + they were run by a getty process (see below). If the configured string is longer than four + characters, it is truncated and the terminal four characters are used. This setting interprets %I style string + replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this + service. + + + + UtmpMode= + + Takes one of init, login or user. If + UtmpIdentifier= is set, controls which type of utmp5/wtmp entries + for this service are generated. This setting has no effect unless UtmpIdentifier= is set + too. If init is set, only an INIT_PROCESS entry is generated and the + invoked process must implement a getty-compatible utmp/wtmp logic. If + login is set, first an INIT_PROCESS entry, followed by a + LOGIN_PROCESS entry is generated. In this case, the invoked process must implement a + login1-compatible + utmp/wtmp logic. If user is set, first an INIT_PROCESS entry, then a + LOGIN_PROCESS entry and finally a USER_PROCESS entry is + generated. In this case, the invoked process may be any process that is suitable to be run as session + leader. Defaults to init. + + + + + + + Environment Variables in Spawned Processes + + Processes started by the service manager are executed with an environment variable block assembled from + multiple sources. Processes started by the system service manager generally do not inherit environment variables + set for the service manager itself (but this may be altered via PassEnvironment=), but processes + started by the user service manager instances generally do inherit all environment variables set for the service + manager itself. + + For each invoked process the list of environment variables set is compiled from the following sources: + + + Variables globally configured for the service manager, using the + DefaultEnvironment= setting in + systemd-system.conf5, + the kernel command line option systemd.setenv= understood by + systemd1, or via + systemctl1 + set-environment verb. + + Variables defined by the service manager itself (see the list below). + + Variables set in the service manager's own environment variable block (subject to + PassEnvironment= for the system service manager). + + Variables set via Environment= in the unit file. + + Variables read from files specified via EnvironmentFile= in the unit + file. + + Variables set by any PAM modules in case PAMName= is in effect, + cf. pam_env8. + + + + If the same environment variable is set by multiple of these sources, the later source — according + to the order of the list above — wins. Note that as the final step all variables listed in + UnsetEnvironment= are removed from the compiled environment variable list, immediately + before it is passed to the executed process. + + The general philosophy is to expose a small curated list of environment variables to processes. + Services started by the system manager (PID 1) will be started, without additional service-specific + configuration, with just a few environment variables. The user manager inherits environment variables as + any other system service, but in addition may receive additional environment variables from PAM, and, + typically, additional imported variables when the user starts a graphical session. It is recommended to + keep the environment blocks in both the system and user managers lean. Importing all variables + inherited by the graphical session or by one of the user shells is strongly discouraged. + + Hint: systemd-run -P env and systemd-run --user -P env print + the effective system and user service environment blocks. + + + Environment Variables Set or Propagated by the Service Manager + + The following environment variables are propagated by the service manager or generated internally + for each invoked process: + + + + $PATH + + Colon-separated list of directories to use when launching + executables. systemd uses a fixed value of + /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin + in the system manager. When compiled for systems with "unmerged /usr/" + (/bin is not a symlink to /usr/bin), + :/sbin:/bin is appended. In case of + the user manager, a different path may be configured by the distribution. It is recommended to + not rely on the order of entries, and have only one program with a given name in + $PATH. + + + + $LANG + + Locale. Can be set in locale.conf5 + or on the kernel command line (see + systemd1 and + kernel-command-line7). + + + + + $USER + $LOGNAME + $HOME + $SHELL + + User name (twice), home directory, and the + login shell. The variables are set for the units that have + User= set, which includes user + systemd instances. See + passwd5. + + + + + $INVOCATION_ID + + Contains a randomized, unique 128bit ID identifying each runtime cycle of the unit, formatted + as 32 character hexadecimal string. A new ID is assigned each time the unit changes from an inactive state into + an activating or active state, and may be used to identify this specific runtime cycle, in particular in data + stored offline, such as the journal. The same ID is passed to all processes run as part of the + unit. + + + + $XDG_RUNTIME_DIR + + The directory to use for runtime objects (such as IPC objects) and volatile state. Set for all + services run by the user systemd instance, as well as any system services that use + PAMName= with a PAM stack that includes pam_systemd. See below and + pam_systemd8 for more + information. + + + + $RUNTIME_DIRECTORY + $STATE_DIRECTORY + $CACHE_DIRECTORY + $LOGS_DIRECTORY + $CONFIGURATION_DIRECTORY + + Absolute paths to the directories defined with + RuntimeDirectory=, StateDirectory=, + CacheDirectory=, LogsDirectory=, and + ConfigurationDirectory= when those settings are used. + + + + + $CREDENTIALS_DIRECTORY + + An absolute path to the per-unit directory with credentials configured via + LoadCredential=/SetCredential=. The directory is marked + read-only and is placed in unswappable memory (if supported and permitted), and is only accessible to + the UID associated with the unit via User= or DynamicUser= (and + the superuser). + + + + $MAINPID + + The PID of the unit's main process if it is + known. This is only set for control processes as invoked by + ExecReload= and similar. + + + + $MANAGERPID + + The PID of the user systemd + instance, set for processes spawned by it. + + + + $LISTEN_FDS + $LISTEN_PID + $LISTEN_FDNAMES + + Information about file descriptors passed to a + service for socket activation. See + sd_listen_fds3. + + + + + $NOTIFY_SOCKET + + The socket + sd_notify() talks to. See + sd_notify3. + + + + + $WATCHDOG_PID + $WATCHDOG_USEC + + Information about watchdog keep-alive notifications. See + sd_watchdog_enabled3. + + + + + $SYSTEMD_EXEC_PID + + The PID of the unit process (e.g. process invoked by + ExecStart=). The child process can use this information to determine + whether the process is directly invoked by the service manager or indirectly as a child of + another process by comparing this value with the current PID (similarly to the scheme used in + sd_listen_fds3 + with $LISTEN_PID and $LISTEN_FDS). + + + + $TERM + + Terminal type, set only for units connected to + a terminal (StandardInput=tty, + StandardOutput=tty, or + StandardError=tty). See + termcap5. + + + + + $LOG_NAMESPACE + + Contains the name of the selected logging namespace when the + LogNamespace= service setting is used. + + + + $JOURNAL_STREAM + + If the standard output or standard error output of the executed processes are connected to the + journal (for example, by setting StandardError=journal) $JOURNAL_STREAM + contains the device and inode numbers of the connection file descriptor, formatted in decimal, separated by a + colon (:). This permits invoked processes to safely detect whether their standard output or + standard error output are connected to the journal. The device and inode numbers of the file descriptors should + be compared with the values set in the environment variable to determine whether the process output is still + connected to the journal. Note that it is generally not sufficient to only check whether + $JOURNAL_STREAM is set at all as services might invoke external processes replacing their + standard output or standard error output, without unsetting the environment variable. + + If both standard output and standard error of the executed processes are connected to the journal via a + stream socket, this environment variable will contain information about the standard error stream, as that's + usually the preferred destination for log data. (Note that typically the same stream is used for both standard + output and standard error, hence very likely the environment variable contains device and inode information + matching both stream file descriptors.) + + This environment variable is primarily useful to allow services to optionally upgrade their used log + protocol to the native journal protocol (using + sd_journal_print3 and other + functions) if their standard output or standard error output is connected to the journal anyway, thus enabling + delivery of structured metadata along with logged messages. + + + + $SERVICE_RESULT + + Only used for the service unit type. This environment variable is passed to all + ExecStop= and ExecStopPost= processes, and encodes the service + "result". Currently, the following values are defined: + + + Defined <varname>$SERVICE_RESULT</varname> values + + + + + + Value + Meaning + + + + + + success + The service ran successfully and exited cleanly. + + + protocol + A protocol violation occurred: the service did not take the steps required by its unit configuration (specifically what is configured in its Type= setting). + + + timeout + One of the steps timed out. + + + exit-code + Service process exited with a non-zero exit code; see $EXIT_CODE below for the actual exit code returned. + + + signal + A service process was terminated abnormally by a signal, without dumping core. See $EXIT_CODE below for the actual signal causing the termination. + + + core-dump + A service process terminated abnormally with a signal and dumped core. See $EXIT_CODE below for the signal causing the termination. + + + watchdog + Watchdog keep-alive ping was enabled for the service, but the deadline was missed. + + + start-limit-hit + A start limit was defined for the unit and it was hit, causing the unit to fail to start. See systemd.unit5's StartLimitIntervalSec= and StartLimitBurst= for details. + + + resources + A catch-all condition in case a system operation failed. + + + +
+ + This environment variable is useful to monitor failure or successful termination of a service. Even + though this variable is available in both ExecStop= and ExecStopPost=, it + is usually a better choice to place monitoring tools in the latter, as the former is only invoked for services + that managed to start up correctly, and the latter covers both services that failed during their start-up and + those which failed during their runtime. + + + + $EXIT_CODE + $EXIT_STATUS + + Only defined for the service unit type. These environment variables are passed to all + ExecStop=, ExecStopPost= processes and contain exit status/code + information of the main process of the service. For the precise definition of the exit code and status, see + wait2. $EXIT_CODE + is one of exited, killed, + dumped. $EXIT_STATUS contains the numeric exit code formatted as string + if $EXIT_CODE is exited, and the signal name in all other cases. Note + that these environment variables are only set if the service manager succeeded to start and identify the main + process of the service. + + + Summary of possible service result variable values + + + + + + + $SERVICE_RESULT + $EXIT_CODE + $EXIT_STATUS + + + + + + success + killed + HUP, INT, TERM, PIPE + + + exited + 0 + + + protocol + not set + not set + + + exited + 0 + + + timeout + killed + TERM, KILL + + + exited + 0, 1, 2, 3, …, 255 + + + exit-code + exited + 1, 2, 3, …, 255 + + + signal + killed + HUP, INT, KILL, … + + + core-dump + dumped + ABRT, SEGV, QUIT, … + + + watchdog + dumped + ABRT + + + killed + TERM, KILL + + + exited + 0, 1, 2, 3, …, 255 + + + exec-condition + exited + 1, 2, 3, 4, …, 254 + + + oom-kill + killed + TERM, KILL + + + start-limit-hit + not set + not set + + + resources + any of the above + any of the above + + + Note: the process may be also terminated by a signal not sent by systemd. In particular the process may send an arbitrary signal to itself in a handler for any of the non-maskable signals. Nevertheless, in the timeout and watchdog rows above only the signals that systemd sends have been included. Moreover, using SuccessExitStatus= additional exit statuses may be declared to indicate clean termination, which is not reflected by this table. + + + +
+ + + + $MONITOR_SERVICE_RESULT + $MONITOR_EXIT_CODE + $MONITOR_EXIT_STATUS + $MONITOR_INVOCATION_ID + $MONITOR_UNIT + + Only defined for the service unit type. Those environment variables are passed to + all ExecStart= and ExecStartPre= processes which run in + services triggered by OnFailure= or OnSuccess= dependencies. + + + Variables $MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE + and $MONITOR_EXIT_STATUS take the same values as for + ExecStop= and ExecStopPost= processes. Variables + $MONITOR_INVOCATION_ID and $MONITOR_UNIT are set to the + invocation id and unit name of the service which triggered the dependency. + + Note that when multiple services trigger the same unit, those variables will be + not be passed. Consider using a template handler unit for that case instead: + OnFailure=handler@%n.service for non-templated units, + or OnFailure=handler@%p-%i.service for templated + units. + + + + $PIDFILE + + The path to the configured PID file, in case the process is forked off on behalf of + a service that uses the PIDFile= setting, see + systemd.service5 + for details. Service code may use this environment variable to automatically generate a PID file at + the location configured in the unit file. This field is set to an absolute path in the file + system. + + + + $TRIGGER_UNIT + $TRIGGER_PATH + $TRIGGER_TIMER_REALTIME_USEC + $TRIGGER_TIMER_MONOTONIC_USEC + + If the unit was activated dynamically (e.g.: a corresponding path unit or timer unit), the + unit that triggered it and other type-dependent information will be passed via these variables. Note that + this information is provided in a best-effort way. For example, multiple triggers happening one after + another will be coalesced and only one will be reported, with no guarantee as to which one it will be. + Because of this, in most cases this variable will be primarily informational, i.e. useful for debugging + purposes, is lossy, and should not be relied upon to propagate a comprehensive reason for activation. + + + + + + For system services, when PAMName= is enabled and pam_systemd is part + of the selected PAM stack, additional environment variables defined by systemd may be set for + services. Specifically, these are $XDG_SEAT, $XDG_VTNR, see + pam_systemd8 for details. + + + + + + Process Exit Codes + + When invoking a unit process the service manager possibly fails to apply the execution parameters configured + with the settings above. In that case the already created service process will exit with a non-zero exit code + before the configured command line is executed. (Or in other words, the child process possibly exits with these + error codes, after having been created by the fork2 system call, but + before the matching execve2 system call is + called.) Specifically, exit codes defined by the C library, by the LSB specification and by the systemd service + manager itself are used. + + The following basic service exit codes are defined by the C library. + + + Basic C library exit codes + + + + Exit Code + Symbolic Name + Description + + + + + 0 + EXIT_SUCCESS + Generic success code. + + + 1 + EXIT_FAILURE + Generic failure or unspecified error. + + + +
+ + The following service exit codes are defined by the LSB specification. + + + + LSB service exit codes + + + + Exit Code + Symbolic Name + Description + + + + + 2 + EXIT_INVALIDARGUMENT + Invalid or excess arguments. + + + 3 + EXIT_NOTIMPLEMENTED + Unimplemented feature. + + + 4 + EXIT_NOPERMISSION + The user has insufficient privileges. + + + 5 + EXIT_NOTINSTALLED + The program is not installed. + + + 6 + EXIT_NOTCONFIGURED + The program is not configured. + + + 7 + EXIT_NOTRUNNING + The program is not running. + + + +
+ + + The LSB specification suggests that error codes 200 and above are reserved for implementations. Some of them are + used by the service manager to indicate problems during process invocation: + + + systemd-specific exit codes + + + + Exit Code + Symbolic Name + Description + + + + + 200 + EXIT_CHDIR + Changing to the requested working directory failed. See WorkingDirectory= above. + + + 201 + EXIT_NICE + Failed to set up process scheduling priority (nice level). See Nice= above. + + + 202 + EXIT_FDS + Failed to close unwanted file descriptors, or to adjust passed file descriptors. + + + 203 + EXIT_EXEC + The actual process execution failed (specifically, the execve2 system call). Most likely this is caused by a missing or non-accessible executable file. + + + 204 + EXIT_MEMORY + Failed to perform an action due to memory shortage. + + + 205 + EXIT_LIMITS + Failed to adjust resource limits. See LimitCPU= and related settings above. + + + 206 + EXIT_OOM_ADJUST + Failed to adjust the OOM setting. See OOMScoreAdjust= above. + + + 207 + EXIT_SIGNAL_MASK + Failed to set process signal mask. + + + 208 + EXIT_STDIN + Failed to set up standard input. See StandardInput= above. + + + 209 + EXIT_STDOUT + Failed to set up standard output. See StandardOutput= above. + + + 210 + EXIT_CHROOT + Failed to change root directory (chroot2). See RootDirectory=/RootImage= above. + + + 211 + EXIT_IOPRIO + Failed to set up IO scheduling priority. See IOSchedulingClass=/IOSchedulingPriority= above. + + + 212 + EXIT_TIMERSLACK + Failed to set up timer slack. See TimerSlackNSec= above. + + + 213 + EXIT_SECUREBITS + Failed to set process secure bits. See SecureBits= above. + + + 214 + EXIT_SETSCHEDULER + Failed to set up CPU scheduling. See CPUSchedulingPolicy=/CPUSchedulingPriority= above. + + + 215 + EXIT_CPUAFFINITY + Failed to set up CPU affinity. See CPUAffinity= above. + + + 216 + EXIT_GROUP + Failed to determine or change group credentials. See Group=/SupplementaryGroups= above. + + + 217 + EXIT_USER + Failed to determine or change user credentials, or to set up user namespacing. See User=/PrivateUsers= above. + + + 218 + EXIT_CAPABILITIES + Failed to drop capabilities, or apply ambient capabilities. See CapabilityBoundingSet=/AmbientCapabilities= above. + + + 219 + EXIT_CGROUP + Setting up the service control group failed. + + + 220 + EXIT_SETSID + Failed to create new process session. + + + 221 + EXIT_CONFIRM + Execution has been cancelled by the user. See the systemd.confirm_spawn= kernel command line setting on kernel-command-line7 for details. + + + 222 + EXIT_STDERR + Failed to set up standard error output. See StandardError= above. + + + 224 + EXIT_PAM + Failed to set up PAM session. See PAMName= above. + + + 225 + EXIT_NETWORK + Failed to set up network namespacing. See PrivateNetwork= above. + + + 226 + EXIT_NAMESPACE + Failed to set up mount, UTS, or IPC namespacing. See ReadOnlyPaths=, ProtectHostname=, PrivateIPC=, and related settings above. + + + 227 + EXIT_NO_NEW_PRIVILEGES + Failed to disable new privileges. See NoNewPrivileges=yes above. + + + 228 + EXIT_SECCOMP + Failed to apply system call filters. See SystemCallFilter= and related settings above. + + + 229 + EXIT_SELINUX_CONTEXT + Determining or changing SELinux context failed. See SELinuxContext= above. + + + 230 + EXIT_PERSONALITY + Failed to set up an execution domain (personality). See Personality= above. + + + 231 + EXIT_APPARMOR_PROFILE + Failed to prepare changing AppArmor profile. See AppArmorProfile= above. + + + 232 + EXIT_ADDRESS_FAMILIES + Failed to restrict address families. See RestrictAddressFamilies= above. + + + 233 + EXIT_RUNTIME_DIRECTORY + Setting up runtime directory failed. See RuntimeDirectory= and related settings above. + + + 235 + EXIT_CHOWN + Failed to adjust socket ownership. Used for socket units only. + + + 236 + EXIT_SMACK_PROCESS_LABEL + Failed to set SMACK label. See SmackProcessLabel= above. + + + 237 + EXIT_KEYRING + Failed to set up kernel keyring. + + + 238 + EXIT_STATE_DIRECTORY + Failed to set up unit's state directory. See StateDirectory= above. + + + 239 + EXIT_CACHE_DIRECTORY + Failed to set up unit's cache directory. See CacheDirectory= above. + + + 240 + EXIT_LOGS_DIRECTORY + Failed to set up unit's logging directory. See LogsDirectory= above. + + + 241 + EXIT_CONFIGURATION_DIRECTORY + Failed to set up unit's configuration directory. See ConfigurationDirectory= above. + + + 242 + EXIT_NUMA_POLICY + Failed to set up unit's NUMA memory policy. See NUMAPolicy= and NUMAMask= above. + + + 243 + EXIT_CREDENTIALS + Failed to set up unit's credentials. See LoadCredential= and SetCredential= above. + + + 245 + EXIT_BPF + Failed to apply BPF restrictions. See RestrictFileSystems= above. + + + +
+ + Finally, the BSD operating systems define a set of exit codes, typically defined on Linux systems too: + + + BSD exit codes + + + + Exit Code + Symbolic Name + Description + + + + + 64 + EX_USAGE + Command line usage error + + + 65 + EX_DATAERR + Data format error + + + 66 + EX_NOINPUT + Cannot open input + + + 67 + EX_NOUSER + Addressee unknown + + + 68 + EX_NOHOST + Host name unknown + + + 69 + EX_UNAVAILABLE + Service unavailable + + + 70 + EX_SOFTWARE + internal software error + + + 71 + EX_OSERR + System error (e.g., can't fork) + + + 72 + EX_OSFILE + Critical OS file missing + + + 73 + EX_CANTCREAT + Can't create (user) output file + + + 74 + EX_IOERR + Input/output error + + + 75 + EX_TEMPFAIL + Temporary failure; user is invited to retry + + + 76 + EX_PROTOCOL + Remote error in protocol + + + 77 + EX_NOPERM + Permission denied + + + 78 + EX_CONFIG + Configuration error + + + +
+ + + + Examples + + + <varname>$MONITOR_<replaceable>*</replaceable></varname> usage + + A service myfailer.service which can trigger an + OnFailure= dependency. + + +[Unit] +Description=Service which can trigger an OnFailure= dependency +OnFailure=myhandler.service + +[Service] +ExecStart=/bin/myprogram + + + A service mysuccess.service which can trigger an + OnSuccess= dependency. + + +[Unit] +Description=Service which can trigger an OnSuccess= dependency +OnSuccess=myhandler.service + +[Service] +ExecStart=/bin/mysecondprogram + + + A service myhandler.service which can be triggered + by any of the above services. + + +[Unit] +Description=Acts on service failing or succeeding + +[Service] +ExecStart=/bin/bash -c "echo $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID $MONITOR_UNIT" + + + If myfailer.service were to run and exit in failure, + then myhandler.service would be triggered and the + monitor variables would be set as follows: + + +MONITOR_SERVICE_RESULT=exit-code +MONITOR_EXIT_CODE=exited +MONITOR_EXIT_STATUS=1 +MONITOR_INVOCATION_ID=cc8fdc149b2b4ca698d4f259f4054236 +MONITOR_UNIT=myfailer.service + + + If mysuccess.service were to run and exit in success, + then myhandler.service would be triggered and the + monitor variables would be set as follows: + + +MONITOR_SERVICE_RESULT=success +MONITOR_EXIT_CODE=exited +MONITOR_EXIT_STATUS=0 +MONITOR_INVOCATION_ID=6ab9af147b8c4a3ebe36e7a5f8611697 +MONITOR_UNIT=mysuccess.service + + + + + + + + See Also + + systemd1, + systemctl1, + systemd-analyze1, + journalctl1, + systemd-system.conf5, + systemd.unit5, + systemd.service5, + systemd.socket5, + systemd.swap5, + systemd.mount5, + systemd.kill5, + systemd.resource-control5, + systemd.time7, + systemd.directives7, + tmpfiles.d5, + exec3, + fork2 + + + + diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml new file mode 100644 index 0000000..1845d83 --- /dev/null +++ b/man/systemd.generator.xml @@ -0,0 +1,359 @@ + + +%entities; +]> + + + + + systemd.generator + systemd + + + + systemd.generator + 7 + + + + systemd.generator + systemd unit generators + + + + + /path/to/generator + normal-dir + early-dir + late-dir + + + + /run/systemd/system-generators/* +/etc/systemd/system-generators/* +/usr/local/lib/systemd/system-generators/* +&SYSTEM_GENERATOR_DIR;/* + + + + /run/systemd/user-generators/* +/etc/systemd/user-generators/* +/usr/local/lib/systemd/user-generators/* +&USER_GENERATOR_DIR;/* + + + + + Description + Generators are small executables placed in &SYSTEM_GENERATOR_DIR;/ and other + directories listed above. + systemd1 will execute + these binaries very early at bootup and at configuration reload time — before unit files are + loaded. Their main purpose is to convert configuration and execution context parameters that are not + native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins, so + that they can extend the unit file hierarchy the service manager subsequently loads and operates + on. + + systemd will call each generator with three directory paths that are to be used + for generator output. In these three directories, generators may dynamically generate unit files (regular + ones, instances, as well as templates), unit file .d/ drop-ins, and create symbolic + links to unit files to add additional dependencies, create aliases, or instantiate existing templates. + Those directories are included in the unit load path, allowing generated configuration to extend or + override existing definitions. For tests, generators may be called with just one argument; the generator + should assume that all three paths are the same in that case. + + Directory paths for generator output differ by priority: …/generator.early has + priority higher than the admin configuration in /etc/, while + …/generator has lower priority than /etc/ but higher than + vendor configuration in /usr/, and …/generator.late has + priority lower than all other configuration. See the next section and the discussion of unit load paths + and unit overriding in + systemd.unit5. + + + Generators are loaded from a set of paths determined during compilation, as listed above. System + and user generators are loaded from directories with names ending in + system-generators/ and user-generators/, + respectively. Generators found in directories listed earlier override the ones with the same name in + directories lower in the list. A symlink to /dev/null or an empty file can be used + to mask a generator, thereby preventing it from running. Please note that the order of the two + directories with the highest priority is reversed with respect to the unit load path, and generators in + /run/ overwrite those in /etc/. + + After installing new generators or updating the configuration, systemctl + daemon-reload may be executed. This will delete the previous configuration created by + generators, re-run all generators, and cause systemd to reload units from disk. See + systemctl1 for more + information. + + + + + Output directories + + Generators are invoked with three arguments: paths to directories where generators can place their + generated unit files or symlinks. By default those paths are runtime directories that are included in the + search path of systemd, but a generator may be called with different paths for + debugging purposes. If only one argument is provided, the generator should use the same directory as the + the three output paths. + + + + normal-dir + In normal use this is /run/systemd/generator in case of the system + generators and $XDG_RUNTIME_DIR/systemd/generator in case of the user + generators. Unit files placed in this directory take precedence over vendor unit configuration but + not over native user/administrator unit configuration. + + + + + early-dir + In normal use this is /run/systemd/generator.early in case of the system + generators and $XDG_RUNTIME_DIR/systemd/generator.early in case of the user + generators. Unit files placed in this directory override unit files in /usr/, + /run/ and /etc/. This means that unit files placed in this + directory take precedence over all normal configuration, both vendor and user/administrator. + + + + late-dir + In normal use this is /run/systemd/generator.late in case of the system + generators and $XDG_RUNTIME_DIR/systemd/generator.late in case of the user + generators. This directory may be used to extend the unit file tree without overriding any other unit + files. Any native configuration files supplied by the vendor or user/administrator take + precedence. + + + + + + Environment + + The service manager sets a number of environment variables when invoking generator + executables. They carry information about the execution context of the generator, in order to simplify + conditionalizing generators to specific environments. The following environment variables are set: + + + + $SYSTEMD_SCOPE + + If the generator is invoked from the system service manager this variable is set to + system; if invoked from the per-user service manager it is set to + user. + + + + $SYSTEMD_IN_INITRD + + If the generator is run as part of an initrd this is set to 1. If + it is run from the regular host (i.e. after the transition from initrd to host) it is set to + 0. This environment variable is only set for system generators. + + + + $SYSTEMD_FIRST_BOOT + + If this boot-up cycle is considered a "first boot", this is set to + 1; if it is a subsequent, regular boot it is set to 0. For + details see the documentation of ConditionFirstBoot= in + systemd.unit5. This + environment variable is only set for system generators. + + + + $SYSTEMD_VIRTUALIZATION + + If the service manager is run in a virtualized environment, + $SYSTEMD_VIRTUALIZATION is set to a pair of strings, separated by a colon. The + first string is either vm or container, categorizing the type + of virtualization. The second string identifies the implementation of the virtualization + technology. If no virtualization is detected this variable will not be set. This data is identical to + what + systemd-detect-virt1 + detects and reports, and uses the same vocabulary of virtualization implementation + identifiers. + + + + $SYSTEMD_ARCHITECTURE + + This variable is set to a short identifier of the reported architecture of the + system. For details about defined values, see documentation of + ConditionArchitecture= in + systemd.unit5. + + + + + + Notes about writing generators + + + + All generators are executed in parallel. That means all executables are started at the very + same time and need to be able to cope with this parallelism. + + + + + Generators are run very early at boot and cannot rely on any external services. They may not + talk to any other process. That includes simple things such as logging to syslog3, or + systemd itself (this means: no + systemctl1)! + Non-essential file systems like /var/ and /home/ are + mounted after generators have run. Generators can however rely on the most basic kernel functionality + to be available, as well as mounted /sys/, /proc/, + /dev/, /usr/ and /run/ file systems. + + + + + Units written by generators are removed when the configuration is reloaded. That means the + lifetime of the generated units is closely bound to the reload cycles of systemd + itself. + + + + Generators should only be used to generate unit files, .d/*.conf drop-ins + for them and symlinks to them, not any other kind of non-unit related configuration. Due to the + lifecycle logic mentioned above, generators are not a good fit to generate dynamic configuration for + other services. If you need to generate dynamic configuration for other services, do so in normal + services you order before the service in question. + + Note that using the StandardInputData=/StandardInputText= + settings of service unit files (see + systemd.exec5), it + is possible to make arbitrary input data (including daemon-specific configuration) part of the unit + definitions, which often might be sufficient to embed data or configuration for other programs into + unit files in a native fashion. + + + + Since + syslog3 + + is not available (see above), log messages have to be written to /dev/kmsg + instead. + + + + The generator should always include its own name in a comment at the top of the generated file, + so that the user can easily figure out which component created or amended a particular unit. + + The SourcePath= directive should be used in generated files to specify the + source configuration file they are generated from. This makes things more easily understood by the + user and also has the benefit that systemd can warn the user about configuration files that changed + on disk but have not been read yet by systemd. The SourcePath= value does not have + to be a file in a physical filesystem. For example, in the common case of the generator looking at + the kernel command line, should be used. + + + + Generators may write out dynamic unit files or just hook unit files into other units with the + usual .wants/ or .requires/ symlinks. Often, it is nicer to + simply instantiate a template unit file from /usr/ with a generator instead of + writing out entirely dynamic unit files. Of course, this works only if a single parameter is to be + used. + + + + If you are careful, you can implement generators in shell scripts. We do recommend C code + however, since generators are executed synchronously and hence delay the entire boot if they are + slow. + + + + Regarding overriding semantics: there are two rules we try to follow when thinking about the + overriding semantics: + + + + User configuration should override vendor configuration. This (mostly) means that stuff + from /etc/ should override stuff from /usr/. + + + + Native configuration should override non-native configuration. This (mostly) means that + stuff you generate should never override native unit files for the same purpose. + + + + Of these two rules the first rule is probably the more important one and breaks the second one + sometimes. Hence, when deciding whether to use argv[1], argv[2], or argv[3], your default choice + should probably be argv[1]. + + + + Instead of heading off now and writing all kind of generators for legacy configuration file + formats, please think twice! It is often a better idea to just deprecate old stuff instead of keeping + it artificially alive. + + + + + + + Examples + + systemd-fstab-generator + + systemd-fstab-generator8 + converts /etc/fstab into native mount units. It uses argv[1] as location to place + the generated unit files in order to allow the user to override /etc/fstab with + their own native unit files, but also to ensure that /etc/fstab overrides any + vendor default from /usr/. + + After editing /etc/fstab, the user should invoke systemctl + daemon-reload. This will re-run all generators and cause systemd to reload + units from disk. To actually mount new directories added to fstab, + systemctl start /path/to/mountpoint or systemctl + start local-fs.target may be used. + + + + systemd-system-update-generator + + systemd-system-update-generator8 + temporarily redirects default.target to system-update.target, + if a system update is scheduled. Since this needs to override the default user configuration for + default.target, it uses argv[2]. For details about this logic, see + systemd.offline-updates7. + + + + + Debugging a generator + + dir=$(mktemp -d) +SYSTEMD_LOG_LEVEL=debug &SYSTEM_GENERATOR_DIR;/systemd-fstab-generator \ + "$dir" "$dir" "$dir" +find $dir + + + + + See also + + + systemd1, + systemd-cryptsetup-generator8, + systemd-debug-generator8, + systemd-fstab-generator8, + fstab5, + systemd-getty-generator8, + systemd-gpt-auto-generator8, + systemd-hibernate-resume-generator8, + systemd-rc-local-generator8, + systemd-system-update-generator8, + systemd-sysv-generator8, + systemd-xdg-autostart-generator8, + systemd.unit5, + systemctl1, + systemd.environment-generator7 + + + diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml new file mode 100644 index 0000000..caedb6e --- /dev/null +++ b/man/systemd.journal-fields.xml @@ -0,0 +1,608 @@ + + + + + + + + systemd.journal-fields + systemd + + + + systemd.journal-fields + 7 + + + + systemd.journal-fields + Special journal fields + + + + Description + + Entries in the journal (as written by + systemd-journald.service8) + resemble a UNIX process environment block in syntax but with fields that may include binary data. + Primarily, fields are formatted UTF-8 text strings, and binary encoding is used only where formatting as + UTF-8 text strings makes little sense. New fields may freely be defined by applications, but a few fields + have special meanings. All fields with special meanings are optional. In some cases, fields may appear + more than once per entry. + + + + User Journal Fields + + User fields are fields that are directly passed from clients + and stored in the journal. + + + + MESSAGE= + + The human-readable message string for this entry. This + is supposed to be the primary text shown to the user. It is + usually not translated (but might be in some cases), and is + not supposed to be parsed for metadata. + + + + + MESSAGE_ID= + + A 128-bit message identifier ID for recognizing certain message types, if this is desirable. This + should contain a 128-bit ID formatted as a lower-case hexadecimal string, without any separating dashes or + suchlike. This is recommended to be a UUID-compatible ID, but this is not enforced, and formatted + differently. Developers can generate a new ID for this purpose with systemd-id128 new. + + + + + + PRIORITY= + + A priority value between 0 (emerg) + and 7 (debug) formatted as a decimal + string. This field is compatible with syslog's priority + concept. + + + + + CODE_FILE= + CODE_LINE= + CODE_FUNC= + + The code location generating this message, if known. + Contains the source filename, the line number and the + function name. + + + + + ERRNO= + + The low-level Unix error number causing this entry, if + any. Contains the numeric value of + errno3 + formatted as a decimal string. + + + + + INVOCATION_ID= + USER_INVOCATION_ID= + + A randomized, unique 128-bit ID identifying each runtime cycle of the unit. This is different from + _SYSTEMD_INVOCATION_ID in that it is only used for messages coming from systemd code + (e.g. logs from the system/user manager or from forked processes performing systemd-related setup). + + + + + SYSLOG_FACILITY= + SYSLOG_IDENTIFIER= + SYSLOG_PID= + SYSLOG_TIMESTAMP= + + Syslog compatibility fields containing the facility (formatted as + decimal string), the identifier string (i.e. "tag"), the client PID, and + the timestamp as specified in the original datagram. (Note that the tag is + usually derived from glibc's + program_invocation_short_name variable, see + program_invocation_short_name3.) + Note that the journal service does not validate the values of any structured + journal fields whose name is not prefixed with an underscore, and this includes any + syslog related fields such as these. Hence, applications that supply a facility, PID, + or log level are expected to do so properly formatted, i.e. as numeric integers formatted + as decimal strings. + + + + + SYSLOG_RAW= + + The original contents of the syslog line as received in the syslog + datagram. This field is only included if the MESSAGE= + field was modified compared to the original payload or the timestamp could + not be located properly and is not included in + SYSLOG_TIMESTAMP=. Message truncation occurs when + the message contains leading or trailing whitespace (trailing and leading + whitespace is stripped), or it contains an embedded + NUL byte (the NUL byte and + anything after it is not included). Thus, the original syslog line is + either stored as SYSLOG_RAW= or it can be recreated + based on the stored priority and facility, timestamp, identifier, and the + message payload in MESSAGE=. + + + + + + DOCUMENTATION= + + A documentation URL with further information about the topic of the log message. Tools such + as journalctl will include a hyperlink to an URL specified this way in their + output. Should be an http://, https://, + file:/, man: or info: URL. + + + + + TID= + + The numeric thread ID (TID) the log message originates from. + + + + + UNIT= + USER_UNIT= + + The name of a unit. Used by the system and user managers when logging about specific + units. + + When or + are used with + journalctl1, a + match pattern that includes UNIT=name.service or + USER_UNIT=name.service will be generated. + + + + + + + Trusted Journal Fields + + Fields prefixed with an underscore are trusted fields, i.e. + fields that are implicitly added by the journal and cannot be + altered by client code. + + + + _PID= + _UID= + _GID= + + The process, user, and group ID of the process the + journal entry originates from formatted as a decimal + string. Note that entries obtained via stdout or + stderr of forked processes will contain credentials valid for a parent + process (that initiated the connection to systemd-journald). + + + + + _COMM= + _EXE= + _CMDLINE= + + The name, the executable path, and the command line of + the process the journal entry originates from. + + + + + _CAP_EFFECTIVE= + + The effective + capabilities7 + of the process the journal entry originates from. + + + + + _AUDIT_SESSION= + _AUDIT_LOGINUID= + + The session and login UID of the process the journal + entry originates from, as maintained by the kernel audit + subsystem. + + + + + _SYSTEMD_CGROUP= + _SYSTEMD_SLICE= + _SYSTEMD_UNIT= + _SYSTEMD_USER_UNIT= + _SYSTEMD_USER_SLICE= + _SYSTEMD_SESSION= + _SYSTEMD_OWNER_UID= + + + The control group path in the systemd hierarchy, the systemd slice unit name, the systemd + unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and + the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry + originates from. + + + + + _SELINUX_CONTEXT= + + The SELinux security context (label) of the process + the journal entry originates from. + + + + + _SOURCE_REALTIME_TIMESTAMP= + + The earliest trusted timestamp of the message, if any + is known that is different from the reception time of the + journal. This is the time in microseconds since the epoch + UTC, formatted as a decimal string. + + + + + _BOOT_ID= + + The kernel boot ID for the boot the message was + generated in, formatted as a 128-bit hexadecimal + string. + + + + + _MACHINE_ID= + + The machine ID of the originating host, as available + in + machine-id5. + + + + + _SYSTEMD_INVOCATION_ID= + + The invocation ID for the runtime cycle of the unit + the message was generated in, as available to processes + of the unit in $INVOCATION_ID (see + systemd.exec5). + + + + + _HOSTNAME= + + The name of the originating host. + + + + + _TRANSPORT= + + How the entry was received by the journal service. + Valid transports are: + + + + + + + + for those read from the kernel audit subsystem + + + + + + + + + + for internally generated messages + + + + + + + + + + for those received via the local syslog socket + with the syslog protocol + + + + + + + + + + for those received via the native journal + protocol + + + + + + + + + + for those read from a service's standard output + or error output + + + + + + + + + + for those read from the kernel + + + + + + + + _STREAM_ID= + + Only applies to _TRANSPORT=stdout records: specifies a randomized 128bit ID assigned + to the stream connection when it was first created. This ID is useful to reconstruct individual log streams + from the log records: all log records carrying the same stream ID originate from the same stream. + + + + _LINE_BREAK= + + Only applies to _TRANSPORT=stdout records: indicates that the log message + in the standard output/error stream was not terminated with a normal newline character + (\n, i.e. ASCII 10). Specifically, when set this field is one of + (in case the line was terminated by a NUL byte), (in + case the maximum log line length was reached, as configured with LineMax= in + journald.conf5), + (if this was the last log record of a stream and the stream ended without a + final newline character), or (if the process which generated the log + output changed in the middle of a line). Note that this record is not generated when a normal + newline character was used for marking the log line end. + + + + _NAMESPACE= + + If this file was written by a systemd-journald instance managing a + journal namespace that is not the default, this field contains the namespace identifier. See + systemd-journald.service8 + for details about journal namespaces. + + + + _RUNTIME_SCOPE= + + A string field that specifies the runtime scope in which the message was logged. If + initrd, the log message was processed while the system was running inside the + initrd. If system, the log message was generated after the system switched + execution to the host root filesystem. + + + + + + Kernel Journal Fields + + Kernel fields are fields that are used by messages + originating in the kernel and stored in the journal. + + + + _KERNEL_DEVICE= + + The kernel device name. If the entry is associated to a block device, contains the major and + minor numbers of the device node, separated by : and prefixed by + b. Similarly for character devices, but prefixed by c. For + network devices, this is the interface index prefixed by n. For all other + devices, this is the subsystem name prefixed by +, followed by + :, followed by the kernel device name. + + + + _KERNEL_SUBSYSTEM= + + The kernel subsystem name. + + + + _UDEV_SYSNAME= + + The kernel device name as it shows up in the device + tree below /sys/. + + + + _UDEV_DEVNODE= + + The device node path of this device in + /dev/. + + + + _UDEV_DEVLINK= + + Additional symlink names pointing to the device node + in /dev/. This field is frequently set + more than once per entry. + + + + + + + Fields to log on behalf of a different program + + Fields in this section are used by programs to specify that + they are logging on behalf of another program or unit. + + + Fields used by the systemd-coredump + coredump kernel helper: + + + + + COREDUMP_UNIT= + COREDUMP_USER_UNIT= + + Used to annotate messages containing coredumps from + system and session units. See + coredumpctl1. + + + + + + Privileged programs (currently UID 0) may attach + OBJECT_PID= to a message. This will instruct + systemd-journald to attach additional fields on + behalf of the caller: + + + + OBJECT_PID=PID + + PID of the program that this message pertains to. + + + + + + OBJECT_UID= + OBJECT_GID= + OBJECT_COMM= + OBJECT_EXE= + OBJECT_CMDLINE= + OBJECT_AUDIT_SESSION= + OBJECT_AUDIT_LOGINUID= + OBJECT_SYSTEMD_CGROUP= + OBJECT_SYSTEMD_SESSION= + OBJECT_SYSTEMD_OWNER_UID= + OBJECT_SYSTEMD_UNIT= + OBJECT_SYSTEMD_USER_UNIT= + + These are additional fields added automatically by + systemd-journald. Their meaning is the + same as + _UID=, + _GID=, + _COMM=, + _EXE=, + _CMDLINE=, + _AUDIT_SESSION=, + _AUDIT_LOGINUID=, + _SYSTEMD_CGROUP=, + _SYSTEMD_SESSION=, + _SYSTEMD_UNIT=, + _SYSTEMD_USER_UNIT=, and + _SYSTEMD_OWNER_UID= + as described above, except that the process identified by + PID is described, instead of the + process which logged the message. + + + + + + + + Address Fields + + During serialization into external formats, such as the + Journal Export Format + or the + Journal JSON Format, + the addresses of journal entries are + serialized into fields prefixed with double underscores. Note that + these are not proper fields when stored in the journal but for + addressing metadata of entries. They cannot be written as part of + structured log entries via calls such as + sd_journal_send3. + They may also not be used as matches for + sd_journal_add_match3. + + + + + __CURSOR= + + The cursor for the entry. A cursor is an opaque text + string that uniquely describes the position of an entry in + the journal and is portable across machines, platforms and + journal files. + + + + + + __REALTIME_TIMESTAMP= + + The wallclock time + (CLOCK_REALTIME) at the point in time + the entry was received by the journal, in microseconds since + the epoch UTC, formatted as a decimal string. This has + different properties from + _SOURCE_REALTIME_TIMESTAMP=, as it is + usually a bit later but more likely to be monotonic. + + + + + + __MONOTONIC_TIMESTAMP= + + The monotonic time + (CLOCK_MONOTONIC) at the point in time + the entry was received by the journal in microseconds, + formatted as a decimal string. To be useful as an address + for the entry, this should be combined with the boot ID in + _BOOT_ID=. + + + + + + + + See Also + + systemd1, + systemd-journald.service8, + journalctl1, + journald.conf5, + sd-journal3, + coredumpctl1, + systemd.directives7 + + + + diff --git a/man/systemd.kill.xml b/man/systemd.kill.xml new file mode 100644 index 0000000..91de22f --- /dev/null +++ b/man/systemd.kill.xml @@ -0,0 +1,195 @@ + + + + + + + systemd.kill + systemd + + + + systemd.kill + 5 + + + + systemd.kill + Process killing procedure + configuration + + + + service.service, + socket.socket, + mount.mount, + swap.swap, + scope.scope + + + + Description + + Unit configuration files for services, sockets, mount + points, swap devices and scopes share a subset of configuration + options which define the killing procedure of processes belonging + to the unit. + + This man page lists the configuration options shared by + these five unit types. See + systemd.unit5 + for the common options shared by all unit configuration files, and + systemd.service5, + systemd.socket5, + systemd.swap5, + systemd.mount5 + and + systemd.scope5 + for more information on the configuration file options specific to + each unit type. + + The kill procedure configuration options are configured in + the [Service], [Socket], [Mount] or [Swap] section, depending on + the unit type. + + + + Options + + + + + KillMode= + Specifies how processes of this unit shall be killed. One of + , , , + . + + If set to , all remaining processes in the control group of this + unit will be killed on unit stop (for services: after the stop command is executed, as configured + with ExecStop=). If set to , the + SIGTERM signal (see below) is sent to the main process while the subsequent + SIGKILL signal (see below) is sent to all remaining processes of the unit's + control group. If set to , only the main process itself is killed (not + recommended!). If set to , no process is killed (strongly recommended + against!). In this case, only the stop command will be executed on unit stop, but no process will be + killed otherwise. Processes remaining alive after stop are left in their control group and the + control group continues to exist after stop unless empty. + + Note that it is not recommended to set KillMode= to + process or even none, as this allows processes to escape + the service manager's lifecycle and resource management, and to remain running even while their + service is considered stopped and is assumed to not consume any resources. + + Processes will first be terminated via SIGTERM (unless the signal to send + is changed via KillSignal= or RestartKillSignal=). Optionally, + this is immediately followed by a SIGHUP (if enabled with + SendSIGHUP=). If processes still remain after: + + the main process of a unit has exited (applies to KillMode=: + ) + the delay configured via the TimeoutStopSec= has passed + (applies to KillMode=: , , + ) + + + the termination request is repeated with the SIGKILL signal or the signal specified via + FinalKillSignal= (unless this is disabled via the SendSIGKILL= + option). See kill2 + for more information. + + Defaults to . + + + + KillSignal= + Specifies which signal to use when stopping a service. This controls the signal that + is sent as first step of shutting down a unit (see above), and is usually followed by + SIGKILL (see above and below). For a list of valid signals, see + signal7. + Defaults to SIGTERM. + + Note that, right after sending the signal specified in this setting, systemd will always send + SIGCONT, to ensure that even suspended tasks can be terminated cleanly. + + + + + RestartKillSignal= + Specifies which signal to use when restarting a service. The same as + KillSignal= described above, with the exception that this setting is used in a + restart job. Not set by default, and the value of KillSignal= is used. + + + + + SendSIGHUP= + Specifies whether to send + SIGHUP to remaining processes immediately + after sending the signal configured with + KillSignal=. This is useful to indicate to + shells and shell-like programs that their connection has been + severed. Takes a boolean value. Defaults to "no". + + + + + SendSIGKILL= + Specifies whether to send + SIGKILL (or the signal specified by + FinalKillSignal=) to remaining processes + after a timeout, if the normal shutdown procedure left + processes of the service around. When disabled, a + KillMode= of control-group + or mixed service will not restart if + processes from prior services exist within the control group. + Takes a boolean value. Defaults to "yes". + + + + + FinalKillSignal= + Specifies which signal to send to remaining + processes after a timeout if SendSIGKILL= + is enabled. The signal configured here should be one that is + not typically caught and processed by services (SIGTERM + is not suitable). Developers can find it useful to use this to + generate a coredump to troubleshoot why a service did not + terminate upon receiving the initial SIGTERM + signal. This can be achieved by configuring LimitCORE= + and setting FinalKillSignal= to either + SIGQUIT or SIGABRT. + Defaults to SIGKILL. + + + + + WatchdogSignal= + Specifies which signal to use to terminate the + service when the watchdog timeout expires (enabled through + WatchdogSec=). Defaults to SIGABRT. + + + + + + + + See Also + + systemd1, + systemctl1, + journalctl1, + systemd.unit5, + systemd.service5, + systemd.socket5, + systemd.swap5, + systemd.mount5, + systemd.exec5, + systemd.directives7, + kill2, + signal7 + + + + diff --git a/man/systemd.link.xml b/man/systemd.link.xml new file mode 100644 index 0000000..cc55b02 --- /dev/null +++ b/man/systemd.link.xml @@ -0,0 +1,1250 @@ + + + + + + + systemd.link + systemd + + + + systemd.link + 5 + + + + systemd.link + Network device configuration + + + + link.link + + + + Description + + A plain ini-style text file that encodes configuration for matching network devices, used by + systemd-udevd8 and in + particular its net_setup_link builtin. See + systemd.syntax7 for a + general description of the syntax. + + The .link files are read from the files located in the system network + directory /usr/lib/systemd/network and + /usr/local/lib/systemd/network, the volatile runtime network directory + /run/systemd/network, and the local administration network directory + /etc/systemd/network. All configuration files are collectively sorted and + processed in alphanumeric order, regardless of the directories in which they live. However, files + with identical filenames replace each other. It is recommended that each filename is prefixed with + a number (e.g. 10-eth0.link). Otherwise, the default + .link files or those generated by + systemd-network-generator.service8 + may take precedence over user configured files. Files in /etc/ have the + highest priority, files in /run/ take precedence over files with the same name + in /usr/lib/. This can be used to override a system-supplied link file with a + local file if needed. As a special case, an empty file (file size 0) or symlink with the same name + pointing to /dev/null disables the configuration file entirely (it is + "masked"). + + Along with the link file foo.link, a "drop-in" directory + foo.link.d/ may exist. All files with the suffix .conf + from this directory will be merged in the alphanumeric order and parsed after the main file itself + has been parsed. This is useful to alter or add configuration settings, without having to modify + the main configuration file. Each drop-in file must have appropriate section headers. + + In addition to /etc/systemd/network, drop-in .d + directories can be placed in /usr/lib/systemd/network or + /run/systemd/network directories. Drop-in files in /etc/ + take precedence over those in /run/ which in turn take precedence over those + in /usr/lib/. Drop-in files under any of these directories take precedence + over the main link file wherever located. + + The link file contains a [Match] section, which determines if a given link file may be applied to a + given device, as well as a [Link] section specifying how the device should be configured. The first (in + lexical order) of the link files that matches a given device is applied. Note that a default file + 99-default.link is shipped by the system. Any user-supplied + .link should hence have a lexically earlier name to be considered at all. + + See udevadm8 for + diagnosing problems with .link files. + + + + [Match] Section Options + + A link file is said to match an interface if all matches specified by the [Match] section are + satisfied. When a link file does not contain valid settings in [Match] section, then the file will + match all interfaces and systemd-udevd warns about that. Hint: to avoid the + warning and to make it clear that all interfaces shall be matched, add the following: + OriginalName=* + The first (in alphanumeric order) of the link files that matches a given interface is applied, all + later files are ignored, even if they match as well. The following keys are accepted: + + + + + + MACAddress= + + A whitespace-separated list of hardware addresses. The acceptable formats are: + + + + + + Each field must be one byte. + E.g. 12:34:56:78:90:ab or AA:BB:CC:DD:EE:FF. + + + + + + Each field must be one byte. + E.g. 12-34-56-78-90-ab or AA-BB-CC-DD-EE-FF. + + + + + + Each field must be two bytes. + E.g. 1234.5678.90ab or AABB.CCDD.EEFF. + + + + + + E.g. 127.0.0.1 or 192.168.0.1. + + + + + + E.g. 2001:0db8:85a3::8a2e:0370:7334 or ::1. + + + + + The total length of each MAC address must be 4 (for IPv4 tunnel), 6 (for Ethernet), 16 + (for IPv6 tunnel), or 20 (for InfiniBand). This option may appear more than once, in which + case the lists are merged. If the empty string is assigned to this option, the list of + hardware addresses defined prior to this is reset. Defaults to unset. + + + + + PermanentMACAddress= + + A whitespace-separated list of hardware's permanent addresses. While + MACAddress= matches the device's current MAC address, this matches the + device's permanent MAC address, which may be different from the current one. Use full + colon-, hyphen- or dot-delimited hexadecimal, or IPv4 or IPv6 address format. This option may + appear more than once, in which case the lists are merged. If the empty string is assigned to + this option, the list of hardware addresses defined prior to this is reset. Defaults to + unset. + + + + + Path= + + A whitespace-separated list of shell-style globs matching + the persistent path, as exposed by the udev property + ID_PATH. + + + + + Driver= + + A whitespace-separated list of shell-style globs matching the driver currently bound to the + device, as exposed by the udev property ID_NET_DRIVER of its parent device, or + if that is not set, the driver as exposed by ethtool -i of the device itself. + If the list is prefixed with a "!", the test is inverted. + + + + + Type= + + A whitespace-separated list of shell-style globs matching the device type, as exposed by + networkctl list. If the list is prefixed with a "!", the test is inverted. + Some valid values are ether, loopback, wlan, wwan. + Valid types are named either from the udev DEVTYPE attribute, or + ARPHRD_ macros in linux/if_arp.h, so this is not comprehensive. + + + + + + Kind= + + A whitespace-separated list of shell-style globs matching the device kind, as exposed by + networkctl status INTERFACE or + ip -d link show INTERFACE. If the list is + prefixed with a "!", the test is inverted. Some valid values are bond, + bridge, gre, tun, + veth. Valid kinds are given by netlink's IFLA_INFO_KIND + attribute, so this is not comprehensive. + + + + + + Property= + + A whitespace-separated list of udev property names with their values after equals sign + (=). If multiple properties are specified, the test results are ANDed. + If the list is prefixed with a "!", the test is inverted. If a value contains white + spaces, then please quote whole key and value pair. If a value contains quotation, then + please escape the quotation with \. + + Example: if a .link file has the following: + Property=ID_MODEL_ID=9999 "ID_VENDOR_FROM_DATABASE=vendor name" "KEY=with \"quotation\"" + then, the .link file matches only when an interface has all the above three properties. + + + + + + OriginalName= + + A whitespace-separated list of shell-style globs matching the device name, as exposed by the + udev property "INTERFACE". This cannot be used to match on names that have already been changed + from userspace. Caution is advised when matching on kernel-assigned names, as they are known to be + unstable between reboots. + + + + + Host= + + Matches against the hostname or machine ID of the host. See ConditionHost= in + systemd.unit5 + for details. When prefixed with an exclamation mark (!), the result is negated. + If an empty string is assigned, the previously assigned value is cleared. + + + + + + Virtualization= + + Checks whether the system is executed in a virtualized environment and optionally test + whether it is a specific implementation. See ConditionVirtualization= in + systemd.unit5 + for details. When prefixed with an exclamation mark (!), the result is negated. + If an empty string is assigned, the previously assigned value is cleared. + + + + + + KernelCommandLine= + + Checks whether a specific kernel command line option is set. See + ConditionKernelCommandLine= in + systemd.unit5 + for details. When prefixed with an exclamation mark (!), the result is negated. + If an empty string is assigned, the previously assigned value is cleared. + + + + + + KernelVersion= + + Checks whether the kernel version (as reported by uname -r) matches a certain + expression. See ConditionKernelVersion= in + systemd.unit5 for + details. When prefixed with an exclamation mark (!), the result is negated. + If an empty string is assigned, the previously assigned value is cleared. + + + + + + Credential= + + Checks whether the specified credential was passed to the + systemd-networkd.service service. See System and Service Credentials for details. When + prefixed with an exclamation mark (!), the result is negated. If an empty + string is assigned, the previously assigned value is cleared. + + + + + + Architecture= + + Checks whether the system is running on a specific architecture. See + ConditionArchitecture= in + systemd.unit5 + for details. When prefixed with an exclamation mark (!), the result is negated. + If an empty string is assigned, the previously assigned value is cleared. + + + + + + Firmware= + + Checks whether the system is running on a machine with the specified firmware. See + ConditionFirmware= in + systemd.unit5 + for details. When prefixed with an exclamation mark (!), the result is negated. + If an empty string is assigned, the previously assigned value is cleared. + + + + + + + + + [Link] Section Options + + The [Link] section accepts the following + keys: + + + + Description= + + A description of the device. + + + + Alias= + + The ifalias interface property is set to this value. + + + + MACAddressPolicy= + + The policy by which the MAC address should be set. The + available policies are: + + + + + + + If the hardware has a persistent MAC address, as + most hardware should, and if it is used by the kernel, + nothing is done. Otherwise, a new MAC address is + generated which is guaranteed to be the same on every + boot for the given machine and the given device, but + which is otherwise random. This feature depends on ID_NET_NAME_* + properties to exist for the link. On hardware where these + properties are not set, the generation of a persistent MAC address + will fail. + + + + + + If the kernel is using a random MAC address, + nothing is done. Otherwise, a new address is randomly + generated each time the device appears, typically at + boot. Either way, the random address will have the + unicast and + locally administered bits set. + + + + + + Keeps the MAC address assigned by the kernel. Or use the MAC address specified in + MACAddress=. + + + + + An empty string assignment is equivalent to setting none. + + + + MACAddress= + + The interface MAC address to use. For this setting to take effect, + MACAddressPolicy= must either be unset, empty, or none. + + + + + NamePolicy= + + An ordered, space-separated list of policies by which the interface name should be set. + NamePolicy= may be disabled by specifying on the + kernel command line. Each of the policies may fail, and the first successful one is used. The name + is not set directly, but is exported to udev as the property , which + is, by default, used by a + udev7, + rule to set NAME. The available policies are: + + + + + + + If the kernel claims that the name it has set + for a device is predictable, then no renaming is + performed. + + + + + + The name is set based on entries in the udev's + Hardware Database with the key + ID_NET_NAME_FROM_DATABASE. + + + + + + + The name is set based on information given by + the firmware for on-board devices, as exported by the + udev property ID_NET_NAME_ONBOARD. + See systemd.net-naming-scheme7. + + + + + + + The name is set based on information given by + the firmware for hot-plug devices, as exported by the + udev property ID_NET_NAME_SLOT. + See systemd.net-naming-scheme7. + + + + + + + The name is set based on the device's physical + location, as exported by the udev property + ID_NET_NAME_PATH. + See systemd.net-naming-scheme7. + + + + + + + The name is set based on the device's persistent + MAC address, as exported by the udev property + ID_NET_NAME_MAC. + See systemd.net-naming-scheme7. + + + + + + + If the device already had a name given by userspace (as part of creation of the device + or a rename), keep it. + + + + + + + Name= + + The interface name to use. This option has lower precedence than + NamePolicy=, so for this setting to take effect, NamePolicy= + must either be unset, empty, disabled, or all policies configured there must fail. Also see the + example below with Name=dmz0. + + Note that specifying a name that the kernel might use for another interface (for example + eth0) is dangerous because the name assignment done by udev will race with the + assignment done by the kernel, and only one interface may use the name. Depending on the order of + operations, either udev or the kernel will win, making the naming unpredictable. It is best to use + some different prefix, for example internal0/external0 or + lan0/lan1/lan3. + + Interface names must have a minimum length of 1 character and a maximum length of 15 + characters, and may contain any 7bit ASCII character, with the exception of control characters, + :, / and %. While . is + an allowed character, it's recommended to avoid it when naming interfaces as various tools (such as + resolvconf1) use + it as separator character. Also, fully numeric interface names are not allowed (in order to avoid + ambiguity with interface specification by numeric indexes), as are the special strings + ., .., all and + default. + + + + AlternativeNamesPolicy= + + A space-separated list of policies by which the interface's alternative names + should be set. Each of the policies may fail, and all successful policies are used. The + available policies are database, onboard, + slot, path, and mac. If the + kernel does not support the alternative names, then this setting will be ignored. + + + + + AlternativeName= + + The alternative interface name to use. This option can be specified multiple times. + If the empty string is assigned to this option, the list is reset, and all prior assignments + have no effect. If the kernel does not support the alternative names, then this setting will + be ignored. + + Alternative interface names may be used to identify interfaces in various tools. In contrast + to the primary name (as configured with Name= above) there may be multiple + alternative names referring to the same interface. Alternative names may have a maximum length of + 127 characters, in contrast to the 15 allowed for the primary interface name, but otherwise are + subject to the same naming constraints. + + + + TransmitQueues= + + Specifies the device's number of transmit queues. An integer in the range 1…4096. + When unset, the kernel's default will be used. + + + + ReceiveQueues= + + Specifies the device's number of receive queues. An integer in the range 1…4096. + When unset, the kernel's default will be used. + + + + TransmitQueueLength= + + Specifies the transmit queue length of the device in number of packets. An unsigned integer + in the range 0…4294967294. When unset, the kernel's default will be used. + + + + MTUBytes= + + The maximum transmission unit in bytes to set for the + device. The usual suffixes K, M, G are supported and are + understood to the base of 1024. + + + + BitsPerSecond= + + The speed to set for the device, the value is rounded + down to the nearest Mbps. The usual suffixes K, M, G are + supported and are understood to the base of 1000. + + + + Duplex= + + The duplex mode to set for the device. The accepted values are and + . + + + + AutoNegotiation= + + Takes a boolean. If set to yes, automatic negotiation of transmission parameters is enabled. + Autonegotiation is a procedure by which two connected ethernet devices choose + common transmission parameters, such as speed, duplex mode, and flow control. + When unset, the kernel's default will be used. + + Note that if autonegotiation is enabled, speed and duplex settings are + read-only. If autonegotiation is disabled, speed and duplex settings are writable + if the driver supports multiple link modes. + + + + WakeOnLan= + + The Wake-on-LAN policy to set for the device. Takes the special value + off which disables Wake-on-LAN, or space separated list of the following + words: + + + + + + Wake on PHY activity. + + + + + + Wake on unicast messages. + + + + + + Wake on multicast messages. + + + + + + Wake on broadcast messages. + + + + + + Wake on ARP. + + + + + + Wake on receipt of a magic packet. + + + + + + + Enable SecureOn password for MagicPacket. Implied when + WakeOnLanPassword= is specified. If specified without + WakeOnLanPassword= option, then the password is read from the + credential LINK.link.wol.password (e.g., + 60-foo.link.wol.password), and if the credential not found, then + read from wol.password. See + LoadCredential=/SetCredential= in + systemd.exec1 + for details. The password in the credential, must be 6 bytes in hex format with each + byte separated by a colon (:) like an Ethernet MAC address, e.g., + aa:bb:cc:dd:ee:ff. + + + + + Defaults to unset, and the device's default will be used. This setting can be specified + multiple times. If an empty string is assigned, then the all previous assignments are + cleared. + + + + WakeOnLanPassword= + + Specifies the SecureOn password for MagicPacket. Takes an absolute path to a regular + file or an AF_UNIX stream socket, or the plain password. When a path to + a regular file is specified, the password is read from it. When an + AF_UNIX stream socket is specified, a connection is made to it and the + password is read from it. The password must be 6 bytes in hex format with each byte separated + by a colon (:) like an Ethernet MAC address, e.g., + aa:bb:cc:dd:ee:ff. This implies WakeOnLan=secureon. + Defaults to unset, and the current value will not be changed. + + + + Port= + + The port option is used to select the device port. The + supported values are: + + + + + + An Ethernet interface using Twisted-Pair cable as the medium. + + + + + + Attachment Unit Interface (AUI). Normally used with hubs. + + + + + + + An Ethernet interface using BNC connectors and co-axial cable. + + + + + + An Ethernet interface using a Media Independent Interface (MII). + + + + + + An Ethernet interface using Optical Fibre as the medium. + + + + + + + Advertise= + + This sets what speeds and duplex modes of operation are advertised for auto-negotiation. + This implies AutoNegotiation=yes. The supported values are: + + + Supported advertise values + + + + + + + Advertise + Speed (Mbps) + Duplex Mode + + + + 10half + + + 10full + + + 100half + + + 100full + + + 1000half + + + 1000full + + + 10000full + + + 2500full + + + 1000full + + + 10000full + + + 10000full + + + 10000full + + + 20000full + + + 20000full + + +
+ + By default this is unset, i.e. all possible modes will be advertised. + This option may be specified more than once, in which case all specified speeds and modes are advertised. + If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect. + + + + + ReceiveChecksumOffload= + + Takes a boolean. If set to true, hardware offload for checksumming of ingress + network packets is enabled. When unset, the kernel's default will be used. + + + + TransmitChecksumOffload= + + Takes a boolean. If set to true, hardware offload for checksumming of egress + network packets is enabled. When unset, the kernel's default will be used. + + + + TCPSegmentationOffload= + + Takes a boolean. If set to true, TCP Segmentation Offload (TSO) is enabled. + When unset, the kernel's default will be used. + + + + TCP6SegmentationOffload= + + Takes a boolean. If set to true, TCP6 Segmentation Offload (tx-tcp6-segmentation) is enabled. + When unset, the kernel's default will be used. + + + + GenericSegmentationOffload= + + Takes a boolean. If set to true, Generic Segmentation Offload (GSO) is enabled. + When unset, the kernel's default will be used. + + + + GenericReceiveOffload= + + Takes a boolean. If set to true, Generic Receive Offload (GRO) is enabled. + When unset, the kernel's default will be used. + + + + GenericReceiveOffloadHardware= + + Takes a boolean. If set to true, hardware accelerated Generic Receive Offload (GRO) is + enabled. When unset, the kernel's default will be used. + + + + LargeReceiveOffload= + + Takes a boolean. If set to true, Large Receive Offload (LRO) is enabled. + When unset, the kernel's default will be used. + + + + ReceiveVLANCTAGHardwareAcceleration= + + Takes a boolean. If set to true, receive VLAN CTAG hardware acceleration is enabled. + When unset, the kernel's default will be used. + + + + TransmitVLANCTAGHardwareAcceleration= + + Takes a boolean. If set to true, transmit VLAN CTAG hardware acceleration is enabled. + When unset, the kernel's default will be used. + + + + ReceiveVLANCTAGFilter= + + Takes a boolean. If set to true, receive filtering on VLAN CTAGs is enabled. + When unset, the kernel's default will be used. + + + + TransmitVLANSTAGHardwareAcceleration= + + Takes a boolean. If set to true, transmit VLAN STAG hardware acceleration is enabled. + When unset, the kernel's default will be used. + + + + NTupleFilter= + + Takes a boolean. If set to true, receive N-tuple filters and actions are enabled. + When unset, the kernel's default will be used. + + + + RxChannels= + TxChannels= + OtherChannels= + CombinedChannels= + + Specifies the number of receive, transmit, other, or combined channels, respectively. + Takes an unsigned integer in the range 1…4294967295 or max. If set to + max, the advertised maximum value of the hardware will be used. When + unset, the number will not be changed. Defaults to unset. + + + + RxBufferSize= + RxMiniBufferSize= + RxJumboBufferSize= + TxBufferSize= + + Specifies the maximum number of pending packets in the NIC receive buffer, mini receive + buffer, jumbo receive buffer, or transmit buffer, respectively. Takes an unsigned integer in + the range 1…4294967295 or max. If set to max, the + advertised maximum value of the hardware will be used. When unset, the number will not be + changed. Defaults to unset. + + + + RxFlowControl= + + Takes a boolean. When set, enables receive flow control, also known as the ethernet + receive PAUSE message (generate and send ethernet PAUSE frames). When unset, the kernel's + default will be used. + + + + TxFlowControl= + + Takes a boolean. When set, enables transmit flow control, also known as the ethernet + transmit PAUSE message (respond to received ethernet PAUSE frames). When unset, the kernel's + default will be used. + + + + AutoNegotiationFlowControl= + + Takes a boolean. When set, auto negotiation enables the interface to exchange state + advertisements with the connected peer so that the two devices can agree on the ethernet + PAUSE configuration. When unset, the kernel's default will be used. + + + + GenericSegmentOffloadMaxBytes= + + Specifies the maximum size of a Generic Segment Offload (GSO) packet the + device should accept. The usual suffixes K, M, G are supported and are + understood to the base of 1024. An unsigned integer in the range 1…65536. + Defaults to unset. + + + + GenericSegmentOffloadMaxSegments= + + Specifies the maximum number of Generic Segment Offload (GSO) segments the device should + accept. An unsigned integer in the range 1…65535. Defaults to unset. + + + + UseAdaptiveRxCoalesce= + UseAdaptiveTxCoalesce= + + Boolean properties that, when set, enable/disable adaptive Rx/Tx coalescing if the hardware + supports it. When unset, the kernel's default will be used. + + + + RxCoalesceSec= + RxCoalesceIrqSec= + RxCoalesceLowSec= + RxCoalesceHighSec= + TxCoalesceSec= + TxCoalesceIrqSec= + TxCoalesceLowSec= + TxCoalesceHighSec= + + These properties configure the delay before Rx/Tx interrupts are generated after a packet is + sent/received. The Irq properties come into effect when the host is servicing an + IRQ. The Low and High properties come into effect when the + packet rate drops below the low packet rate threshold or exceeds the high packet rate threshold + respectively if adaptive Rx/Tx coalescing is enabled. When unset, the kernel's defaults will be + used. + + + + RxMaxCoalescedFrames= + RxMaxCoalescedIrqFrames= + RxMaxCoalescedLowFrames= + RxMaxCoalescedHighFrames= + TxMaxCoalescedFrames= + TxMaxCoalescedIrqFrames= + TxMaxCoalescedLowFrames= + TxMaxCoalescedHighFrames= + + These properties configure the maximum number of frames that are sent/received before a Rx/Tx + interrupt is generated. The Irq properties come into effect when the host is + servicing an IRQ. The Low and High properties come into + effect when the packet rate drops below the low packet rate threshold or exceeds the high packet + rate threshold respectively if adaptive Rx/Tx coalescing is enabled. When unset, the kernel's + defaults will be used. + + + + CoalescePacketRateLow= + CoalescePacketRateHigh= + + These properties configure the low and high packet rate (expressed in packets per second) + threshold respectively and are used to determine when the corresponding coalescing settings for low + and high packet rates come into effect if adaptive Rx/Tx coalescing is enabled. If unset, the + kernel's defaults will be used. + + + + CoalescePacketRateSampleIntervalSec= + + Configures how often to sample the packet rate used for adaptive Rx/Tx coalescing. This + property cannot be zero. This lowest time granularity supported by this property is seconds. + Partial seconds will be rounded up before being passed to the kernel. If unset, the kernel's + default will be used. + + + + StatisticsBlockCoalesceSec= + + How long to delay driver in-memory statistics block updates. If the driver does not have an + in-memory statistic block, this property is ignored. This property cannot be zero. If unset, the + kernel's default will be used. + + + + + MDI= + + Specifies the medium dependent interface (MDI) mode for the interface. A MDI describes + the interface from a physical layer implementation to the physical medium used to carry the + transmission. Takes one of the following words: straight (or equivalently: + mdi), crossover (or equivalently: + mdi-x, mdix), and auto. When + straight, the MDI straight through mode will be used. When + crossover, the MDI crossover (MDI-X) mode will be used. When + auto, the MDI status is automatically detected. Defaults to unset, and the + kernel's default will be used. + + + + + SR-IOVVirtualFunctions= + + Specifies the number of SR-IOV virtual functions. Takes an integer in the range + 0…2147483647. Defaults to unset, and automatically determined from the values specified in + the VirtualFunction= settings in the [SR-IOV] sections. + + + + + + + + [SR-IOV] Section Options + The [SR-IOV] section accepts the following keys. Specify several [SR-IOV] sections to + configure several SR-IOVs. SR-IOV provides the ability to partition a single physical PCI resource + into virtual PCI functions which can then be injected into a VM. In the case of network VFs, SR-IOV + improves north-south network performance (that is, traffic with endpoints outside the host machine) + by allowing traffic to bypass the host machine’s network stack. + + + + VirtualFunction= + + Specifies a Virtual Function (VF), lightweight PCIe function designed solely to move + data in and out. Takes an integer in the range 0…2147483646. This option is compulsory. + + + + + + VLANId= + + Specifies VLAN ID of the virtual function. Takes an integer in the range 1…4095. + + + + + QualityOfService= + + Specifies quality of service of the virtual function. Takes an integer in the range + 1…4294967294. + + + + + VLANProtocol= + + Specifies VLAN protocol of the virtual function. Takes 802.1Q or + 802.1ad. + + + + + MACSpoofCheck= + + Takes a boolean. Controls the MAC spoof checking. When unset, the kernel's default will + be used. + + + + + QueryReceiveSideScaling= + + Takes a boolean. Toggle the ability of querying the receive side scaling (RSS) + configuration of the virtual function (VF). The VF RSS information like RSS hash key may be + considered sensitive on some devices where this information is shared between VF and the + physical function (PF). When unset, the kernel's default will be used. + + + + + Trust= + + Takes a boolean. Allows one to set trust mode of the virtual function (VF). When set, + VF users can set a specific feature which may impact security and/or performance. When unset, + the kernel's default will be used. + + + + + LinkState= + + Allows one to set the link state of the virtual function (VF). Takes a boolean or a + special value auto. Setting to auto means a + reflection of the physical function (PF) link state, yes lets the VF to + communicate with other VFs on this host even if the PF link state is down, + no causes the hardware to drop any packets sent by the VF. When unset, + the kernel's default will be used. + + + + + MACAddress= + + Specifies the MAC address for the virtual function. + + + + + + + Examples + + + /usr/lib/systemd/network/99-default.link + + The link file 99-default.link that is + shipped with systemd defines the default naming policy for + links. + + [Link] +NamePolicy=kernel database onboard slot path +MACAddressPolicy=persistent + + + + /etc/systemd/network/10-dmz.link + + This example assigns the fixed name dmz0 to the interface with the MAC address + 00:a0:de:63:7a:e6: + + [Match] +MACAddress=00:a0:de:63:7a:e6 + +[Link] +Name=dmz0 + + NamePolicy= is not set, so Name= takes effect. We use the + 10- prefix to order this file early in the list. Note that it needs to be before + 99-link, i.e. it needs a numerical prefix, to have any effect at all. + + + + Debugging <varname>NamePolicy=</varname> assignments + + $ sudo SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/hub0 +… +Parsed configuration file /usr/lib/systemd/network/99-default.link +Parsed configuration file /etc/systemd/network/10-eth0.link +ID_NET_DRIVER=cdc_ether +Config file /etc/systemd/network/10-eth0.link applies to device hub0 +link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. +hub0: Device has name_assign_type=4 +Using default interface naming scheme 'v240'. +hub0: Policies didn't yield a name, using specified Name=hub0. +ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link +ID_NET_NAME=hub0 +… + + Explicit Name= configuration wins in this case. + + sudo SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/enp0s31f6 +… +Parsed configuration file /usr/lib/systemd/network/99-default.link +Parsed configuration file /etc/systemd/network/10-eth0.link +Created link configuration context. +ID_NET_DRIVER=e1000e +Config file /usr/lib/systemd/network/99-default.link applies to device enp0s31f6 +link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. +enp0s31f6: Device has name_assign_type=4 +Using default interface naming scheme 'v240'. +enp0s31f6: Policy *keep*: keeping existing userspace name +enp0s31f6: Device has addr_assign_type=0 +enp0s31f6: MAC on the device already matches policy *persistent* +ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link +… + + + In this case, the interface was already renamed, so the policy specified as + the first option in 99-default.link means that the existing name is + preserved. If was removed, or if were in boot before the renaming has happened, + we might get the following instead: + + enp0s31f6: Policy *path* yields "enp0s31f6". +enp0s31f6: Device has addr_assign_type=0 +enp0s31f6: MAC on the device already matches policy *persistent* +ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link +ID_NET_NAME=enp0s31f6 +… + + + Please note that the details of output are subject to change. + + + + /etc/systemd/network/10-internet.link + + This example assigns the fixed name + internet0 to the interface with the device + path pci-0000:00:1a.0-*: + + [Match] +Path=pci-0000:00:1a.0-* + +[Link] +Name=internet0 + + + + /etc/systemd/network/25-wireless.link + + Here's an overly complex example that shows the use of a large number of [Match] and [Link] settings. + + [Match] +MACAddress=12:34:56:78:9a:bc +Driver=brcmsmac +Path=pci-0000:02:00.0-* +Type=wlan +Virtualization=no +Host=my-laptop +Architecture=x86-64 + +[Link] +Name=wireless0 +MTUBytes=1450 +BitsPerSecond=10M +WakeOnLan=magic +MACAddress=cb:a9:87:65:43:21 + + + + + See Also + + + systemd-udevd.service8 + , + + udevadm8 + , + + systemd.netdev5 + , + + systemd.network5 + , + + systemd-network-generator.service8 + + + + + diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml new file mode 100644 index 0000000..da6ade8 --- /dev/null +++ b/man/systemd.mount.xml @@ -0,0 +1,599 @@ + + + + + + + systemd.mount + systemd + + + + systemd.mount + 5 + + + + systemd.mount + Mount unit configuration + + + + mount.mount + + + + Description + + A unit configuration file whose name ends in + .mount encodes information about a file system + mount point controlled and supervised by systemd. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The mount specific configuration options are + configured in the [Mount] section. + + Additional options are listed in + systemd.exec5, + which define the execution environment the + mount8 + program is executed in, and in + systemd.kill5, + which define the way the processes are terminated, and in + systemd.resource-control5, + which configure resource control settings for the processes of the + service. + + Note that the options User= and + Group= are not useful for mount units. + systemd passes two parameters to + mount8; + the values of What= and Where=. + When invoked in this way, + mount8 + does not read any options from /etc/fstab, and + must be run as UID 0. + + Mount units must be named after the mount point directories they control. Example: the mount point + /home/lennart must be configured in a unit file + home-lennart.mount. For details about the escaping logic used to convert a file + system path to a unit name, see + systemd.unit5. Note + that mount units cannot be templated, nor is possible to add multiple names to a mount unit by creating + symlinks to its unit file. + + Optionally, a mount unit may be accompanied by an automount + unit, to allow on-demand or parallelized mounting. See + systemd.automount5. + + Mount points created at runtime (independently of unit files + or /etc/fstab) will be monitored by systemd + and appear like any other mount unit in systemd. See + /proc/self/mountinfo description in + proc5. + + + Some file systems have special semantics as API file systems + for kernel-to-userspace and userspace-to-userspace interfaces. Some + of them may not be changed via mount units, and cannot be + disabled. For a longer discussion see API + File Systems. + + The + systemd-mount1 command + allows creating .mount and .automount units dynamically and + transiently from the command line. + + + + Automatic Dependencies + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + If a mount unit is beneath another mount unit in the file + system hierarchy, both a requirement dependency and an ordering + dependency between both units are created automatically. + + Block device backed file systems automatically gain + BindsTo= and After= type + dependencies on the device unit encapsulating the block + device (see below). + + If traditional file system quota is enabled for a mount + unit, automatic Wants= and + Before= dependencies on + systemd-quotacheck.service and + quotaon.service are added. + + Additional implicit dependencies may be added as result of + execution and resource control parameters as documented in + systemd.exec5 + and + systemd.resource-control5. + + + + + + Default Dependencies + + The following dependencies are added unless DefaultDependencies=no is set: + + + All mount units acquire automatic Before= and Conflicts= on + umount.target in order to be stopped during shutdown. + + Mount units referring to local file systems automatically gain + an After= dependency on local-fs-pre.target, and a + Before= dependency on local-fs.target unless + mount option is set. + + Network mount units + automatically acquire After= dependencies on remote-fs-pre.target, + network.target and network-online.target, and gain a + Before= dependency on remote-fs.target unless + mount option is set. Towards the latter a + Wants= unit is added as well. + + + Mount units referring to local and network file systems are distinguished by their file system type + specification. In some cases this is not sufficient (for example network block device based mounts, such as + iSCSI), in which case may be added to the mount option string of the unit, which forces + systemd to consider the mount unit a network mount. + + + + + <filename>fstab</filename> + + Mount units may either be configured via unit files, or via /etc/fstab (see + fstab5 + for details). Mounts listed in /etc/fstab will be converted into native units + dynamically at boot and when the configuration of the system manager is reloaded. In general, configuring + mount points through /etc/fstab is the preferred approach to manage mounts for + humans. For tooling, writing mount units should be preferred over editing /etc/fstab. + See systemd-fstab-generator8 + for details about the conversion from /etc/fstab to mount units. + + The NFS mount option for NFS background mounts + as documented in nfs5 + is detected by systemd-fstab-generator and the options + are transformed so that systemd fulfills the job-control implications of + that option. Specifically systemd-fstab-generator acts + as though x-systemd.mount-timeout=infinity,retry=10000 was + prepended to the option list, and fg,nofail was appended. + Depending on specific requirements, it may be appropriate to provide some of + these options explicitly, or to make use of the + x-systemd.automount option described below instead + of using bg. + + When reading /etc/fstab a few special + mount options are understood by systemd which influence how + dependencies are created for mount points. systemd will create a + dependency of type Wants= or + (see option + below), from either local-fs.target or + remote-fs.target, depending whether the file + system is local or remote. + + + + + + + Configures a Requires= and + an After= dependency between the created + mount unit and another systemd unit, such as a device or mount + unit. The argument should be a unit name, or an absolute path + to a device node or mount point. This option may be specified + more than once. This option is particularly useful for mount + point declarations that need an additional device to be around + (such as an external journal device for journal file systems) + or an additional mount to be in place (such as an overlay file + system that merges multiple mount points). See + After= and Requires= in + systemd.unit5 + for details. + + Note that this option always applies to the created mount unit + only regardless whether has been + specified. + + + + + + + In the created mount unit, configures a + Before= or After= + dependency on another systemd unit, such as a mount unit. + The argument should be a unit name or an absolute path + to a mount point. This option may be specified more than once. + This option is particularly useful for mount point declarations + with option that are mounted + asynchronously but need to be mounted before or after some unit + start, for example, before local-fs.target + unit. + See Before= and After= in + systemd.unit5 + for details. + + Note that these options always apply to the created mount unit + only regardless whether has been + specified. + + + + + + + In the created mount unit, configures a + WantedBy= or RequiredBy= + dependency on another unit. This option may be + specified more than once. If this is specified, the normal + automatic dependencies on the created mount unit, e.g., + local-fs.target, are not automatically + created. See WantedBy= and RequiredBy= in + systemd.unit5 + for details. + + + + + + Configures a + RequiresMountsFor= dependency between the + created mount unit and other mount units. The argument must be + an absolute path. This option may be specified more than once. + See RequiresMountsFor= in + systemd.unit5 + for details. + + + + + + The block device backed file system will be upgraded + to BindsTo= dependency. This option is only useful + when mounting file systems manually with + mount8 + as the default dependency in this case is Requires=. + This option is already implied by entries in /etc/fstab + or by mount units. + + + + + + + An automount unit will be created for the file + system. See + systemd.automount5 + for details. + + + + + + Configures the idle timeout of the + automount unit. See TimeoutIdleSec= in + systemd.automount5 + for details. + + + + + + Configure how long systemd should wait for a + device to show up before giving up on an entry from + /etc/fstab. Specify a time in seconds or + explicitly append a unit such as s, + min, h, + ms. + + Note that this option can only be used in + /etc/fstab, and will be + ignored when part of the Options= + setting in a unit file. + + + + + + + Configure how long systemd should wait for the + mount command to finish before giving up on an entry from + /etc/fstab. Specify a time in seconds or + explicitly append a unit such as s, + min, h, + ms. + + Note that this option can only be used in + /etc/fstab, and will be + ignored when part of the Options= + setting in a unit file. + + See TimeoutSec= below for + details. + + + + + + + The file system will be initialized + on the device. If the device is not "empty", i.e. it contains any signature, + the operation will be skipped. It is hence expected that this option + remains set even after the device has been initialized. + + Note that this option can only be used in + /etc/fstab, and will be ignored when part of the + Options= setting in a unit file. + + See + systemd-makefs@.service8. + + + wipefs8 + may be used to remove any signatures from a block device to force + to reinitialize the device. + + + + + + + The file system will be grown to occupy the full block + device. If the file system is already at maximum size, no action will + be performed. It is hence expected that this option remains set even after + the file system has been grown. Only certain file system types are supported, + see + systemd-makefs@.service8 + for details. + + Note that this option can only be used in + /etc/fstab, and will be ignored when part of the + Options= setting in a unit file. + + + + + + If a mount operation fails to mount the file system + read-write, it normally tries mounting the file system read-only instead. + This option disables that behaviour, and causes the mount to fail + immediately instead. This option is translated into the + ReadWriteOnly= setting in a unit file. + + + + + + + Normally the file system type is used to determine if a + mount is a "network mount", i.e. if it should only be started after the + network is available. Using this option overrides this detection and + specifies that the mount requires network. + + Network mount units are ordered between remote-fs-pre.target + and remote-fs.target, instead of + local-fs-pre.target and local-fs.target. + They also pull in network-online.target and are ordered after + it and network.target. + + + + + + + + With , the mount unit will not be added as a dependency for + local-fs.target or remote-fs.target. This means that it + will not be mounted automatically during boot, unless it is pulled in by some other unit. The + option has the opposite meaning and is the default. + + Note that if (see above) is used, neither + nor have any effect. The matching automount unit will + be added as a dependency to the appropriate target. + + + + + + + With , this mount will be only wanted, not required, by + local-fs.target or remote-fs.target. Moreover the mount unit is not + ordered before these target units. This means that the boot will continue without waiting for the mount unit + and regardless whether the mount point can be mounted successfully. + + + + + + + An additional filesystem to be mounted in the initrd. See + initrd-fs.target description in + systemd.special7. + + + + + If a mount point is configured in both + /etc/fstab and a unit file that is stored + below /usr/, the former will take precedence. + If the unit file is stored below /etc/, it + will take precedence. This means: native unit files take + precedence over traditional configuration files, but this is + superseded by the rule that configuration in + /etc/ will always take precedence over + configuration in /usr/. + + + + Options + + Mount unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + + + Mount unit files must include a [Mount] section, which carries + information about the file system mount points it supervises. A + number of options that may be used in this section are shared with + other unit types. These options are documented in + systemd.exec5 + and + systemd.kill5. + The options specific to the [Mount] section of mount units are the + following: + + + + + What= + Takes an absolute path of a device node, file or other resource to mount. See + mount8 for + details. If this refers to a device node, a dependency on the respective device unit is automatically + created. (See + systemd.device5 + for more information.) This option is mandatory. Note that the usual specifier expansion is applied + to this setting, literal percent characters should hence be written as %%. If this mount is a bind mount and the specified path does not exist + yet it is created as directory. + + + + Where= + Takes an absolute path of a file or directory for the mount point; in particular, the + destination cannot be a symbolic link. If the mount point does not exist at the time of mounting, it + is created as either a directory or a file. The former is the usual case; the latter is done only if this mount + is a bind mount and the source (What=) is not a directory. + This string must be reflected in the unit filename. (See above.) This option + is mandatory. + + + + Type= + Takes a string for the file system type. See + mount8 + for details. This setting is optional. + + + + Options= + + Mount options to use when mounting. This takes a comma-separated list of options. This setting + is optional. Note that the usual specifier expansion is applied to this setting, literal percent characters + should hence be written as %%. + + + + SloppyOptions= + + Takes a boolean argument. If true, parsing of + the options specified in Options= is + relaxed, and unknown mount options are tolerated. This + corresponds with + mount8's + -s switch. Defaults to + off. + + + + LazyUnmount= + + Takes a boolean argument. If true, detach the + filesystem from the filesystem hierarchy at time of the unmount + operation, and clean up all references to the filesystem as + soon as they are not busy anymore. + This corresponds with + umount8's + -l switch. Defaults to + off. + + + + ReadWriteOnly= + + Takes a boolean argument. If false, a mount + point that shall be mounted read-write but cannot be mounted + so is retried to be mounted read-only. If true the operation + will fail immediately after the read-write mount attempt did + not succeed. This corresponds with + mount8's + -w switch. Defaults to + off. + + + + ForceUnmount= + + Takes a boolean argument. If true, force an + unmount (in case of an unreachable NFS system). + This corresponds with + umount8's + -f switch. Defaults to + off. + + + + DirectoryMode= + Directories of mount points (and any parent + directories) are automatically created if needed. This option + specifies the file system access mode used when creating these + directories. Takes an access mode in octal notation. Defaults + to 0755. + + + + TimeoutSec= + Configures the time to wait for the mount + command to finish. If a command does not exit within the + configured time, the mount will be considered failed and be + shut down again. All commands still running will be terminated + forcibly via SIGTERM, and after another + delay of this time with SIGKILL. (See + in + systemd.kill5.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass 0 to disable the timeout logic. The + default value is set from DefaultTimeoutStartSec= option in + systemd-system.conf5. + + + + + + + + + See Also + + systemd1, + systemctl1, + systemd-system.conf5, + systemd.unit5, + systemd.exec5, + systemd.kill5, + systemd.resource-control5, + systemd.service5, + systemd.device5, + proc5, + mount8, + systemd-fstab-generator8, + systemd.directives7, + systemd-mount1 + + + + diff --git a/man/systemd.net-naming-scheme.xml b/man/systemd.net-naming-scheme.xml new file mode 100644 index 0000000..e0050e7 --- /dev/null +++ b/man/systemd.net-naming-scheme.xml @@ -0,0 +1,555 @@ + + + + + + + systemd.net-naming-scheme + systemd + + + + systemd.net-naming-scheme + 7 + + + + systemd.net-naming-scheme + Network device naming schemes + + + + Description + + Network interfaces names and MAC addresses may be generated based on certain stable interface + attributes. This is possible when there is enough information about the device to generate those + attributes and the use of this information is configured. This page describes interface naming, i.e. what + possible names may be generated. Those names are generated by the + systemd-udevd.service8 + builtin net_id and exported as udev properties + (ID_NET_NAME_ONBOARD=, ID_NET_LABEL_ONBOARD=, + ID_NET_NAME_PATH=, ID_NET_NAME_SLOT=). + + Names and MAC addresses are derived from various stable device metadata attributes. Newer versions + of udev take more of these attributes into account, improving (and thus possibly changing) the names and + addresses used for the same devices. Different versions of those generation rules are called "naming + schemes". The default naming scheme is chosen at compilation time. Usually this will be the latest + implemented version, but it is also possible to set one of the older versions to preserve + compatibility. This may be useful for example for distributions, which may introduce new versions of + systemd in stable releases without changing the naming scheme. The naming scheme may also be overridden + using the net.naming-scheme= kernel command line switch, see + systemd-udevd.service8. + Available naming schemes are described below. + + After the udev properties have been generated, appropriate udev rules may be used to actually rename + devices based on those properties. See the description of NamePolicy= and + MACAddressPolicy= in + systemd.link5. + + Note that while the concept of network interface naming schemes is primarily relevant in the + context of systemd-udevd.service, the + systemd-nspawn1 + container manager also takes it into account when naming network interfaces, see below. + + + + Policies + + All names start with a two-character prefix that signifies the interface type. + + + Two character prefixes based on the type of interface + + + + + Prefix + Description + + + + + en + Ethernet + + + ib + InfiniBand + + + sl + Serial line IP (slip) + + + wl + Wireless local area network (WLAN) + + + ww + Wireless wide area network (WWAN) + + + +
+ + The udev net_id builtin exports the following udev device properties: + + + + ID_NET_NAME_ONBOARD=prefixonumber + ID_NET_NAME_ONBOARD=prefixdnumber + + This name is set based on the numeric ordering information given by the firmware + for on-board devices. Different schemes are used depending on the firmware type, as described in the table below. + + + Onboard naming schemes + + + + + Format + Description + + + + + + prefixonumber + PCI onboard index + + + + prefixdnumber + Devicetree alias index + + + + +
+ + + + + ID_NET_LABEL_ONBOARD=prefix label + + This property is set based on textual label given by the firmware for on-board + devices. The name consists of the prefix concatenated with the label. This is only available for + PCI devices. + + + + + + ID_NET_NAME_MAC=prefixxAABBCCDDEEFF + + This name consists of the prefix, letter x, and 12 hexadecimal + digits of the MAC address. It is available if the device has a fixed MAC address. Because this name + is based on an attribute of the card itself, it remains "stable" when the device is moved (even + between machines), but will change when the hardware is replaced. + + + + + ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port] + ID_NET_NAME_SLOT=prefixvslot + ID_NET_NAME_SLOT=prefixxslot + ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]bnumber + ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]uport…[cconfig][iinterface] + ID_NET_NAME_SLOT=prefix[Pdomain]sslot[ffunction][nport_name|ddev_port]vslot + + This property describes the slot position. Different schemes are used depending on + the bus type, as described in the table below. In case of USB, BCMA, and SR-VIO devices, the full + name consists of the prefix, PCI slot identifier, and USB or BCMA or SR-VIO slot identifier. The + first two parts are denoted as "…" in the table below. + + + Slot naming schemes + + + + + Format + Description + + + + + + prefix [Pdomain] sslot [ffunction] [nport_name | ddev_port] + PCI slot number + + + + prefix vslot + VIO slot number (IBM PowerVM) + + + + prefix Xnumber + VIF interface number (Xen) + + + + … bnumber + Broadcom bus (BCMA) core number + + + + … uport… [cconfig] [iinterface] + USB port number chain + + + + … vslot + SR-VIO slot number + + + +
+ + The PCI domain is only prepended when it is not 0. All multi-function PCI devices will carry + the ffunction number in the device name, including + the function 0 device. For non-multi-function devices, the number is suppressed if 0. The port name + port_name is used, or the port number + ddev_port if the name is not known. + + For BCMA devices, the core number is suppressed when 0. + + For USB devices the full chain of port numbers of hubs is composed. If the name gets longer + than the maximum number of 15 characters, the name is not exported. The usual USB configuration + number 1 and interface number 0 values are suppressed. + + SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of + v and the virtual device number, with any leading zeros removed. The bus + number is ignored. + + In some configurations a parent PCI bridge of a given network controller may be associated + with a slot. In such case we don't generate this device property to avoid possible naming conflicts. + + + + + ID_NET_NAME_PATH=prefixcbus_id + ID_NET_NAME_PATH=prefixavendormodeliinstance + ID_NET_NAME_PATH=prefixiaddressnport_name + ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port] + ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port]bnumber + ID_NET_NAME_PATH=prefix[Pdomain]pbussslot[ffunction][nphys_port_name|ddev_port]uport…[cconfig][iinterface] + + This property describes the device installation location. Different schemes are + used depending on the bus type, as described in the table below. For BCMA and USB devices, PCI path + information must known, and the full name consists of the prefix, PCI slot identifier, and USB or + BCMA location. The first two parts are denoted as "…" in the table below. + + + Path naming schemes + + + + + Format + Description + + + + + + prefix cbus_id + CCW or grouped CCW device identifier + + + + prefix avendor model iinstance + ACPI path names for ARM64 platform devices + + + + prefix iaddress nport_name + Netdevsim (simulated networking device) device number and port name + + + + prefix [Pdomain] pbus sslot [ffunction] [nphys_port_name | ddev_port] + PCI geographical location + + + + … bnumber + Broadcom bus (BCMA) core number + + + + … uport… [cconfig] [iinterface] + USB port number chain + + + + +
+ + CCW and grouped CCW devices are found in IBM System Z mainframes. Any leading zeros and + dots are suppressed. + + For PCI, BCMA, and USB devices, the same rules as described above for slot naming are + used. + + + + + + + History + + The following "naming schemes" have been defined (which may be chosen at system boot-up time via + the net.naming-scheme= kernel command line switch, see above): + + + + v238 + + This is the naming scheme that was implemented in systemd 238. + + + + v239 + + Naming was changed for virtual network interfaces created with SR-IOV and NPAR and + for devices where the PCI network controller device does not have a slot number associated. + + SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of + vport, where port is the + virtual device number. Previously those virtual devices were named as if completely independent. + + + The ninth and later NPAR virtual devices are named following the scheme used for the first + eight NPAR partitions. Previously those devices were not renamed and the kernel default + ("ethN") was used. + + Names are also generated for PCI devices where the PCI network controller device does not + have an associated slot number itself, but one of its parents does. Previously those devices were + not renamed and the kernel default was used. + + + + + v240 + + The ib prefix and stable names for infiniband devices are + introduced. Previously those devices were not renamed. + + The ACPI index field (used in ID_NET_NAME_ONBOARD=) is now also used when + 0. + + A new naming policy NamePolicy=keep was introduced. With this policy, if + the network device name was already set by userspace, the device will not be renamed + again. Previously, this naming policy applied implicitly, and now it must be explicitly + requested. Effectively, this means that network devices will be renamed according to the + configuration, even if they have been renamed already, if keep is not + specified as the naming policy in the .link file. See + systemd.link5 + for a description of NamePolicy=. + + + + v241 + + was extended to set MAC addresses + based on the device name. Previously addresses were only based on the + ID_NET_NAME_* attributes, which meant that interface names would + never be generated for virtual devices. Now a persistent address will be generated for most + devices, including in particular bridges. + + Note: when userspace does not set a MAC address for a bridge device, the kernel will + initially assign a random address, and then change it when the first device is enslaved to the + bridge. With this naming policy change, bridges get a persistent MAC address based on the bridge + name instead of the first enslaved device. + + + + v243 + + Support for renaming netdevsim (simulated networking) devices was added. Previously + those devices were not renamed. + + Previously two-letter interface type prefix was prepended to + ID_NET_LABEL_ONBOARD=. This is not done anymore. + + + + v245 + + When + systemd-nspawn1 + derives the name for the host side of the network interface created with + from the container name it previously simply truncated the result + at 15 characters if longer (since that's the maximum length for network interface names). From now + on, for any interface name that would be longer than 15 characters the last 4 characters are set to + a 24bit hash value of the full interface name. This way network interface name collisions between + multiple similarly named containers (who only differ in container name suffix) should be less + likely (but still possible, since the 24bit hash value is very small). + + + + v247 + + When a PCI slot is associated with a PCI bridge that has multiple child network + controllers, the same value of the ID_NET_NAME_SLOT property might be derived + for those controllers. This would cause a naming conflict if the property is selected as the device + name. Now, we detect this situation and don't produce the ID_NET_NAME_SLOT + property. + + + + v249 + + PCI hotplug slot names for the s390 PCI driver are a hexadecimal representation + of the function_id device attribute. This attribute is now used to build the + ID_NET_NAME_SLOT. Before that, all slot names were parsed as decimal + numbers, which could either result in an incorrect value of the ID_NET_NAME_SLOT + property or none at all. + + Some firmware and hypervisor implementations report unreasonably high numbers for the onboard + index. To prevent the generation of bogus onbard interface names, index numbers greater than 16381 + (2¹⁴-1) were ignored. For s390 PCI devices index values up to 65535 (2¹⁶-1) are valid. To account + for that, the limit was increased to 65535. + + The udev rule NAME= replaces :, + /, and % with an underscore (_), and + refuses strings which contain only numerics. + + + + + v250 + + Added naming scheme for Xen netfront "vif" interfaces based on the guest side + VIF number set from the Xen config (or the interface index in AWS EC2). + + + + + v251 + + Since version v247 we no longer set + ID_NET_NAME_SLOT if we detect that a PCI device associated with a slot is a PCI + bridge as that would create naming conflict when there are more child devices on that bridge. Now, + this is relaxed and we will use slot information to generate the name based on it but only if + the PCI device has multiple functions. This is safe because distinct function number is a part of + the device name for multifunction devices. + + + + + v252 + + Added naming scheme for platform devices with devicetree aliases. + + + + + + Note that latest may be used to denote the latest scheme known (to this + particular version of systemd). + + + + Examples + + + Using <command>udevadm test-builtin</command> to display device properties + + $ udevadm test-builtin net_id /sys/class/net/enp0s31f6 +... +Using default interface naming scheme 'v243'. +ID_NET_NAMING_SCHEME=v243 +ID_NET_NAME_MAC=enx54ee75cb1dc0 +ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd. +ID_NET_NAME_PATH=enp0s31f6 +... + + + + PCI Ethernet card with firmware index "1" + + ID_NET_NAME_ONBOARD=eno1 +ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1 + + + + + PCI Ethernet card in hotplug slot with firmware index number + + # /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1 +ID_NET_NAME_MAC=enx000000000466 +ID_NET_NAME_PATH=enp5s0 +ID_NET_NAME_SLOT=ens1 + + + + PCI Ethernet multi-function card with 2 ports + + # /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0 +ID_NET_NAME_MAC=enx78e7d1ea46da +ID_NET_NAME_PATH=enp2s0f0 + +# /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1 +ID_NET_NAME_MAC=enx78e7d1ea46dc +ID_NET_NAME_PATH=enp2s0f1 + + + + PCI WLAN card + + # /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0 +ID_NET_NAME_MAC=wlx0024d7e31130 +ID_NET_NAME_PATH=wlp3s0 + + + + PCI IB host adapter with 2 ports + + # /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.0/net/ibp21s0f0 +ID_NET_NAME_PATH=ibp21s0f0 + +# /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.1/net/ibp21s0f1 +ID_NET_NAME_PATH=ibp21s0f1 + + + + USB built-in 3G modem + + # /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6 +ID_NET_NAME_MAC=wwx028037ec0200 +ID_NET_NAME_PATH=wwp0s29u1u4i6 + + + + USB Android phone + + # /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2 +ID_NET_NAME_MAC=enxd626b3450fb5 +ID_NET_NAME_PATH=enp0s29u1u2 + + + + s390 grouped CCW interface + + # /sys/devices/css0/0.0.0007/0.0.f5f0/group_device/net/encf5f0 +ID_NET_NAME_MAC=enx026d3c00000a +ID_NET_NAME_PATH=encf5f0 + + + + + See Also + + udev7, + udevadm8, + Predictable Network Interface Names, + systemd-nspawn1 + + + + diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml new file mode 100644 index 0000000..4505438 --- /dev/null +++ b/man/systemd.netdev.xml @@ -0,0 +1,2480 @@ + + + + + + + + systemd.network + systemd + + + + systemd.netdev + 5 + + + + systemd.netdev + Virtual Network Device configuration + + + + netdev.netdev + + + + Description + + A plain ini-style text file that encodes configuration about a virtual network device, used by + systemd-networkd8. + See systemd.syntax7 + for a general description of the syntax. + + The main Virtual Network Device file must have the extension .netdev; + other extensions are ignored. Virtual network devices are created as soon as networkd is + started. If a netdev with the specified name already exists, networkd will use that as-is rather + than create its own. Note that the settings of the pre-existing netdev will not be changed by + networkd. + + The .netdev files are read from the files located in the system network + directory /usr/lib/systemd/network and + /usr/local/lib/systemd/network, the volatile runtime network directory + /run/systemd/network and the local administration network directory + /etc/systemd/network. All configuration files are collectively sorted and + processed in alphanumeric order, regardless of the directories in which they live. However, files + with identical filenames replace each other. It is recommended that each filename is prefixed with + a number (e.g. 10-vlan.netdev). Otherwise, .netdev files + generated by + systemd-network-generator.service8 + may take precedence over user configured files. Files in /etc/ have the + highest priority, files in /run/ take precedence over files with the same name + in /usr/lib/. This can be used to override a system-supplied configuration + file with a local file if needed. As a special case, an empty file (file size 0) or symlink with + the same name pointing to /dev/null disables the configuration file entirely + (it is "masked"). + + Along with the netdev file foo.netdev, a "drop-in" directory + foo.netdev.d/ may exist. All files with the suffix .conf + from this directory will be merged in the alphanumeric order and parsed after the main file itself + has been parsed. This is useful to alter or add configuration settings, without having to modify + the main configuration file. Each drop-in file must have appropriate section headers. + + In addition to /etc/systemd/network, drop-in .d + directories can be placed in /usr/lib/systemd/network or + /run/systemd/network directories. Drop-in files in + /etc/ take precedence over those in /run/ which in turn + take precedence over those in /usr/lib/. Drop-in files under any of these + directories take precedence over the main netdev file wherever located. (Of course, since + /run/ is temporary and /usr/lib/ is for vendors, it is + unlikely drop-ins should be used in either of those places.) + + + + Supported netdev kinds + + The following kinds of virtual network devices may be + configured in .netdev files: + + + Supported kinds of virtual network devices + + + + + + Kind + Description + + + bond + A bond device is an aggregation of all its slave devices. See Linux Ethernet Bonding Driver HOWTO for details. + + bridge + A bridge device is a software switch, and each of its slave devices and the bridge itself are ports of the switch. + + dummy + A dummy device drops all packets sent to it. + + gre + A Level 3 GRE tunnel over IPv4. See RFC 2784 for details. Name gre0 should not be used, as the kernel creates a device with this name when the corresponding kernel module is loaded. + + gretap + A Level 2 GRE tunnel over IPv4. Name gretap0 should not be used, as the kernel creates a device with this name when the corresponding kernel module is loaded. + + erspan + ERSPAN mirrors traffic on one or more source ports and delivers the mirrored traffic to one or more destination ports on another switch. The traffic is encapsulated in generic routing encapsulation (GRE) and is therefore routable across a layer 3 network between the source switch and the destination switch. Name erspan0 should not be used, as the kernel creates a device with this name when the corresponding kernel module is loaded. + + ip6gre + A Level 3 GRE tunnel over IPv6. + + ip6tnl + An IPv4 or IPv6 tunnel over IPv6 + + ip6gretap + A Level 2 GRE tunnel over IPv6. + + ipip + An IPv4 over IPv4 tunnel. + + ipvlan + An IPVLAN device is a stacked device which receives packets from its underlying device based on IP address filtering. + + ipvtap + An IPVTAP device is a stacked device which receives packets from its underlying device based on IP address filtering and can be accessed using the tap user space interface. + + macvlan + A macvlan device is a stacked device which receives packets from its underlying device based on MAC address filtering. + + macvtap + A macvtap device is a stacked device which receives packets from its underlying device based on MAC address filtering. + + sit + An IPv6 over IPv4 tunnel. + + tap + A persistent Level 2 tunnel between a network device and a device node. + + tun + A persistent Level 3 tunnel between a network device and a device node. + + veth + An Ethernet tunnel between a pair of network devices. + + vlan + A VLAN is a stacked device which receives packets from its underlying device based on VLAN tagging. See IEEE 802.1Q for details. + + vti + An IPv4 over IPSec tunnel. + + vti6 + An IPv6 over IPSec tunnel. + + vxlan + A virtual extensible LAN (vxlan), for connecting Cloud computing deployments. + + geneve + A GEneric NEtwork Virtualization Encapsulation (GENEVE) netdev driver. + + l2tp + A Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It does not provide any encryption or confidentiality by itself + + macsec + Media Access Control Security (MACsec) is an 802.1AE IEEE industry-standard security technology that provides secure communication for all traffic on Ethernet links. MACsec provides point-to-point security on Ethernet links between directly connected nodes and is capable of identifying and preventing most security threats. + + vrf + A Virtual Routing and Forwarding (VRF) interface to create separate routing and forwarding domains. + + vcan + The virtual CAN driver (vcan). Similar to the network loopback devices, vcan offers a virtual local CAN interface. + + vxcan + The virtual CAN tunnel driver (vxcan). Similar to the virtual ethernet driver veth, vxcan implements a local CAN traffic tunnel between two virtual CAN network devices. When creating a vxcan, two vxcan devices are created as pair. When one end receives the packet it appears on its pair and vice versa. The vxcan can be used for cross namespace communication. + + + wireguard + WireGuard Secure Network Tunnel. + + nlmon + A Netlink monitor device. Use an nlmon device when you want to monitor system Netlink messages. + + fou + Foo-over-UDP tunneling. + + xfrm + A virtual tunnel interface like vti/vti6 but with several advantages. + + ifb + The Intermediate Functional Block (ifb) pseudo network interface acts as a QoS concentrator for multiple different sources of traffic. + + bareudp + Bare UDP tunnels provide a generic L3 encapsulation support for tunnelling different L3 protocols like MPLS, IP etc. inside of an UDP tunnel. + + batadv + B.A.T.M.A.N. Advanced is a routing protocol for multi-hop mobile ad-hoc networks which operates on layer 2. + + ipoib + An IP over Infiniband subinterface. + + wlan + A virtual wireless network (WLAN) interface. + + +
+ + + + + [Match] Section Options + + A virtual network device is only created if the [Match] section matches the current + environment, or if the section is empty. The following keys are accepted: + + + + + + + + + + + + + + [NetDev] Section Options + + The [NetDev] section accepts the + following keys: + + + + Description= + + A free-form description of the netdev. + + + + Name= + + The interface name used when creating the netdev. + This setting is compulsory. + + + + Kind= + + The netdev kind. This setting is compulsory. See the + Supported netdev kinds section for the + valid keys. + + + + MTUBytes= + + The maximum transmission unit in bytes to set for the device. The usual suffixes K, M, G + are supported and are understood to the base of 1024. For tun or + tap devices, MTUBytes= setting is not currently supported in + [NetDev] section. Please specify it in [Link] section of + corresponding + systemd.network5 + files. + + + + MACAddress= + + Specifies the MAC address to use for the device, or takes the special value + none. When none, systemd-networkd + does not request the MAC address for the device, and the kernel will assign a random MAC + address. For tun, tap, or l2tp + devices, the MACAddress= setting in the [NetDev] section is not + supported and will be ignored. Please specify it in the [Link] section of the corresponding + systemd.network5 + file. If this option is not set, vlan device inherits the MAC address of + the master interface. For other kind of netdevs, if this option is not set, then the MAC + address is generated based on the interface name and the + machine-id5. + + Note, even if none is specified, systemd-udevd + will assign the persistent MAC address for the device, as 99-default.link + has MACAddressPolicy=persistent. So, it is also necessary to create a + custom .link file for the device, if the MAC address assignment is not desired. + + + + + + + [Bridge] Section Options + + The [Bridge] section only applies for + netdevs of kind bridge, and accepts the + following keys: + + + + HelloTimeSec= + + HelloTimeSec specifies the number of seconds between two hello packets + sent out by the root bridge and the designated bridges. Hello packets are + used to communicate information about the topology throughout the entire + bridged local area network. + + + + MaxAgeSec= + + MaxAgeSec specifies the number of seconds of maximum message age. + If the last seen (received) hello packet is more than this number of + seconds old, the bridge in question will start the takeover procedure + in attempt to become the Root Bridge itself. + + + + ForwardDelaySec= + + ForwardDelaySec specifies the number of seconds spent in each + of the Listening and Learning states before the Forwarding state is entered. + + + + AgeingTimeSec= + + This specifies the number of seconds a MAC Address will be kept in + the forwarding database after having a packet received from this MAC Address. + + + + Priority= + + The priority of the bridge. An integer between 0 and 65535. A lower value + means higher priority. The bridge having the lowest priority will be elected as root bridge. + + + + GroupForwardMask= + + A 16-bit bitmask represented as an integer which allows forwarding of link + local frames with 802.1D reserved addresses (01:80:C2:00:00:0X). A logical AND + is performed between the specified bitmask and the exponentiation of 2^X, the + lower nibble of the last octet of the MAC address. For example, a value of 8 + would allow forwarding of frames addressed to 01:80:C2:00:00:03 (802.1X PAE). + + + + DefaultPVID= + + This specifies the default port VLAN ID of a newly attached bridge port. + Set this to an integer in the range 1…4094 or none to disable the PVID. + + + + MulticastQuerier= + + Takes a boolean. This setting controls the IFLA_BR_MCAST_QUERIER option in the kernel. + If enabled, the kernel will send general ICMP queries from a zero source address. + This feature should allow faster convergence on startup, but it causes some + multicast-aware switches to misbehave and disrupt forwarding of multicast packets. + When unset, the kernel's default will be used. + + + + + MulticastSnooping= + + Takes a boolean. This setting controls the IFLA_BR_MCAST_SNOOPING option in the kernel. + If enabled, IGMP snooping monitors the Internet Group Management Protocol (IGMP) traffic + between hosts and multicast routers. When unset, the kernel's default will be used. + + + + + VLANFiltering= + + Takes a boolean. This setting controls the IFLA_BR_VLAN_FILTERING option in the kernel. + If enabled, the bridge will be started in VLAN-filtering mode. When unset, the kernel's default will be used. + + + + + VLANProtocol= + + Allows setting the protocol used for VLAN filtering. Takes + or, + , and defaults to unset and kernel's default is used. + + + + + STP= + + Takes a boolean. This enables the bridge's Spanning Tree Protocol (STP). + When unset, the kernel's default will be used. + + + + + MulticastIGMPVersion= + + Allows changing bridge's multicast Internet Group Management Protocol (IGMP) version. + Takes an integer 2 or 3. When unset, the kernel's default will be used. + + + + + + + + [VLAN] Section Options + + The [VLAN] section only applies for + netdevs of kind vlan, and accepts the + following key: + + + + Id= + + The VLAN ID to use. An integer in the range 0…4094. + This setting is compulsory. + + + + Protocol= + + Allows setting the protocol used for the VLAN interface. Takes 802.1q or, + 802.1ad, and defaults to unset and kernel's default is used. + + + + GVRP= + + Takes a boolean. The Generic VLAN Registration Protocol (GVRP) is a protocol that + allows automatic learning of VLANs on a network. + When unset, the kernel's default will be used. + + + + + MVRP= + + Takes a boolean. Multiple VLAN Registration Protocol (MVRP) formerly known as GARP VLAN + Registration Protocol (GVRP) is a standards-based Layer 2 network protocol, + for automatic configuration of VLAN information on switches. It was defined + in the 802.1ak amendment to 802.1Q-2005. When unset, the kernel's default will be used. + + + + + LooseBinding= + + Takes a boolean. The VLAN loose binding mode, in which only the operational state is passed + from the parent to the associated VLANs, but the VLAN device state is not changed. + When unset, the kernel's default will be used. + + + + ReorderHeader= + + Takes a boolean. When enabled, the VLAN reorder header is used and VLAN interfaces behave + like physical interfaces. When unset, the kernel's default will be used. + + + + EgressQOSMaps= + IngressQOSMaps= + + Defines a mapping of Linux internal packet priority (SO_PRIORITY) + to VLAN header PCP field for outgoing and incoming frames, respectively. Takes a + whitespace-separated list of integer pairs, where each integer must be in the range + 1…4294967294, in the format from-to, e.g., + 21-7 45-5. Note that from must be greater than or equal + to to. When unset, the kernel's default will be used. + + + + + + + [MACVLAN] Section Options + + The [MACVLAN] section only applies for + netdevs of kind macvlan, and accepts the + following key: + + + + Mode= + + The MACVLAN mode to use. The supported options are + private, + vepa, + bridge, + passthru, and + source. + + + + + SourceMACAddress= + + A whitespace-separated list of remote hardware addresses allowed on the MACVLAN. This + option only has an effect in source mode. Use full colon-, hyphen- or dot-delimited + hexadecimal. This option may appear more than once, in which case the lists are merged. If + the empty string is assigned to this option, the list of hardware addresses defined prior + to this is reset. Defaults to unset. + + + + BroadcastMulticastQueueLength= + + Specifies the length of the receive queue for broadcast/multicast packets. An unsigned + integer in the range 0…4294967294. Defaults to unset. + + + + + + + [MACVTAP] Section Options + + The [MACVTAP] section applies for netdevs of kind macvtap and accepts the same + keys as [MACVLAN]. + + + + [IPVLAN] Section Options + + The [IPVLAN] section only applies for + netdevs of kind ipvlan, and accepts the + following key: + + + + Mode= + + The IPVLAN mode to use. The supported options are + L2,L3 and L3S. + + + + + Flags= + + The IPVLAN flags to use. The supported options are + bridge,private and vepa. + + + + + + + + [IPVTAP] Section Options + + The [IPVTAP] section only applies for netdevs of kind ipvtap and accepts the + same keys as [IPVLAN]. + + + + [VXLAN] Section Options + + The [VXLAN] section only applies for + netdevs of kind vxlan, and accepts the + following keys: + + + + VNI= + + The VXLAN Network Identifier (or VXLAN Segment ID). Takes a number in the range 1…16777215. + + + + Remote= + + Configures destination IP address. + + + + Local= + + Configures local IP address. It must be an address on the underlying interface of the + VXLAN interface, or one of the special values ipv4_link_local, + ipv6_link_local, dhcp4, dhcp6, and + slaac. If one of the special values is specified, an address which matches + the corresponding type on the underlying interface will be used. Defaults to unset. + + + + Group= + + Configures VXLAN multicast group IP address. All members of a VXLAN must use the same + multicast group address. + + + + TOS= + + The Type Of Service byte value for a vxlan interface. + + + + TTL= + + A fixed Time To Live N on Virtual eXtensible Local Area Network packets. + Takes inherit or a number in the range 0…255. 0 is a special + value meaning inherit the inner protocol's TTL value. inherit + means that it will inherit the outer protocol's TTL value. + + + + MacLearning= + + Takes a boolean. When true, enables dynamic MAC learning + to discover remote MAC addresses. + + + + FDBAgeingSec= + + The lifetime of Forwarding Database entry learnt by + the kernel, in seconds. + + + + MaximumFDBEntries= + + Configures maximum number of FDB entries. + + + + ReduceARPProxy= + + Takes a boolean. When true, bridge-connected VXLAN tunnel + endpoint answers ARP requests from the local bridge on behalf + of remote Distributed Overlay Virtual Ethernet + + (DOVE) clients. Defaults to false. + + + + L2MissNotification= + + Takes a boolean. When true, enables netlink LLADDR miss + notifications. + + + + L3MissNotification= + + Takes a boolean. When true, enables netlink IP address miss notifications. + + + + RouteShortCircuit= + + Takes a boolean. When true, route short circuiting is turned + on. + + + + UDPChecksum= + + Takes a boolean. When true, transmitting UDP checksums when doing VXLAN/IPv4 is turned on. + + + + UDP6ZeroChecksumTx= + + Takes a boolean. When true, sending zero checksums in VXLAN/IPv6 is turned on. + + + + UDP6ZeroChecksumRx= + + Takes a boolean. When true, receiving zero checksums in VXLAN/IPv6 is turned on. + + + + RemoteChecksumTx= + + Takes a boolean. When true, remote transmit checksum offload of VXLAN is turned on. + + + + RemoteChecksumRx= + + Takes a boolean. When true, remote receive checksum offload in VXLAN is turned on. + + + + GroupPolicyExtension= + + Takes a boolean. When true, it enables Group Policy VXLAN extension security label mechanism + across network peers based on VXLAN. For details about the Group Policy VXLAN, see the + + VXLAN Group Policy document. Defaults to false. + + + + GenericProtocolExtension= + + Takes a boolean. When true, Generic Protocol Extension extends the existing VXLAN protocol + to provide protocol typing, OAM, and versioning capabilities. For details about the VXLAN GPE + Header, see the + Generic Protocol Extension for VXLAN document. If destination port is not specified and + Generic Protocol Extension is set then default port of 4790 is used. Defaults to false. + + + + DestinationPort= + + Configures the default destination UDP port. If the destination port is not specified then + Linux kernel default will be used. Set to 4789 to get the IANA assigned value. + + + + PortRange= + + Configures the source port range for the VXLAN. The kernel assigns the source UDP port based + on the flow to help the receiver to do load balancing. When this option is not set, the normal + range of local UDP ports is used. + + + + FlowLabel= + + Specifies the flow label to use in outgoing packets. + The valid range is 0-1048575. + + + + + IPDoNotFragment= + + Allows setting the IPv4 Do not Fragment (DF) bit in outgoing packets, or to inherit its + value from the IPv4 inner header. Takes a boolean value, or inherit. Set + to inherit if the encapsulated protocol is IPv6. When unset, the kernel's + default will be used. + + + + Independent= + + Takes a boolean. When true, the vxlan interface is created without any underlying network + interface. Defaults to false, which means that a .network file that requests this VXLAN interface + using VXLAN= is required for the VXLAN to be created. + + + + + + + [GENEVE] Section Options + + The [GENEVE] section only applies for + netdevs of kind geneve, and accepts the + following keys: + + + + Id= + + Specifies the Virtual Network Identifier (VNI) to use, a number between 0 and 16777215. This + field is mandatory. + + + + Remote= + + Specifies the unicast destination IP address to use in outgoing packets. + + + + TOS= + + Specifies the TOS value to use in outgoing packets. Takes a number between 1 and 255. + + + + TTL= + + Accepts the same values as in the [VXLAN] section, except that when unset + or set to 0, the kernel's default will be used, meaning that packet TTL will be set from + /proc/sys/net/ipv4/ip_default_ttl. + + + + UDPChecksum= + + Takes a boolean. When true, specifies that UDP checksum is calculated for transmitted packets + over IPv4. + + + + UDP6ZeroChecksumTx= + + Takes a boolean. When true, skip UDP checksum calculation for transmitted packets over IPv6. + + + + UDP6ZeroChecksumRx= + + Takes a boolean. When true, allows incoming UDP packets over IPv6 with zero checksum field. + + + + DestinationPort= + + Specifies destination port. Defaults to 6081. If not set or assigned the empty string, the default + port of 6081 is used. + + + + FlowLabel= + + Specifies the flow label to use in outgoing packets. + + + + IPDoNotFragment= + + Accepts the same key as in [VXLAN] section. + + + + + + + [BareUDP] Section Options + + The [BareUDP] section only applies for + netdevs of kind bareudp, and accepts the + following keys: + + + + DestinationPort= + + Specifies the destination UDP port (in range 1…65535). This is mandatory. + + + + + EtherType= + + Specifies the L3 protocol. Takes one of ipv4, ipv6, mpls-uc + or mpls-mc. This is mandatory. + + + + + + + [L2TP] Section Options + + The [L2TP] section only applies for + netdevs of kind l2tp, and accepts the + following keys: + + + + TunnelId= + + Specifies the tunnel identifier. Takes an number in the range 1…4294967295. The value used + must match the PeerTunnelId= value being used at the peer. This setting is + compulsory. + + + + PeerTunnelId= + + Specifies the peer tunnel id. Takes a number in the range 1…4294967295. The value used must + match the TunnelId= value being used at the peer. This setting is compulsory. + + + + + Remote= + + Specifies the IP address of the remote peer. This setting is compulsory. + + + + Local= + + Specifies the IP address of a local interface. Takes an IP address, or the special + values auto, static, or dynamic. + Optionally a name of a local interface can be specified after @, e.g. + 192.168.0.1@eth0 or auto@eth0. When an address is + specified, then a local or specified interface must have the address, and the remote address + must be accessible through the local address. If auto, then one of the + addresses on a local or specified interface which is accessible to the remote address will be + used. Similarly, if static or dynamic is set, then one + of the static or dynamic addresses will be used. Defaults to auto. + + + + EncapsulationType= + + Specifies the encapsulation type of the tunnel. Takes one of udp or + ip. + + + + UDPSourcePort= + + Specifies the UDP source port to be used for the tunnel. When UDP encapsulation is selected + it's mandatory. Ignored when IP encapsulation is selected. + + + + UDPDestinationPort= + + Specifies destination port. When UDP encapsulation is selected it's mandatory. Ignored when IP + encapsulation is selected. + + + + UDPChecksum= + + Takes a boolean. When true, specifies that UDP checksum is calculated for transmitted packets + over IPv4. + + + + UDP6ZeroChecksumTx= + + Takes a boolean. When true, skip UDP checksum calculation for transmitted packets over IPv6. + + + + UDP6ZeroChecksumRx= + + Takes a boolean. When true, allows incoming UDP packets over IPv6 with zero checksum field. + + + + + + + [L2TPSession] Section Options + + The [L2TPSession] section only applies for + netdevs of kind l2tp, and accepts the + following keys: + + + Name= + + Specifies the name of the session. This setting is compulsory. + + + + SessionId= + + Specifies the session identifier. Takes an number in the range 1…4294967295. The value used + must match the SessionId= value being used at the peer. This setting is + compulsory. + + + + PeerSessionId= + + Specifies the peer session identifier. Takes an number in the range 1…4294967295. + The value used must match the PeerSessionId= value being used at the peer. + This setting is compulsory. + + + + Layer2SpecificHeader= + + Specifies layer2specific header type of the session. One of none or default. Defaults to default. + + + + + + + [MACsec] Section Options + + The [MACsec] section only applies for network devices of kind + macsec, and accepts the following keys: + + + + Port= + + Specifies the port to be used for the MACsec transmit channel. The port is used to make + secure channel identifier (SCI). Takes a value between 1 and 65535. Defaults to unset. + + + + + Encrypt= + + Takes a boolean. When true, enable encryption. Defaults to unset. + + + + + + + [MACsecReceiveChannel] Section Options + The [MACsecReceiveChannel] section only applies for network devices of + kind macsec, and accepts the following keys: + + + + Port= + + Specifies the port to be used for the MACsec receive channel. The port is used to make + secure channel identifier (SCI). Takes a value between 1 and 65535. This option is + compulsory, and is not set by default. + + + + MACAddress= + + Specifies the MAC address to be used for the MACsec receive channel. The MAC address + used to make secure channel identifier (SCI). This setting is compulsory, and is not set by + default. + + + + + + + [MACsecTransmitAssociation] Section Options + + The [MACsecTransmitAssociation] section only applies for network devices + of kind macsec, and accepts the following keys: + + + + PacketNumber= + + Specifies the packet number to be used for replay protection and the construction of + the initialization vector (along with the secure channel identifier [SCI]). Takes a value + between 1-4,294,967,295. Defaults to unset. + + + + + KeyId= + + Specifies the identification for the key. Takes a number between 0-255. This option + is compulsory, and is not set by default. + + + + Key= + + Specifies the encryption key used in the transmission channel. The same key must be + configured on the peer’s matching receive channel. This setting is compulsory, and is not set + by default. Takes a 128-bit key encoded in a hexadecimal string, for example + dffafc8d7b9a43d5b9a3dfbbf6a30c16. + + + + KeyFile= + + Takes an absolute path to a file which contains a 128-bit key encoded in a hexadecimal string, + which will be used in the transmission channel. When this option is specified, + Key= is ignored. Note that the file must be readable by the user + systemd-network, so it should be, e.g., owned by + root:systemd-network with a 0640 file mode. If the path + refers to an AF_UNIX stream socket in the file system a connection is made to + it and the key read from it. + + + + Activate= + + Takes a boolean. If enabled, then the security association is activated. Defaults to + unset. + + + + UseForEncoding= + + Takes a boolean. If enabled, then the security association is used for encoding. Only + one [MACsecTransmitAssociation] section can enable this option. When enabled, + Activate=yes is implied. Defaults to unset. + + + + + + + [MACsecReceiveAssociation] Section Options + + The [MACsecReceiveAssociation] section only applies for + network devices of kind macsec, and accepts the + following keys: + + + + Port= + + Accepts the same key as in [MACsecReceiveChannel] section. + + + + MACAddress= + + Accepts the same key as in [MACsecReceiveChannel] section. + + + + PacketNumber= + + Accepts the same key as in [MACsecTransmitAssociation] section. + + + + KeyId= + + Accepts the same key as in [MACsecTransmitAssociation] section. + + + + Key= + + Accepts the same key as in [MACsecTransmitAssociation] section. + + + + KeyFile= + + Accepts the same key as in [MACsecTransmitAssociation] section. + + + + Activate= + + Accepts the same key as in [MACsecTransmitAssociation] section. + + + + + + + [Tunnel] Section Options + + The [Tunnel] section only applies for + netdevs of kind + ipip, + sit, + gre, + gretap, + ip6gre, + ip6gretap, + vti, + vti6, + ip6tnl, and + erspan and accepts + the following keys: + + + + External= + + Takes a boolean value. When true, then the tunnel is externally controlled, which is + also known as collect metadata mode, and most settings below like Local= + or Remote= are ignored. This implies Independent=. + Defaults to false. + + + + Local= + + A static local address for tunneled packets. It must be an address on another interface + of this host, or one of the special values any, + ipv4_link_local, ipv6_link_local, + dhcp4, dhcp6, and slaac. If one + of the special values except for any is specified, an address which + matches the corresponding type on the underlying interface will be used. Defaults to + any. + + + + Remote= + + The remote endpoint of the tunnel. Takes an IP address or the special value + any. + + + + TOS= + + The Type Of Service byte value for a tunnel interface. + For details about the TOS, see the + Type of + Service in the Internet Protocol Suite document. + + + + + TTL= + + A fixed Time To Live N on tunneled packets. N is a + number in the range 1…255. 0 is a special value meaning that + packets inherit the TTL value. The default value for IPv4 + tunnels is 0 (inherit). The default value for IPv6 tunnels is + 64. + + + + DiscoverPathMTU= + + Takes a boolean. When true, enables Path MTU Discovery on + the tunnel. + + + + IPv6FlowLabel= + + Configures the 20-bit flow label (see + RFC 6437) field in the IPv6 header (see + RFC 2460), which is used by a node to label packets of a flow. + It is only used for IPv6 tunnels. + A flow label of zero is used to indicate packets that have + not been labeled. + It can be configured to a value in the range 0…0xFFFFF, or be + set to inherit, in which case the original flowlabel is used. + + + + CopyDSCP= + + Takes a boolean. When true, the Differentiated Service Code + Point (DSCP) field will be copied to the inner header from + outer header during the decapsulation of an IPv6 tunnel + packet. DSCP is a field in an IP packet that enables different + levels of service to be assigned to network traffic. + Defaults to no. + + + + + EncapsulationLimit= + + The Tunnel Encapsulation Limit option specifies how many additional + levels of encapsulation are permitted to be prepended to the packet. + For example, a Tunnel Encapsulation Limit option containing a limit + value of zero means that a packet carrying that option may not enter + another tunnel before exiting the current tunnel. + (see RFC 2473). + The valid range is 0…255 and none. Defaults to 4. + + + + + Key= + + The Key= parameter specifies the same key to use in + both directions (InputKey= and OutputKey=). + The Key= is either a number or an IPv4 address-like dotted quad. + It is used as mark-configured SAD/SPD entry as part of the lookup key (both in data + and control path) in IP XFRM (framework used to implement IPsec protocol). + See + ip-xfrm — transform configuration for details. It is only used for VTI/VTI6, + GRE, GRETAP, and ERSPAN tunnels. + + + + InputKey= + + The InputKey= parameter specifies the key to use for input. + The format is same as Key=. It is only used for VTI/VTI6, GRE, GRETAP, + and ERSPAN tunnels. + + + + OutputKey= + + The OutputKey= parameter specifies the key to use for output. + The format is same as Key=. It is only used for VTI/VTI6, GRE, GRETAP, + and ERSPAN tunnels. + + + + Mode= + + An ip6tnl tunnel can be in one of three + modes + ip6ip6 for IPv6 over IPv6, + ipip6 for IPv4 over IPv6 or + any for either. + + + + + Independent= + + Takes a boolean. When false (the default), the tunnel is always created over some network + device, and a .network file that requests this tunnel using Tunnel= is required + for the tunnel to be created. When true, the tunnel is created independently of any network as + "tunnel@NONE". + + + + AssignToLoopback= + + Takes a boolean. If set to yes, the loopback interface lo + is used as the underlying device of the tunnel interface. Defaults to no. + + + + AllowLocalRemote= + + Takes a boolean. When true allows tunnel traffic on ip6tnl devices where the remote endpoint is a local host address. + When unset, the kernel's default will be used. + + + + + FooOverUDP= + + Takes a boolean. Specifies whether FooOverUDP= tunnel is to be configured. + Defaults to false. This takes effects only for IPIP, SIT, GRE, and GRETAP tunnels. + For more detail information see + Foo over UDP + + + + FOUDestinationPort= + + This setting specifies the UDP destination port for encapsulation. + This field is mandatory when FooOverUDP=yes, and is not set by default. + + + + FOUSourcePort= + + This setting specifies the UDP source port for encapsulation. Defaults to 0 + — that is, the source port for packets is left to the network stack to decide. + + + + Encapsulation= + + Accepts the same key as in the [FooOverUDP] section. + + + + IPv6RapidDeploymentPrefix= + + Reconfigure the tunnel for IPv6 Rapid + Deployment, also known as 6rd. The value is an ISP-specific IPv6 prefix with a non-zero length. Only + applicable to SIT tunnels. + + + + ISATAP= + + Takes a boolean. If set, configures the tunnel as Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) tunnel. + Only applicable to SIT tunnels. When unset, the kernel's default will be used. + + + + SerializeTunneledPackets= + + Takes a boolean. If set to yes, then packets are serialized. Only applies for GRE, + GRETAP, and ERSPAN tunnels. When unset, the kernel's default will be used. + + + + + ERSPANVersion= + + Specifies the ERSPAN version number. Takes 0 for version 0 (a.k.a. type I), 1 for version 1 + (a.k.a. type II), or 2 for version 2 (a.k.a. type III). Defaults to 1. + + + + ERSPANIndex= + + Specifies the ERSPAN v1 index field for the interface. Takes an integer in the range + 0…1048575, which is associated with the ERSPAN traffic's source port and direction. Only used when + ERSPANVersion=1. Defaults to 0. + + + + ERSPANDirection= + + Specifies the ERSPAN v2 mirrored traffic's direction. Takes ingress or + egress. Only used when ERSPANVersion=2. Defaults to + ingress. + + + + ERSPANHardwareId= + + Specifies an unique identifier of the ERSPAN v2 engine. Takes an integer in the range 0…63. + Only used when ERSPANVersion=2. Defaults to 0. + + + + + + + [FooOverUDP] Section Options + + The [FooOverUDP] section only applies for + netdevs of kind fou and accepts the + following keys: + + + + Encapsulation= + + Specifies the encapsulation mechanism used to store networking packets of various protocols + inside the UDP packets. Supports the following values: + + FooOverUDP provides the simplest no-frills model of UDP encapsulation, it simply + encapsulates packets directly in the UDP payload. GenericUDPEncapsulation is a + generic and extensible encapsulation, it allows encapsulation of packets for any IP protocol and + optional data as part of the encapsulation. For more detailed information see Generic UDP Encapsulation. Defaults to + FooOverUDP. + + + + + Port= + + Specifies the port number where the encapsulated packets will arrive. Those packets will be + removed and manually fed back into the network stack with the encapsulation removed to be sent to + the real destination. This option is mandatory. + + + + PeerPort= + + Specifies the peer port number. Defaults to unset. Note that when peer port is set + Peer= address is mandatory. + + + + Protocol= + + The Protocol= specifies the protocol number of the packets arriving + at the UDP port. When Encapsulation=FooOverUDP, this field is mandatory + and is not set by default. Takes an IP protocol name such as gre or + ipip, or an integer within the range 1…255. When + Encapsulation=GenericUDPEncapsulation, this must not be specified. + + + + Peer= + + Configures peer IP address. Note that when peer address is set PeerPort= + is mandatory. + + + + Local= + + Configures local IP address. + + + + + + + [Peer] Section Options + + The [Peer] section only applies for + netdevs of kind veth and accepts the + following keys: + + + + Name= + + The interface name used when creating the netdev. + This setting is compulsory. + + + + MACAddress= + + The peer MACAddress, if not set, it is generated in + the same way as the MAC address of the main + interface. + + + + + + + [VXCAN] Section Options + + The [VXCAN] section only applies for + netdevs of kind vxcan and accepts the + following key: + + + + Peer= + + The peer interface name used when creating the netdev. + This setting is compulsory. + + + + + + + [Tun] Section Options + + The [Tun] section only applies for + netdevs of kind tun, and accepts the following + keys: + + + + MultiQueue= + Takes a boolean. Configures whether + to use multiple file descriptors (queues) to parallelize + packets sending and receiving. Defaults to + no. + + + + PacketInfo= + Takes a boolean. Configures whether + packets should be prepended with four extra bytes (two flag + bytes and two protocol bytes). If disabled, it indicates that + the packets will be pure IP packets. Defaults to + no. + + + + VNetHeader= + Takes a boolean. Configures + IFF_VNET_HDR flag for a tun or tap device. It allows sending + and receiving larger Generic Segmentation Offload (GSO) + packets. This may increase throughput significantly. + Defaults to + no. + + + + User= + User to grant access to the + /dev/net/tun device. + + + + Group= + Group to grant access to the + /dev/net/tun device. + + + + KeepCarrier= + + Takes a boolean. If enabled, to make the interface maintain its carrier status, the file + descriptor of the interface is kept open. This may be useful to keep the interface in running + state, for example while the backing process is temporarily shutdown. Defaults to + no. + + + + + + + [Tap] Section Options + + The [Tap] section only applies for + netdevs of kind tap, and accepts the same keys + as the [Tun] section. + + + + [WireGuard] Section Options + + The [WireGuard] section accepts the following + keys: + + + + PrivateKey= + + The Base64 encoded private key for the interface. It can be + generated using the wg genkey command + (see wg8). + This option or PrivateKeyFile= is mandatory to use WireGuard. + Note that because this information is secret, you may want to set + the permissions of the .netdev file to be owned by root:systemd-network + with a 0640 file mode. + + + + PrivateKeyFile= + + Takes an absolute path to a file which contains the Base64 encoded private key for the + interface. When this option is specified, then PrivateKey= is ignored. Note + that the file must be readable by the user systemd-network, so it should be, + e.g., owned by root:systemd-network with a 0640 file mode. If + the path refers to an AF_UNIX stream socket in the file system a connection is + made to it and the key read from it. + + + + ListenPort= + + Sets UDP port for listening. Takes either value between 1 and 65535 + or auto. If auto is specified, + the port is automatically generated based on interface name. + Defaults to auto. + + + + FirewallMark= + + Sets a firewall mark on outgoing WireGuard packets from this interface. Takes a number between 1 and 4294967295. + + + + RouteTable= + + The table identifier for the routes to the addresses specified in the + AllowedIPs=. Takes a negative boolean value, one of the predefined names + default, main, and local, names + defined in RouteTable= in + networkd.conf5, + or a number in the range 1…4294967295. When off the routes to the + addresses specified in the AllowedIPs= setting will not be configured. + Defaults to false. This setting will be ignored when the same setting is specified in the + [WireGuardPeer] section. + + + + RouteMetric= + + The priority of the routes to the addresses specified in the + AllowedIPs=. Takes an integer in the range 0…4294967295. Defaults to 0 + for IPv4 addresses, and 1024 for IPv6 addresses. This setting will be ignored when the same + setting is specified in the [WireGuardPeer] section. + + + + + + + [WireGuardPeer] Section Options + + The [WireGuardPeer] section accepts the following + keys: + + + + PublicKey= + + Sets a Base64 encoded public key calculated by wg pubkey + (see wg8) + from a private key, and usually transmitted out of band to the + author of the configuration file. This option is mandatory for this + section. + + + + PresharedKey= + + Optional preshared key for the interface. It can be generated + by the wg genpsk command. This option adds an + additional layer of symmetric-key cryptography to be mixed into the + already existing public-key cryptography, for post-quantum + resistance. + Note that because this information is secret, you may want to set + the permissions of the .netdev file to be owned by root:systemd-network + with a 0640 file mode. + + + + PresharedKeyFile= + + Takes an absolute path to a file which contains the Base64 encoded preshared key for the + peer. When this option is specified, then PresharedKey= is ignored. Note that + the file must be readable by the user systemd-network, so it should be, e.g., + owned by root:systemd-network with a 0640 file mode. If the + path refers to an AF_UNIX stream socket in the file system a connection is + made to it and the key read from it. + + + + AllowedIPs= + + Sets a comma-separated list of IP (v4 or v6) addresses with CIDR masks + from which this peer is allowed to send incoming traffic and to + which outgoing traffic for this peer is directed. + + The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, + and ::/0 may be specified for matching all IPv6 addresses. + + Note that this only affects routing inside the network interface itself, + i.e. the packets that pass through the tunnel itself. To cause packets to be sent via the tunnel in + the first place, an appropriate route needs to be added as well — either in the + [Routes] section on the .network matching the wireguard + interface, or externally to systemd-networkd. + + + + Endpoint= + + Sets an endpoint IP address or hostname, followed by a colon, and then + a port number. IPv6 address must be in the square brackets. For example, + 111.222.333.444:51820 for IPv4 and [1111:2222::3333]:51820 + for IPv6 address. This endpoint will be updated automatically once to + the most recent source IP address and port of correctly + authenticated packets from the peer at configuration time. + + + + PersistentKeepalive= + + Sets a seconds interval, between 1 and 65535 inclusive, of how often + to send an authenticated empty packet to the peer for the purpose + of keeping a stateful firewall or NAT mapping valid persistently. + For example, if the interface very rarely sends traffic, but it + might at anytime receive traffic from a peer, and it is behind NAT, + the interface might benefit from having a persistent keepalive + interval of 25 seconds. If set to 0 or "off", this option is + disabled. By default or when unspecified, this option is off. + Most users will not need this. + + + + RouteTable= + + The table identifier for the routes to the addresses specified in the + AllowedIPs=. Takes a negative boolean value, one of the predefined names + default, main, and local, names + defined in RouteTable= in + networkd.conf5, + or a number in the range 1…4294967295. Defaults to unset, and the value specified in the + same setting in the [WireGuard] section will be used. + + + + RouteMetric= + + The priority of the routes to the addresses specified in the + AllowedIPs=. Takes an integer in the range 0…4294967295. Defaults to + unset, and the value specified in the same setting in the [WireGuard] section will be used. + + + + + + + + [Bond] Section Options + + The [Bond] section accepts the following + key: + + + + Mode= + + Specifies one of the bonding policies. The default is + balance-rr (round robin). Possible values are + balance-rr, + active-backup, + balance-xor, + broadcast, + 802.3ad, + balance-tlb, and + balance-alb. + + + + + + TransmitHashPolicy= + + Selects the transmit hash policy to use for slave + selection in balance-xor, 802.3ad, and tlb modes. Possible + values are + layer2, + layer3+4, + layer2+3, + encap2+3, and + encap3+4. + + + + + + LACPTransmitRate= + + Specifies the rate with which link partner transmits + Link Aggregation Control Protocol Data Unit packets in + 802.3ad mode. Possible values are slow, + which requests partner to transmit LACPDUs every 30 seconds, + and fast, which requests partner to + transmit LACPDUs every second. The default value is + slow. + + + + + MIIMonitorSec= + + Specifies the frequency that Media Independent + Interface link monitoring will occur. A value of zero + disables MII link monitoring. This value is rounded down to + the nearest millisecond. The default value is 0. + + + + + UpDelaySec= + + Specifies the delay before a link is enabled after a + link up status has been detected. This value is rounded down + to a multiple of MIIMonitorSec=. The default value is + 0. + + + + + DownDelaySec= + + Specifies the delay before a link is disabled after a + link down status has been detected. This value is rounded + down to a multiple of MIIMonitorSec=. The default value is + 0. + + + + + LearnPacketIntervalSec= + + Specifies the number of seconds between instances where the bonding + driver sends learning packets to each slave peer switch. + The valid range is 1…0x7fffffff; the default value is 1. This option + has an effect only for the balance-tlb and balance-alb modes. + + + + + AdSelect= + + Specifies the 802.3ad aggregation selection logic to use. Possible values are + stable, + bandwidth and + count. + + + + + + AdActorSystemPriority= + + Specifies the 802.3ad actor system priority. Takes a number in the range 1…65535. + + + + + AdUserPortKey= + + Specifies the 802.3ad user defined portion of the port key. Takes a number in the range + 0…1023. + + + + + AdActorSystem= + + Specifies the 802.3ad system MAC address. This cannot be a null or multicast address. + + + + + + FailOverMACPolicy= + + Specifies whether the active-backup mode should set all slaves to + the same MAC address at the time of enslavement or, when enabled, to perform special handling of the + bond's MAC address in accordance with the selected policy. The default policy is none. + Possible values are + none, + active and + follow. + + + + + + ARPValidate= + + Specifies whether or not ARP probes and replies should be + validated in any mode that supports ARP monitoring, or whether + non-ARP traffic should be filtered (disregarded) for link + monitoring purposes. Possible values are + none, + active, + backup and + all. + + + + + + ARPIntervalSec= + + Specifies the ARP link monitoring frequency. A value of 0 disables ARP monitoring. The + default value is 0, and the default unit seconds. + + + + + + ARPIPTargets= + + Specifies the IP addresses to use as ARP monitoring peers when + ARPIntervalSec= is greater than 0. These are the targets of the ARP + request sent to determine the health of the link to the targets. + Specify these values in IPv4 dotted decimal format. At least one IP + address must be given for ARP monitoring to function. The + maximum number of targets that can be specified is 16. The + default value is no IP addresses. + + + + + + ARPAllTargets= + + Specifies the quantity of ARPIPTargets= that must be reachable + in order for the ARP monitor to consider a slave as being up. + This option affects only active-backup mode for slaves with + ARPValidate enabled. Possible values are + any and + all. + + + + + + PrimaryReselectPolicy= + + Specifies the reselection policy for the primary slave. This + affects how the primary slave is chosen to become the active slave + when failure of the active slave or recovery of the primary slave + occurs. This option is designed to prevent flip-flopping between + the primary slave and other slaves. Possible values are + always, + better and + failure. + + + + + + ResendIGMP= + + Specifies the number of IGMP membership reports to be issued after + a failover event. One membership report is issued immediately after + the failover, subsequent packets are sent in each 200ms interval. + The valid range is 0…255. Defaults to 1. A value of 0 + prevents the IGMP membership report from being issued in response + to the failover event. + + + + + + PacketsPerSlave= + + Specify the number of packets to transmit through a slave before + moving to the next one. When set to 0, then a slave is chosen at + random. The valid range is 0…65535. Defaults to 1. This option + only has effect when in balance-rr mode. + + + + + + GratuitousARP= + + Specify the number of peer notifications (gratuitous ARPs and + unsolicited IPv6 Neighbor Advertisements) to be issued after a + failover event. As soon as the link is up on the new slave, + a peer notification is sent on the bonding device and each + VLAN sub-device. This is repeated at each link monitor interval + (ARPIntervalSec or MIIMonitorSec, whichever is active) if the number is + greater than 1. The valid range is 0…255. The default value is 1. + These options affect only the active-backup mode. + + + + + + AllSlavesActive= + + Takes a boolean. Specifies that duplicate frames (received on inactive ports) + should be dropped when false, or delivered when true. Normally, bonding will drop + duplicate frames (received on inactive ports), which is desirable for + most users. But there are some times it is nice to allow duplicate + frames to be delivered. The default value is false (drop duplicate frames + received on inactive ports). + + + + + + DynamicTransmitLoadBalancing= + + Takes a boolean. Specifies if dynamic shuffling of flows is enabled. Applies only + for balance-tlb mode. Defaults to unset. + + + + + + MinLinks= + + Specifies the minimum number of links that must be active before + asserting carrier. The default value is 0. + + + + + + For more detail information see + + Linux Ethernet Bonding Driver HOWTO + + + + [Xfrm] Section Options + + The [Xfrm] section accepts the following + keys: + + + + InterfaceId= + + Sets the ID/key of the xfrm interface which needs to be associated with a SA/policy. + Can be decimal or hexadecimal, valid range is 1-0xffffffff. This is mandatory. + + + + Independent= + + Takes a boolean. If false (the default), the xfrm interface must have an underlying device + which can be used for hardware offloading. + + + + + For more detail information see + Virtual XFRM Interfaces. + + + + [VRF] Section Options + The [VRF] section only applies for + netdevs of kind vrf and accepts the + following key: + + + + Table= + + The numeric routing table identifier. This setting is compulsory. + + + + + + + [BatmanAdvanced] Section Options + + The [BatmanAdvanced] section only applies for netdevs of kind batadv and accepts + the following keys: + + + + GatewayMode= + + Takes one of off, server, or client. + A batman-adv node can either run in server mode (sharing its internet + connection with the mesh) or in client mode (searching for the most suitable internet connection + in the mesh) or having the gateway support turned off entirely (which is the default setting). + + + + + Aggregation= + + Takes a boolean value. Enables or disables aggregation of originator messages. Defaults to + true. + + + + + BridgeLoopAvoidance= + + Takes a boolean value. Enables or disables avoidance of loops on bridges. Defaults to true. + + + + + DistributedArpTable= + + Takes a boolean value. Enables or disables the distributed ARP table. Defaults to true. + + + + Fragmentation= + + Takes a boolean value. Enables or disables fragmentation. Defaults to true. + + + + HopPenalty= + + The hop penalty setting allows one to modify + batctl8 + preference for multihop routes vs. short routes. This integer value is applied to the + TQ (Transmit Quality) of each forwarded OGM (Originator Message), thereby propagating the + cost of an extra hop (the packet has to be received and retransmitted which costs airtime). + A higher hop penalty will make it more unlikely that other nodes will choose this node as + intermediate hop towards any given destination. The default hop penalty of '15' is a reasonable + value for most setups and probably does not need to be changed. However, mobile nodes could + choose a value of 255 (maximum value) to avoid being chosen as a router by other nodes. + The minimum value is 0. + + + + + OriginatorIntervalSec= + + The value specifies the interval in seconds, unless another time unit is specified in which + batman-adv floods the network with its protocol information. + See systemd.time7 + for more information. + + + + GatewayBandwidthDown= + + If the node is a server, this + parameter is used to inform other nodes in the network about + this node's internet connection download bandwidth in bits per second. Just enter any number + suffixed with K, M, G or T (base 1000) and the batman-adv + module will propagate the entered value in the mesh. + + + + GatewayBandwidthUp= + + If the node is a server, this + parameter is used to inform other nodes in the network about + this node's internet connection upload bandwidth in bits per second. Just enter any number + suffixed with K, M, G or T (base 1000) and the batman-adv + module will propagate the entered value in the mesh. + + + + RoutingAlgorithm= + + This can be either batman-v or batman-iv and describes which routing_algo + of batctl8 to use. The algorithm + cannot be changed after interface creation. Defaults to batman-v. + + + + + + + + [IPoIB] Section Options + The [IPoIB] section only applies for netdevs of kind ipoib and accepts the + following keys: + + + + PartitionKey= + + Takes an integer in the range 1…0xffff, except for 0x8000. Defaults to unset, and the + kernel's default is used. + + + + + Mode= + + Takes one of the special values datagram or + connected. Defaults to unset, and the kernel's default is used. + + When datagram, the Infiniband unreliable datagram (UD) transport is + used, and so the interface MTU is equal to the IB L2 MTU minus the IPoIB encapsulation + header (4 bytes). For example, in a typical IB fabric with a 2K MTU, the IPoIB MTU will be + 2048 - 4 = 2044 bytes. + + When connected, the Infiniband reliable connected (RC) transport is + used. Connected mode takes advantage of the connected nature of the IB transport and allows + an MTU up to the maximal IP packet size of 64K, which reduces the number of IP packets needed + for handling large UDP datagrams, TCP segments, etc and increases the performance for large + messages. + + + + + IgnoreUserspaceMulticastGroup= + + Takes an boolean value. When true, the kernel ignores multicast groups handled by + userspace. Defaults to unset, and the kernel's default is used. + + + + + + + [WLAN] Section Options + The [WLAN] section only applies to WLAN interfaces, and accepts the following keys: + + + + PhysicalDevice= + + Specifies the name or index of the physical WLAN device (e.g. 0 or + phy0). The list of the physical WLAN devices that exist on the host can be + obtained by iw phy command. This option is mandatory. + + + + + Type= + + Specifies the type of the interface. Takes one of the ad-hoc, + station, ap, ap-vlan, + wds, monitor, mesh-point, + p2p-client, p2p-go, p2p-device, + ocb, and nan. This option is mandatory. + + + + + WDS= + + Enables the Wireless Distribution System (WDS) mode on the interface. The mode is also + known as the 4 address mode. Takes a boolean value. Defaults to unset, and + the kernel's default will be used. + + + + + + + Examples + + /etc/systemd/network/25-bridge.netdev + + [NetDev] +Name=bridge0 +Kind=bridge + + + + /etc/systemd/network/25-vlan1.netdev + + [Match] +Virtualization=no + +[NetDev] +Name=vlan1 +Kind=vlan + +[VLAN] +Id=1 + + + /etc/systemd/network/25-ipip.netdev + [NetDev] +Name=ipip-tun +Kind=ipip +MTUBytes=1480 + +[Tunnel] +Local=192.168.223.238 +Remote=192.169.224.239 +TTL=64 + + + /etc/systemd/network/1-fou-tunnel.netdev + [NetDev] +Name=fou-tun +Kind=fou + +[FooOverUDP] +Port=5555 +Protocol=4 + + + + /etc/systemd/network/25-fou-ipip.netdev + [NetDev] +Name=ipip-tun +Kind=ipip + +[Tunnel] +Independent=yes +Local=10.65.208.212 +Remote=10.65.208.211 +FooOverUDP=yes +FOUDestinationPort=5555 + + + + /etc/systemd/network/25-tap.netdev + [NetDev] +Name=tap-test +Kind=tap + +[Tap] +MultiQueue=yes +PacketInfo=yes + + + /etc/systemd/network/25-sit.netdev + [NetDev] +Name=sit-tun +Kind=sit +MTUBytes=1480 + +[Tunnel] +Local=10.65.223.238 +Remote=10.65.223.239 + + + + /etc/systemd/network/25-6rd.netdev + [NetDev] +Name=6rd-tun +Kind=sit +MTUBytes=1480 + +[Tunnel] +Local=10.65.223.238 +IPv6RapidDeploymentPrefix=2602::/24 + + + + /etc/systemd/network/25-gre.netdev + [NetDev] +Name=gre-tun +Kind=gre +MTUBytes=1480 + +[Tunnel] +Local=10.65.223.238 +Remote=10.65.223.239 + + + + /etc/systemd/network/25-ip6gre.netdev + [NetDev] +Name=ip6gre-tun +Kind=ip6gre + +[Tunnel] +Key=123 + + + + /etc/systemd/network/25-vti.netdev + + [NetDev] +Name=vti-tun +Kind=vti +MTUBytes=1480 + +[Tunnel] +Local=10.65.223.238 +Remote=10.65.223.239 + + + + /etc/systemd/network/25-veth.netdev + [NetDev] +Name=veth-test +Kind=veth + +[Peer] +Name=veth-peer + + + + /etc/systemd/network/25-bond.netdev + [NetDev] +Name=bond1 +Kind=bond + +[Bond] +Mode=802.3ad +TransmitHashPolicy=layer3+4 +MIIMonitorSec=1s +LACPTransmitRate=fast + + + + + /etc/systemd/network/25-dummy.netdev + [NetDev] +Name=dummy-test +Kind=dummy +MACAddress=12:34:56:78:9a:bc + + + /etc/systemd/network/25-vrf.netdev + Create a VRF interface with table 42. + [NetDev] +Name=vrf-test +Kind=vrf + +[VRF] +Table=42 + + + + /etc/systemd/network/25-macvtap.netdev + Create a MacVTap device. + [NetDev] +Name=macvtap-test +Kind=macvtap + + + + /etc/systemd/network/25-wireguard.netdev + [NetDev] +Name=wg0 +Kind=wireguard + +[WireGuard] +PrivateKey=EEGlnEPYJV//kbvvIqxKkQwOiS+UENyPncC4bF46ong= +ListenPort=51820 + +[WireGuardPeer] +PublicKey=RDf+LSpeEre7YEIKaxg+wbpsNV7du+ktR99uBEtIiCA= +AllowedIPs=fd31:bf08:57cb::/48,192.168.26.0/24 +Endpoint=wireguard.example.com:51820 + + + + /etc/systemd/network/27-xfrm.netdev + [NetDev] +Name=xfrm0 +Kind=xfrm + +[Xfrm] +Independent=yes + + + + + See Also + + systemd1, + systemd-networkd8, + systemd.link5, + systemd.network5, + systemd-network-generator.service8 + + + + diff --git a/man/systemd.network.xml b/man/systemd.network.xml new file mode 100644 index 0000000..e1c050f --- /dev/null +++ b/man/systemd.network.xml @@ -0,0 +1,4940 @@ + + + + + + + + systemd.network + systemd + + + + systemd.network + 5 + + + + systemd.network + Network configuration + + + + network.network + + + + Description + + A plain ini-style text file that encodes network configuration for matching network + interfaces, used by + systemd-networkd8. + See systemd.syntax7 + for a general description of the syntax. + + The main network file must have the extension .network; other + extensions are ignored. Networks are applied to links whenever the links appear. + + The .network files are read from the files located in the system network + directories /usr/lib/systemd/network and + /usr/local/lib/systemd/network, the volatile runtime network directory + /run/systemd/network and the local administration network directory + /etc/systemd/network. All configuration files are collectively sorted and + processed in alphanumeric order, regardless of the directories in which they live. However, files + with identical filenames replace each other. It is recommended that each filename is prefixed with + a number (e.g. 10-eth0.network). Otherwise, the default + .network files or those generated by + systemd-network-generator.service8 + may take precedence over user configured files. Files in /etc/ have the highest + priority, files in /run/ take precedence over files with the same name under + /usr/. This can be used to override a system-supplied configuration file with + a local file if needed. As a special case, an empty file (file size 0) or symlink with the same + name pointing to /dev/null disables the configuration file entirely (it is + "masked"). + + Along with the network file foo.network, a "drop-in" directory + foo.network.d/ may exist. All files with the suffix + .conf from this directory will be merged in the alphanumeric order and parsed + after the main file itself has been parsed. This is useful to alter or add configuration settings, + without having to modify the main configuration file. Each drop-in file must have appropriate + section headers. + + In addition to /etc/systemd/network, drop-in .d + directories can be placed in /usr/lib/systemd/network or + /run/systemd/network directories. Drop-in files in + /etc/ take precedence over those in /run/ which in turn + take precedence over those in /usr/lib/. Drop-in files under any of these + directories take precedence over the main network file wherever located. + + + + [Match] Section Options + + The network file contains a [Match] section, which determines if a given network file may + be applied to a given interface; and a [Network] section specifying how the interface should be + configured. The first (in alphanumeric order) of the network files that matches a given interface + is applied, all later files are ignored, even if they match as well. + + A network file is said to match a network interface if all matches specified by the [Match] + section are satisfied. When a network file does not contain valid settings in [Match] section, then + the file will match all interfaces and systemd-networkd warns about that. Hint: + to avoid the warning and to make it clear that all interfaces shall be matched, add the following: + Name=* The following keys are accepted: + + + + + + + + + + + + Name= + + A whitespace-separated list of shell-style globs matching the device name, as exposed + by the udev property INTERFACE, or device's alternative names. If the + list is prefixed with a "!", the test is inverted. + + + + + WLANInterfaceType= + + A whitespace-separated list of wireless network type. Supported values are + ad-hoc, station, ap, + ap-vlan, wds, monitor, + mesh-point, p2p-client, p2p-go, + p2p-device, ocb, and nan. If the + list is prefixed with a "!", the test is inverted. + + + + + SSID= + + A whitespace-separated list of shell-style globs matching the SSID of the currently + connected wireless LAN. If the list is prefixed with a "!", the test is inverted. + + + + + BSSID= + + A whitespace-separated list of hardware address of the currently connected wireless + LAN. Use full colon-, hyphen- or dot-delimited hexadecimal. See the example in + MACAddress=. This option may appear more than once, in which case the + lists are merged. If the empty string is assigned to this option, the list is reset. + + + + + + + + + + + + + + + [Link] Section Options + + The [Link] section accepts the following keys: + + + + MACAddress= + + The hardware address to set for the device. + + + + + MTUBytes= + + The maximum transmission unit in bytes to set for the device. The usual suffixes K, M, + G, are supported and are understood to the base of 1024. + Note that if IPv6 is enabled on the interface, and the MTU is chosen below 1280 (the + minimum MTU for IPv6) it will automatically be increased to this value. + + + + + ARP= + + Takes a boolean. If set to true, the ARP (low-level Address Resolution Protocol) + for this interface is enabled. When unset, the kernel's default will be used. + For example, disabling ARP is useful when creating multiple MACVLAN or VLAN virtual + interfaces atop a single lower-level physical interface, which will then only serve as a + link/"bridge" device aggregating traffic to the same physical link and not participate in + the network otherwise. Defaults to unset. + + + + + Multicast= + + Takes a boolean. If set to true, the multicast flag on the device is enabled. Defaults + to unset. + + + + + AllMulticast= + + Takes a boolean. If set to true, the driver retrieves all multicast packets from the + network. This happens when multicast routing is enabled. Defaults to unset. + + + + + Promiscuous= + + Takes a boolean. If set to true, promiscuous mode of the interface is enabled. Defaults + to unset. + If this is set to false for the underlying link of a passthru mode + MACVLAN/MACVTAP, the virtual interface will be created with the nopromisc + flag set. + + + + + Unmanaged= + + Takes a boolean. When yes, no attempts are made to bring up or + configure matching links, equivalent to when there are no matching network files. Defaults to + no. + This is useful for preventing later matching network files from interfering with + certain interfaces that are fully controlled by other applications. + + + + + Group= + + Link groups are similar to port ranges found in managed switches. When network + interfaces are added to a numbered group, operations on all the interfaces from that group + can be performed at once. Takes an unsigned integer in the range 0…2147483647. Defaults to + unset. + + + + + RequiredForOnline= + + Takes a boolean or a minimum operational state and an optional maximum operational + state. Please see + networkctl1 + for possible operational states. When yes, the network is deemed required + when determining whether the system is online (including when running + systemd-networkd-wait-online). When no, the network is + ignored when determining the online state. When a minimum operational state and an optional + maximum operational state are set, yes is implied, and this controls the + minimum and maximum operational state required for the network interface to be considered + online. + + Defaults to yes when ActivationPolicy= is not + set, or set to up, always-up, or + bound. Defaults to no when + ActivationPolicy= is set to manual or + down. This is forced to no when + ActivationPolicy= is set to always-down. + + The network will be brought up normally (as configured by + ActivationPolicy=), but in the event that there is no address being + assigned by DHCP or the cable is not plugged in, the link will simply remain offline and be + skipped automatically by systemd-networkd-wait-online if + RequiredForOnline=no. + + + + + RequiredFamilyForOnline= + + Takes an address family. When specified, an IP address in the given family is deemed + required when determining whether the link is online (including when running + systemd-networkd-wait-online). Takes one of ipv4, + ipv6, both, or any. Defaults to + any. Note that this option has no effect if + RequiredForOnline=no, or if RequiredForOnline= + specifies a minimum operational state below degraded. + + + + + ActivationPolicy= + + Specifies the policy for systemd-networkd managing the link + administrative state. Specifically, this controls how systemd-networkd + changes the network device's IFF_UP flag, which is sometimes + controlled by system administrators by running e.g., + ip link set dev eth0 up or ip link set dev eth0 down, + and can also be changed with networkctl up eth0 or + networkctl down eth0. + + Takes one of up, always-up, + manual, always-down, down, + or bound. When manual, + systemd-networkd will not change the link's admin state automatically; + the system administrator must bring the interface up or down manually, as desired. When + up (the default) or always-up, or + down or always-down, + systemd-networkd will set the link up or down, respectively, when the + interface is (re)configured. When always-up or + always-down, systemd-networkd will set the link up or + down, respectively, any time systemd-networkd detects a change in the + administrative state. When BindCarrier= is also set, this is automatically + set to bound and any other value is ignored. + + When the policy is set to down or manual, the + default value of RequiredForOnline= is no. When the + policy is set to always-down, the value of + RequiredForOnline= forced to no. + + The administrative state is not the same as the carrier state, so using + always-up does not mean the link will never lose carrier. The link carrier + depends on both the administrative state as well as the network device's physical connection. + However, to avoid reconfiguration failures, when using always-up, + IgnoreCarrierLoss= is forced to true. + + + + + + + + + [Network] Section Options + + The [Network] section accepts the following keys: + + + + Description= + + A description of the device. This is only used for presentation purposes. + + + + + DHCP= + + Enables DHCPv4 and/or DHCPv6 client support. Accepts yes, + no, ipv4, or ipv6. Defaults to + no. + + Note that DHCPv6 will by default be triggered by Router Advertisements, if reception is + enabled, regardless of this parameter. By explicitly enabling DHCPv6 support here, the DHCPv6 + client will be started in the mode specified by the WithoutRA= setting in the + [DHCPv6] section, regardless of the presence of routers on the link, or what flags the routers + pass. See IPv6AcceptRA=. + + Furthermore, note that by default the domain name specified through DHCP is not used + for name resolution. See option below. + + See the [DHCPv4] or [DHCPv6] sections below for further configuration options for the + DHCP client support. + + + + + DHCPServer= + + Takes a boolean. If set to yes, DHCPv4 server will be started. + Defaults to no. Further settings for the DHCP server may be set in the + [DHCPServer] section described below. + + + + + LinkLocalAddressing= + + Enables link-local address autoconfiguration. Accepts , + , , and . An IPv6 link-local + address is configured when or . An IPv4 link-local + address is configured when or and when DHCPv4 + autoconfiguration has been unsuccessful for some time. (IPv4 link-local address + autoconfiguration will usually happen in parallel with repeated attempts to acquire a DHCPv4 + lease). + + Defaults to when KeepMaster= or + Bridge= is set or when the specified + MACVLAN=/MACVTAP= has Mode=passthru, + or otherwise. + + + + + IPv6LinkLocalAddressGenerationMode= + + Specifies how IPv6 link-local address is generated. Takes one of + eui64, none, stable-privacy and + random. When unset, stable-privacy is used if + IPv6StableSecretAddress= is specified, and if not, + eui64 is used. Note that if LinkLocalAddressing= is + no or ipv4, then + IPv6LinkLocalAddressGenerationMode= will be ignored. Also, even if + LinkLocalAddressing= is yes or ipv6, + setting IPv6LinkLocalAddressGenerationMode=none + disables to configure an IPv6 link-local address. + + + + + IPv6StableSecretAddress= + + Takes an IPv6 address. The specified address will be used as a stable secret for + generating IPv6 link-local address. If this setting is specified, and + IPv6LinkLocalAddressGenerationMode= is unset, then + IPv6LinkLocalAddressGenerationMode=stable-privacy is implied. + If this setting is not specified, and stable-privacy is set to + IPv6LinkLocalAddressGenerationMode=, + then a stable secret address will be generated from the local machine ID and the interface + name. + + + + + IPv4LLStartAddress= + + Specifies the first IPv4 link-local address to try. Takes an IPv4 address for example + 169.254.1.2, from the link-local address range: 169.254.0.0/16 except for 169.254.0.0/24 and + 169.254.255.0/24. This setting may be useful if the device should always have the same address + as long as there is no address conflict. When unset, a random address will be automatically + selected. Defaults to unset. + + + + + IPv4LLRoute= + + Takes a boolean. If set to true, sets up the route needed for non-IPv4LL hosts to + communicate with IPv4LL-only hosts. Defaults to false. + + + + + DefaultRouteOnDevice= + + Takes a boolean. If set to true, sets up the IPv4 default route bound to the interface. + Defaults to false. This is useful when creating routes on point-to-point interfaces. This is + equivalent to e.g. the following, + ip route add default dev veth99 + or, + [Route] +Gateway=0.0.0.0 + Currently, there are no way to specify e.g., the table for the route configured by this + setting. To configure the default route with such an additional property, please use the + following instead: + [Route] +Gateway=0.0.0.0 +Table=1234 + If you'd like to create an IPv6 default route bound to the interface, please use the + following: + [Route] +Gateway=:: +Table=1234 + + + + + LLMNR= + + Takes a boolean or resolve. When true, enables + Link-Local Multicast Name Resolution + on the link. When set to resolve, only resolution is enabled, but not host + registration and announcement. Defaults to true. This setting is read by + systemd-resolved.service8. + + + + + + MulticastDNS= + + Takes a boolean or resolve. When true, enables + Multicast DNS support on the link. + When set to resolve, only resolution is enabled, but not host or service + registration and announcement. Defaults to false. This setting is read by + systemd-resolved.service8. + + + + + + DNSOverTLS= + + Takes a boolean or opportunistic. When true, enables + DNS-over-TLS support on the link. + When set to opportunistic, compatibility with non-DNS-over-TLS servers is + increased, by automatically turning off DNS-over-TLS servers in this case. This option + defines a per-interface setting for + resolved.conf5's + global DNSOverTLS= option. Defaults to unset, and the global setting will + be used. This setting is read by + systemd-resolved.service8. + + + + + + DNSSEC= + + Takes a boolean or allow-downgrade. When true, enables + DNSSEC DNS validation support on the + link. When set to allow-downgrade, compatibility with non-DNSSEC capable + networks is increased, by automatically turning off DNSSEC in this case. This option defines + a per-interface setting for + resolved.conf5's + global DNSSEC= option. Defaults to unset, and the global setting will be + used. This setting is read by + systemd-resolved.service8. + + + + + + DNSSECNegativeTrustAnchors= + + A space-separated list of DNSSEC negative trust anchor domains. If specified and DNSSEC + is enabled, look-ups done via the interface's DNS server will be subject to the list of + negative trust anchors, and not require authentication for the specified domains, or anything + below it. Use this to disable DNSSEC authentication for specific private domains, that cannot + be proven valid using the Internet DNS hierarchy. Defaults to the empty list. This setting is + read by + systemd-resolved.service8. + + + + + + LLDP= + + Controls support for Ethernet LLDP packet reception. LLDP is a link-layer protocol + commonly implemented on professional routers and bridges which announces which physical port + a system is connected to, as well as other related data. Accepts a boolean or the special + value routers-only. When true, incoming LLDP packets are accepted and a + database of all LLDP neighbors maintained. If routers-only is set only + LLDP data of various types of routers is collected and LLDP data about other types of devices + ignored (such as stations, telephones and others). If false, LLDP reception is disabled. + Defaults to routers-only. Use + networkctl1 + to query the collected neighbor data. LLDP is only available on Ethernet links. See + EmitLLDP= below for enabling LLDP packet emission from the local system. + + + + + + EmitLLDP= + + Controls support for Ethernet LLDP packet emission. Accepts a boolean parameter or the + special values nearest-bridge, non-tpmr-bridge and + customer-bridge. Defaults to false, which turns off LLDP packet emission. + If not false, a short LLDP packet with information about the local system is sent out in + regular intervals on the link. The LLDP packet will contain information about the local + hostname, the local machine ID (as stored in + machine-id5) + and the local interface name, as well as the pretty hostname of the system (as set in + machine-info5). + LLDP emission is only available on Ethernet links. Note that this setting passes data + suitable for identification of host to the network and should thus not be enabled on + untrusted networks, where such identification data should not be made available. Use this + option to permit other systems to identify on which interfaces they are connected to this + system. The three special values control propagation of the LLDP packets. The + nearest-bridge setting permits propagation only to the nearest connected + bridge, non-tpmr-bridge permits propagation across Two-Port MAC Relays, + but not any other bridges, and customer-bridge permits propagation until + a customer bridge is reached. For details about these concepts, see + IEEE 802.1AB-2016. + Note that configuring this setting to true is equivalent to + nearest-bridge, the recommended and most restricted level of propagation. + See LLDP= above for an option to enable LLDP reception. + + + + + BindCarrier= + + A link name or a list of link names. When set, controls the behavior of the current + link. When all links in the list are in an operational down state, the current link is + brought down. When at least one link has carrier, the current interface is brought up. + + This forces ActivationPolicy= to be set to bound. + + + + + + Address= + + A static IPv4 or IPv6 address and its prefix length, separated by a + / character. Specify this key more than once to configure several + addresses. The format of the address must be as described in + inet_pton3. + This is a short-hand for an [Address] section only containing an Address key (see below). + This option may be specified more than once. + + If the specified address is 0.0.0.0 (for IPv4) or + :: (for IPv6), a new address range of the requested size is automatically + allocated from a system-wide pool of unused ranges. Note that the prefix length must be equal + or larger than 8 for IPv4, and 64 for IPv6. The allocated range is checked against all + current network interfaces and all known network configuration files to avoid address range + conflicts. The default system-wide pool consists of 192.168.0.0/16, 172.16.0.0/12 and + 10.0.0.0/8 for IPv4, and fd00::/8 for IPv6. This functionality is useful to manage a large + number of dynamically created network interfaces with the same network configuration and + automatic address range assignment. + + + + + Gateway= + + The gateway address, which must be in the format described in + inet_pton3. + This is a short-hand for a [Route] section only containing a Gateway= key. + This option may be specified more than once. + + + + + DNS= + + A DNS server address, which must be in the format described in + inet_pton3. + This option may be specified more than once. Each address can optionally take a port number + separated with :, a network interface name or index separated with + %, and a Server Name Indication (SNI) separated with #. + When IPv6 address is specified with a port number, then the address must be in the square + brackets. That is, the acceptable full formats are + 111.222.333.444:9953%ifname#example.com for IPv4 and + [1111:2222::3333]:9953%ifname#example.com for IPv6. If an empty string is + assigned, then the all previous assignments are cleared. This setting is read by + systemd-resolved.service8. + + + + + + Domains= + + A whitespace-separated list of domains which should be resolved using the DNS servers + on this link. Each item in the list should be a domain name, optionally prefixed with a tilde + (~). The domains with the prefix are called "routing-only domains". The + domains without the prefix are called "search domains" and are first used as search suffixes + for extending single-label hostnames (hostnames containing no dots) to become fully qualified + domain names (FQDNs). If a single-label hostname is resolved on this interface, each of the + specified search domains are appended to it in turn, converting it into a fully qualified + domain name, until one of them may be successfully resolved. + + Both "search" and "routing-only" domains are used for routing of DNS queries: look-ups + for hostnames ending in those domains (hence also single label names, if any "search domains" + are listed), are routed to the DNS servers configured for this interface. The domain routing + logic is particularly useful on multi-homed hosts with DNS servers serving particular private + DNS zones on each interface. + + The "routing-only" domain ~. (the tilde indicating definition of a + routing domain, the dot referring to the DNS root domain which is the implied suffix of all + valid DNS names) has special effect. It causes all DNS traffic which does not match another + configured domain routing entry to be routed to DNS servers specified for this interface. + This setting is useful to prefer a certain set of DNS servers if a link on which they are + connected is available. + + This setting is read by + systemd-resolved.service8. + "Search domains" correspond to the domain and search + entries in + resolv.conf5. + Domain name routing has no equivalent in the traditional glibc API, which has no concept of + domain name servers limited to a specific link. + + + + + DNSDefaultRoute= + + Takes a boolean argument. If true, this link's configured DNS servers are used for + resolving domain names that do not match any link's configured Domains= + setting. If false, this link's configured DNS servers are never used for such domains, and + are exclusively used for resolving names that match at least one of the domains configured on + this link. If not specified defaults to an automatic mode: queries not matching any link's + configured domains will be routed to this link if it has no routing-only domains configured. + + + + + + NTP= + + An NTP server address (either an IP address, or a hostname). This option may be + specified more than once. This setting is read by + systemd-timesyncd.service8. + + + + + + IPForward= + + Configures IP packet forwarding for the system. If enabled, incoming packets on any + network interface will be forwarded to any other interfaces according to the routing table. + Takes a boolean, or the values ipv4 or ipv6, which only + enable IP packet forwarding for the specified address family. This controls the + net.ipv4.ip_forward and net.ipv6.conf.all.forwarding + sysctl options of the network interface (see + IP Sysctl + for details about sysctl options). Defaults to no. + + Note: this setting controls a global kernel option, and does so one way only: if a + network that has this setting enabled is set up the global setting is turned on. However, + it is never turned off again, even after all networks with this setting enabled are shut + down again. + + To allow IP packet forwarding only between specific network interfaces use a firewall. + + + + + + IPMasquerade= + + Configures IP masquerading for the network interface. If enabled, packets forwarded + from the network interface will be appear as coming from the local host. Takes one of + ipv4, ipv6, both, or + no. Defaults to no. If enabled, this automatically sets + IPForward= to one of ipv4, ipv6 or + yes. + Note. Any positive boolean values such as yes or + true are now deprecated. Please use one of the values in the above. + + + + + IPv6PrivacyExtensions= + + Configures use of stateless temporary addresses that change over time (see + RFC 4941, + Privacy Extensions for Stateless Address Autoconfiguration in IPv6). Takes a boolean or the + special values prefer-public and kernel. When true, + enables the privacy extensions and prefers temporary addresses over public addresses. When + prefer-public, enables the privacy extensions, but prefers public + addresses over temporary addresses. When false, the privacy extensions remain disabled. When + kernel, the kernel's default setting will be left in place. Defaults to + no. + + + + + IPv6AcceptRA= + + Takes a boolean. Controls IPv6 Router Advertisement (RA) reception support for the + interface. If true, RAs are accepted; if false, RAs are ignored. When RAs are accepted, they + may trigger the start of the DHCPv6 client if the relevant flags are set in the RA data, or + if no routers are found on the link. The default is to disable RA reception for bridge + devices or when IP forwarding is enabled, and to enable it otherwise. Cannot be enabled on + bond devices and when link-local addressing is disabled. + + Further settings for the IPv6 RA support may be configured in the [IPv6AcceptRA] + section, see below. + + Also see + IP Sysctl + in the kernel documentation regarding accept_ra, but note that systemd's + setting of 1 (i.e. true) corresponds to kernel's setting of + 2. + + Note that kernel's implementation of the IPv6 RA protocol is always disabled, + regardless of this setting. If this option is enabled, a userspace implementation of the IPv6 + RA protocol is used, and the kernel's own implementation remains disabled, since + systemd-networkd needs to know all details supplied in the advertisements, + and these are not available from the kernel if the kernel's own implementation is used. + + + + + + IPv6DuplicateAddressDetection= + + Configures the amount of IPv6 Duplicate Address Detection (DAD) probes to send. When + unset, the kernel's default will be used. + + + + + IPv6HopLimit= + + Configures IPv6 Hop Limit. For each router that forwards the packet, the hop limit is + decremented by 1. When the hop limit field reaches zero, the packet is discarded. When unset, + the kernel's default will be used. + + + + + IPv4AcceptLocal= + + Takes a boolean. Accept packets with local source addresses. In combination with + suitable routing, this can be used to direct packets between two local interfaces over the + wire and have them accepted properly. When unset, the kernel's default will be used. + + + + + IPv4RouteLocalnet= + + Takes a boolean. When true, the kernel does not consider loopback addresses as martian + source or destination while routing. This enables the use of 127.0.0.0/8 for local routing + purposes. When unset, the kernel's default will be used. + + + + + IPv4ProxyARP= + + Takes a boolean. Configures proxy ARP for IPv4. Proxy ARP is the technique in which one + host, usually a router, answers ARP requests intended for another machine. By "faking" its + identity, the router accepts responsibility for routing packets to the "real" destination. + See RFC 1027. When unset, the + kernel's default will be used. + + + + + IPv6ProxyNDP= + + Takes a boolean. Configures proxy NDP for IPv6. Proxy NDP (Neighbor Discovery Protocol) + is a technique for IPv6 to allow routing of addresses to a different destination when peers + expect them to be present on a certain physical link. In this case a router answers Neighbour + Advertisement messages intended for another machine by offering its own MAC address as + destination. Unlike proxy ARP for IPv4, it is not enabled globally, but will only send + Neighbour Advertisement messages for addresses in the IPv6 neighbor proxy table, which can + also be shown by ip -6 neighbour show proxy. systemd-networkd will control + the per-interface `proxy_ndp` switch for each configured interface depending on this option. + When unset, the kernel's default will be used. + + + + + IPv6ProxyNDPAddress= + + An IPv6 address, for which Neighbour Advertisement messages will be proxied. This + option may be specified more than once. systemd-networkd will add the + IPv6ProxyNDPAddress= entries to the kernel's IPv6 neighbor proxy table. + This setting implies IPv6ProxyNDP=yes but has no effect if + IPv6ProxyNDP= has been set to false. When unset, the kernel's default will + be used. + + + + + IPv6SendRA= + + Whether to enable or disable Router Advertisement sending on a link. Takes a boolean + value. When enabled, prefixes configured in [IPv6Prefix] sections and routes configured in + the [IPv6RoutePrefix] sections are distributed as defined in the [IPv6SendRA] section. If + DHCPPrefixDelegation= is enabled, then the delegated prefixes are also + distributed. See DHCPPrefixDelegation= setting and the [IPv6SendRA], + [IPv6Prefix], [IPv6RoutePrefix], and [DHCPPrefixDelegation] sections for more configuration + options. + + + + + DHCPPrefixDelegation= + + Takes a boolean value. When enabled, requests subnet prefixes on another link via the DHCPv6 + protocol or via the 6RD option in the DHCPv4 protocol. An address within each delegated prefix will + be assigned, and the prefixes will be announced through IPv6 Router Advertisement if + IPv6SendRA= is enabled. This behaviour can be configured in the + [DHCPPrefixDelegation] section. Defaults to disabled. + + + + + IPv6MTUBytes= + + Configures IPv6 maximum transmission unit (MTU). An integer greater than or equal to + 1280 bytes. When unset, the kernel's default will be used. + + + + + KeepMaster= + + Takes a boolean value. When enabled, the current master interface index will not be + changed, and BatmanAdvanced=, Bond=, + Bridge=, and VRF= settings are ignored. This may be + useful when a netdev with a master interface is created by another program, e.g. + systemd-nspawn1. + Defaults to false. + + + + + BatmanAdvanced= + Bond= + Bridge= + VRF= + + The name of the B.A.T.M.A.N. Advanced, bond, bridge, or VRF interface to add the link + to. See + systemd.netdev5. + + + + + + IPoIB= + IPVLAN= + IPVTAP= + MACsec= + MACVLAN= + MACVTAP= + Tunnel= + VLAN= + VXLAN= + Xfrm= + + The name of an IPoIB, IPVLAN, IPVTAP, MACsec, MACVLAN, MACVTAP, tunnel, VLAN, + VXLAN, or Xfrm to be created on the link. See + systemd.netdev5. + This option may be specified more than once. + + + + + ActiveSlave= + + Takes a boolean. Specifies the new active slave. The ActiveSlave= + option is only valid for following modes: active-backup, + balance-alb, and balance-tlb. Defaults to false. + + + + + PrimarySlave= + + Takes a boolean. Specifies which slave is the primary device. The specified device will + always be the active slave while it is available. Only when the primary is off-line will + alternate devices be used. This is useful when one slave is preferred over another, e.g. + when one slave has higher throughput than another. The PrimarySlave= + option is only valid for following modes: active-backup, + balance-alb, and balance-tlb. Defaults to false. + + + + + ConfigureWithoutCarrier= + + Takes a boolean. Allows networkd to configure a specific link even if it has no + carrier. Defaults to false. If enabled, and the IgnoreCarrierLoss= setting + is not explicitly set, then it is enabled as well. + + + + + IgnoreCarrierLoss= + + Takes a boolean or a timespan. When true, systemd-networkd retains + both the static and dynamic configuration of the interface even if its carrier is lost. When + false, systemd-networkd drops both the static and dynamic configuration of + the interface. When a timespan is specified, systemd-networkd waits for + the specified timespan, and ignores the carrier loss if the link regain its carrier within + the timespan. Setting 0 seconds is equivalent to no, and + infinite is equivalent to yes. + + Setting a finite timespan may be useful when e.g. in the following cases: + + + A wireless interface connecting to a network which has multiple access points with + the same SSID. + + + Enslaving a wireless interface to a bond interface, which may disconnect from the + connected access point and causes its carrier to be lost. + + + The driver of the interface resets when the MTU is changed. + + + + + When Bond= is specified to a wireless interface, defaults to 3 + seconds. When the DHCPv4 client is enabled and UseMTU= in the [DHCPv4] + section enabled, defaults to 5 seconds. Otherwise, defaults to the value specified with + ConfigureWithoutCarrier=. When ActivationPolicy= is set + to always-up, this is forced to yes, and ignored any + user specified values. + + + + + KeepConfiguration= + + Takes a boolean or one of static, dhcp-on-stop, + dhcp. When static, systemd-networkd + will not drop static addresses and routes on starting up process. When set to + dhcp-on-stop, systemd-networkd will not drop addresses + and routes on stopping the daemon. When dhcp, + the addresses and routes provided by a DHCP server will never be dropped even if the DHCP + lease expires. This is contrary to the DHCP specification, but may be the best choice if, + e.g., the root filesystem relies on this connection. The setting dhcp + implies dhcp-on-stop, and yes implies + dhcp and static. Defaults to + dhcp-on-stop when systemd-networkd is running in + initrd, yes when the root filesystem is a network filesystem, and + no otherwise. + + + + + + + [Address] Section Options + + An [Address] section accepts the following keys. Specify several [Address] sections to + configure several addresses. + + + + Address= + + As in the [Network] section. This setting is mandatory. Each [Address] section can + contain one Address= setting. + + + + + Peer= + + The peer address in a point-to-point connection. Accepts the same format as the + Address= setting. + + + + + Broadcast= + + Takes an IPv4 address or boolean value. The address must be in the format described in + inet_pton3. + If set to true, then the IPv4 broadcast address will be derived from the + Address= setting. If set to false, then the broadcast address will not be + set. Defaults to true, except for wireguard interfaces, where it default to false. + + + + + Label= + + Specifies the label for the IPv4 address. The label must be a 7-bit ASCII string with + a length of 1…15 characters. Defaults to unset. + + + + + PreferredLifetime= + + Allows the default "preferred lifetime" of the address to be overridden. Only three + settings are accepted: forever, infinity, which is the + default and means that the address never expires, and 0, which means that + the address is considered immediately "expired" and will not be used, unless explicitly + requested. A setting of is useful for addresses which + are added to be used only by a specific application, which is then configured to use them + explicitly. + + + + + Scope= + + The scope of the address, which can be global (valid everywhere on + the network, even through a gateway), link (only valid on this device, + will not traverse a gateway) or host (only valid within the device itself, + e.g. 127.0.0.1) or an integer in the range 0…255. Defaults to global. + + + + + + RouteMetric= + + The metric of the prefix route, which is pointing to the subnet of the configured IP + address, taking the configured prefix length into account. Takes an unsigned integer in the + range 0…4294967295. When unset or set to 0, the kernel's default value is used. This + setting will be ignored when AddPrefixRoute= is false. + + + + + HomeAddress= + + Takes a boolean. Designates this address the "home address" as defined in + RFC 6275. Supported only on IPv6. + Defaults to false. + + + + + DuplicateAddressDetection= + + Takes one of ipv4, ipv6, both, + or none. When ipv4, performs IPv4 Address Conflict + Detection. See RFC 5227. + When ipv6, performs IPv6 Duplicate Address Detection. See + RFC 4862. Defaults to + ipv4 for IPv4 link-local addresses, ipv6 for IPv6 + addresses, and none otherwise. + + + + + ManageTemporaryAddress= + + Takes a boolean. If true the kernel manage temporary addresses created from this one as + template on behalf of Privacy Extensions + RFC 3041. For this to become active, + the use_tempaddr sysctl setting has to be set to a value greater than zero. The given address + needs to have a prefix length of 64. This flag allows using privacy extensions in a manually + configured network, just like if stateless auto-configuration was active. Defaults to false. + + + + + + AddPrefixRoute= + + Takes a boolean. When true, the prefix route for the address is automatically added. + Defaults to true. + + + + + AutoJoin= + + Takes a boolean. Joining multicast group on ethernet level via + ip maddr command would not work if we have an Ethernet switch that does + IGMP snooping since the switch would not replicate multicast packets on ports that did not + have IGMP reports for the multicast addresses. Linux vxlan interfaces created via + ip link add vxlan or networkd's netdev kind vxlan have the group option + that enables them to do the required join. By extending ip address command + with option autojoin we can get similar functionality for openvswitch (OVS) + vxlan interfaces as well as other tunneling mechanisms that need to receive multicast traffic. + Defaults to no. + + + + + NetLabel=label + + + This setting provides a method for integrating static and dynamic network configuration into + Linux NetLabel subsystem rules, + used by Linux Security Modules + (LSMs) for network access control. The label, with suitable LSM rules, can be used to + control connectivity of (for example) a service with peers in the local network. At least with + SELinux, only the ingress can be controlled but not egress. The benefit of using this setting is + that it may be possible to apply interface independent part of NetLabel configuration at very early + stage of system boot sequence, at the time when the network interfaces are not available yet, with + netlabelctl8, + and the per-interface configuration with systemd-networkd once the interfaces + appear later. Currently this feature is only implemented for SELinux. + + The option expects a single NetLabel label. The label must conform to lexical restrictions of + LSM labels. When an interface is configured with IP addresses, the addresses and subnetwork masks + will be appended to the NetLabel + Fallback Peer Labeling rules. They will be removed when the interface is + deconfigured. Failures to manage the labels will be ignored. + + Warning: Once labeling is enabled for network traffic, a lot of LSM access control points in + Linux networking stack go from dormant to active. Care should be taken to avoid getting into a + situation where for example remote connectivity is broken, when the security policy hasn't been + updated to consider LSM per-packet access controls and no rules would allow any network + traffic. Also note that additional configuration with netlabelctl8 + is needed. + + Example: + [Address] +NetLabel=system_u:object_r:localnet_peer_t:s0 + + With the example rules applying for interface eth0, when the interface is + configured with an IPv4 address of 10.0.0.123/8, systemd-networkd performs the + equivalent of netlabelctl operation + + netlabelctl unlbl add interface eth0 address:10.0.0.0/8 label:system_u:object_r:localnet_peer_t:s0 + + and the reverse operation when the IPv4 address is deconfigured. The configuration can be used with + LSM rules; in case of SELinux to allow a SELinux domain to receive data from objects of SELinux + peer class. For example: + + type localnet_peer_t; +allow my_server_t localnet_peer_t:peer recv; + + The effect of the above configuration and rules (in absence of other rules as may be the case) is + to only allow my_server_t (and nothing else) to receive data from local subnet + 10.0.0.0/8 of interface eth0. + + + + + + + + [Neighbor] Section Options + + A [Neighbor] section accepts the following keys. The neighbor section adds a permanent, + static entry to the neighbor table (IPv6) or ARP table (IPv4) for the given hardware address on the + links matched for the network. Specify several [Neighbor] sections to configure several static + neighbors. + + + + Address= + + The IP address of the neighbor. + + + + + LinkLayerAddress= + + The link layer address (MAC address or IP address) of the neighbor. + + + + + + + [IPv6AddressLabel] Section Options + + An [IPv6AddressLabel] section accepts the following keys. Specify several [IPv6AddressLabel] + sections to configure several address labels. IPv6 address labels are used for address selection. + See RFC 3484. Precedence is managed by + userspace, and only the label itself is stored in the kernel. + + + + Label= + + The label for the prefix, an unsigned integer in the range 0…4294967294. 0xffffffff is + reserved. This setting is mandatory. + + + + + Prefix= + + IPv6 prefix is an address with a prefix length, separated by a slash + / character. This setting is mandatory. + + + + + + + [RoutingPolicyRule] Section Options + + An [RoutingPolicyRule] section accepts the following settings. Specify several + [RoutingPolicyRule] sections to configure several rules. + + + + TypeOfService= + + Takes a number between 0 and 255 that specifies the type of service to match. + + + + + From= + + Specifies the source address prefix to match. Possibly followed by a slash and the + prefix length. + + + + + To= + + Specifies the destination address prefix to match. Possibly followed by a slash and the + prefix length. + + + + + FirewallMark= + + Specifies the iptables firewall mark value to match (a number in the range + 1…4294967295). Optionally, the firewall mask (also a number between 1…4294967295) can be + suffixed with a slash (/), e.g., 7/255. + + + + + Table= + + Specifies the routing table identifier to lookup if the rule selector matches. Takes + one of predefined names default, main, and + local, and names defined in RouteTable= in + networkd.conf5, + or a number between 1 and 4294967295. Defaults to main. + + + + + Priority= + + Specifies the priority of this rule. Priority= is an integer in the + range 0…4294967295. Higher number means lower priority, and rules get processed in order of + increasing number. Defaults to unset, and the kernel will pick a value dynamically. + + + + + IncomingInterface= + + Specifies incoming device to match. If the interface is loopback, the rule only matches + packets originating from this host. + + + + + OutgoingInterface= + + Specifies the outgoing device to match. The outgoing interface is only available for + packets originating from local sockets that are bound to a device. + + + + + SourcePort= + + Specifies the source IP port or IP port range match in forwarding information base + (FIB) rules. A port range is specified by the lower and upper port separated by a dash. + Defaults to unset. + + + + + DestinationPort= + + Specifies the destination IP port or IP port range match in forwarding information base + (FIB) rules. A port range is specified by the lower and upper port separated by a dash. + Defaults to unset. + + + + + IPProtocol= + + Specifies the IP protocol to match in forwarding information base (FIB) rules. Takes IP + protocol name such as tcp, udp or + sctp, or IP protocol number such as 6 for + tcp or 17 for udp. Defaults to unset. + + + + + + InvertRule= + + A boolean. Specifies whether the rule is to be inverted. Defaults to false. + + + + + Family= + + Takes a special value ipv4, ipv6, or + both. By default, the address family is determined by the address + specified in To= or From=. If neither + To= nor From= are specified, then defaults to + ipv4. + + + + + User= + + Takes a username, a user ID, or a range of user IDs separated by a dash. Defaults to + unset. + + + + + SuppressPrefixLength= + + Takes a number N in the range 0…128 and rejects routing + decisions that have a prefix length of N or less. Defaults to + unset. + + + + + SuppressInterfaceGroup= + + Takes an integer in the range 0…2147483647 and rejects routing decisions that have + an interface with the same group id. It has the same meaning as + in ip rule. Defaults to unset. + + + + + Type= + + Specifies Routing Policy Database (RPDB) rule type. Takes one of + blackhole, unreachable or prohibit. + + + + + + + + [NextHop] Section Options + + The [NextHop] section is used to manipulate entries in the kernel's "nexthop" tables. The + [NextHop] section accepts the following settings. Specify several [NextHop] sections to configure + several hops. + + + + Id= + + The id of the next hop. Takes an integer in the range 1…4294967295. If unspecified, + then automatically chosen by kernel. + + + + + Gateway= + + As in the [Network] section. + + + + + Family= + + Takes one of the special values ipv4 or ipv6. + By default, the family is determined by the address specified in + Gateway=. If Gateway= is not specified, then defaults + to ipv4. + + + + + OnLink= + + Takes a boolean. If set to true, the kernel does not have to check if the gateway is + reachable directly by the current machine (i.e., attached to the local network), so that we + can insert the nexthop in the kernel table without it being complained about. Defaults to + no. + + + + + Blackhole= + + Takes a boolean. If enabled, packets to the corresponding routes are discarded + silently, and Gateway= cannot be specified. Defaults to + no. + + + + + Group= + + Takes a whitespace separated list of nexthop IDs. Each ID must be in the range + 1…4294967295. Optionally, each nexthop ID can take a weight after a colon + (id:weight). + The weight must be in the range 1…255. If the weight is not specified, then it is assumed + that the weight is 1. This setting cannot be specified with Gateway=, + Family=, Blackhole=. This setting can be specified + multiple times. If an empty string is assigned, then the all previous assignments are + cleared. Defaults to unset. + + + + + + + [Route] Section Options + + The [Route] section accepts the following settings. Specify several [Route] sections to + configure several routes. + + + + Gateway= + + Takes the gateway address or the special values _dhcp4 and + _ipv6ra. If _dhcp4 or _ipv6ra is + set, then the gateway address provided by DHCPv4 or IPv6 RA is used. + + + + + GatewayOnLink= + + Takes a boolean. If set to true, the kernel does not have to check if the gateway is + reachable directly by the current machine (i.e., attached to the local network), so that we + can insert the route in the kernel table without it being complained about. Defaults to + no. + + + + + Destination= + + The destination prefix of the route. Possibly followed by a slash and the prefix + length. If omitted, a full-length host route is assumed. + + + + + Source= + + The source prefix of the route. Possibly followed by a slash and the prefix length. If + omitted, a full-length host route is assumed. + + + + + Metric= + + The metric of the route. Takes an unsigned integer in the range 0…4294967295. Defaults + to unset, and the kernel's default will be used. + + + + + IPv6Preference= + + Specifies the route preference as defined in + RFC 4191 for Router Discovery + messages. Which can be one of low the route has a lowest priority, + medium the route has a default priority or high the + route has a highest priority. + + + + + Scope= + + The scope of the IPv4 route, which can be global, + site, link, host, or + nowhere: + + + global means the route can reach hosts more than one hop away. + + + + + site means an interior route in the local autonomous system. + + + + + link means the route can only reach hosts on the local network + (one hop away). + + + + host means the route will not leave the local machine (used for + internal addresses like 127.0.0.1). + + + + nowhere means the destination doesn't exist. + + + + For IPv4 route, defaults to host if Type= is + local or nat, and link if + Type= is broadcast, multicast, + anycast, or unicast. In other cases, + defaults to global. The value is not used for IPv6. + + + + + PreferredSource= + + The preferred source address of the route. The address must be in the format described + in + inet_pton3. + + + + + + Table= + + The table identifier for the route. Takes one of predefined names + default, main, and local, and names + defined in RouteTable= in + networkd.conf5, + or a number between 1 and 4294967295. The table can be retrieved using + ip route show table num. If unset and + Type= is local, broadcast, + anycast, or nat, then local is used. + In other cases, defaults to main. + + + + + Protocol= + + The protocol identifier for the route. Takes a number between 0 and 255 or the special + values kernel, boot, static, + ra and dhcp. Defaults to static. + + + + + + Type= + + Specifies the type for the route. Takes one of unicast, + local, broadcast, anycast, + multicast, blackhole, unreachable, + prohibit, throw, nat, and + xresolve. If unicast, a regular route is defined, i.e. + a route indicating the path to take to a destination network address. If + blackhole, packets to the defined route are discarded silently. If + unreachable, packets to the defined route are discarded and the ICMP + message "Host Unreachable" is generated. If prohibit, packets to the + defined route are discarded and the ICMP message "Communication Administratively Prohibited" + is generated. If throw, route lookup in the current routing table will + fail and the route selection process will return to Routing Policy Database (RPDB). Defaults + to unicast. + + + + + InitialCongestionWindow= + + The TCP initial congestion window is used during the start of a TCP connection. + During the start of a TCP session, when a client requests a resource, the server's initial + congestion window determines how many packets will be sent during the initial burst of data + without waiting for acknowledgement. Takes a number between 1 and 1023. Note that 100 is + considered an extremely large value for this option. When unset, the kernel's default + (typically 10) will be used. + + + + + InitialAdvertisedReceiveWindow= + + The TCP initial advertised receive window is the amount of receive data (in bytes) + that can initially be buffered at one time on a connection. The sending host can send only + that amount of data before waiting for an acknowledgment and window update from the + receiving host. Takes a number between 1 and 1023. Note that 100 is considered an extremely + large value for this option. When unset, the kernel's default will be used. + + + + + QuickAck= + + Takes a boolean. When true enables TCP quick ack mode for the route. When unset, the + kernel's default will be used. + + + + + FastOpenNoCookie= + + Takes a boolean. When true enables TCP fastopen without a cookie on a per-route basis. + When unset, the kernel's default will be used. + + + + + TTLPropagate= + + Takes a boolean. When true enables TTL propagation at Label Switched Path (LSP) egress. + When unset, the kernel's default will be used. + + + + + MTUBytes= + + The maximum transmission unit in bytes to set for the route. The usual suffixes K, M, + G, are supported and are understood to the base of 1024. + + + + + TCPAdvertisedMaximumSegmentSize= + + Specifies the Path MSS (in bytes) hints given on TCP layer. The usual suffixes K, M, G, + are supported and are understood to the base of 1024. An unsigned integer in the range + 1…4294967294. When unset, the kernel's default will be used. + + + + + TCPCongestionControlAlgorithm= + + Specifies the TCP congestion control algorithm for the route. Takes a name of the algorithm, + e.g. bbr, dctcp, or vegas. When unset, + the kernel's default will be used. + + + + + MultiPathRoute=address[@name] [weight] + + Configures multipath route. Multipath routing is the technique of using multiple + alternative paths through a network. Takes gateway address. Optionally, takes a network + interface name or index separated with @, and a weight in 1..256 for this + multipath route separated with whitespace. This setting can be specified multiple times. If + an empty string is assigned, then the all previous assignments are cleared. + + + + + NextHop= + + Specifies the nexthop id. Takes an unsigned integer in the range 1…4294967295. If set, + the corresponding [NextHop] section must be configured. Defaults to unset. + + + + + + + [DHCPv4] Section Options + + The [DHCPv4] section configures the DHCPv4 client, if it is enabled with the + DHCP= setting described above: + + + + + + + SendHostname= + + When true (the default), the machine's hostname (or the value specified with + Hostname=, described below) will be sent to the DHCP server. Note that the + hostname must consist only of 7-bit ASCII lower-case characters and no spaces or dots, and be + formatted as a valid DNS domain name. Otherwise, the hostname is not sent even if this option + is true. + + + + + Hostname= + + Use this value for the hostname which is sent to the DHCP server, instead of machine's + hostname. Note that the specified hostname must consist only of 7-bit ASCII lower-case + characters and no spaces or dots, and be formatted as a valid DNS domain name. + + + + + MUDURL= + + When configured, the specified Manufacturer Usage Description (MUD) URL will be sent + to the DHCPv4 server. Takes a URL of length up to 255 characters. A superficial verification + that the string is a valid URL will be performed. DHCPv4 clients are intended to have at most + one MUD URL associated with them. See + RFC 8520. + + MUD is an embedded software standard defined by the IETF that allows IoT device makers + to advertise device specifications, including the intended communication patterns for their + device when it connects to the network. The network can then use this to author a + context-specific access policy, so the device functions only within those parameters. + + + + + ClientIdentifier= + + The DHCPv4 client identifier to use. Takes one of , + or . If set to , the + MAC address of the link is used. If set to , an RFC4361-compliant Client + ID, which is the combination of IAID and DUID (see below), is used. If set to + , only DUID is used, this may not be RFC compliant, but some setups + may require to use this. Defaults to . + + + + + VendorClassIdentifier= + + The vendor class identifier used to identify vendor type and configuration. + + + + + UserClass= + + A DHCPv4 client can use UserClass option to identify the type or category of user or + applications it represents. The information contained in this option is a string that + represents the user class of which the client is a member. Each class sets an identifying + string of information to be used by the DHCP service to classify clients. Takes a + whitespace-separated list of strings. + + + + + DUIDType= + + Override the global DUIDType= setting for this network. See + networkd.conf5 + for a description of possible values. + + + + + DUIDRawData= + + Override the global DUIDRawData= setting for this network. See + networkd.conf5 + for a description of possible values. + + + + + IAID= + + The DHCP Identity Association Identifier (IAID) for the interface, a 32-bit unsigned + integer. + + + + + Anonymize= + + Takes a boolean. When true, the options sent to the DHCP server will follow the + RFC 7844 (Anonymity Profiles for + DHCP Clients) to minimize disclosure of identifying information. Defaults to false. + + This option should only be set to true when MACAddressPolicy= is set + to (see + systemd.link5). + + + When true, + ClientIdentifier=mac, + SendHostname=no, + Use6RD=no, + UseCaptivePortal=no, + UseMTU=no, + UseNTP=no, + UseSIP=no, and + UseTimezone=no + are implied and these settings in the .network file are silently ignored. Also, + Hostname=, + MUDURL=, + RequestOptions=, + SendOption=, + SendVendorOption=, + UserClass=, and + VendorClassIdentifier= + are silently ignored. + + With this option enabled DHCP requests will mimic those generated by Microsoft + Windows, in order to reduce the ability to fingerprint and recognize installations. This + means DHCP request sizes will grow and lease data will be more comprehensive than normally, + though most of the requested data is not actually used. + + + + + RequestOptions= + + Sets request options to be sent to the server in the DHCPv4 request options list. A + whitespace-separated list of integers in the range 1…254. Defaults to unset. + + + + + SendOption= + + Send an arbitrary raw option in the DHCPv4 request. Takes a DHCP option number, data + type and data separated with a colon + (option:type:value). + The option number must be an integer in the range 1…254. The type takes one of + uint8, uint16, uint32, + ipv4address, or string. Special characters in the data + string may be escaped using + C-style + escapes. This setting can be specified multiple times. If an empty string is + specified, then all options specified earlier are cleared. Defaults to unset. + + + + + SendVendorOption= + + Send an arbitrary vendor option in the DHCPv4 request. Takes a DHCP option number, data + type and data separated with a colon + (option:type:value). + The option number must be an integer in the range 1…254. The type takes one of + uint8, uint16, uint32, + ipv4address, or string. Special characters in the data + string may be escaped using + C-style + escapes. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Defaults to unset. + + + + + IPServiceType= + + Takes one of the special values none, CS6, or + CS4. When none no IP service type is set to the packet + sent from the DHCPv4 client. When CS6 (network control) or + CS4 (realtime), the corresponding service type will be set. Defaults to + CS6. + + + + + + + Label= + + Specifies the label for the IPv4 address received from the DHCP server. The label must + be a 7-bit ASCII string with a length of 1…15 characters. Defaults to unset. + + + + + UseDNS= + + When true (the default), the DNS servers received from the DHCP server will be used. + + + This corresponds to the option in + resolv.conf5. + + + + + + RoutesToDNS= + + When true, the routes to the DNS servers received from the DHCP server will be + configured. When UseDNS= is disabled, this setting is ignored. Defaults to + true. + + + + + UseNTP= + + When true (the default), the NTP servers received from the DHCP server will be used by + systemd-timesyncd.service. + + + + + RoutesToNTP= + + When true, the routes to the NTP servers received from the DHCP server will be + configured. When UseNTP= is disabled, this setting is ignored. Defaults to + true. + + + + + UseSIP= + + When true (the default), the SIP servers received from the DHCP server will be collected + and made available to client programs. + + + + + UseMTU= + + When true, the interface maximum transmission unit from the DHCP server will be used on + the current link. If MTUBytes= is set, then this setting is ignored. + Defaults to false. + + Note, some drivers will reset the interfaces if the MTU is changed. For such + interfaces, please try to use IgnoreCarrierLoss= with a short timespan, + e.g. 3 seconds. + + + + + UseHostname= + + When true (the default), the hostname received from the DHCP server will be set as the + transient hostname of the system. + + + + + UseDomains= + + Takes a boolean, or the special value . When true, the domain name + received from the DHCP server will be used as DNS search domain over this link, similarly to the + effect of the setting. If set to , the domain name + received from the DHCP server will be used for routing DNS queries only, but not for searching, + similarly to the effect of the setting when the argument is prefixed with + ~. Defaults to false. + + It is recommended to enable this option only on trusted networks, as setting this + affects resolution of all hostnames, in particular of single-label names. It is generally + safer to use the supplied domain only as routing domain, rather than as search domain, in + order to not have it affect local resolution of single-label names. + + When set to true, this setting corresponds to the option in + resolv.conf5. + + + + + + UseRoutes= + + When true (the default), the static routes will be requested from the DHCP server and + added to the routing table with a metric of 1024, and a scope of , + or , depending on the route's destination and + gateway. If the destination is on the local host, e.g., 127.x.x.x, or the same as the link's + own address, the scope will be set to . Otherwise if the gateway is null + (a direct route), a scope will be used. For anything else, scope + defaults to . + + + + + RouteMetric= + + Set the routing metric for routes specified by the DHCP server (including the prefix + route added for the specified prefix). Takes an unsigned integer in the range 0…4294967295. + Defaults to 1024. + + + + + RouteTable=num + + The table identifier for DHCP routes. Takes one of predefined names + default, main, and local, and names + defined in RouteTable= in + networkd.conf5, + or a number between 1…4294967295. + + When used in combination with VRF=, the VRF's routing table is + used when this parameter is not specified. + + + + + RouteMTUBytes= + + Specifies the MTU for the DHCP routes. Please see the [Route] section for further + details. + + + + + UseGateway= + + When true, the gateway will be requested from the DHCP server and added to the routing + table with a metric of 1024, and a scope of . When unset, the value + specified with UseRoutes= is used. + + + + + UseTimezone= + When true, the timezone received from the DHCP server will be set as timezone + of the local system. Defaults to false. + + + + Use6RD= + + When true, subnets of the received IPv6 prefix are assigned to downstream interfaces + which enables DHCPPrefixDelegation=. See also + DHCPPrefixDelegation= in the [Network] section, the [DHCPPrefixDelegation] + section, and RFC 5969. Defaults to + false. + + + + + FallbackLeaseLifetimeSec= + + Allows one to set DHCPv4 lease lifetime when DHCPv4 server does not send the lease + lifetime. Takes one of forever or infinity. If + specified, the acquired address never expires. Defaults to unset. + + + + + + + RequestBroadcast= + + Request the server to use broadcast messages before the IP address has been configured. + This is necessary for devices that cannot receive RAW packets, or that cannot receive packets + at all before an IP address has been configured. On the other hand, this must not be enabled + on networks where broadcasts are filtered out. + + + + + MaxAttempts= + + Specifies how many times the DHCPv4 client configuration should be attempted. Takes a + number or infinity. Defaults to infinity. Note that the + time between retries is increased exponentially, up to approximately one per minute, so the + network will not be overloaded even if this number is high. The default is suitable in most + circumstances. + + + + + ListenPort= + + Set the port from which the DHCP client packets originate. + + + + + DenyList= + + A whitespace-separated list of IPv4 addresses. Each address can optionally take a + prefix length after /. DHCP offers from servers in the list are rejected. + Note that if AllowList= is configured then DenyList= is + ignored. + + + + + AllowList= + + A whitespace-separated list of IPv4 addresses. Each address can optionally take a + prefix length after /. DHCP offers from servers in the list are accepted. + + + + + + SendRelease= + + When true, the DHCPv4 client sends a DHCP release packet when it stops. Defaults to + true. + + + + + SendDecline= + + A boolean. When true, systemd-networkd performs IPv4 Duplicate + Address Detection to the acquired address by the DHCPv4 client. If duplicate is detected, + the DHCPv4 client rejects the address by sending a DHCPDECLINE packet to + the DHCP server, and tries to obtain an IP address again. See + RFC 5227. Defaults to false. + + + + + NetLabel= + + This applies the NetLabel for the addresses received with DHCP, like + NetLabel= in [Address] section applies it to statically configured + addresses. See NetLabel= in [Address] section for more details. + + + + + + + [DHCPv6] Section Options + + The [DHCPv6] section configures the DHCPv6 client, if it is enabled with the + DHCP= setting described above, or invoked by the IPv6 Router Advertisement: + + + + + + + + MUDURL= + IAID= + DUIDType= + DUIDRawData= + RequestOptions= + + As in the [DHCPv4] section. + + + + + SendOption= + + As in the [DHCPv4] section, however because DHCPv6 uses 16-bit fields to store option + numbers, the option number is an integer in the range 1…65536. + + + + + SendVendorOption= + + Send an arbitrary vendor option in the DHCPv6 request. Takes an enterprise identifier, + DHCP option number, data type, and data separated with a colon + (enterprise identifier:option:type:value). + Enterprise identifier is an unsigned integer in the range 1…4294967294. The option number + must be an integer in the range 1…254. Data type takes one of uint8, + uint16, uint32, ipv4address, + ipv6address, or string. Special characters in the data + string may be escaped using + C-style + escapes. This setting can be specified multiple times. If an empty string is + specified, then all options specified earlier are cleared. Defaults to unset. + + + + + UserClass= + + A DHCPv6 client can use User Class option to identify the type or category of user or + applications it represents. The information contained in this option is a string that + represents the user class of which the client is a member. Each class sets an identifying + string of information to be used by the DHCP service to classify clients. Special characters + in the data string may be escaped using + C-style + escapes. This setting can be specified multiple times. If an empty string is + specified, then all options specified earlier are cleared. Takes a whitespace-separated list + of strings. Note that currently NUL bytes are not allowed. + + + + + VendorClass= + + A DHCPv6 client can use VendorClass option to identify the vendor that manufactured the + hardware on which the client is running. The information contained in the data area of this + option is contained in one or more opaque fields that identify details of the hardware + configuration. Takes a whitespace-separated list of strings. + + + + + PrefixDelegationHint= + + Takes an IPv6 address with prefix length in the same format as the + Address= in the [Network] section. The DHCPv6 client will include a prefix + hint in the DHCPv6 solicitation sent to the server. The prefix length must be in the range + 1…128. Defaults to unset. + + + + + RapidCommit= + + Takes a boolean. The DHCPv6 client can obtain configuration parameters from a DHCPv6 server + through a rapid two-message exchange (solicit and reply). When the rapid commit option is set by + both the DHCPv6 client and the DHCPv6 server, the two-message exchange is used. Otherwise, the + four-message exchange (solicit, advertise, request, and reply) is used. The two-message exchange + provides faster client configuration. See + RFC 3315 for details. + Defaults to true, and the two-message exchange will be used if the server support it. + + + + + + + UseAddress= + + When true (the default), the IP addresses provided by the DHCPv6 server will be + assigned. + + + + + UseDelegatedPrefix= + + When true (the default), the client will request the DHCPv6 server to delegate + prefixes. If the server provides prefixes to be delegated, then subnets of the prefixes are + assigned to the interfaces that have DHCPPrefixDelegation=yes. + See also the DHCPPrefixDelegation= setting in the [Network] section, + settings in the [DHCPPrefixDelegation] section, and + RFC 8415. + + + + + + UseDNS= + UseNTP= + UseHostname= + UseDomains= + NetLabel= + + As in the [DHCPv4] section. + + + + + + + WithoutRA= + + Allows DHCPv6 client to start without router advertisements's + managed or other configuration flag. Takes one of + no, solicit, or + information-request. If this is not specified, + solicit is used when DHCPPrefixDelegation= is enabled + and UplinkInterface=:self is specified in the [DHCPPrefixDelegation] + section. Otherwise, defaults to no, and the DHCPv6 client will be started + when an RA is received. See also the DHCPv6Client= setting in the + [IPv6AcceptRA] section. + + + + + + + [DHCPPrefixDelegation] Section Options + The [DHCPPrefixDelegation] section configures subnet prefixes of the delegated prefixes + acquired by a DHCPv6 client, or by a DHCPv4 client through the 6RD option on another interface. + The settings in this section are used only when the DHCPPrefixDelegation= + setting in the [Network] section is enabled. + + + + UplinkInterface= + + Specifies the name or the index of the uplink interface, or one of the special values + :self and :auto. When :self, the + interface itself is considered the uplink interface, and + WithoutRA=solicit is implied if the setting is not explicitly specified. + When :auto, the first link which acquired prefixes to be delegated from + the DHCPv6 or DHCPv4 server is selected. Defaults to :auto. + + + + + SubnetId= + + Configure a specific subnet ID on the interface from a (previously) received prefix + delegation. You can either set "auto" (the default) or a specific subnet ID (as defined in + RFC 4291, section + 2.5.4), in which case the allowed value is hexadecimal, from 0 to 0x7fffffffffffffff + inclusive. + + + + + Announce= + + Takes a boolean. When enabled, and IPv6SendRA= in [Network] section + is enabled, the delegated prefixes are distributed through the IPv6 Router Advertisement. + This setting will be ignored when the DHCPPrefixDelegation= setting is + enabled on the upstream interface. Defaults to yes. + + + + + Assign= + + Takes a boolean. Specifies whether to add an address from the delegated prefixes which + are received from the WAN interface by the DHCPv6 Prefix Delegation. When true (on LAN + interfce), the EUI-64 algorithm will be used by default to form an interface identifier from + the delegated prefixes. See also Token= setting below. Defaults to yes. + + + + + + Token= + + Specifies an optional address generation mode for assigning an address in each + delegated prefix. This accepts the same syntax as Token= in the + [IPv6AcceptRA] section. If Assign= is set to false, then this setting will + be ignored. Defaults to unset, which means the EUI-64 algorithm will be used. + + + + + ManageTemporaryAddress= + + As in the [Address] section, but defaults to true. + + + + + RouteMetric= + + The metric of the route to the delegated prefix subnet. Takes an unsigned integer in + the range 0…4294967295. When set to 0, the kernel's default value is used. Defaults to 256. + + + + + + NetLabel= + + This applies the NetLabel for the addresses received with DHCP, like + NetLabel= in [Address] section applies it to statically configured + addresses. See NetLabel= in [Address] section for more details. + + + + + + + [IPv6AcceptRA] Section Options + The [IPv6AcceptRA] section configures the IPv6 Router Advertisement (RA) client, if it is enabled + with the IPv6AcceptRA= setting described above: + + + + Token= + + Specifies an optional address generation mode for the Stateless Address + Autoconfiguration (SLAAC). The following values are supported: + + + + + + + The EUI-64 algorithm will be used to generate an address for that prefix. Only + supported by Ethernet or InfiniBand interfaces. + + + + + + + + An IPv6 address must be specified after a colon (:), and the + lower bits of the supplied address are combined with the upper bits of a prefix + received in a Router Advertisement (RA) message to form a complete address. Note + that if multiple prefixes are received in an RA message, or in multiple RA messages, + addresses will be formed from each of them using the supplied address. This mode + implements SLAAC but uses a static interface identifier instead of an identifier + generated by using the EUI-64 algorithm. Because the interface identifier is static, + if Duplicate Address Detection detects that the computed address is a duplicate + (in use by another node on the link), then this mode will fail to provide an address + for that prefix. If an IPv6 address without mode is specified, then + static mode is assumed. + + + + + + + + The algorithm specified in + RFC 7217 will be used to + generate interface identifiers. This mode can optionally take an IPv6 address + separated with a colon (:). If an IPv6 address is specified, + then an interface identifier is generated only when a prefix received in an RA + message matches the supplied address. + + + This mode can also optionally take a non-null UUID in the format which + sd_id128_from_string() accepts, e.g. + 86b123b969ba4b7eb8b3d8605123525a or + 86b123b9-69ba-4b7e-b8b3-d8605123525a. If a UUID is specified, the + value is used as the secret key to generate interface identifiers. If not specified, + then an application specific ID generated with the system's machine-ID will be used + as the secret key. See + sd-id1283, + sd_id128_from_string3, + and + sd_id128_get_machine3. + + + Note that the prefixstable algorithm uses both the interface + name and MAC address as input to the hash to compute the interface identifier, so + if either of those are changed the resulting interface identifier (and address) + will be changed, even if the prefix received in the RA message has not been + changed. + + + + + + If no address generation mode is specified (which is the default), or a received + prefix does not match any of the addresses provided in prefixstable + mode, then the EUI-64 algorithm will be used for Ethernet or InfiniBand interfaces, + otherwise prefixstable will be used to form an interface identifier for + that prefix. + + This setting can be specified multiple times. If an empty string is assigned, then + the all previous assignments are cleared. + + Examples: + Token=eui64 +Token=::1a:2b:3c:4d +Token=static:::1a:2b:3c:4d +Token=prefixstable +Token=prefixstable:2002:da8:1:: + + + + + UseDNS= + + When true (the default), the DNS servers received in the Router Advertisement will be used. + + This corresponds to the option in resolv.conf5. + + + + + UseDomains= + + Takes a boolean, or the special value route. When true, the domain name + received via IPv6 Router Advertisement (RA) will be used as DNS search domain over this link, + similarly to the effect of the setting. If set to + route, the domain name received via IPv6 RA will be used for routing DNS queries + only, but not for searching, similarly to the effect of the setting when + the argument is prefixed with ~. Defaults to false. + + It is recommended to enable this option only on trusted networks, as setting this affects resolution + of all hostnames, in particular of single-label names. It is generally safer to use the supplied domain + only as routing domain, rather than as search domain, in order to not have it affect local resolution of + single-label names. + + When set to true, this setting corresponds to the option in resolv.conf5. + + + + + RouteTable=num + + The table identifier for the routes received in the Router Advertisement. Takes one of + predefined names default, main, and local, + and names defined in RouteTable= in + networkd.conf5, + or a number between 1…4294967295. + + When used in combination with VRF=, the VRF's routing table is + used when this parameter is not specified. + + + + + RouteMetric= + + Set the routing metric for the routes received in the Router Advertisement. Takes an + unsigned integer in the range 0…4294967295. Defaults to 1024. + + + + + UseMTU= + + Takes a boolean. When true, the MTU received in the Router Advertisement will be + used. Defaults to true. + + + + + UseGateway= + + When true (the default), the router address will be configured as the default gateway. + + + + + + UseRoutePrefix= + + When true (the default), the routes corresponding to the route prefixes received in + the Router Advertisement will be configured. + + + + + UseAutonomousPrefix= + + When true (the default), the autonomous prefix received in the Router Advertisement will be used and take + precedence over any statically configured ones. + + + + + UseOnLinkPrefix= + + When true (the default), the onlink prefix received in the Router Advertisement will be + used and takes precedence over any statically configured ones. + + + + + RouterDenyList= + + A whitespace-separated list of IPv6 router addresses. Each address can optionally + take a prefix length after /. Any information advertised by the listed + router is ignored. + + + + + RouterAllowList= + + A whitespace-separated list of IPv6 router addresses. Each address can optionally + take a prefix length after /. Only information advertised by the listed + router is accepted. Note that if RouterAllowList= is configured then + RouterDenyList= is ignored. + + + + + PrefixDenyList= + + A whitespace-separated list of IPv6 prefixes. Each prefix can optionally take its + prefix length after /. IPv6 prefixes supplied via router advertisements + in the list are ignored. + + + + + PrefixAllowList= + + A whitespace-separated list of IPv6 prefixes. Each prefix can optionally take its + prefix length after /. IPv6 prefixes supplied via router advertisements + in the list are allowed. Note that if PrefixAllowList= is configured + then PrefixDenyList= is ignored. + + + + + RouteDenyList= + + A whitespace-separated list of IPv6 route prefixes. Each prefix can optionally take + its prefix length after /. IPv6 route prefixes supplied via router + advertisements in the list are ignored. + + + + + RouteAllowList= + + A whitespace-separated list of IPv6 route prefixes. Each prefix can optionally take + its prefix length after /. IPv6 route prefixes supplied via router + advertisements in the list are allowed. Note that if RouteAllowList= is + configured then RouteDenyList= is ignored. + + + + + DHCPv6Client= + + Takes a boolean, or the special value always. When true, the + DHCPv6 client will be started in solicit mode if the RA has the + managed flag or information-request mode if the RA + lacks the managed flag but has the + other configuration flag. If set to always, the + DHCPv6 client will be started in solicit mode when an RA is received, + even if neither the managed nor the + other configuration flag is set in the RA. This will be ignored when + WithoutRA= in the [DHCPv6] section is enabled, or + UplinkInterface=:self in the [DHCPPrefixDelegation] section is + specified. Defaults to true. + + + + + NetLabel= + + This applies the NetLabel for the addresses received with RA, like + NetLabel= in [Address] section applies it to statically configured + addresses. See NetLabel= in [Address] section for more details. + + + + + + + [DHCPServer] Section Options + The [DHCPServer] section contains settings for the DHCP server, if enabled via the + DHCPServer= option described above: + + + + + ServerAddress= + Specifies server address for the DHCP server. Takes an IPv4 address with prefix + length, for example 192.168.0.1/24. This setting may be useful when the link on + which the DHCP server is running has multiple static addresses. When unset, one of static addresses + in the link will be automatically selected. Defaults to unset. + + + + PoolOffset= + PoolSize= + + Configures the pool of addresses to hand out. The pool + is a contiguous sequence of IP addresses in the subnet configured for + the server address, which does not include the subnet nor the broadcast + address. PoolOffset= takes the offset of the pool + from the start of subnet, or zero to use the default value. + PoolSize= takes the number of IP addresses in the + pool or zero to use the default value. By default, the pool starts at + the first address after the subnet address and takes up the rest of + the subnet, excluding the broadcast address. If the pool includes + the server address (the default), this is reserved and not handed + out to clients. + + + + DefaultLeaseTimeSec= + MaxLeaseTimeSec= + + Control the default and maximum DHCP lease + time to pass to clients. These settings take time values in seconds or + another common time unit, depending on the suffix. The default + lease time is used for clients that did not ask for a specific + lease time. If a client asks for a lease time longer than the + maximum lease time, it is automatically shortened to the + specified time. The default lease time defaults to 1h, the + maximum lease time to 12h. Shorter lease times are beneficial + if the configuration data in DHCP leases changes frequently + and clients shall learn the new settings with shorter + latencies. Longer lease times reduce the generated DHCP + network traffic. + + + + UplinkInterface= + Specifies the name or the index of the uplink interface, or one of the special + values :none and :auto. When emitting DNS, NTP, or SIP + servers is enabled but no servers are specified, the servers configured in the uplink interface + will be emitted. When :auto, the link which has a default gateway with the + highest priority will be automatically selected. When :none, no uplink + interface will be selected. Defaults to :auto. + + + + EmitDNS= + DNS= + + EmitDNS= takes a boolean. Configures whether the DHCP leases + handed out to clients shall contain DNS server information. Defaults to yes. + The DNS servers to pass to clients may be configured with the DNS= option, + which takes a list of IPv4 addresses, or special value _server_address which + will be converted to the address used by the DHCP server. + + If the EmitDNS= option is enabled but no servers configured, the + servers are automatically propagated from an "uplink" interface that has appropriate servers + set. The "uplink" interface is determined by the default route of the system with the highest + priority. Note that this information is acquired at the time the lease is handed out, and does + not take uplink interfaces into account that acquire DNS server information at a later point. + If no suitable uplink interface is found the DNS server data from + /etc/resolv.conf is used. Also, note that the leases are not refreshed if + the uplink network configuration changes. To ensure clients regularly acquire the most current + uplink DNS server information, it is thus advisable to shorten the DHCP lease time via + MaxLeaseTimeSec= described above. + + This setting can be specified multiple times. If an empty string is specified, then all + DNS servers specified earlier are cleared. + + + + EmitNTP= + NTP= + EmitSIP= + SIP= + EmitPOP3= + POP3= + EmitSMTP= + SMTP= + EmitLPR= + LPR= + + Similar to the EmitDNS= and DNS= settings + described above, these settings configure whether and what server information for the indicate + protocol shall be emitted as part of the DHCP lease. The same syntax, propagation semantics and + defaults apply as for EmitDNS= and DNS=. + + + + EmitRouter= + Router= + + The EmitRouter= setting takes a boolean value, and configures + whether the DHCP lease should contain the router option. The Router= setting + takes an IPv4 address, and configures the router address to be emitted. When the + Router= setting is not specified, then the server address will be used for + the router option. When the EmitRouter= setting is disabled, the + Router= setting will be ignored. The EmitRouter= setting + defaults to true, and the Router= setting defaults to unset. + + + + + EmitTimezone= + Timezone= + + Takes a boolean. Configures whether the DHCP leases handed out + to clients shall contain timezone information. Defaults to yes. The + Timezone= setting takes a timezone string + (such as Europe/Berlin or + UTC) to pass to clients. If no explicit + timezone is set, the system timezone of the local host is + propagated, as determined by the + /etc/localtime symlink. + + + + BootServerAddress= + + + Takes an IPv4 address of the boot server used by e.g. PXE boot systems. When specified, this + address is sent in the field of the DHCP message header. See RFC 2131 for more details. Defaults to + unset. + + + + + BootServerName= + + + Takes a name of the boot server used by e.g. PXE boot systems. When specified, this name is + sent in the DHCP option 66 ("TFTP server name"). See RFC 2132 for more details. Defaults to + unset. + + Note that typically setting one of BootServerName= or + BootServerAddress= is sufficient, but both can be set too, if desired. + + + + + BootFilename= + + + Takes a path or URL to a file loaded by e.g. a PXE boot loader. When specified, this path is + sent in the DHCP option 67 ("Bootfile name"). See RFC 2132 for more details. Defaults to + unset. + + + + + SendOption= + + Send a raw option with value via DHCPv4 server. Takes a DHCP option number, data type + and data (option:type:value). + The option number is an integer in the range 1…254. The type takes one of uint8, + uint16, uint32, ipv4address, ipv6address, or + string. Special characters in the data string may be escaped using + C-style + escapes. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Defaults to unset. + + + + + SendVendorOption= + + Send a vendor option with value via DHCPv4 server. Takes a DHCP option number, data type + and data (option:type:value). + The option number is an integer in the range 1…254. The type takes one of uint8, + uint16, uint32, ipv4address, or + string. Special characters in the data string may be escaped using + C-style + escapes. This setting can be specified multiple times. If an empty string is specified, + then all options specified earlier are cleared. Defaults to unset. + + + + BindToInterface= + + Takes a boolean value. When yes, DHCP server socket will be bound + to its network interface and all socket communication will be restricted to this interface. + Defaults to yes, except if RelayTarget= is used (see below), + in which case it defaults to no. + + + + RelayTarget= + + Takes an IPv4 address, which must be in the format described in + inet_pton3. + Turns this DHCP server into a DHCP relay agent. See RFC 1542. + The address is the address of DHCP server or another relay agent to forward DHCP messages to and from. + + + + RelayAgentCircuitId= + + Specifies value for Agent Circuit ID suboption of Relay Agent Information option. + Takes a string, which must be in the format string:value, + where value should be replaced with the value of the suboption. + Defaults to unset (means no Agent Circuit ID suboption is generated). + Ignored if RelayTarget= is not specified. + + + + RelayAgentRemoteId= + + Specifies value for Agent Remote ID suboption of Relay Agent Information option. + Takes a string, which must be in the format string:value, + where value should be replaced with the value of the suboption. + Defaults to unset (means no Agent Remote ID suboption is generated). + Ignored if RelayTarget= is not specified. + + + + + + + + [DHCPServerStaticLease] Section Options + The [DHCPServerStaticLease] section configures a static DHCP lease to assign a + fixed IPv4 address to a specific device based on its MAC address. This section can be specified multiple + times. + + + + MACAddress= + + The hardware address of a device to match. This key is mandatory. + + + + Address= + + The IPv4 address that should be assigned to the device that was matched with + MACAddress=. This key is mandatory. + + + + + + [IPv6SendRA] Section Options + The [IPv6SendRA] section contains settings for sending IPv6 Router Advertisements and whether + to act as a router, if enabled via the IPv6SendRA= option described above. IPv6 + network prefixes or routes are defined with one or more [IPv6Prefix] or [IPv6RoutePrefix] sections. + + + + + + Managed= + OtherInformation= + + Takes a boolean. Controls whether a DHCPv6 server is used to acquire IPv6 + addresses on the network link when Managed= + is set to true or if only additional network + information can be obtained via DHCPv6 for the network link when + OtherInformation= is set to + true. Both settings default to + false, which means that a DHCPv6 server is not being + used. + + + + RouterLifetimeSec= + + Takes a timespan. Configures the IPv6 router lifetime in seconds. The value must be 0 + seconds, or between 4 seconds and 9000 seconds. When set to 0, the host is not acting as a router. + Defaults to 1800 seconds (30 minutes). + + + + + RouterPreference= + + Configures IPv6 router preference if + RouterLifetimeSec= is non-zero. Valid values are + high, medium and + low, with normal and + default added as synonyms for + medium just to make configuration easier. See + RFC 4191 + for details. Defaults to medium. + + + + UplinkInterface= + Specifies the name or the index of the uplink interface, or one of the special + values :none and :auto. When emitting DNS servers or + search domains is enabled but no servers are specified, the servers configured in the uplink + interface will be emitted. When :auto, the value specified to the same + setting in the [DHCPPrefixDelegation] section will be used if + DHCPPrefixDelegation= is enabled, otherwise the link which has a default + gateway with the highest priority will be automatically selected. When :none, + no uplink interface will be selected. Defaults to :auto. + + + + EmitDNS= + DNS= + + DNS= specifies a list of recursive DNS server IPv6 addresses + that are distributed via Router Advertisement messages when EmitDNS= is true. + DNS= also takes special value _link_local; in that case + the IPv6 link-local address is distributed. If DNS= is empty, DNS servers are + read from the [Network] section. If the [Network] section does not contain any DNS servers + either, DNS servers from the uplink interface specified in UplinkInterface= + will be used. When EmitDNS= is false, no DNS server information is sent in + Router Advertisement messages. EmitDNS= defaults to true. + + + + EmitDomains= + Domains= + + A list of DNS search domains distributed via Router Advertisement messages when + EmitDomains= is true. If Domains= is empty, DNS search + domains are read from the [Network] section. If the [Network] section does not contain any DNS + search domains either, DNS search domains from the uplink interface specified in + UplinkInterface= will be used. When EmitDomains= is false, + no DNS search domain information is sent in Router Advertisement messages. + EmitDomains= defaults to true. + + + + DNSLifetimeSec= + + Lifetime in seconds for the DNS server addresses listed in + DNS= and search domains listed in Domains=. Defaults to + 3600 seconds (one hour). + + + + + + + [IPv6Prefix] Section Options + One or more [IPv6Prefix] sections contain the IPv6 prefixes that are announced via Router + Advertisements. See RFC 4861 for further + details. + + + + + AddressAutoconfiguration= + OnLink= + + Takes a boolean to specify whether IPv6 addresses can be + autoconfigured with this prefix and whether the prefix can be used for + onlink determination. Both settings default to true + in order to ease configuration. + + + + + Prefix= + + The IPv6 prefix that is to be distributed to hosts. Similarly to configuring static + IPv6 addresses, the setting is configured as an IPv6 prefix and its prefix length, separated by a + / character. Use multiple [IPv6Prefix] sections to configure multiple IPv6 + prefixes since prefix lifetimes, address autoconfiguration and onlink status may differ from one + prefix to another. + + + + PreferredLifetimeSec= + ValidLifetimeSec= + + Preferred and valid lifetimes for the prefix measured in seconds. + PreferredLifetimeSec= defaults to 1800 seconds (30 minutes) and + ValidLifetimeSec= defaults to 3600 seconds (one hour). + + + + Assign= + Takes a boolean. When true, adds an address from the prefix. Default to false. + + + + + Token= + + Specifies an optional address generation mode for assigning an address in each + prefix. This accepts the same syntax as Token= in the [IPv6AcceptRA] + section. If Assign= is set to false, then this setting will be ignored. + Defaults to unset, which means the EUI-64 algorithm will be used. + + + + + RouteMetric= + + The metric of the prefix route. Takes an unsigned integer in the range 0…4294967295. + When unset or set to 0, the kernel's default value is used. This setting is ignored when + Assign= is false. + + + + + + + [IPv6RoutePrefix] Section Options + One or more [IPv6RoutePrefix] sections contain the IPv6 + prefix routes that are announced via Router Advertisements. See + RFC 4191 + for further details. + + + + + Route= + + The IPv6 route that is to be distributed to hosts. Similarly to configuring static + IPv6 routes, the setting is configured as an IPv6 prefix routes and its prefix route length, + separated by a / character. Use multiple [IPv6RoutePrefix] sections to configure + multiple IPv6 prefix routes. + + + + LifetimeSec= + + Lifetime for the route prefix measured in seconds. + LifetimeSec= defaults to 3600 seconds (one hour). + + + + + + + [Bridge] Section Options + The [Bridge] section accepts the following keys: + + + UnicastFlood= + + Takes a boolean. Controls whether the bridge should flood + traffic for which an FDB entry is missing and the destination + is unknown through this port. When unset, the kernel's default will be used. + + + + + MulticastFlood= + + Takes a boolean. Controls whether the bridge should flood + traffic for which an MDB entry is missing and the destination + is unknown through this port. When unset, the kernel's default will be used. + + + + + MulticastToUnicast= + + Takes a boolean. Multicast to unicast works on top of the multicast snooping feature of + the bridge. Which means unicast copies are only delivered to hosts which are interested in it. + When unset, the kernel's default will be used. + + + + + NeighborSuppression= + + Takes a boolean. Configures whether ARP and ND neighbor suppression is enabled for + this port. When unset, the kernel's default will be used. + + + + + Learning= + + Takes a boolean. Configures whether MAC address learning is enabled for + this port. When unset, the kernel's default will be used. + + + + + HairPin= + + Takes a boolean. Configures whether traffic may be sent back out of the port on which it + was received. When this flag is false, then the bridge will not forward traffic back out of the + receiving port. When unset, the kernel's default will be used. + + + + Isolated= + + Takes a boolean. Configures whether this port is isolated or not. Within a bridge, + isolated ports can only communicate with non-isolated ports. When set to true, this port can only + communicate with other ports whose Isolated setting is false. When set to false, this port + can communicate with any other ports. When unset, the kernel's default will be used. + + + + UseBPDU= + + Takes a boolean. Configures whether STP Bridge Protocol Data Units will be + processed by the bridge port. When unset, the kernel's default will be used. + + + + FastLeave= + + Takes a boolean. This flag allows the bridge to immediately stop multicast + traffic on a port that receives an IGMP Leave message. It is only used with + IGMP snooping if enabled on the bridge. When unset, the kernel's default will be used. + + + + AllowPortToBeRoot= + + Takes a boolean. Configures whether a given port is allowed to + become a root port. Only used when STP is enabled on the bridge. + When unset, the kernel's default will be used. + + + + ProxyARP= + + Takes a boolean. Configures whether proxy ARP to be enabled on this port. + When unset, the kernel's default will be used. + + + + ProxyARPWiFi= + + Takes a boolean. Configures whether proxy ARP to be enabled on this port + which meets extended requirements by IEEE 802.11 and Hotspot 2.0 specifications. + When unset, the kernel's default will be used. + + + + MulticastRouter= + + Configures this port for having multicast routers attached. A port with a multicast + router will receive all multicast traffic. Takes one of no + to disable multicast routers on this port, query to let the system detect + the presence of routers, permanent to permanently enable multicast traffic + forwarding on this port, or temporary to enable multicast routers temporarily + on this port, not depending on incoming queries. When unset, the kernel's default will be used. + + + + Cost= + + Sets the "cost" of sending packets of this interface. + Each port in a bridge may have a different speed and the cost + is used to decide which link to use. Faster interfaces + should have lower costs. It is an integer value between 1 and + 65535. + + + + Priority= + + Sets the "priority" of sending packets on this interface. + Each port in a bridge may have a different priority which is used + to decide which link to use. Lower value means higher priority. + It is an integer value between 0 to 63. Networkd does not set any + default, meaning the kernel default value of 32 is used. + + + + + + [BridgeFDB] Section Options + The [BridgeFDB] section manages the forwarding database table of a port and accepts the following + keys. Specify several [BridgeFDB] sections to configure several static MAC table entries. + + + + MACAddress= + + As in the [Network] section. This key is mandatory. + + + + Destination= + + Takes an IP address of the destination VXLAN tunnel endpoint. + + + + VLANId= + + The VLAN ID for the new static MAC table entry. If + omitted, no VLAN ID information is appended to the new static MAC + table entry. + + + + VNI= + + The VXLAN Network Identifier (or VXLAN Segment ID) to use to connect to + the remote VXLAN tunnel endpoint. Takes a number in the range 1…16777215. + Defaults to unset. + + + + AssociatedWith= + + Specifies where the address is associated with. Takes one of use, + self, master or router. + use means the address is in use. User space can use this option to + indicate to the kernel that the fdb entry is in use. self means + the address is associated with the port drivers fdb. Usually hardware. master + means the address is associated with master devices fdb. router means + the destination address is associated with a router. Note that it's valid if the referenced + device is a VXLAN type device and has route shortcircuit enabled. Defaults to self. + + + + OutgoingInterface= + + Specifies the name or index of the outgoing interface for the VXLAN device driver to + reach the remote VXLAN tunnel endpoint. Defaults to unset. + + + + + + [BridgeMDB] Section Options + The [BridgeMDB] section manages the multicast membership entries forwarding database table of a port and accepts the following + keys. Specify several [BridgeMDB] sections to configure several permanent multicast membership entries. + + + + MulticastGroupAddress= + + Specifies the IPv4 or IPv6 multicast group address to add. This setting is mandatory. + + + + VLANId= + + The VLAN ID for the new entry. Valid ranges are 0 (no VLAN) to 4094. Optional, defaults to 0. + + + + + + + [LLDP] Section Options + The [LLDP] section manages the Link Layer Discovery Protocol (LLDP) and accepts the following + keys: + + + MUDURL= + + When configured, the specified Manufacturer Usage Descriptions (MUD) URL will be sent in + LLDP packets. The syntax and semantics are the same as for MUDURL= in the + [DHCPv4] section described above. + + The MUD URLs received via LLDP packets are saved and can be read using the + sd_lldp_neighbor_get_mud_url() function. + + + + + + + [CAN] Section Options + The [CAN] section manages the Controller Area Network (CAN bus) and accepts the + following keys: + + + BitRate= + + The bitrate of CAN device in bits per second. The usual SI prefixes (K, M) with the base of 1000 can + be used here. Takes a number in the range 1…4294967295. + + + + SamplePoint= + + Optional sample point in percent with one decimal (e.g. 75%, + 87.5%) or permille (e.g. 875‰). This will be ignored when + BitRate= is unspecified. + + + + TimeQuantaNSec= + PropagationSegment= + PhaseBufferSegment1= + PhaseBufferSegment2= + SyncJumpWidth= + + Specifies the time quanta, propagation segment, phase buffer segment 1 and 2, and the + synchronization jump width, which allow one to define the CAN bit-timing in a hardware + independent format as proposed by the Bosch CAN 2.0 Specification. + TimeQuantaNSec= takes a timespan in nanoseconds. + PropagationSegment=, PhaseBufferSegment1=, + PhaseBufferSegment2=, and SyncJumpWidth= take number + of time quantum specified in TimeQuantaNSec= and must be an unsigned + integer in the range 0…4294967295. These settings except for + SyncJumpWidth= will be ignored when BitRate= is + specified. + + + + DataBitRate= + DataSamplePoint= + + The bitrate and sample point for the data phase, if CAN-FD is used. These settings are + analogous to the BitRate= and SamplePoint= keys. + + + + DataTimeQuantaNSec= + DataPropagationSegment= + DataPhaseBufferSegment1= + DataPhaseBufferSegment2= + DataSyncJumpWidth= + + Specifies the time quanta, propagation segment, phase buffer segment 1 and 2, and the + synchronization jump width for the data phase, if CAN-FD is used. These settings are + analogous to the TimeQuantaNSec= or related settings. + + + + FDMode= + + Takes a boolean. When yes, CAN-FD mode is enabled for the interface. + Note, that a bitrate and optional sample point should also be set for the CAN-FD data phase using + the DataBitRate= and DataSamplePoint= keys, or + DataTimeQuanta= and related settings. + + + + FDNonISO= + + Takes a boolean. When yes, non-ISO CAN-FD mode is enabled for the + interface. When unset, the kernel's default will be used. + + + + RestartSec= + + Automatic restart delay time. If set to a non-zero value, a restart of the CAN controller will be + triggered automatically in case of a bus-off condition after the specified delay time. Subsecond delays can + be specified using decimals (e.g. 0.1s) or a ms or + us postfix. Using infinity or 0 will turn the + automatic restart off. By default automatic restart is disabled. + + + + Termination= + + Takes a boolean or a termination resistor value in ohm in the range 0…65535. When + yes, the termination resistor is set to 120 ohm. When + no or 0 is set, the termination resistor is disabled. + When unset, the kernel's default will be used. + + + + TripleSampling= + + Takes a boolean. When yes, three samples (instead of one) are used to determine + the value of a received bit by majority rule. When unset, the kernel's default will be used. + + + + BusErrorReporting= + + Takes a boolean. When yes, reporting of CAN bus errors is activated + (those include single bit, frame format, and bit stuffing errors, unable to send dominant bit, + unable to send recessive bit, bus overload, active error announcement, error occurred on + transmission). When unset, the kernel's default will be used. Note: in case of a CAN bus with a + single CAN device, sending a CAN frame may result in a huge number of CAN bus errors. + + + + ListenOnly= + + Takes a boolean. When yes, listen-only mode is enabled. When the + interface is in listen-only mode, the interface neither transmit CAN frames nor send ACK + bit. Listen-only mode is important to debug CAN networks without interfering with the + communication or acknowledge the CAN frame. When unset, the kernel's default will be used. + + + + + Loopback= + + Takes a boolean. When yes, loopback mode is enabled. When the + loopback mode is enabled, the interface treats messages transmitted by itself as received + messages. The loopback mode is important to debug CAN networks. When unset, the kernel's + default will be used. + + + + OneShot= + + Takes a boolean. When yes, one-shot mode is enabled. When unset, + the kernel's default will be used. + + + + PresumeAck= + + Takes a boolean. When yes, the interface will ignore missing CAN + ACKs. When unset, the kernel's default will be used. + + + + ClassicDataLengthCode= + + Takes a boolean. When yes, the interface will handle the 4bit data + length code (DLC). When unset, the kernel's default will be used. + + + + + + + [IPoIB] Section Options + The [IPoIB] section manages the IP over Infiniband and accepts the following keys: + + + + + + + + [QDisc] Section Options + The [QDisc] section manages the traffic control queueing discipline (qdisc). + + + + Parent= + + Specifies the parent Queueing Discipline (qdisc). Takes one of clsact + or ingress. This is mandatory. + + + + + + + + + [NetworkEmulator] Section Options + The [NetworkEmulator] section manages the queueing discipline (qdisc) of the network emulator. It + can be used to configure the kernel packet scheduler and simulate packet delay and loss for UDP or TCP + applications, or limit the bandwidth usage of a particular service to simulate internet connections. + + + + + + + + DelaySec= + + Specifies the fixed amount of delay to be added to all packets going out of the + interface. Defaults to unset. + + + + + DelayJitterSec= + + Specifies the chosen delay to be added to the packets outgoing to the network + interface. Defaults to unset. + + + + + PacketLimit= + + Specifies the maximum number of packets the qdisc may hold queued at a time. + An unsigned integer in the range 0…4294967294. Defaults to 1000. + + + + + LossRate= + + Specifies an independent loss probability to be added to the packets outgoing from the + network interface. Takes a percentage value, suffixed with "%". Defaults to unset. + + + + + DuplicateRate= + + Specifies that the chosen percent of packets is duplicated before queuing them. + Takes a percentage value, suffixed with "%". Defaults to unset. + + + + + + + [TokenBucketFilter] Section Options + The [TokenBucketFilter] section manages the queueing discipline (qdisc) of token bucket filter + (tbf). + + + + + + + LatencySec= + + Specifies the latency parameter, which specifies the maximum amount of time a + packet can sit in the Token Bucket Filter (TBF). Defaults to unset. + + + + + LimitBytes= + + Takes the number of bytes that can be queued waiting for tokens to become available. + When the size is suffixed with K, M, or G, it is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. Defaults to unset. + + + + + BurstBytes= + + Specifies the size of the bucket. This is the maximum amount of bytes that tokens + can be available for instantaneous transfer. When the size is suffixed with K, M, or G, it is + parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to + unset. + + + + + Rate= + + Specifies the device specific bandwidth. When suffixed with K, M, or G, the specified + bandwidth is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of 1000. + Defaults to unset. + + + + + MPUBytes= + + The Minimum Packet Unit (MPU) determines the minimal token usage (specified in bytes) + for a packet. When suffixed with K, M, or G, the specified size is parsed as Kilobytes, + Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to zero. + + + + + PeakRate= + + Takes the maximum depletion rate of the bucket. When suffixed with K, M, or G, the + specified size is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of + 1000. Defaults to unset. + + + + + MTUBytes= + + Specifies the size of the peakrate bucket. When suffixed with K, M, or G, the specified + size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. + Defaults to unset. + + + + + + + [PIE] Section Options + The [PIE] section manages the queueing discipline (qdisc) of Proportional Integral + controller-Enhanced (PIE). + + + + + + + PacketLimit= + + Specifies the hard limit on the queue size in number of packets. When this limit is reached, + incoming packets are dropped. An unsigned integer in the range 1…4294967294. Defaults to unset and + kernel's default is used. + + + + + + + [FlowQueuePIE] Section Options + The [FlowQueuePIE] section manages the queueing discipline + (qdisc) of Flow Queue Proportional Integral controller-Enhanced (fq_pie). + + + + + + + PacketLimit= + + Specifies the hard limit on the queue size in number of packets. When this limit is reached, + incoming packets are dropped. An unsigned integer ranges 1 to 4294967294. Defaults to unset and + kernel's default is used. + + + + + + + [StochasticFairBlue] Section Options + The [StochasticFairBlue] section manages the queueing discipline (qdisc) of stochastic fair blue + (sfb). + + + + + + + PacketLimit= + + Specifies the hard limit on the queue size in number of packets. When this limit is reached, + incoming packets are dropped. An unsigned integer in the range 0…4294967294. Defaults to unset and + kernel's default is used. + + + + + + + [StochasticFairnessQueueing] Section Options + The [StochasticFairnessQueueing] section manages the queueing discipline (qdisc) of stochastic + fairness queueing (sfq). + + + + + + + PerturbPeriodSec= + + Specifies the interval in seconds for queue algorithm perturbation. Defaults to unset. + + + + + + + [BFIFO] Section Options + The [BFIFO] section manages the queueing discipline (qdisc) of Byte limited Packet First In First + Out (bfifo). + + + + + + + LimitBytes= + + Specifies the hard limit in bytes on the FIFO buffer size. The size limit prevents overflow + in case the kernel is unable to dequeue packets as quickly as it receives them. When this limit is + reached, incoming packets are dropped. When suffixed with K, M, or G, the specified size is parsed + as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and + kernel default is used. + + + + + + + [PFIFO] Section Options + The [PFIFO] section manages the queueing discipline (qdisc) of Packet First In First Out + (pfifo). + + + + + + + PacketLimit= + + Specifies the hard limit on the number of packets in the FIFO queue. The size limit prevents + overflow in case the kernel is unable to dequeue packets as quickly as it receives them. When this + limit is reached, incoming packets are dropped. An unsigned integer in the range + 0…4294967294. Defaults to unset and kernel's default is used. + + + + + + + [PFIFOHeadDrop] Section Options + The [PFIFOHeadDrop] section manages the queueing discipline (qdisc) of Packet First In First Out + Head Drop (pfifo_head_drop). + + + + + + + PacketLimit= + + As in [PFIFO] section. + + + + + + [PFIFOFast] Section Options + The [PFIFOFast] section manages the queueing discipline (qdisc) of Packet First In First Out Fast + (pfifo_fast). + + + + + + + + + [CAKE] Section Options + The [CAKE] section manages the queueing discipline (qdisc) of Common Applications Kept Enhanced + (CAKE). + + + + + + + Bandwidth= + + Specifies the shaper bandwidth. When suffixed with K, M, or G, the specified size is + parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of 1000. Defaults to + unset and kernel's default is used. + + + + + AutoRateIngress= + + Takes a boolean value. Enables automatic capacity estimation based on traffic arriving + at this qdisc. This is most likely to be useful with cellular links, which tend to change + quality randomly. If this setting is enabled, the Bandwidth= setting is + used as an initial estimate. Defaults to unset, and the kernel's default is used. + + + + + OverheadBytes= + + Specifies that bytes to be addeded to the size of each packet. Bytes may be negative. + Takes an integer in the range -64…256. Defaults to unset and kernel's default is used. + + + + + + MPUBytes= + + Rounds each packet (including overhead) up to the specified bytes. Takes an integer in + the range 1…256. Defaults to unset and kernel's default is used. + + + + + CompensationMode= + + Takes one of none, atm, or ptm. + Specifies the compensation mode for overhead calculation. When none, no + compensation is taken into account. When atm, enables the compensation for + ATM cell framing, which is normally found on ADSL links. When ptm, enables + the compensation for PTM encoding, which is normally found on VDSL2 links and uses a 64b/65b + encoding scheme. Defaults to unset and the kernel's default is used. + + + + + UseRawPacketSize= + + Takes a boolean value. When true, the packet size reported by the Linux kernel will be + used, instead of the underlying IP packet size. Defaults to unset, and the kernel's default + is used. + + + + + FlowIsolationMode= + + CAKE places packets from different flows into different queues, then packets from each + queue are delivered fairly. This specifies whether the fairness is based on source address, + destination address, individual flows, or any combination of those. The available values are: + + + + + + + The flow isolation is disabled, and all traffic passes through a single queue. + + + + + + Flows are defined only by source address. Equivalent to the srchost + option for tc qdisc command. See also + tc-cake8. + + + + + + Flows are defined only by destination address. Equivalent to the + dsthost option for tc qdisc command. See also + tc-cake8. + + + + + + Flows are defined by source-destination host pairs. Equivalent to the same option for + tc qdisc command. See also + tc-cake8. + + + + + + Flows are defined by the entire 5-tuple of source address, destination address, + transport protocol, source port and destination port. Equivalent to the same option for + tc qdisc command. See also + tc-cake8. + + + + + + Flows are defined by the 5-tuple (see flows in the above), and + fairness is applied first over source addresses, then over individual flows. Equivalent + to the dual-srchost option for tc qdisc command. + See also + tc-cake8. + + + + + + Flows are defined by the 5-tuple (see flows in the above), and + fairness is applied first over destination addresses, then over individual flows. + Equivalent to the dual-dsthost option for + tc qdisc command. See also + tc-cake8. + + + + + + Flows are defined by the 5-tuple (see flows), and fairness is + applied over source and destination addresses, and also over individual flows. + Equivalent to the triple-isolate option for + tc qdisc command. See also + tc-cake8. + + + + + Defaults to unset and the kernel's default is used. + + + + + NAT= + + Takes a boolean value. When true, CAKE performs a NAT lookup before applying + flow-isolation rules, to determine the true addresses and port numbers of the packet, to + improve fairness between hosts inside the NAT. This has no practical effect when + FlowIsolationMode= is none or flows, + or if NAT is performed on a different host. Defaults to unset, and the kernel's default is + used. + + + + + PriorityQueueingPreset= + + CAKE divides traffic into tins, and each tin has its own independent + set of flow-isolation queues, bandwidth threshold, and priority. This specifies the preset of + tin profiles. The available values are: + + + + + + Disables priority queueing by placing all traffic in one tin. + + + + + + Enables priority queueing based on the legacy interpretation of TOS + Precedence field. Use of this preset on the modern Internet is + firmly discouraged. + + + + + + Enables priority queueing based on the Differentiated Service + (DiffServ) field with eight tins: Background Traffic, High + Throughput, Best Effort, Video Streaming, Low Latency Transactions, Interactive Shell, + Minimum Latency, and Network Control. + + + + + + Enables priority queueing based on the Differentiated Service + (DiffServ) field with four tins: Background Traffic, Best Effort, + Streaming Media, and Latency Sensitive. + + + + + + Enables priority queueing based on the Differentiated Service + (DiffServ) field with three tins: Background Traffic, Best Effort, + and Latency Sensitive. + + + + + Defaults to unset, and the kernel's default is used. + + + + + FirewallMark= + + Takes an integer in the range 1…4294967295. When specified, firewall-mark-based + overriding of CAKE's tin selection is enabled. Defaults to unset, and the kernel's default is + used. + + + + + Wash= + + Takes a boolean value. When true, CAKE clears the DSCP fields, except for ECN bits, of + any packet passing through CAKE. Defaults to unset, and the kernel's default is used. + + + + + SplitGSO= + + Takes a boolean value. When true, CAKE will split General Segmentation Offload (GSO) + super-packets into their on-the-wire components and dequeue them individually. Defaults to + unset, and the kernel's default is used. + + + + + + + + [ControlledDelay] Section Options + The [ControlledDelay] section manages the queueing discipline (qdisc) of + controlled delay (CoDel). + + + + + + + PacketLimit= + + Specifies the hard limit on the queue size in number of packets. When this limit is reached, + incoming packets are dropped. An unsigned integer in the range 0…4294967294. Defaults to unset and + kernel's default is used. + + + + + TargetSec= + + Takes a timespan. Specifies the acceptable minimum standing/persistent queue delay. + Defaults to unset and kernel's default is used. + + + + + IntervalSec= + + Takes a timespan. This is used to ensure that the measured minimum delay does not + become too stale. Defaults to unset and kernel's default is used. + + + + + ECN= + + Takes a boolean. This can be used to mark packets instead of dropping them. Defaults to + unset and kernel's default is used. + + + + + CEThresholdSec= + + Takes a timespan. This sets a threshold above which all packets are marked with ECN + Congestion Experienced (CE). Defaults to unset and kernel's default is used. + + + + + + + [DeficitRoundRobinScheduler] Section Options + The [DeficitRoundRobinScheduler] section manages the queueing discipline (qdisc) of Deficit Round + Robin Scheduler (DRR). + + + + + + + + + [DeficitRoundRobinSchedulerClass] Section Options + The [DeficitRoundRobinSchedulerClass] section manages the traffic control class of Deficit Round + Robin Scheduler (DRR). + + + + + + + QuantumBytes= + + Specifies the amount of bytes a flow is allowed to dequeue before the scheduler moves + to the next class. When suffixed with K, M, or G, the specified size is parsed as Kilobytes, + Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to the MTU of the + interface. + + + + + + + + [EnhancedTransmissionSelection] Section Options + The [EnhancedTransmissionSelection] section manages the queueing discipline (qdisc) of Enhanced + Transmission Selection (ETS). + + + + + + + Bands= + + Specifies the number of bands. An unsigned integer in the range 1…16. This value has to be at + least large enough to cover the strict bands specified through the StrictBands= + and bandwidth-sharing bands specified in QuantumBytes=. + + + + + StrictBands= + + Specifies the number of bands that should be created in strict mode. An unsigned integer in + the range 1…16. + + + + + QuantumBytes= + + Specifies the white-space separated list of quantum used in band-sharing bands. When + suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. This setting can be specified multiple times. If an empty + string is assigned, then the all previous assignments are cleared. + + + + + PriorityMap= + + The priority map maps the priority of a packet to a band. The argument is a whitespace + separated list of numbers. The first number indicates which band the packets with priority 0 should + be put to, the second is for priority 1, and so on. There can be up to 16 numbers in the list. If + there are fewer, the default band that traffic with one of the unmentioned priorities goes to is + the last one. Each band number must be in the range 0…255. This setting can be specified multiple + times. If an empty string is assigned, then the all previous assignments are cleared. + + + + + + + [GenericRandomEarlyDetection] Section Options + The [GenericRandomEarlyDetection] section manages the queueing discipline (qdisc) of Generic Random + Early Detection (GRED). + + + + + + + VirtualQueues= + + Specifies the number of virtual queues. Takes an integer in the range 1…16. Defaults to unset + and kernel's default is used. + + + + + DefaultVirtualQueue= + + Specifies the number of default virtual queue. This must be less than VirtualQueue=. + Defaults to unset and kernel's default is used. + + + + + GenericRIO= + + Takes a boolean. It turns on the RIO-like buffering scheme. Defaults to + unset and kernel's default is used. + + + + + + + [FairQueueingControlledDelay] Section Options + The [FairQueueingControlledDelay] section manages the queueing discipline (qdisc) of fair queuing + controlled delay (FQ-CoDel). + + + + + + + PacketLimit= + + Specifies the hard limit on the real queue size. When this limit is reached, incoming packets are + dropped. Defaults to unset and kernel's default is used. + + + + + MemoryLimitBytes= + + Specifies the limit on the total number of bytes that can be queued in this FQ-CoDel instance. + When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. Defaults to unset and kernel's default is used. + + + + + Flows= + + Specifies the number of flows into which the incoming packets are classified. + Defaults to unset and kernel's default is used. + + + + + TargetSec= + + Takes a timespan. Specifies the acceptable minimum standing/persistent queue delay. + Defaults to unset and kernel's default is used. + + + + + IntervalSec= + + Takes a timespan. This is used to ensure that the measured minimum delay does not + become too stale. Defaults to unset and kernel's default is used. + + + + + QuantumBytes= + + Specifies the number of bytes used as the "deficit" in the fair queuing algorithm timespan. + When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. Defaults to unset and kernel's default is used. + + + + + ECN= + + Takes a boolean. This can be used to mark packets instead of dropping them. Defaults to + unset and kernel's default is used. + + + + + CEThresholdSec= + + Takes a timespan. This sets a threshold above which all packets are marked with ECN + Congestion Experienced (CE). Defaults to unset and kernel's default is used. + + + + + + + [FairQueueing] Section Options + The [FairQueueing] section manages the queueing discipline (qdisc) of fair queue traffic policing + (FQ). + + + + + + + PacketLimit= + + Specifies the hard limit on the real queue size. When this limit is reached, incoming packets are + dropped. Defaults to unset and kernel's default is used. + + + + + FlowLimit= + + Specifies the hard limit on the maximum number of packets queued per flow. Defaults to + unset and kernel's default is used. + + + + + QuantumBytes= + + Specifies the credit per dequeue RR round, i.e. the amount of bytes a flow is allowed + to dequeue at once. When suffixed with K, M, or G, the specified size is parsed as Kilobytes, + Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and kernel's + default is used. + + + + + InitialQuantumBytes= + + Specifies the initial sending rate credit, i.e. the amount of bytes a new flow is + allowed to dequeue initially. When suffixed with K, M, or G, the specified size is parsed as + Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and + kernel's default is used. + + + + + MaximumRate= + + Specifies the maximum sending rate of a flow. When suffixed with K, M, or G, the + specified size is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of + 1000. Defaults to unset and kernel's default is used. + + + + + Buckets= + + Specifies the size of the hash table used for flow lookups. Defaults to unset and + kernel's default is used. + + + + + OrphanMask= + + Takes an unsigned integer. For packets not owned by a socket, fq is able to mask a part + of hash and reduce number of buckets associated with the traffic. Defaults to unset and + kernel's default is used. + + + + + Pacing= + + Takes a boolean, and enables or disables flow pacing. Defaults to unset and kernel's + default is used. + + + + + CEThresholdSec= + + Takes a timespan. This sets a threshold above which all packets are marked with ECN + Congestion Experienced (CE). Defaults to unset and kernel's default is used. + + + + + + + [TrivialLinkEqualizer] Section Options + The [TrivialLinkEqualizer] section manages the queueing discipline (qdisc) of trivial link + equalizer (teql). + + + + + + + Id= + + Specifies the interface ID N of teql. Defaults to 0. + Note that when teql is used, currently, the module sch_teql with + max_equalizers=N+1 option must be loaded before + systemd-networkd is started. + + + + + + + [HierarchyTokenBucket] Section Options + The [HierarchyTokenBucket] section manages the queueing discipline (qdisc) of hierarchy token + bucket (htb). + + + + + + + DefaultClass= + + Takes the minor id in hexadecimal of the default class. Unclassified traffic gets sent + to the class. Defaults to unset. + + + + + RateToQuantum= + + Takes an unsigned integer. The DRR quantums are calculated by dividing the value + configured in Rate= by RateToQuantum=. + + + + + + + [HierarchyTokenBucketClass] Section Options + The [HierarchyTokenBucketClass] section manages the traffic control class of hierarchy token bucket + (htb). + + + + + + + Priority= + + Specifies the priority of the class. In the round-robin process, classes with the lowest + priority field are tried for packets first. + + + + + QuantumBytes= + + Specifies how many bytes to serve from leaf at once. When suffixed with K, M, or G, the + specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of + 1024. + + + + + MTUBytes= + + Specifies the maximum packet size we create. When suffixed with K, M, or G, the specified + size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. + + + + + OverheadBytes= + + Takes an unsigned integer which specifies per-packet size overhead used in rate + computations. When suffixed with K, M, or G, the specified size is parsed as Kilobytes, + Megabytes, or Gigabytes, respectively, to the base of 1024. + + + + + Rate= + + Specifies the maximum rate this class and all its children are guaranteed. When suffixed + with K, M, or G, the specified size is parsed as Kilobits, Megabits, or Gigabits, respectively, + to the base of 1000. This setting is mandatory. + + + + + CeilRate= + + Specifies the maximum rate at which a class can send, if its parent has bandwidth to spare. + When suffixed with K, M, or G, the specified size is parsed as Kilobits, Megabits, or Gigabits, + respectively, to the base of 1000. When unset, the value specified with Rate= + is used. + + + + + BufferBytes= + + Specifies the maximum bytes burst which can be accumulated during idle period. When suffixed + with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, + to the base of 1024. + + + + + CeilBufferBytes= + + Specifies the maximum bytes burst for ceil which can be accumulated during idle period. + When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, + respectively, to the base of 1024. + + + + + + + [HeavyHitterFilter] Section Options + The [HeavyHitterFilter] section manages the queueing discipline (qdisc) of Heavy Hitter Filter + (hhf). + + + + + + + PacketLimit= + + Specifies the hard limit on the queue size in number of packets. When this limit is reached, + incoming packets are dropped. An unsigned integer in the range 0…4294967294. Defaults to unset and + kernel's default is used. + + + + + + + [QuickFairQueueing] Section Options + The [QuickFairQueueing] section manages the queueing discipline (qdisc) of Quick Fair Queueing + (QFQ). + + + + + + + + + [QuickFairQueueingClass] Section Options + The [QuickFairQueueingClass] section manages the traffic control class of Quick Fair Queueing + (qfq). + + + + + + + Weight= + + Specifies the weight of the class. Takes an integer in the range 1…1023. Defaults to + unset in which case the kernel default is used. + + + + + MaxPacketBytes= + + Specifies the maximum packet size in bytes for the class. When suffixed with K, M, or G, the + specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of + 1024. When unset, the kernel default is used. + + + + + + + [BridgeVLAN] Section Options + The [BridgeVLAN] section manages the VLAN ID configuration of a bridge port and accepts the + following keys. Specify several [BridgeVLAN] sections to configure several VLAN entries. The + VLANFiltering= option has to be enabled, see the [Bridge] section in + systemd.netdev5. + + + + VLAN= + + The VLAN ID allowed on the port. This can be either a single ID or a range M-N. Takes + an integer in the range 1…4094. + + + + EgressUntagged= + + The VLAN ID specified here will be used to untag frames on egress. Configuring + EgressUntagged= implicates the use of VLAN= above and will enable the + VLAN ID for ingress as well. This can be either a single ID or a range M-N. + + + + PVID= + + The Port VLAN ID specified here is assigned to all untagged frames at ingress. + PVID= can be used only once. Configuring PVID= implicates the use of + VLAN= above and will enable the VLAN ID for ingress as well. + + + + + + + Examples + + Static network configuration + + # /etc/systemd/network/50-static.network +[Match] +Name=enp2s0 + +[Network] +Address=192.168.0.15/24 +Gateway=192.168.0.1 + + This brings interface enp2s0 up with a static address. The + specified gateway will be used for a default route. + + + + DHCP on ethernet links + + # /etc/systemd/network/80-dhcp.network +[Match] +Name=en* + +[Network] +DHCP=yes + + This will enable DHCPv4 and DHCPv6 on all interfaces with names starting with + en (i.e. ethernet interfaces). + + + + IPv6 Prefix Delegation (DHCPv6 PD) + + # /etc/systemd/network/55-dhcpv6-pd-upstream.network +[Match] +Name=enp1s0 + +[Network] +DHCP=ipv6 + +# The below setting is optional, to also assign an address in the delegated prefix +# to the upstream interface. If not necessary, then comment out the line below and +# the [DHCPPrefixDelegation] section. +DHCPPrefixDelegation=yes + +# If the upstream network provides Router Advertisement with Managed bit set, +# then comment out the line below and WithoutRA= setting in the [DHCPv6] section. +IPv6AcceptRA=no + +[DHCPv6] +WithoutRA=solicit + +[DHCPPrefixDelegation] +UplinkInterface=:self +SubnetId=0 +Announce=no + + # /etc/systemd/network/55-dhcpv6-pd-downstream.network +[Match] +Name=enp2s0 + +[Network] +DHCPPrefixDelegation=yes +IPv6SendRA=yes + +# It is expected that the host is acting as a router. So, usually it is not +# necessary to receive Router Advertisement from other hosts in the downstream network. +IPv6AcceptRA=no + +[DHCPPrefixDelegation] +UplinkInterface=enp1s0 +SubnetId=1 +Announce=yes + + This will enable DHCPv6-PD on the interface enp1s0 as an upstream interface where the + DHCPv6 client is running and enp2s0 as a downstream interface where the prefix is delegated to. + The delegated prefixes are distributed by IPv6 Router Advertisement on the downstream network. + + + + + IPv6 Prefix Delegation (DHCPv4 6RD) + + # /etc/systemd/network/55-dhcpv4-6rd-upstream.network +[Match] +Name=enp1s0 + +[Network] +DHCP=ipv4 + +# When DHCPv4-6RD is used, the upstream network does not support IPv6. +# Hence, it is not necessary to wait for Router Advertisement, which is enabled by default. +IPv6AcceptRA=no + +[DHCPv4] +Use6RD=yes + + # /etc/systemd/network/55-dhcpv4-6rd-downstream.network +[Match] +Name=enp2s0 + +[Network] +DHCPPrefixDelegation=yes +IPv6SendRA=yes + +# It is expected that the host is acting as a router. So, usually it is not +# necessary to receive Router Advertisement from other hosts in the downstream network. +IPv6AcceptRA=no + +[DHCPPrefixDelegation] +UplinkInterface=enp1s0 +SubnetId=1 +Announce=yes + + This will enable DHCPv4-6RD on the interface enp1s0 as an upstream interface where the + DHCPv4 client is running and enp2s0 as a downstream interface where the prefix is delegated to. + The delegated prefixes are distributed by IPv6 Router Advertisement on the downstream network. + + + + + A bridge with two enslaved links + + # /etc/systemd/network/25-bridge-static.netdev +[NetDev] +Name=bridge0 +Kind=bridge + + # /etc/systemd/network/25-bridge-static.network +[Match] +Name=bridge0 + +[Network] +Address=192.168.0.15/24 +Gateway=192.168.0.1 +DNS=192.168.0.1 + + # /etc/systemd/network/25-bridge-slave-interface-1.network +[Match] +Name=enp2s0 + +[Network] +Bridge=bridge0 + + # /etc/systemd/network/25-bridge-slave-interface-2.network +[Match] +Name=wlp3s0 + +[Network] +Bridge=bridge0 + + This creates a bridge and attaches devices enp2s0 and + wlp3s0 to it. The bridge will have the specified static address + and network assigned, and a default route via the specified gateway will be + added. The specified DNS server will be added to the global list of DNS resolvers. + + + + + Bridge port with VLAN forwarding + + +# /etc/systemd/network/25-bridge-slave-interface-1.network +[Match] +Name=enp2s0 + +[Network] +Bridge=bridge0 + +[BridgeVLAN] +VLAN=1-32 +PVID=42 +EgressUntagged=42 + +[BridgeVLAN] +VLAN=100-200 + +[BridgeVLAN] +EgressUntagged=300-400 + + This overrides the configuration specified in the previous example for the + interface enp2s0, and enables VLAN on that bridge port. VLAN IDs + 1-32, 42, 100-400 will be allowed. Packets tagged with VLAN IDs 42, 300-400 will be + untagged when they leave on this interface. Untagged packets which arrive on this + interface will be assigned VLAN ID 42. + + + + Various tunnels + + /etc/systemd/network/25-tunnels.network +[Match] +Name=ens1 + +[Network] +Tunnel=ipip-tun +Tunnel=sit-tun +Tunnel=gre-tun +Tunnel=vti-tun + + + /etc/systemd/network/25-tunnel-ipip.netdev +[NetDev] +Name=ipip-tun +Kind=ipip + + + /etc/systemd/network/25-tunnel-sit.netdev +[NetDev] +Name=sit-tun +Kind=sit + + + /etc/systemd/network/25-tunnel-gre.netdev +[NetDev] +Name=gre-tun +Kind=gre + + + /etc/systemd/network/25-tunnel-vti.netdev +[NetDev] +Name=vti-tun +Kind=vti + + + This will bring interface ens1 up and create an IPIP tunnel, + a SIT tunnel, a GRE tunnel, and a VTI tunnel using it. + + + + A bond device + + # /etc/systemd/network/30-bond1.network +[Match] +Name=bond1 + +[Network] +DHCP=ipv6 + + + # /etc/systemd/network/30-bond1.netdev +[NetDev] +Name=bond1 +Kind=bond + + + # /etc/systemd/network/30-bond1-dev1.network +[Match] +MACAddress=52:54:00:e9:64:41 + +[Network] +Bond=bond1 + + + # /etc/systemd/network/30-bond1-dev2.network +[Match] +MACAddress=52:54:00:e9:64:42 + +[Network] +Bond=bond1 + + + This will create a bond device bond1 and enslave the two + devices with MAC addresses 52:54:00:e9:64:41 and 52:54:00:e9:64:42 to it. IPv6 DHCP + will be used to acquire an address. + + + + Virtual Routing and Forwarding (VRF) + Add the bond1 interface to the VRF master interface + vrf1. This will redirect routes generated on this interface to be + within the routing table defined during VRF creation. For kernels before 4.8 traffic + won't be redirected towards the VRFs routing table unless specific ip-rules are added. + + # /etc/systemd/network/25-vrf.network +[Match] +Name=bond1 + +[Network] +VRF=vrf1 + + + + + MacVTap + This brings up a network interface macvtap-test + and attaches it to enp0s25. + # /usr/lib/systemd/network/25-macvtap.network +[Match] +Name=enp0s25 + +[Network] +MACVTAP=macvtap-test + + + + + A Xfrm interface with physical underlying device. + + # /etc/systemd/network/27-xfrm.netdev +[NetDev] +Name=xfrm0 +Kind=xfrm + +[Xfrm] +InterfaceId=7 + + # /etc/systemd/network/27-eth0.network +[Match] +Name=eth0 + +[Network] +Xfrm=xfrm0 + + This creates a xfrm0 interface and binds it to the eth0 device. + This allows hardware based ipsec offloading to the eth0 nic. + If offloading is not needed, xfrm interfaces can be assigned to the lo device. + + + + + + See Also + + systemd1, + systemd-networkd.service8, + systemd.link5, + systemd.netdev5, + systemd-network-generator.service8, + systemd-resolved.service8 + + + + diff --git a/man/systemd.nspawn.xml b/man/systemd.nspawn.xml new file mode 100644 index 0000000..c1eef78 --- /dev/null +++ b/man/systemd.nspawn.xml @@ -0,0 +1,598 @@ + + +%entities; +]> + + + + + + systemd.nspawn + systemd + + + + systemd.nspawn + 5 + + + + systemd.nspawn + Container settings + + + + /etc/systemd/nspawn/machine.nspawn + /run/systemd/nspawn/machine.nspawn + /var/lib/machines/machine.nspawn + + + + Description + + An nspawn container settings file (suffix .nspawn) contains runtime + configuration for a local container, and is used by + systemd-nspawn1. + Files of this type are named after the containers they define settings for. They are optional, and only + required for containers whose execution environment shall differ from the defaults. Files of this type + mostly contain settings that may also be set on the systemd-nspawn command line, and + make it easier to persistently attach specific settings to specific containers. The syntax of these files + is inspired by .desktop files, similarly to other configuration files supported by + the systemd project. See + systemd.syntax7 for an + overview. + + + + <filename>.nspawn</filename> File Discovery + + Files are searched for by appending the .nspawn suffix to the machine name of + the container, as specified with the switch of + systemd-nspawn, or derived from the directory or image file name. This file is first + searched for in /etc/systemd/nspawn/ and + /run/systemd/nspawn/. If found there, the settings are read and all of them take + full effect (but may still be overridden by corresponding command line arguments). Otherwise, the file + will then be searched for next to the image file or in the immediate parent of the root directory of the + container. If the file is found there, only a subset of the settings will take effect however. All + settings that possibly elevate privileges or grant additional access to resources of the host (such as + files or directories) are ignored. To which options this applies is documented below. + + Persistent settings files created and maintained by the + administrator (and thus trusted) should be placed in + /etc/systemd/nspawn/, while automatically + downloaded (and thus potentially untrusted) settings files are + placed in /var/lib/machines/ instead (next to + the container images), where their security impact is limited. In + order to add privileged settings to .nspawn + files acquired from the image vendor, it is recommended to copy the + settings files into /etc/systemd/nspawn/ and + edit them there, so that the privileged options become + available. The precise algorithm for how the files are searched and + interpreted may be configured with + systemd-nspawn's + switch, see + systemd-nspawn1 + for details. + + + + [Exec] Section Options + + Settings files may include an [Exec] + section, which carries various execution parameters: + + + + + Boot= + + Takes a boolean argument, which defaults to off. If enabled, systemd-nspawn + will automatically search for an init executable and invoke it. In this case, the + specified parameters using Parameters= are passed as additional arguments to the + init process. This setting corresponds to the switch on the + systemd-nspawn command line. This option may not be combined with + ProcessTwo=yes. This option is specified by default in the + systemd-nspawn@.service template unit. + + + + Ephemeral= + + Takes a boolean argument, which defaults to off, If enabled, the container is run with + a temporary snapshot of its file system that is removed immediately when the container terminates. + This is equivalent to the command line switch. See + systemd-nspawn1 for details + about the specific options supported. + + + + ProcessTwo= + + Takes a boolean argument, which defaults to off. If enabled, the specified program is run as + PID 2. A stub init process is run as PID 1. This setting corresponds to the switch + on the systemd-nspawn command line. This option may not be combined with + Boot=yes. + + + + Parameters= + + Takes a whitespace-separated list of arguments. Single (') and + double (") quotes may be used around arguments with whitespace. This is either a + command line, beginning with the binary name to execute, or – if Boot= is enabled + – the list of arguments to pass to the init process. This setting corresponds to the command line + parameters passed on the systemd-nspawn command line. + + Note: , is the same as + systemd-nspawn a b "c c", and , + is the same as systemd-nspawn --boot b 'c c'. + + + + Environment= + + Takes an environment variable assignment + consisting of key and value, separated by + =. Sets an environment variable for the + main process invoked in the container. This setting may be + used multiple times to set multiple environment variables. It + corresponds to the command line + switch. + + + + User= + + Takes a UNIX user name. Specifies the user + name to invoke the main process of the container as. This user + must be known in the container's user database. This + corresponds to the command line + switch. + + + + WorkingDirectory= + + Selects the working directory for the process invoked in the container. Expects an absolute + path in the container's file system namespace. This corresponds to the command line + switch. + + + + PivotRoot= + + Selects a directory to pivot to / inside the container when starting up. + Takes a single path, or a pair of two paths separated by a colon. Both paths must be absolute, and are resolved + in the container's file system namespace. This corresponds to the command line + switch. + + + + Capability= + DropCapability= + + Takes a space-separated list of Linux process + capabilities (see + capabilities7 + for details). The Capability= setting + specifies additional capabilities to pass on top of the + default set of capabilities. The + DropCapability= setting specifies + capabilities to drop from the default set. These settings + correspond to the and + command line + switches. Note that Capability= is a + privileged setting, and only takes effect in + .nspawn files in + /etc/systemd/nspawn/ and + /run/system/nspawn/ (see above). On the + other hand, DropCapability= takes effect in + all cases. If the special value all is passed, all + capabilities are retained (or dropped). + These settings change the bounding set of capabilities which + also limits the ambient capabilities as given with the + AmbientCapability=. + + + + AmbientCapability= + Takes a space-separated list of Linux process + capabilities (see + capabilities7 + for details). The AmbientCapability= setting + specifies capabilities which will be passed to the started program + in the inheritable and ambient capability sets. This will grant + these capabilities to this process. This setting correspond to + the command line switch. + + + The value all is not supported for this + setting. + + The setting of AmbientCapability= must + be covered by the bounding set settings which were established by + Capability= and DropCapability=. + + + Note that AmbientCapability= is a privileged + setting (see above). + + + + NoNewPrivileges= + + Takes a boolean argument that controls the PR_SET_NO_NEW_PRIVS flag for + the container payload. This is equivalent to the + command line switch. See + systemd-nspawn1 for + details. + + + + + KillSignal= + + Specify the process signal to send to the + container's PID 1 when nspawn itself receives SIGTERM, in + order to trigger an orderly shutdown of the container. + Defaults to SIGRTMIN+3 if is used + (on systemd-compatible init systems SIGRTMIN+3 triggers an + orderly shutdown). For a list of valid signals, see + signal7. + + + + Personality= + + Configures the kernel personality for the + container. This is equivalent to the + switch. + + + + MachineID= + + Configures the 128-bit machine ID (UUID) to pass to + the container. This is equivalent to the + command line switch. This option is + privileged (see above). + + + + PrivateUsers= + + Configures support for usernamespacing. This is equivalent to the + command line switch, and takes the same options. This option is privileged + (see above). This option is the default if the systemd-nspawn@.service template unit file + is used. + + + + NotifyReady= + + Configures support for notifications from the container's init process. This is equivalent to + the command line switch, and takes the same parameters. See + systemd-nspawn1 for details + about the specific options supported. + + + + SystemCallFilter= + + Configures the system call filter applied to containers. This is equivalent to the + command line switch, and takes the same list parameter. See + systemd-nspawn1 for + details. + + + + LimitCPU= + LimitFSIZE= + LimitDATA= + LimitSTACK= + LimitCORE= + LimitRSS= + LimitNOFILE= + LimitAS= + LimitNPROC= + LimitMEMLOCK= + LimitLOCKS= + LimitSIGPENDING= + LimitMSGQUEUE= + LimitNICE= + LimitRTPRIO= + LimitRTTIME= + + Configures various types of resource limits applied to containers. This is equivalent to the + command line switch, and takes the same arguments. See + systemd-nspawn1 for + details. + + + + OOMScoreAdjust= + + Configures the OOM score adjustment value. This is equivalent to the + command line switch, and takes the same argument. See + systemd-nspawn1 for + details. + + + + CPUAffinity= + + Configures the CPU affinity. This is equivalent to the command + line switch, and takes the same argument. See + systemd-nspawn1 for + details. + + + + Hostname= + + Configures the kernel hostname set for the container. This is equivalent to the + command line switch, and takes the same argument. See + systemd-nspawn1 for + details. + + + + ResolvConf= + + Configures how /etc/resolv.conf in the container shall be handled. This is + equivalent to the command line switch, and takes the same argument. See + systemd-nspawn1 for + details. + + + + Timezone= + + Configures how /etc/localtime in the container shall be handled. This is + equivalent to the command line switch, and takes the same argument. See + systemd-nspawn1 for + details. + + + + LinkJournal= + + Configures how to link host and container journal setups. This is equivalent to the + command line switch, and takes the same parameter. See + systemd-nspawn1 for + details. + + + + SuppressSync= + + Configures whether to suppress disk synchronization for the container payload. This + is equivalent to the command line switch, and takes the same + parameter. See + systemd-nspawn1 + for details. + + + + + + + [Files] Section Options + + Settings files may include a [Files] + section, which carries various parameters configuring the file + system of the container: + + + + + ReadOnly= + + Takes a boolean argument, which defaults to off. If + specified, the container will be run with a read-only file + system. This setting corresponds to the + command line + switch. + + + + Volatile= + + Takes a boolean argument, or the special value + state. This configures whether to run the + container with volatile state and/or configuration. This + option is equivalent to , see + systemd-nspawn1 + for details about the specific options + supported. + + + + Bind= + BindReadOnly= + + Adds a bind mount from the host into the + container. Takes a single path, a pair of two paths separated + by a colon, or a triplet of two paths plus an option string + separated by colons. This option may be used multiple times to + configure multiple bind mounts. This option is equivalent to + the command line switches and + , see + systemd-nspawn1 + for details about the specific options supported. This setting + is privileged (see above). + + + + BindUser= + + Binds a user from the host into the container. This option is equivalent to the + command line switch , see + systemd-nspawn1 + for details about the specific options supported. This setting is privileged (see + above). + + + + TemporaryFileSystem= + + Adds a tmpfs mount to the + container. Takes a path or a pair of path and option string, + separated by a colon. This option may be used multiple times to + configure multiple tmpfs mounts. This + option is equivalent to the command line switch + , see + systemd-nspawn1 + for details about the specific options supported. This setting + is privileged (see above). + + + + Inaccessible= + + Masks the specified file or directory in the container, by over-mounting it with an empty file + node of the same type with the most restrictive access mode. Takes a file system path as argument. This option + may be used multiple times to mask multiple files or directories. This option is equivalent to the command line + switch , see + systemd-nspawn1 for details + about the specific options supported. This setting is privileged (see above). + + + + Overlay= + OverlayReadOnly= + + Adds an overlay mount point. Takes a colon-separated list of paths. This option may be used + multiple times to configure multiple overlay mounts. This option is equivalent to the command line switches + and , see + systemd-nspawn1 for details + about the specific options supported. This setting is privileged (see above). + + + + PrivateUsersOwnership= + + Configures whether the ownership of the files and directories in the container tree + shall be adjusted to the UID/GID range used, if necessary and user namespacing is enabled. This is + equivalent to the command line switch. This option is + privileged (see above). + + + + + + + [Network] Section Options + + Settings files may include a [Network] + section, which carries various parameters configuring the network + connectivity of the container: + + + + + Private= + + Takes a boolean argument, which defaults to off. If + enabled, the container will run in its own network namespace + and not share network interfaces and configuration with the + host. This setting corresponds to the + command line + switch. + + + + VirtualEthernet= + + Takes a boolean argument. Configures whether to create a virtual Ethernet connection + (veth) between host and the container. This setting implies + Private=yes. This setting corresponds to the command line + switch. This option is privileged (see above). This option is the default if the + systemd-nspawn@.service template unit file is used. + + + + VirtualEthernetExtra= + + Takes a colon-separated pair of interface names. Configures an additional virtual + Ethernet connection (veth) between host and the container. The first specified + name is the interface name on the host, the second the interface name in the container. The latter + may be omitted in which case it is set to the same name as the host side interface. This setting + implies Private=yes. This setting corresponds to the + command line switch, and maybe be used multiple times. It is + independent of VirtualEthernet=. Note that this option is unrelated to the + Bridge= setting below, and thus any connections created this way are not + automatically added to any bridge device on the host side. This option is privileged (see + above). + + + + Interface= + + Takes a space-separated list of interfaces to + add to the container. This option corresponds to the + command line switch and + implies Private=yes. This option is + privileged (see above). + + + + MACVLAN= + IPVLAN= + + Takes a space-separated list of interfaces to + add MACLVAN or IPVLAN interfaces to, which are then added to + the container. These options correspond to the + and + command line switches and + imply Private=yes. These options are + privileged (see above). + + + + Bridge= + + Takes an interface name. This setting implies + VirtualEthernet=yes and + Private=yes and has the effect that the + host side of the created virtual Ethernet link is connected to + the specified bridge interface. This option corresponds to the + command line switch. This + option is privileged (see above). + + + + Zone= + + Takes a network zone name. This setting implies VirtualEthernet=yes and + Private=yes and has the effect that the host side of the created virtual Ethernet link is + connected to an automatically managed bridge interface named after the passed argument, prefixed with + vz-. This option corresponds to the command line + switch. This option is privileged (see above). + + + + Port= + + Exposes a TCP or UDP port of the container on + the host. This option corresponds to the + command line switch, see + systemd-nspawn1 + for the precise syntax of the argument this option takes. This + option is privileged (see above). + + + + + + See Also + + systemd1, + systemd-nspawn1, + systemd.directives7 + + + + diff --git a/man/systemd.offline-updates.xml b/man/systemd.offline-updates.xml new file mode 100644 index 0000000..6706451 --- /dev/null +++ b/man/systemd.offline-updates.xml @@ -0,0 +1,163 @@ + + + + + + + systemd.offline-updates + systemd + + + + systemd.offline-updates + 7 + + + + systemd.offline-updates + Implementation of offline updates in systemd + + + + Implementing Offline System Updates + + This man page describes how to implement "offline" system updates with systemd. By "offline" + OS updates we mean package installations and updates that are run with the system booted into a + special system update mode, in order to avoid problems related to conflicts of libraries and + services that are currently running with those on disk. This document is inspired by this + GNOME design whiteboard. + + + The logic: + + + + The package manager prepares system updates by downloading all (.rpm or .deb or + whatever) packages to update off-line in a special directory + /var/lib/system-update (or + another directory of the package/upgrade manager's choice). + + + + When the user OK'ed the update, the symlink /system-update is + created that points to /var/lib/system-update (or + wherever the directory with the upgrade files is located) and the system is rebooted. This + symlink is in the root directory, since we need to check for it very early at boot, at a + time where /var/ is not available yet. + + + + Very early in the new boot + systemd-system-update-generator8 + checks whether /system-update exists. If so, it (temporarily and for + this boot only) redirects (i.e. symlinks) default.target to + system-update.target, a special target that pulls in the base system + (i.e. sysinit.target, so that all file systems are mounted but little + else) and the system update units. + + + + The system now continues to boot into default.target, and + thus into system-update.target. This target pulls in all system + update units. Only one service should perform an update (see the next point), and all + the other ones should exit cleanly with a "success" return code and without doing + anything. Update services should be ordered after sysinit.target + so that the update starts after all file systems have been mounted. + + + + As the first step, an update service should check if the + /system-update symlink points to the location used by that update + service. In case it does not exist or points to a different location, the service must exit + without error. It is possible for multiple update services to be installed, and for multiple + update services to be launched in parallel, and only the one that corresponds to the tool + that created the symlink before reboot should perform any actions. It + is unsafe to run multiple updates in parallel. + + + + The update service should now do its job. If applicable and possible, it should + create a file system snapshot, then install all packages. After completion (regardless + whether the update succeeded or failed) the machine must be rebooted, for example by + calling systemctl reboot. In addition, on failure the script should + revert to the old file system snapshot (without the symlink). + + + + The update scripts should exit only after the update is finished. It is expected + that the service which performs the update will cause the machine to reboot after it + is done. If the system-update.target is successfully reached, i.e. + all update services have run, and the /system-update symlink still + exists, it will be removed and the machine rebooted as a safety measure. + + + + After a reboot, now that the /system-update symlink is gone, + the generator won't redirect default.target anymore and the system + now boots into the default target again. + + + + + + Recommendations + + + + To make things a bit more robust we recommend hooking the update script into + system-update.target via a .wants/ + symlink in the distribution package, rather than depending on systemctl + enable in the postinst scriptlets of your package. More specifically, for your + update script create a .service file, without [Install] section, and then add a symlink like + /usr/lib/systemd/system/system-update.target.wants/foobar.service + → ../foobar.service to your package. + + + + Make sure to remove the /system-update symlink as early as + possible in the update script to avoid reboot loops in case the update fails. + + + + Use FailureAction=reboot in the service file for your update script + to ensure that a reboot is automatically triggered if the update fails. + FailureAction= makes sure that the specified unit is activated if your + script exits uncleanly (by non-zero error code, or signal/coredump). If your script succeeds + you should trigger the reboot in your own code, for example by invoking logind's + Reboot() call or calling systemctl reboot. See + org.freedesktop.login15 + for details about the logind D-Bus API. + + + + The update service should declare DefaultDependencies=no, + Requires=sysinit.target, After=sysinit.target, + After=system-update-pre.target, Before=system-update.target + and explicitly pull in any other services it requires. + + + + It may be desirable to always run an auxiliary unit when booting + into offline-updates mode, which itself does not install updates. To + do this create a .service file with + Wants=system-update-pre.target and + Before=system-update-pre.target and add a symlink + to that file under + /usr/lib/systemd/system-update.target.wants + . + + + + + + See also + + + systemd1, + systemd.generator7, + systemd-system-update-generator8, + dnf.plugin.system-upgrade8 + + + diff --git a/man/systemd.path.xml b/man/systemd.path.xml new file mode 100644 index 0000000..f8748bf --- /dev/null +++ b/man/systemd.path.xml @@ -0,0 +1,225 @@ + + + + + + + systemd.path + systemd + + + + systemd.path + 5 + + + + systemd.path + Path unit configuration + + + + path.path + + + + Description + + A unit configuration file whose name ends in + .path encodes information about a path + monitored by systemd, for path-based activation. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The path specific configuration options are + configured in the [Path] section. + + For each path file, a matching unit file must exist, + describing the unit to activate when the path changes. By default, + a service by the same name as the path (except for the suffix) is + activated. Example: a path file foo.path + activates a matching service foo.service. The + unit to activate may be controlled by Unit= + (see below). + + Internally, path units use the + inotify7 + API to monitor file systems. Due to that, it suffers by the same + limitations as inotify, and for example cannot be used to monitor + files or directories changed by other machines on remote NFS file + systems. + + When a service unit triggered by a path unit terminates (regardless whether it exited successfully + or failed), monitored paths are checked immediately again, and the service accordingly restarted + instantly. As protection against busy looping in this trigger/start cycle, a start rate limit is enforced + on the service unit, see StartLimitIntervalSec= and + StartLimitBurst= in + systemd.unit5. Unlike + other service failures, the error condition that the start rate limit is hit is propagated from the + service unit to the path unit and causes the path unit to fail as well, thus ending the loop. + + + + Automatic Dependencies + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + If a path unit is beneath another mount unit in the file + system hierarchy, both a requirement and an ordering dependency + between both units are created automatically. + + An implicit Before= dependency is added + between a path unit and the unit it is supposed to activate. + + + + + Default Dependencies + + The following dependencies are added unless DefaultDependencies=no is set: + + + Path units will automatically have dependencies of type Before= on + paths.target, + dependencies of type After= and Requires= on + sysinit.target, and have dependencies of type Conflicts= and + Before= on shutdown.target. These ensure that path units are terminated + cleanly prior to system shutdown. Only path units involved with early boot or late system shutdown should + disable DefaultDependencies= option. + + + + + + + + Options + + Path unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + + + Path unit files must include a [Path] section, which carries information about the path or paths it + monitors. The options specific to the [Path] section of path units are the following: + + + + PathExists= + PathExistsGlob= + PathChanged= + PathModified= + DirectoryNotEmpty= + + Defines paths to monitor for certain changes: + PathExists= may be used to watch the mere + existence of a file or directory. If the file specified + exists, the configured unit is activated. + PathExistsGlob= works similarly, but checks + for the existence of at least one file matching the globbing + pattern specified. PathChanged= may be used + to watch a file or directory and activate the configured unit + whenever it changes. It is not activated on every write to the + watched file but it is activated if the file which was open + for writing gets closed. PathModified= is + similar, but additionally it is activated also on simple + writes to the watched file. + DirectoryNotEmpty= may be used to watch a + directory and activate the configured unit whenever it + contains at least one file. + + The arguments of these directives must be absolute file + system paths. + + Multiple directives may be combined, of the same and of + different types, to watch multiple paths. If the empty string + is assigned to any of these options, the list of paths to + watch is reset, and any prior assignments of these options + will not have any effect. + + If a path already exists (in case of + PathExists= and + PathExistsGlob=) or a directory already is + not empty (in case of DirectoryNotEmpty=) + at the time the path unit is activated, then the configured + unit is immediately activated as well. Something similar does + not apply to PathChanged= and + PathModified=. + + If the path itself or any of the containing directories + are not accessible, systemd will watch for + permission changes and notice that conditions are satisfied + when permissions allow that. + + + Unit= + + The unit to activate when any of the + configured paths changes. The argument is a unit name, whose + suffix is not .path. If not specified, this + value defaults to a service that has the same name as the path + unit, except for the suffix. (See above.) It is recommended + that the unit name that is activated and the unit name of the + path unit are named identical, except for the + suffix. + + + MakeDirectory= + + Takes a boolean argument. If true, the + directories to watch are created before watching. This option + is ignored for PathExists= settings. + Defaults to . + + + DirectoryMode= + + If MakeDirectory= is + enabled, use the mode specified here to create the directories + in question. Takes an access mode in octal notation. Defaults + to . + + + TriggerLimitIntervalSec= + TriggerLimitBurst= + + Configures a limit on how often this path unit may be activated within a specific + time interval. The TriggerLimitIntervalSec= may be used to configure the length of + the time interval in the usual time units us, ms, + s, min, h, … and defaults to 2s. See + systemd.time7 for + details on the various time units understood. The TriggerLimitBurst= setting takes + a positive integer value and specifies the number of permitted activations per time interval, and + defaults to 200. Set either to 0 to disable any form of trigger rate limiting. If the limit is hit, + the unit is placed into a failure mode, and will not watch the paths anymore until restarted. Note + that this limit is enforced before the service activation is enqueued. + + + + + + + + See Also + Environment variables with details on the trigger will be set for triggered units. See the + Environment Variables Set on Triggered Units section in + systemd.exec1 + for more details. + + systemd1, + systemctl1, + systemd.unit5, + systemd.service5, + inotify7, + systemd.directives7 + + + + diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml new file mode 100644 index 0000000..ab730d2 --- /dev/null +++ b/man/systemd.preset.xml @@ -0,0 +1,222 @@ + + + + + + + + systemd.preset + systemd + + + + systemd.preset + 5 + + + + systemd.preset + Service enablement presets + + + + /etc/systemd/system-preset/*.preset + /run/systemd/system-preset/*.preset + /usr/lib/systemd/system-preset/*.preset + /etc/systemd/user-preset/*.preset + /run/systemd/user-preset/*.preset + /usr/lib/systemd/user-preset/*.preset + + + + Description + + Preset files may be used to encode policy which units shall be enabled by default and which ones + shall be disabled. They are read by systemctl preset which uses this information to + enable or disable a unit. Depending on that policy, systemctl preset is identical to + systemctl enable or systemctl disable. + + systemctl preset is used by the post install scriptlets of rpm packages (or other OS + package formats), to enable/disable specific units by default on package installation, enforcing + distribution, spin or administrator preset policy. This allows choosing a certain set of units to be + enabled/disabled even before installing the actual package. For more information, see + systemctl1. + + It is not recommended to ship preset files within the respective software packages implementing the + units, but rather centralize them in a distribution or spin default policy, which can be amended by + administrator policy, see below. + + If no preset files exist, preset operations will enable all units that are installed by default. If + this is not desired and all units shall rather be disabled, it is necessary to ship a preset file with a + single, catchall "disable *" line. (See example 1, below.) + + When the machine is booted for the first time, + systemd1 will + enable/disable all units according to preset policy, similarly to systemctl + preset-all. Also see "First Boot Semantics" in + machine-id5. + + + + + Preset File Format + + The preset files contain a list of directives consisting of + either the word enable or + disable followed by a space and a unit name + (possibly with shell style wildcards), separated by newlines. + Empty lines and lines whose first non-whitespace character is # or + ; are ignored. Multiple instance names for unit + templates may be specified as a space separated list at the end of + the line instead of the customary position between @ + and the unit suffix. + + Presets must refer to the "real" unit file, and not to any aliases. See + systemd.unit5 + for a description of unit aliasing. + + Two different directives are understood: + enable may be used to enable units by default, + disable to disable units by default. + + If multiple lines apply to a unit name, the first matching + one takes precedence over all others. + + Each preset file shall be named in the style of + <priority>-<policy-name>.preset. Files + in /etc/ override files with the same name in + /usr/lib/ and /run/. + Files in /run/ override files with the same + name in /usr/lib/. Packages should install + their preset files in /usr/lib/. Files in + /etc/ are reserved for the local + administrator, who may use this logic to override the preset files + installed by vendor packages. All preset files are sorted by their + filename in lexicographic order, regardless of which of the + directories they reside in. If multiple files specify the same + unit name, the entry in the file with the lexicographically + earliest name will be applied. It is recommended to prefix all + filenames with a two-digit number and a dash, to simplify the + ordering of the files. + + If the administrator wants to disable a preset file supplied + by the vendor, the recommended way is to place a symlink to + /dev/null in + /etc/systemd/system-preset/ bearing the same + filename. + + + + Examples + + + Default to off + + # /usr/lib/systemd/system-preset/99-default.preset + +disable * + + + This disables all units. Due to the filename prefix + 99-, it will be read last and hence can easily + be overridden by spin or administrator preset policy. + + + Enable multiple template instances + + # /usr/lib/systemd/system-preset/80-dirsrv.preset + +enable dirsrv@.service foo bar baz + + + This enables all three of dirsrv@foo.service, + dirsrv@bar.service and dirsrv@baz.service. + + + A GNOME spin + + # /usr/lib/systemd/system-preset/50-gnome.preset + +enable gdm.service +enable colord.service +enable accounts-daemon.service +enable avahi-daemon.* + + + + This enables the three mentioned units, plus all + avahi-daemon regardless of which unit type. A + file like this could be useful for inclusion in a GNOME spin of a + distribution. It will ensure that the units necessary for GNOME + are properly enabled as they are installed. It leaves all other + units untouched, and subject to other (later) preset files, for + example like the one from the first example above. + + + Administrator policy + + # /etc/systemd/system-preset/00-lennart.preset + +enable httpd.service +enable sshd.service +enable postfix.service +disable * + + + This enables three specific services and disables all + others. This is useful for administrators to specifically select + the units to enable, and disable all others. Due to the filename + prefix 00- it will be read early and + override all other preset policy files. + + + + Motivation for the preset logic + + Different distributions have different policies on which services shall be enabled by default when + the package they are shipped in is installed. On Fedora all services stay off by default, so that + installing a package will not cause a service to be enabled (with some exceptions). On Debian all + services are immediately enabled by default, so that installing a package will cause its services to be + enabled right-away. + + Even within a single distribution, different spins (flavours, remixes, whatever you might want to + call them) of a distribution also have different policies on what services to enable, and what services + to leave off. For example, Fedora Workstation will enable gdm as display manager by + default, while the Fedora KDE spin will enable sddm instead. + + Different sites might also have different policies what to turn on by default and what to turn + off. For example, one administrator would prefer to enforce the policy of "sshd should + be always on, but everything else off", while another one might say "snmpd always on, + and for everything else use the distribution policy defaults". + + Traditionally, policy about which services shall be enabled were implemented in each package + individually. This made it cumbersome to implement different policies per spin or per site, or to create + software packages that do the right thing on more than one distribution. The enablement mechanism was + also encoding the enablement policy. + + The preset mechanism allows clean separation of the enablement mechanism (inside the package + scriptlets, by invoking systemctl preset) and enablement policy (centralized in the + preset files), and lifts the configuration out of individual packages. Preset files may be written for + specific distributions, for specific spins or for specific sites, in order to enforce different policies + as needed. It is recommended to apply the policy encoded in preset files in package installation + scriptlets. + + + + See Also + + systemd1, + systemctl1, + systemd-delta1 + + + daemon7 + has a discussion of packaging scriptlets. + + Fedora page introducing the use of presets: + Features/PackagePresets. + + + + diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml new file mode 100644 index 0000000..48e7c52 --- /dev/null +++ b/man/systemd.resource-control.xml @@ -0,0 +1,1286 @@ + + + + + + + systemd.resource-control + systemd + + + + systemd.resource-control + 5 + + + + systemd.resource-control + Resource control unit settings + + + + + slice.slice, + scope.scope, + service.service, + socket.socket, + mount.mount, + swap.swap + + + + + Description + + Unit configuration files for services, slices, scopes, sockets, mount points, and swap devices share a subset + of configuration options for resource control of spawned processes. Internally, this relies on the Linux Control + Groups (cgroups) kernel concept for organizing processes in a hierarchical tree of named groups for the purpose of + resource management. + + This man page lists the configuration options shared by + those six unit types. See + systemd.unit5 + for the common options of all unit configuration files, and + systemd.slice5, + systemd.scope5, + systemd.service5, + systemd.socket5, + systemd.mount5, + and + systemd.swap5 + for more information on the specific unit configuration files. The + resource control configuration options are configured in the + [Slice], [Scope], [Service], [Socket], [Mount], or [Swap] + sections, depending on the unit type. + + In addition, options which control resources available to programs + executed by systemd are listed in + systemd.exec5. + Those options complement options listed here. + + + Enabling and disabling controllers + + Controllers in the cgroup hierarchy are hierarchical, and resource control is realized by + distributing resource assignments between siblings in branches of the cgroup hierarchy. There is no + need to explicitly enable a cgroup controller for a unit. + systemd will instruct the kernel to enable a controller for a given unit when this + unit has configuration for a given controller. For example, when CPUWeight= is set, + the controller will be enabled, and when TasksMax= are set, the + controller will be enabled. In addition, various controllers may be also be + enabled explicitly via the + MemoryAccounting=/TasksAccounting=/IOAccounting= + settings. Because of how the cgroup hierarchy works, controllers will be automatically enabled for all + parent units and for any sibling units starting with the lowest level at which a controller is enabled. + Units for which a controller is enabled may be subject to resource control even if they don't have any + explicit configuration. + + Setting Delegate= enables any delegated controllers for that unit (see below). + The delegatee may then enable controllers for its children as appropriate. In particular, if the + delegatee is systemd (in the user@.service unit), it will + repeat the same logic as the system instance and enable controllers for user units which have resource + limits configured, and their siblings and parents and parents' siblings. + + Controllers may be disabled for parts of the cgroup hierarchy with + DisableControllers= (see below). + + + Enabling and disabling controllers + + + -.slice + / \ + /-----/ \--------------\ + / \ + system.slice user.slice + / \ / \ + / \ / \ + / \ user@42.service user@1000.service + / \ Delegate= Delegate=yes +a.service b.slice / \ +CPUWeight=20 DisableControllers=cpu / \ + / \ app.slice session.slice + / \ CPUWeight=100 CPUWeight=100 + / \ + b1.service b2.service + CPUWeight=1000 + + + In this hierarchy, the controller is enabled for all units shown except + b1.service and b2.service. Because there is no explicit + configuration for system.slice and user.slice, CPU + resources will be split equally between them. Similarly, resources are allocated equally between + children of user.slice and between the child slices beneath + user@1000.service. Assuming that there is no futher configuration of resources + or delegation below slices app.slice or session.slice, the + controller would not be enabled for units in those slices and CPU resources + would be further allocated using other mechanisms, e.g. based on nice levels. The manager for user + 42 has delegation enabled without any controllers, i.e. it can manipulate its subtree of the cgroup + hierarchy, but without resource control. + + In the slice system.slice, CPU resources are split 1:6 for service + a.service, and 5:6 for slice b.slice, because slice + b.slice gets the default value of 100 for cpu.weight when + CPUWeight= is not set. + + CPUWeight= setting in service b2.service is neutralized + by DisableControllers= in slice b.slice, so the + controller would not be enabled for services b1.service and + b2.service, and CPU resources would be further allocated using other mechanisms, + e.g. based on nice levels. + + + + + Setting resource controls for a group of related units + + As described in + systemd.unit5, the + settings listed here may be set through the main file of a unit and drop-in snippets in + *.d/ directories. The list of directories searched for drop-ins + includes names formed by repeatedly truncating the unit name after all dashes. This is particularly + convenient to set resource limits for a group of units with similar names. + + For example, every user gets their own slice + user-nnn.slice. Drop-ins with local configuration that + affect user 1000 may be placed in + /etc/systemd/system/user-1000.slice, + /etc/systemd/system/user-1000.slice.d/*.conf, but also + /etc/systemd/system/user-.slice.d/*.conf. This last directory + applies to all user slices. + + + See the New + Control Group Interfaces for an introduction on how to make + use of resource control APIs from programs. + + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + Units with the Slice= setting set automatically acquire + Requires= and After= dependencies on the specified + slice unit. + + + + + + + Options + + Units of the types listed above can have settings + for resource control configuration: + + + + + CPUAccounting= + + + Turn on CPU usage accounting for this unit. Takes a + boolean argument. Note that turning on CPU accounting for + one unit will also implicitly turn it on for all units + contained in the same slice and for all its parent slices + and the units contained therein. The system default for this + setting may be controlled with + DefaultCPUAccounting= in + systemd-system.conf5. + + Under the unified cgroup hierarchy, CPU accounting is available for all units and this + setting has no effect. + + + + + CPUWeight=weight + StartupCPUWeight=weight + + + These settings control the controller in the unified hierarchy. + + These options accept an integer value or a the special string "idle": + + + If set to an integer value, assign the specified CPU time weight to the processes + executed, if the unified control group hierarchy is used on the system. These options control + the cpu.weight control group attribute. The allowed range is 1 to 10000. + Defaults to unset, but the kernel default is 100. For details about this control group + attribute, see Control Groups + v2 and CFS + Scheduler. The available CPU time is split up among all units within one slice + relative to their CPU time weight. A higher weight means more CPU time, a lower weight means + less. + + + If set to the special string "idle", mark the cgroup for "idle scheduling", which means + that it will get CPU resources only when there are no processes not marked in this way to execute in this + cgroup or its siblings. This setting corresponds to the cpu.idle cgroup attribute. + + Note that this value only has an effect on cgroup-v2, for cgroup-v1 it is equivalent to the minimum weight. + + + + While StartupCPUWeight= applies to the startup and shutdown phases of the system, + CPUWeight= applies to normal runtime of the system, and if the former is not set also to + the startup and shutdown phases. Using StartupCPUWeight= allows prioritizing specific services at + boot-up and shutdown differently than during normal runtime. + + In addition to the resource allocation performed by the controller, the + kernel may automatically divide resources based on session-id grouping, see "The autogroup feature" + in sched7. + The effect of this feature is similar to the controller with no explicit + configuration, so users should be careful to not mistake one for the other. + + + + + CPUQuota= + + + This setting controls the controller in the unified hierarchy. + + Assign the specified CPU time quota to the processes executed. Takes a percentage value, suffixed with + "%". The percentage specifies how much CPU time the unit shall get at maximum, relative to the total CPU time + available on one CPU. Use values > 100% for allotting CPU time on more than one CPU. This controls the + cpu.max attribute on the unified control group hierarchy and + cpu.cfs_quota_us on legacy. For details about these control group attributes, see Control Groups v2 and CFS Bandwidth Control. + Setting CPUQuota= to an empty value unsets the quota. + + Example: CPUQuota=20% ensures that the executed processes will never get more than + 20% CPU time on one CPU. + + + + + + CPUQuotaPeriodSec= + + + This setting controls the controller in the unified hierarchy. + + Assign the duration over which the CPU time quota specified by CPUQuota= is measured. + Takes a time duration value in seconds, with an optional suffix such as "ms" for milliseconds (or "s" for seconds.) + The default setting is 100ms. The period is clamped to the range supported by the kernel, which is [1ms, 1000ms]. + Additionally, the period is adjusted up so that the quota interval is also at least 1ms. + Setting CPUQuotaPeriodSec= to an empty value resets it to the default. + + This controls the second field of cpu.max attribute on the unified control group hierarchy + and cpu.cfs_period_us on legacy. For details about these control group attributes, see + Control Groups v2 and + CFS Scheduler. + + Example: CPUQuotaPeriodSec=10ms to request that the CPU quota is measured in periods of 10ms. + + + + + AllowedCPUs= + StartupAllowedCPUs= + + + This setting controls the controller in the unified hierarchy. + + Restrict processes to be executed on specific CPUs. Takes a list of CPU indices or ranges separated by either + whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a dash. + + Setting AllowedCPUs= or StartupAllowedCPUs= doesn't guarantee that all + of the CPUs will be used by the processes as it may be limited by parent units. The effective configuration is + reported as EffectiveCPUs=. + + While StartupAllowedCPUs= applies to the startup and shutdown phases of the system, + AllowedCPUs= applies to normal runtime of the system, and if the former is not set also to + the startup and shutdown phases. Using StartupAllowedCPUs= allows prioritizing specific services at + boot-up and shutdown differently than during normal runtime. + + This setting is supported only with the unified control group hierarchy. + + + + + AllowedMemoryNodes= + StartupAllowedMemoryNodes= + + + These settings control the controller in the unified hierarchy. + + Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes indices + or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper + NUMA nodes indices separated by a dash. + + Setting AllowedMemoryNodes= or StartupAllowedMemoryNodes= doesn't + guarantee that all of the memory NUMA nodes will be used by the processes as it may be limited by parent units. + The effective configuration is reported as EffectiveMemoryNodes=. + + While StartupAllowedMemoryNodes= applies to the startup and shutdown phases of the system, + AllowedMemoryNodes= applies to normal runtime of the system, and if the former is not set also to + the startup and shutdown phases. Using StartupAllowedMemoryNodes= allows prioritizing specific services at + boot-up and shutdown differently than during normal runtime. + + This setting is supported only with the unified control group hierarchy. + + + + + MemoryAccounting= + + + This setting controls the controller in the unified hierarchy. + + Turn on process and kernel memory accounting for this + unit. Takes a boolean argument. Note that turning on memory + accounting for one unit will also implicitly turn it on for + all units contained in the same slice and for all its parent + slices and the units contained therein. The system default + for this setting may be controlled with + DefaultMemoryAccounting= in + systemd-system.conf5. + + + + + MemoryMin=bytes, MemoryLow=bytes + + + These settings control the controller in the unified hierarchy. + + Specify the memory usage protection of the executed processes in this unit. + When reclaiming memory, the unit is treated as if it was using less memory resulting in memory + to be preferentially reclaimed from unprotected units. + Using MemoryLow= results in a weaker protection where memory may still + be reclaimed to avoid invoking the OOM killer in case there is no other reclaimable memory. + + For a protection to be effective, it is generally required to set a corresponding + allocation on all ancestors, which is then distributed between children + (with the exception of the root slice). + Any MemoryMin= or MemoryLow= allocation that is not + explicitly distributed to specific children is used to create a shared protection for all children. + As this is a shared protection, the children will freely compete for the memory. + + Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a + percentage value may be specified, which is taken relative to the installed physical memory on the + system. If assigned the special value infinity, all available memory is protected, which may be + useful in order to always inherit all of the protection afforded by ancestors. + This controls the memory.min or memory.low control group attribute. + For details about this control group attribute, see Memory Interface Files. + + Units may have their children use a default memory.min or + memory.low value by specifying DefaultMemoryMin= or + DefaultMemoryLow=, which has the same semantics as + MemoryMin= and MemoryLow=. + This setting does not affect memory.min or memory.low + in the unit itself. + Using it to set a default child allocation is only useful on kernels older than 5.7, + which do not support the memory_recursiveprot cgroup2 mount option. + + + + + MemoryHigh=bytes + + + These settings control the controller in the unified hierarchy. + + Specify the throttling limit on memory usage of the executed processes in this unit. Memory usage may go + above the limit if unavoidable, but the processes are heavily slowed down and memory is taken away + aggressively in such cases. This is the main mechanism to control memory usage of a unit. + + Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a + percentage value may be specified, which is taken relative to the installed physical memory on the + system. If assigned the + special value infinity, no memory throttling is applied. This controls the + memory.high control group attribute. For details about this control group attribute, see + Memory Interface Files. + + + + + MemoryMax=bytes + + + These settings control the controller in the unified hierarchy. + + Specify the absolute limit on memory usage of the executed processes in this unit. If memory usage + cannot be contained under the limit, out-of-memory killer is invoked inside the unit. It is recommended to + use MemoryHigh= as the main control mechanism and use MemoryMax= as the + last line of defense. + + Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a + percentage value may be specified, which is taken relative to the installed physical memory on the system. If + assigned the special value infinity, no memory limit is applied. This controls the + memory.max control group attribute. For details about this control group attribute, see + Memory Interface Files. + + + + + MemorySwapMax=bytes + + + These settings control the controller in the unified hierarchy. + + Specify the absolute limit on swap usage of the executed processes in this unit. + + Takes a swap size in bytes. If the value is suffixed with K, M, G or T, the specified swap size is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the + special value infinity, no swap limit is applied. This controls the + memory.swap.max control group attribute. For details about this control group attribute, + see Memory Interface Files. + + + + + TasksAccounting= + + + This setting controls the controller in the unified hierarchy. + + Turn on task accounting for this unit. Takes a boolean argument. If enabled, the kernel will + keep track of the total number of tasks in the unit and its children. This number includes both + kernel threads and userspace processes, with each thread counted individually. Note that turning on + tasks accounting for one unit will also implicitly turn it on for all units contained in the same + slice and for all its parent slices and the units contained therein. The system default for this + setting may be controlled with DefaultTasksAccounting= in + systemd-system.conf5. + + + + + TasksMax=N + + + This setting controls the controller in the unified hierarchy. + + Specify the maximum number of tasks that may be created in the unit. This ensures that the + number of tasks accounted for the unit (see above) stays below a specific limit. This either takes + an absolute number of tasks or a percentage value that is taken relative to the configured maximum + number of tasks on the system. If assigned the special value infinity, no tasks + limit is applied. This controls the pids.max control group attribute. For + details about this control group attribute, the + pids controller + . + + The system default for this setting may be controlled with + DefaultTasksMax= in + systemd-system.conf5. + + + + + IOAccounting= + + + This setting controls the controller in the unified hierarchy. + + Turn on Block I/O accounting for this unit, if the unified control group hierarchy is used on the + system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly + turn it on for all units contained in the same slice and all for its parent slices and the units contained + therein. The system default for this setting may be controlled with DefaultIOAccounting= + in + systemd-system.conf5. + + + + + IOWeight=weight + StartupIOWeight=weight + + + These settings control the controller in the unified hierarchy. + + Set the default overall block I/O weight for the executed processes, if the unified control + group hierarchy is used on the system. Takes a single weight value (between 1 and 10000) to set the + default block I/O weight. This controls the io.weight control group attribute, + which defaults to 100. For details about this control group attribute, see IO + Interface Files. The available I/O bandwidth is split up among all units within one slice + relative to their block I/O weight. A higher weight means more I/O bandwidth, a lower weight means + less. + + While StartupIOWeight= applies + to the startup and shutdown phases of the system, + IOWeight= applies to the later runtime of + the system, and if the former is not set also to the startup + and shutdown phases. This allows prioritizing specific services at boot-up + and shutdown differently than during runtime. + + + + + IODeviceWeight=device weight + + + This setting controls the controller in the unified hierarchy. + + Set the per-device overall block I/O weight for the executed processes, if the unified control group + hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify + the device specific weight value, between 1 and 10000. (Example: /dev/sda 1000). The file + path may be specified as path to a block device node or as any other file, in which case the backing block + device of the file system of the file is determined. This controls the io.weight control + group attribute, which defaults to 100. Use this option multiple times to set weights for multiple devices. + For details about this control group attribute, see IO Interface Files. + + The specified device node should reference a block device that has an I/O scheduler + associated, i.e. should not refer to partition or loopback block devices, but to the originating, + physical device. When a path to a regular file or directory is specified it is attempted to + discover the correct originating device backing the file system of the specified path. This works + correctly only for simpler cases, where the file system is directly placed on a partition or + physical block device, or where simple 1:1 encryption using dm-crypt/LUKS is used. This discovery + does not cover complex storage and in particular RAID and volume management storage devices. + + + + + IOReadBandwidthMax=device bytes + IOWriteBandwidthMax=device bytes + + + These settings control the controller in the unified hierarchy. + + Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified + control group hierarchy is used on the system. This limit is not work-conserving and the executed processes + are not allowed to use more even if the device has idle capacity. Takes a space-separated pair of a file + path and a bandwidth value (in bytes per second) to specify the device specific bandwidth. The file path may + be a path to a block device node, or as any other file in which case the backing block device of the file + system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is + parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the io.max control + group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For details + about this control group attribute, see IO Interface Files. + + + Similar restrictions on block device discovery as for IODeviceWeight= apply, see above. + + + + + IOReadIOPSMax=device IOPS + IOWriteIOPSMax=device IOPS + + + These settings control the controller in the unified hierarchy. + + Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the + unified control group hierarchy is used on the system. This limit is not work-conserving and the executed + processes are not allowed to use more even if the device has idle capacity. Takes a space-separated pair of + a file path and an IOPS value to specify the device specific IOPS. The file path may be a path to a block + device node, or as any other file in which case the backing block device of the file system of the file is + used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS, MegaIOPS, + GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example: + "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This controls the io.max control + group attributes. Use this option multiple times to set IOPS limits for multiple devices. For details about + this control group attribute, see IO Interface Files. + + + Similar restrictions on block device discovery as for IODeviceWeight= apply, see above. + + + + + IODeviceLatencyTargetSec=device target + + + This setting controls the controller in the unified hierarchy. + + Set the per-device average target I/O latency for the executed processes, if the unified control group + hierarchy is used on the system. Takes a file path and a timespan separated by a space to specify + the device specific latency target. (Example: "/dev/sda 25ms"). The file path may be specified + as path to a block device node or as any other file, in which case the backing block device of the file + system of the file is determined. This controls the io.latency control group + attribute. Use this option multiple times to set latency target for multiple devices. For details about this + control group attribute, see IO Interface Files. + + Implies IOAccounting=yes. + + These settings are supported only if the unified control group hierarchy is used. + + Similar restrictions on block device discovery as for IODeviceWeight= apply, see above. + + + + + IPAccounting= + + + Takes a boolean argument. If true, turns on IPv4 and IPv6 network traffic accounting for packets sent + or received by the unit. When this option is turned on, all IPv4 and IPv6 sockets created by any process of + the unit are accounted for. + + When this option is used in socket units, it applies to all IPv4 and IPv6 sockets + associated with it (including both listening and connection sockets where this applies). Note that for + socket-activated services, this configuration setting and the accounting data of the service unit and the + socket unit are kept separate, and displayed separately. No propagation of the setting and the collected + statistics is done, in either direction. Moreover, any traffic sent or received on any of the socket unit's + sockets is accounted to the socket unit — and never to the service unit it might have activated, even if the + socket is used by it. + + The system default for this setting may be controlled with DefaultIPAccounting= in + systemd-system.conf5. + + + + + IPAddressAllow=ADDRESS[/PREFIXLENGTH]… + IPAddressDeny=ADDRESS[/PREFIXLENGTH]… + + + Turn on network traffic filtering for IP packets sent and received over + AF_INET and AF_INET6 sockets. Both directives take a + space separated list of IPv4 or IPv6 addresses, each optionally suffixed with an address prefix + length in bits after a / character. If the suffix is omitted, the address is + considered a host address, i.e. the filter covers the whole address (32 bits for IPv4, 128 bits for + IPv6). + + The access lists configured with this option are applied to all sockets created by processes + of this unit (or in the case of socket units, associated with it). The lists are implicitly + combined with any lists configured for any of the parent slice units this unit might be a member + of. By default both access lists are empty. Both ingress and egress traffic is filtered by these + settings. In case of ingress traffic the source IP address is checked against these access lists, + in case of egress traffic the destination IP address is checked. The following rules are applied in + turn: + + + Access is granted when the checked IP address matches an entry in the + IPAddressAllow= list. + + Otherwise, access is denied when the checked IP address matches an entry in the + IPAddressDeny= list. + + Otherwise, access is granted. + + + In order to implement an allow-listing IP firewall, it is recommended to use a + IPAddressDeny=any setting on an upper-level slice unit + (such as the root slice -.slice or the slice containing all system services + system.slice – see + systemd.special7 + for details on these slice units), plus individual per-service IPAddressAllow= + lines permitting network access to relevant services, and only them. + + Note that for socket-activated services, the IP access list configured on the socket unit + applies to all sockets associated with it directly, but not to any sockets created by the + ultimately activated services for it. Conversely, the IP access list configured for the service is + not applied to any sockets passed into the service via socket activation. Thus, it is usually a + good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless, + it may make sense to maintain one list more open and the other one more restricted, depending on + the usecase. + + If these settings are used multiple times in the same unit the specified lists are combined. If an + empty string is assigned to these settings the specific access list is reset and all previous settings undone. + + In place of explicit IPv4 or IPv6 address and prefix length specifications a small set of symbolic + names may be used. The following names are defined: + + + Special address/network names + + + + + + + + + Symbolic Name + Definition + Meaning + + + + + + any + 0.0.0.0/0 ::/0 + Any host + + + + localhost + 127.0.0.0/8 ::1/128 + All addresses on the local loopback + + + + link-local + 169.254.0.0/16 fe80::/64 + All link-local IP addresses + + + + multicast + 224.0.0.0/4 ff00::/8 + All IP multicasting addresses + + + +
+ + Note that these settings might not be supported on some systems (for example if eBPF control group + support is not enabled in the underlying kernel or container manager). These settings will have no effect in + that case. If compatibility with such systems is desired it is hence recommended to not exclusively rely on + them for IP security. + + + + + IPIngressFilterPath=BPF_FS_PROGRAM_PATH + IPEgressFilterPath=BPF_FS_PROGRAM_PATH + + + Add custom network traffic filters implemented as BPF programs, applying to all IP packets + sent and received over AF_INET and AF_INET6 sockets. + Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/). + + + The filters configured with this option are applied to all sockets created by processes + of this unit (or in the case of socket units, associated with it). The filters are loaded in addition + to filters any of the parent slice units this unit might be a member of as well as any + IPAddressAllow= and IPAddressDeny= filters in any of these units. + By default there are no filters specified. + + If these settings are used multiple times in the same unit all the specified programs are attached. If an + empty string is assigned to these settings the program list is reset and all previous specified programs ignored. + + If the path BPF_FS_PROGRAM_PATH in IPIngressFilterPath= assignment + is already being handled by BPFProgram= ingress hook, e.g. + BPFProgram=ingress:BPF_FS_PROGRAM_PATH, + the assignment will be still considered valid and the program will be attached to a cgroup. Same for + IPEgressFilterPath= path and egress hook. + + Note that for socket-activated services, the IP filter programs configured on the socket unit apply to + all sockets associated with it directly, but not to any sockets created by the ultimately activated services + for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into + the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both + the socket and the service unit, however it often makes sense to maintain one configuration more open and the other + one more restricted, depending on the usecase. + + Note that these settings might not be supported on some systems (for example if eBPF control group + support is not enabled in the underlying kernel or container manager). These settings will fail the service in + that case. If compatibility with such systems is desired it is hence recommended to attach your filter manually + (requires Delegate=yes) instead of using this setting. + + + + + BPFProgram=type:program-path + + Add a custom cgroup BPF program. + + BPFProgram= allows attaching BPF hooks to the cgroup of a systemd unit. + (This generalizes the functionality exposed via IPEgressFilterPath= for egress and + IPIngressFilterPath= for ingress.) + Cgroup-bpf hooks in the form of BPF programs loaded to the BPF filesystem are attached with cgroup-bpf attach + flags determined by the unit. For details about attachment types and flags see . + For general BPF documentation please refer to . + + The specification of BPF program consists of a type followed by a + program-path with : as the separator: + type:program-path. + + type is the string name of BPF attach type also used in + bpftool. type can be one of egress, + ingress, sock_create, sock_ops, + device, bind4, bind6, + connect4, connect6, post_bind4, + post_bind6, sendmsg4, sendmsg6, + sysctl, recvmsg4, recvmsg6, + getsockopt, setsockopt. + + Setting BPFProgram= to an empty value makes previous assignments ineffective. + Multiple assignments of the same type:program-path + value have the same effect as a single assignment: the program with the path program-path + will be attached to cgroup hook type just once. + If BPF egress pinned to program-path path is already being + handled by IPEgressFilterPath=, BPFProgram= + assignment will be considered valid and BPFProgram= will be attached to a cgroup. + Similarly for ingress hook and IPIngressFilterPath= assignment. + + BPF programs passed with BPFProgram= are attached to the cgroup of a unit with BPF + attach flag multi, that allows further attachments of the same + type within cgroup hierarchy topped by the unit cgroup. + + Examples: +BPFProgram=egress:/sys/fs/bpf/egress-hook +BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook + + + + + + SocketBindAllow=bind-rule + SocketBindDeny=bind-rule + + + Allow or deny binding a socket address to a socket by matching it with the bind-rule and + applying a corresponding action if there is a match. + + bind-rule describes socket properties such as address-family, + transport-protocol and ip-ports. + + bind-rule := + { [address-family:][transport-protocol:][ip-ports] | any } + + address-family := { ipv4 | ipv6 } + + transport-protocol := { tcp | udp } + + ip-ports := { ip-port | ip-port-range } + + An optional address-family expects ipv4 or ipv6 values. + If not specified, a rule will be matched for both IPv4 and IPv6 addresses and applied depending on other socket fields, e.g. transport-protocol, + ip-port. + + An optional transport-protocol expects tcp or udp transport protocol names. + If not specified, a rule will be matched for any transport protocol. + + An optional ip-port value must lie within 1…65535 interval inclusively, i.e. + dynamic port 0 is not allowed. A range of sequential ports is described by + ip-port-range := ip-port-low-ip-port-high, + where ip-port-low is smaller than or equal to ip-port-high + and both are within 1…65535 inclusively. + + A special value any can be used to apply a rule to any address family, transport protocol and any port with a positive value. + + To allow multiple rules assign SocketBindAllow= or SocketBindDeny= multiple times. + To clear the existing assignments pass an empty SocketBindAllow= or SocketBindDeny= + assignment. + + For each of SocketBindAllow= and SocketBindDeny=, maximum allowed number of assignments is + 128. + + + Binding to a socket is allowed when a socket address matches an entry in the + SocketBindAllow= list. + + Otherwise, binding is denied when the socket address matches an entry in the + SocketBindDeny= list. + + Otherwise, binding is allowed. + + + The feature is implemented with cgroup/bind4 and cgroup/bind6 cgroup-bpf hooks. + Examples:… +# Allow binding IPv6 socket addresses with a port greater than or equal to 10000. +[Service] +SocketBindAllow=ipv6:10000-65535 +SocketBindDeny=any +… +# Allow binding IPv4 and IPv6 socket addresses with 1234 and 4321 ports. +[Service] +SocketBindAllow=1234 +SocketBindAllow=4321 +SocketBindDeny=any +… +# Deny binding IPv6 socket addresses. +[Service] +SocketBindDeny=ipv6 +… +# Deny binding IPv4 and IPv6 socket addresses. +[Service] +SocketBindDeny=any +… +# Allow binding only over TCP +[Service] +SocketBindAllow=tcp +SocketBindDeny=any +… +# Allow binding only over IPv6/TCP +[Service] +SocketBindAllow=ipv6:tcp +SocketBindDeny=any +… +# Allow binding ports within 10000-65535 range over IPv4/UDP. +[Service] +SocketBindAllow=ipv4:udp:10000-65535 +SocketBindDeny=any +… + + + + + RestrictNetworkInterfaces= + + + Takes a list of space-separated network interface names. This option restricts the network + interfaces that processes of this unit can use. By default processes can only use the network interfaces + listed (allow-list). If the first character of the rule is ~, the effect is inverted: + the processes can only use network interfaces not listed (deny-list). + + + This option can appear multiple times, in which case the network interface names are merged. If the + empty string is assigned the set is reset, all prior assignments will have not effect. + + + If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered + will take precedence and will dictate the default action (allow vs deny). Then the next occurrences of this + option will add or delete the listed network interface names from the set, depending of its type and the + default action. + + + The loopback interface ("lo") is not treated in any special way, you have to configure it explicitly + in the unit file. + + Example 1: allow-list + +RestrictNetworkInterfaces=eth1 +RestrictNetworkInterfaces=eth2 + Programs in the unit will be only able to use the eth1 and eth2 network + interfaces. + + + Example 2: deny-list + +RestrictNetworkInterfaces=~eth1 eth2 + Programs in the unit will be able to use any network interface but eth1 and eth2. + + + Example 3: mixed + +RestrictNetworkInterfaces=eth1 eth2 +RestrictNetworkInterfaces=~eth1 + Programs in the unit will be only able to use the eth2 network interface. + + + + + + DeviceAllow= + + + Control access to specific device nodes by the executed processes. Takes two space-separated + strings: a device node specifier followed by a combination of r, + w, m to control reading, + writing, or creation of the specific device nodes by the unit + (mknod), respectively. This functionality is implemented using eBPF + filtering. + + When access to all physical devices should be disallowed, + PrivateDevices= may be used instead. See + systemd.exec5. + + + The device node specifier is either a path to a device node in the file system, starting with + /dev/, or a string starting with either char- or + block- followed by a device group name, as listed in + /proc/devices. The latter is useful to allow-list all current and future + devices belonging to a specific device group at once. The device group is matched according to + filename globbing rules, you may hence use the * and ? + wildcards. (Note that such globbing wildcards are not available for device node path + specifications!) In order to match device nodes by numeric major/minor, use device node paths in + the /dev/char/ and /dev/block/ directories. However, + matching devices by major/minor is generally not recommended as assignments are neither stable nor + portable between systems or different kernel versions. + + Examples: /dev/sda5 is a path to a device node, referring to an ATA or + SCSI block device. char-pts and char-alsa are specifiers for + all pseudo TTYs and all ALSA sound devices, respectively. char-cpu/* is a + specifier matching all CPU related device groups. + + Note that allow lists defined this way should only reference device groups which are + resolvable at the time the unit is started. Any device groups not resolvable then are not added to + the device allow list. In order to work around this limitation, consider extending service units + with a pair of After=modprobe@xyz.service and + Wants=modprobe@xyz.service lines that load the necessary kernel module + implementing the device group if missing. + Example: … +[Unit] +Wants=modprobe@loop.service +After=modprobe@loop.service + +[Service] +DeviceAllow=block-loop +DeviceAllow=/dev/loop-control +… + + + + + + DevicePolicy=auto|closed|strict + + + + Control the policy for allowing device access: + + + + + + means to only allow types of access that are + explicitly specified. + + + + + + + in addition, allows access to standard pseudo + devices including + /dev/null, + /dev/zero, + /dev/full, + /dev/random, and + /dev/urandom. + + + + + + + + + in addition, allows access to all devices if no + explicit DeviceAllow= is present. + This is the default. + + + + + + + + + Slice= + + + The name of the slice unit to place the unit + in. Defaults to system.slice for all + non-instantiated units of all unit types (except for slice + units themselves see below). Instance units are by default + placed in a subslice of system.slice + that is named after the template name. + + This option may be used to arrange systemd units in a + hierarchy of slices each of which might have resource + settings applied. + + For units of type slice, the only accepted value for + this setting is the parent slice. Since the name of a slice + unit implies the parent slice, it is hence redundant to ever + set this parameter directly for slice units. + + Special care should be taken when relying on the default slice assignment in templated service units + that have DefaultDependencies=no set, see + systemd.service5, section + "Default Dependencies" for details. + + + + + + Delegate= + + + Turns on delegation of further resource control partitioning to processes of the unit. Units where this + is enabled may create and manage their own private subhierarchy of control groups below the control group of + the unit itself. For unprivileged services (i.e. those using the User= setting) the unit's + control group will be made accessible to the relevant user. + + When enabled the service manager will refrain from manipulating control groups or moving + processes below the unit's control group, so that a clear concept of ownership is established: the + control group tree at the level of the unit's control group and above (i.e. towards the root + control group) is owned and managed by the service manager of the host, while the control group + tree below the unit's control group is owned and managed by the unit itself. + + Takes either a boolean argument or a (possibly empty) list of control group controller names. + If true, delegation is turned on, and all supported controllers are enabled for the unit, making + them available to the unit's processes for management. If false, delegation is turned off entirely + (and no additional controllers are enabled). If set to a list of controllers, delegation is turned + on, and the specified controllers are enabled for the unit. Assigning the empty string will enable + delegation, but reset the list of controllers, and all assignments prior to this will have no + effect. Note that additional controllers other than the ones specified might be made available as + well, depending on configuration of the containing slice unit or other units contained in it. + Defaults to false. + + Note that controller delegation to less privileged code is only safe on the unified control + group hierarchy. Accordingly, access to the specified controllers will not be granted to + unprivileged services on the legacy hierarchy, even when requested. + + + + Not all of these controllers are available on all kernels however, and some are specific to + the unified hierarchy while others are specific to the legacy hierarchy. Also note that the kernel + might support further controllers, which aren't covered here yet as delegation is either not + supported at all for them or not defined cleanly. + + Note that because of the hierarchical nature of cgroup hierarchy, any controllers that are + delegated will be enabled for the parent and sibling units of the unit with delegation. + + For further details on the delegation model consult Control Group APIs and Delegation. + + + + + DisableControllers= + + + Disables controllers from being enabled for a unit's children. If a controller listed is + already in use in its subtree, the controller will be removed from the subtree. This can be used to + avoid configuration in child units from being able to implicitly or explicitly enable a controller. + Defaults to empty. + + Multiple controllers may be specified, separated by spaces. You may also pass + DisableControllers= multiple times, in which case each new instance adds another controller + to disable. Passing DisableControllers= by itself with no controller name present resets + the disabled controller list. + + It may not be possible to disable a controller after units have been started, if the unit or + any child of the unit in question delegates controllers to its children, as any delegated subtree + of the cgroup hierarchy is unmanaged by systemd. + + + + + + + ManagedOOMSwap=auto|kill + ManagedOOMMemoryPressure=auto|kill + + + Specifies how + systemd-oomd.service8 + will act on this unit's cgroups. Defaults to . + + When set to , the unit becomes a candidate for monitoring by + systemd-oomd. If the cgroup passes the limits set by + oomd.conf5 or + the unit configuration, systemd-oomd will select a descendant cgroup and send + SIGKILL to all of the processes under it. You can find more details on + candidates and kill behavior at + systemd-oomd.service8 + and + oomd.conf5. + + Setting either of these properties to will also result in + After= and Wants= dependencies on + systemd-oomd.service unless DefaultDependencies=no. + + When set to , systemd-oomd will not actively use this + cgroup's data for monitoring and detection. However, if an ancestor cgroup has one of these + properties set to , a unit with can still be a candidate + for systemd-oomd to terminate. + + + + + ManagedOOMMemoryPressureLimit= + + + Overrides the default memory pressure limit set by + oomd.conf5 for + this unit (cgroup). Takes a percentage value between 0% and 100%, inclusive. This property is + ignored unless ManagedOOMMemoryPressure=. Defaults to 0%, + which means to use the default set by + oomd.conf5. + + + + + + ManagedOOMPreference=none|avoid|omit + + + Allows deprioritizing or omitting this unit's cgroup as a candidate when + systemd-oomd needs to act. Requires support for extended attributes (see + xattr7) + in order to use or . + + When calculating candidates to relieve swap usage, systemd-oomd will + only respect these extended attributes if the unit's cgroup is owned by root. + + When calculating candidates to relieve memory pressure, systemd-oomd + will only respect these extended attributes if the unit's cgroup owner, and the + owner of the monitored ancestor cgroup are the same. For example, if systemd-oomd + is calculating candidates for -.slice, then extended attributes set + on descendants of /user.slice/user-1000.slice/user@1000.service/ + will be ignored because the descendants are owned by UID 1000, and -.slice + is owned by UID 0. But, if calculating candidates for + /user.slice/user-1000.slice/user@1000.service/, then extended attributes set + on the descendants would be respected. + + If this property is set to , the service manager will convey this to + systemd-oomd, which will only select this cgroup if there are no other viable + candidates. + + If this property is set to , the service manager will convey this to + systemd-oomd, which will ignore this cgroup as a candidate and will not perform + any actions on it. + + It is recommended to use and sparingly, as it + can adversely affect systemd-oomd's kill behavior. Also note that these extended + attributes are not applied recursively to cgroups under this unit's cgroup. + + Defaults to which means systemd-oomd will rank this + unit's cgroup as defined in + systemd-oomd.service8 + and oomd.conf5. + + + + + + + + History + + + + systemd 252 + Options for controlling the Legacy Control Group Hierarchy (Control Groups version 1 are + now fully deprecated: CPUShares=weight, + StartupCPUShares=weight, + MemoryLimit=bytes, + BlockIOAccounting=, + BlockIOWeight=weight, + StartupBlockIOWeight=weight, + BlockIODeviceWeight=device + weight, + BlockIOReadBandwidth=device + bytes, + BlockIOWriteBandwidth=device + bytes. + Please switch to the unified cgroup hierarchy. + + + + + + See Also + + systemd1, + systemd-system.conf5, + systemd.unit5, + systemd.service5, + systemd.slice5, + systemd.scope5, + systemd.socket5, + systemd.mount5, + systemd.swap5, + systemd.exec5, + systemd.directives7, + systemd.special7, + systemd-oomd.service8, + The documentation for control groups and specific controllers in the Linux kernel: + Control Groups v2. + + + diff --git a/man/systemd.scope.xml b/man/systemd.scope.xml new file mode 100644 index 0000000..95969bf --- /dev/null +++ b/man/systemd.scope.xml @@ -0,0 +1,143 @@ + + + + + + + systemd.scope + systemd + + + + systemd.scope + 5 + + + + systemd.scope + Scope unit configuration + + + + scope.scope + + + + Description + + Scope units are not configured via unit configuration files, + but are only created programmatically using the bus interfaces of + systemd. They are named similar to filenames. A unit whose name + ends in .scope refers to a scope unit. Scopes + units manage a set of system processes. Unlike service units, scope + units manage externally created processes, and do not fork off + processes on its own. + + The main purpose of scope units is grouping worker processes + of a system service for organization and for managing resources. + + systemd-run may + be used to easily launch a command in a new scope unit from the + command line. + + See the New + Control Group Interfaces for an introduction on how to make + use of scope units from programs. + + Note that, unlike service units, scope units have no "main" process: all processes in the scope are + equivalent. The lifecycle of the scope unit is thus not bound to the lifetime of one specific process, + but to the existence of at least one process in the scope. This also means that the exit statuses of + these processes are not relevant for the scope unit failure state. Scope units may still enter a failure + state, for example due to resource exhaustion or stop timeouts being reached, but not due to programs + inside of them terminating uncleanly. Since processes managed as scope units generally remain children of + the original process that forked them off, it is also the job of that process to collect their exit + statuses and act on them as needed. + + + + Automatic Dependencies + + + Implicit Dependencies + + Implicit dependencies may be added as result of + resource control parameters as documented in + systemd.resource-control5. + + + + Default Dependencies + + The following dependencies are added unless + DefaultDependencies=no is set: + + + Scope units will automatically have dependencies of + type Conflicts= and + Before= on + shutdown.target. These ensure + that scope units are removed prior to system + shutdown. Only scope units involved with early boot or + late system shutdown should disable + DefaultDependencies= option. + + + + + + Options + + Scope files may include a [Unit] section, which is described in + systemd.unit5. + + + Scope files may include a [Scope] + section, which carries information about the scope and the + units it contains. A number of options that may be used in + this section are shared with other unit types. These options are + documented in + systemd.kill5 + and + systemd.resource-control5. + The options specific to the [Scope] section + of scope units are the following: + + + + + + RuntimeMaxSec= + + Configures a maximum time for the scope to run. If this is used and the scope has been + active for longer than the specified time it is terminated and put into a failure state. Pass + infinity (the default) to configure no runtime limit. + + + + RuntimeRandomizedExtraSec= + + This option modifies RuntimeMaxSec= by increasing the maximum runtime by an + evenly distributed duration between 0 and the specified value (in seconds). If RuntimeMaxSec= is + unspecified, then this feature will be disabled. + + + + + + + + + See Also + + systemd1, + systemd-run1, + systemd.unit5, + systemd.resource-control5, + systemd.service5, + systemd.directives7. + + + + diff --git a/man/systemd.service.xml b/man/systemd.service.xml new file mode 100644 index 0000000..40c3173 --- /dev/null +++ b/man/systemd.service.xml @@ -0,0 +1,1567 @@ + + + + + + + systemd.service + systemd + + + + systemd.service + 5 + + + + systemd.service + Service unit configuration + + + + service.service + + + + Description + + A unit configuration file whose name ends in + .service encodes information about a process + controlled and supervised by systemd. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic + [Unit] and [Install] + sections. The service specific configuration options are + configured in the [Service] section. + + Additional options are listed in + systemd.exec5, + which define the execution environment the commands are executed + in, and in + systemd.kill5, + which define the way the processes of the service are terminated, + and in + systemd.resource-control5, + which configure resource control settings for the processes of the + service. + + If SysV init compat is enabled, systemd automatically creates service units that wrap SysV init + scripts (the service name is the same as the name of the script, with a .service + suffix added); see + systemd-sysv-generator8. + + + The systemd-run1 + command allows creating .service and .scope units dynamically + and transiently from the command line. + + + + Service Templates + + It is possible for systemd services to take a single argument via the + service@argument.service + syntax. Such services are called "instantiated" services, while the unit definition without the + argument parameter is called a "template". An example could be a + dhcpcd@.service service template which takes a network interface as a + parameter to form an instantiated service. Within the service file, this parameter or "instance + name" can be accessed with %-specifiers. See + systemd.unit5 + for details. + + + + Automatic Dependencies + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + Services with Type=dbus set automatically + acquire dependencies of type Requires= and + After= on + dbus.socket. + + Socket activated services are automatically ordered after + their activating .socket units via an + automatic After= dependency. + Services also pull in all .socket units + listed in Sockets= via automatic + Wants= and After= dependencies. + + + Additional implicit dependencies may be added as result of + execution and resource control parameters as documented in + systemd.exec5 + and + systemd.resource-control5. + + + + Default Dependencies + + The following dependencies are added unless DefaultDependencies=no is set: + + + Service units will have dependencies of type Requires= and + After= on sysinit.target, a dependency of type After= on + basic.target as well as dependencies of type Conflicts= and + Before= on shutdown.target. These ensure that normal service units pull in + basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early + boot or late system shutdown should disable this option. + + Instanced service units (i.e. service units with an @ in their name) are assigned by + default a per-template slice unit (see + systemd.slice5), named after the + template unit, containing all instances of the specific template. This slice is normally stopped at shutdown, + together with all template instances. If that is not desired, set DefaultDependencies=no in the + template unit, and either define your own per-template slice unit file that also sets + DefaultDependencies=no, or set Slice=system.slice (or another suitable slice) + in the template unit. Also see + systemd.resource-control5. + + + + + + + Options + + Service unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + + + Service unit files must include a [Service] + section, which carries information about the service and the + process it supervises. A number of options that may be used in + this section are shared with other unit types. These options are + documented in + systemd.exec5, + systemd.kill5 + and + systemd.resource-control5. + The options specific to the [Service] section + of service units are the following: + + + + Type= + + + Configures the process start-up type for this service unit. One of , + , , , , + or : + + + If set to (the default if ExecStart= is + specified but neither Type= nor BusName= are), the service manager + will consider the unit started immediately after the main service process has been forked off. It is + expected that the process configured with ExecStart= is the main process of the + service. In this mode, if the process offers functionality to other processes on the system, its + communication channels should be installed before the service is started up (e.g. sockets set up by + systemd, via socket activation), as the service manager will immediately proceed starting follow-up units, + right after creating the main service process, and before executing the service's binary. Note that this + means systemctl start command lines for services will report + success even if the service's binary cannot be invoked successfully (for example because the selected + User= doesn't exist, or the service binary is missing). + + The type is similar to , but the service + manager will consider the unit started immediately after the main service binary has been executed. The service + manager will delay starting of follow-up units until that point. (Or in other words: + proceeds with further jobs right after fork() returns, while + will not proceed before both fork() and + execve() in the service process succeeded.) Note that this means systemctl + start command lines for services will report failure when the service's + binary cannot be invoked successfully (for example because the selected User= doesn't + exist, or the service binary is missing). + + If set to , it is expected that the process configured with + ExecStart= will call fork() as part of its start-up. The parent + process is expected to exit when start-up is complete and all communication channels are set up. The child + continues to run as the main service process, and the service manager will consider the unit started when + the parent process exits. This is the behavior of traditional UNIX services. If this setting is used, it is + recommended to also use the PIDFile= option, so that systemd can reliably identify the + main process of the service. systemd will proceed with starting follow-up units as soon as the parent + process exits. + + Behavior of is similar to ; + however, the service manager will consider the unit up after the main process exits. It will then + start follow-up units. RemainAfterExit= is particularly useful for this type + of service. Type= is the implied default if neither + Type= nor ExecStart= are specified. Note that if this + option is used without RemainAfterExit= the service will never enter + active unit state, but directly transition from activating + to deactivating or dead since no process is configured that + shall run continuously. In particular this means that after a service of this type ran (and which + has RemainAfterExit= not set) it will not show up as started afterwards, but + as dead. + + Behavior of is similar to ; however, + it is expected that the service acquires a name on the D-Bus bus, as configured by + BusName=. systemd will proceed with starting follow-up units after the D-Bus + bus name has been acquired. Service units with this option configured implicitly gain + dependencies on the dbus.socket unit. This type is the default if + BusName= is specified. A service unit of this type is considered to be in the + activating state until the specified bus name is acquired. It is considered activated while the + bus name is taken. Once the bus name is released the service is considered being no longer + functional which has the effect that the service manager attempts to terminate any remaining + processes belonging to the service. Services that drop their bus name as part of their shutdown + logic thus should be prepared to receive a SIGTERM (or whichever signal is + configured in KillSignal=) as result. + + Behavior of is similar to ; however, it is + expected that the service sends a notification message via + sd_notify3 or an + equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after + this notification message has been sent. If this option is used, NotifyAccess= (see + below) should be set to open access to the notification socket provided by systemd. If + NotifyAccess= is missing or set to , it will be forcibly set to + . + + Behavior of is very similar to ; however, + actual execution of the service program is delayed until all active jobs are dispatched. This may be used + to avoid interleaving of output of shell services with the status output on the console. Note that this + type is useful only to improve console output, it is not useful as a general unit ordering tool, and the + effect of this service type is subject to a 5s timeout, after which the service program is invoked + anyway. + + + It is generally recommended to use Type= for long-running + services whenever possible, as it is the simplest and fastest option. However, as this service type won't + propagate service start-up failures and doesn't allow ordering of other units against completion of + initialization of the service (which for example is useful if clients need to connect to the service through + some form of IPC, and the IPC channel is only established by the service itself — in contrast to doing this + ahead of time through socket or bus activation or similar), it might not be sufficient for many cases. If so, + or (the latter only in case the service provides a D-Bus + interface) are the preferred options as they allow service program code to precisely schedule when to + consider the service started up successfully and when to proceed with follow-up units. The + service type requires explicit support in the service codebase (as + sd_notify() or an equivalent API needs to be invoked by the service at the appropriate + time) — if it's not supported, then is an alternative: it supports the traditional + UNIX service start-up protocol. Finally, might be an option for cases where it is + enough to ensure the service binary is invoked, and where the service binary itself executes no or little + initialization on its own (and its initialization is unlikely to fail). Note that using any type other than + possibly delays the boot process, as the service manager needs to wait for service + initialization to complete. It is hence recommended not to needlessly use any types other than + . (Also note it is generally not recommended to use or + for long-running services.) + + + + + ExitType= + + + Specifies when the manager should consider the service to be finished. One of or + : + + + If set to (the default), the service manager + will consider the unit stopped when the main process, which is determined according to the + Type=, exits. Consequently, it cannot be used with + Type=. + + If set to , the service will be considered running as long as at + least one process in the cgroup has not exited. + + + It is generally recommended to use ExitType= when a service has + a known forking model and a main process can reliably be determined. ExitType= + is meant for applications whose forking model is not known ahead of time and which + might not have a specific main process. It is well suited for transient or automatically generated services, + such as graphical applications inside of a desktop environment. + + + + + RemainAfterExit= + + Takes a boolean value that specifies whether + the service shall be considered active even when all its + processes exited. Defaults to . + + + + + GuessMainPID= + + Takes a boolean value that specifies whether + systemd should try to guess the main PID of a service if it + cannot be determined reliably. This option is ignored unless + is set and + is unset because for the other types + or with an explicitly configured PID file, the main PID is + always known. The guessing algorithm might come to incorrect + conclusions if a daemon consists of more than one process. If + the main PID cannot be determined, failure detection and + automatic restarting of a service will not work reliably. + Defaults to . + + + + + PIDFile= + + Takes a path referring to the PID file of the service. Usage of this option is recommended for + services where Type= is set to . The path specified typically points + to a file below /run/. If a relative path is specified it is hence prefixed with + /run/. The service manager will read the PID of the main process of the service from this + file after start-up of the service. The service manager will not write to the file configured here, although it + will remove the file after the service has shut down if it still exists. The PID file does not need to be owned + by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: + the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the + PID file must refer to a process already belonging to the service. + + Note that PID files should be avoided in modern projects. Use or + where possible, which does not require use of PID files to determine the + main process of a service and avoids needless forking. + + + + BusName= + + Takes a D-Bus destination name that this service shall use. This option is mandatory + for services where Type= is set to . It is recommended to + always set this property if known to make it easy to map the service name to the D-Bus destination. + In particular, systemctl service-log-level/service-log-target verbs make use of + this. + + + + + ExecStart= + Commands with their arguments that are + executed when this service is started. The value is split into + zero or more command lines according to the rules described + below (see section "Command Lines" below). + + + Unless Type= is , exactly one command must be given. When + Type=oneshot is used, zero or more commands may be specified. Commands may be specified by + providing multiple command lines in the same directive, or alternatively, this directive may be specified more + than once with the same effect. If the empty string is assigned to this option, the list of commands to start + is reset, prior assignments of this option will have no effect. If no ExecStart= is + specified, then the service must have RemainAfterExit=yes and at least one + ExecStop= line set. (Services lacking both ExecStart= and + ExecStop= are not valid.) + + For each of the specified commands, the first argument must be either an absolute path to an executable + or a simple file name without any slashes. Optionally, this filename may be prefixed with a number of special + characters: + + + Special executable prefixes + + + + + + + + Prefix + Effect + + + + + @ + If the executable path is prefixed with @, the second specified token will be passed as argv[0] to the executed process (instead of the actual filename), followed by the further arguments specified. + + + + - + If the executable path is prefixed with -, an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is recorded, but has no further effect and is considered equivalent to success. + + + + : + If the executable path is prefixed with :, environment variable substitution (as described by the "Command Lines" section below) is not applied. + + + + + + If the executable path is prefixed with + then the process is executed with full privileges. In this mode privilege restrictions configured with User=, Group=, CapabilityBoundingSet= or the various file system namespacing options (such as PrivateDevices=, PrivateTmp=) are not applied to the invoked command line (but still affect any other ExecStart=, ExecStop=, … lines). + + + + ! + + Similar to the + character discussed above this permits invoking command lines with elevated privileges. However, unlike + the ! character exclusively alters the effect of User=, Group= and SupplementaryGroups=, i.e. only the stanzas that affect user and group credentials. Note that this setting may be combined with DynamicUser=, in which case a dynamic user/group pair is allocated before the command is invoked, but credential changing is left to the executed process itself. + + + + !! + + This prefix is very similar to !, however it only has an effect on systems lacking support for ambient process capabilities, i.e. without support for AmbientCapabilities=. It's intended to be used for unit files that take benefit of ambient capabilities to run processes with minimal privileges wherever possible while remaining compatible with systems that lack ambient capabilities support. Note that when !! is used, and a system lacking ambient capability support is detected any configured SystemCallFilter= and CapabilityBoundingSet= stanzas are implicitly modified, in order to permit spawned processes to drop credentials and capabilities themselves, even if this is configured to not be allowed. Moreover, if this prefix is used and a system lacking ambient capability support is detected AmbientCapabilities= will be skipped and not be applied. On systems supporting ambient capabilities, !! has no effect and is redundant. + + + +
+ + @, -, :, and one of + +/!/!! may be used together and they can appear in any + order. However, only one of +, !, !! may be used at a + time. Note that these prefixes are also supported for the other command line settings, + i.e. ExecStartPre=, ExecStartPost=, ExecReload=, + ExecStop= and ExecStopPost=. + + If more than one command is specified, the commands are + invoked sequentially in the order they appear in the unit + file. If one of the commands fails (and is not prefixed with + -), other lines are not executed, and the + unit is considered failed. + + Unless Type=forking is set, the + process started via this command line will be considered the + main process of the daemon. + + + + + ExecStartPre= + ExecStartPost= + Additional commands that are executed before + or after the command in ExecStart=, + respectively. Syntax is the same as for + ExecStart=, except that multiple command + lines are allowed and the commands are executed one after the + other, serially. + + If any of those commands (not prefixed with + -) fail, the rest are not executed and the + unit is considered failed. + + ExecStart= commands are only run after + all ExecStartPre= commands that were not prefixed + with a - exit successfully. + + ExecStartPost= commands are only run after the commands specified in + ExecStart= have been invoked successfully, as determined by Type= + (i.e. the process has been started for Type=simple or Type=idle, the last + ExecStart= process exited successfully for Type=oneshot, the initial + process exited successfully for Type=forking, READY=1 is sent for + Type=notify, or the BusName= has been taken for + Type=dbus). + + Note that ExecStartPre= may not be + used to start long-running processes. All processes forked + off by processes invoked via ExecStartPre= will + be killed before the next service process is run. + + Note that if any of the commands specified in ExecStartPre=, + ExecStart=, or ExecStartPost= fail (and are not prefixed with + -, see above) or time out before the service is fully up, execution continues with commands + specified in ExecStopPost=, the commands in ExecStop= are skipped. + + Note that the execution of ExecStartPost= is taken into account for the purpose of + Before=/After= ordering constraints. + + + + + ExecCondition= + Optional commands that are executed before the commands in ExecStartPre=. + Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the + commands are executed one after the other, serially. + + The behavior is like an ExecStartPre= and condition check hybrid: when an + ExecCondition= command exits with exit code 1 through 254 (inclusive), the remaining + commands are skipped and the unit is not marked as failed. However, if an + ExecCondition= command exits with 255 or abnormally (e.g. timeout, killed by a + signal, etc.), the unit will be considered failed (and remaining commands will be skipped). Exit code of 0 or + those matching SuccessExitStatus= will continue execution to the next commands. + + The same recommendations about not running long-running processes in ExecStartPre= + also applies to ExecCondition=. ExecCondition= will also run the commands + in ExecStopPost=, as part of stopping the service, in the case of any non-zero or abnormal + exits, like the ones described above. + + + + + ExecReload= + Commands to execute to trigger a configuration + reload in the service. This argument takes multiple command + lines, following the same scheme as described for + ExecStart= above. Use of this setting is + optional. Specifier and environment variable substitution is + supported here following the same scheme as for + ExecStart=. + + One additional, special environment variable is set: if + known, $MAINPID is set to the main process + of the daemon, and may be used for command lines like the + following: + + ExecReload=kill -HUP $MAINPID + + Note however that reloading a daemon by sending a signal + (as with the example line above) is usually not a good choice, + because this is an asynchronous operation and hence not + suitable to order reloads of multiple services against each + other. It is strongly recommended to set + ExecReload= to a command that not only + triggers a configuration reload of the daemon, but also + synchronously waits for it to complete. For example, + dbus-broker1 + uses the following: + + ExecReload=busctl call org.freedesktop.DBus \ + /org/freedesktop/DBus org.freedesktop.DBus \ + ReloadConfig + + + + + + ExecStop= + Commands to execute to stop the service started via + ExecStart=. This argument takes multiple command lines, following the same scheme + as described for ExecStart= above. Use of this setting is optional. After the + commands configured in this option are run, it is implied that the service is stopped, and any + processes remaining for it are terminated according to the KillMode= setting (see + systemd.kill5). + If this option is not specified, the process is terminated by sending the signal specified in + KillSignal= or RestartKillSignal= when service stop is + requested. Specifier and environment variable substitution is supported (including + $MAINPID, see above). + + Note that it is usually not sufficient to specify a command for this setting that only asks the + service to terminate (for example, by sending some form of termination signal to it), but does not + wait for it to do so. Since the remaining processes of the services are killed according to + KillMode= and KillSignal= or + RestartKillSignal= as described above immediately after the command exited, this + may not result in a clean stop. The specified command should hence be a synchronous operation, not an + asynchronous one. + + Note that the commands specified in ExecStop= are only executed when the service + started successfully first. They are not invoked if the service was never started at all, or in case its + start-up failed, for example because any of the commands specified in ExecStart=, + ExecStartPre= or ExecStartPost= failed (and weren't prefixed with + -, see above) or timed out. Use ExecStopPost= to invoke commands when a + service failed to start up correctly and is shut down again. Also note that the stop operation is always + performed if the service started successfully, even if the processes in the service terminated on their + own or were killed. The stop commands must be prepared to deal with that case. $MAINPID + will be unset if systemd knows that the main process exited by the time the stop commands are called. + + Service restart requests are implemented as stop operations followed by start operations. This + means that ExecStop= and ExecStopPost= are executed during a + service restart operation. + + It is recommended to use this setting for commands that communicate with the service requesting + clean termination. For post-mortem clean-up steps use ExecStopPost= instead. + + + + + ExecStopPost= + Additional commands that are executed after the service is stopped. This includes cases where + the commands configured in ExecStop= were used, where the service does not have any + ExecStop= defined, or where the service exited unexpectedly. This argument takes multiple + command lines, following the same scheme as described for ExecStart=. Use of these settings + is optional. Specifier and environment variable substitution is supported. Note that – unlike + ExecStop= – commands specified with this setting are invoked when a service failed to start + up correctly and is shut down again. + + It is recommended to use this setting for clean-up operations that shall be executed even when the + service failed to start up correctly. Commands configured with this setting need to be able to operate even if + the service failed starting up half-way and left incompletely initialized data around. As the service's + processes have been terminated already when the commands specified with this setting are executed they should + not attempt to communicate with them. + + Note that all commands that are configured with this setting are invoked with the result code of the + service, as well as the main process' exit code and status, set in the $SERVICE_RESULT, + $EXIT_CODE and $EXIT_STATUS environment variables, see + systemd.exec5 for + details. + + Note that the execution of ExecStopPost= is taken into account for the purpose of + Before=/After= ordering constraints. + + + + RestartSec= + Configures the time to sleep before restarting + a service (as configured with Restart=). + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Defaults to 100ms. + + + + TimeoutStartSec= + Configures the time to wait for start-up. If a daemon service does not signal start-up + completion within the configured time, the service will be considered failed and will be shut down again. The + precise action depends on the TimeoutStartFailureMode= option. Takes a unit-less value in + seconds, or a time span value such as "5min 20s". Pass infinity to disable the timeout logic. + Defaults to DefaultTimeoutStartSec= from the manager configuration file, except when + Type=oneshot is used, in which case the timeout is disabled by default (see + systemd-system.conf5). + + + If a service of Type=notify sends EXTEND_TIMEOUT_USEC=…, this may cause + the start time to be extended beyond TimeoutStartSec=. The first receipt of this message + must occur before TimeoutStartSec= is exceeded, and once the start time has extended beyond + TimeoutStartSec=, the service manager will allow the service to continue to start, provided + the service repeats EXTEND_TIMEOUT_USEC=… within the interval specified until the service + startup status is finished by READY=1. (see + sd_notify3). + + + + + TimeoutStopSec= + This option serves two purposes. First, it configures the time to wait for each + ExecStop= command. If any of them times out, subsequent ExecStop= commands + are skipped and the service will be terminated by SIGTERM. If no ExecStop= + commands are specified, the service gets the SIGTERM immediately. This default behavior + can be changed by the TimeoutStopFailureMode= option. Second, it configures the time + to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated + by SIGKILL (see KillMode= in + systemd.kill5). + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass infinity to disable the + timeout logic. Defaults to + DefaultTimeoutStopSec= from the manager + configuration file (see + systemd-system.conf5). + + + If a service of Type=notify sends EXTEND_TIMEOUT_USEC=…, this may cause + the stop time to be extended beyond TimeoutStopSec=. The first receipt of this message + must occur before TimeoutStopSec= is exceeded, and once the stop time has extended beyond + TimeoutStopSec=, the service manager will allow the service to continue to stop, provided + the service repeats EXTEND_TIMEOUT_USEC=… within the interval specified, or terminates itself + (see sd_notify3). + + + + + TimeoutAbortSec= + This option configures the time to wait for the service to terminate when it was aborted due to a + watchdog timeout (see WatchdogSec=). If the service has a short TimeoutStopSec= + this option can be used to give the system more time to write a core dump of the service. Upon expiration the service + will be forcibly terminated by SIGKILL (see KillMode= in + systemd.kill5). The core file will + be truncated in this case. Use TimeoutAbortSec= to set a sensible timeout for the core dumping per + service that is large enough to write all expected data while also being short enough to handle the service failure + in due time. + + + Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass an empty value to skip + the dedicated watchdog abort timeout handling and fall back TimeoutStopSec=. Pass + infinity to disable the timeout logic. Defaults to DefaultTimeoutAbortSec= from + the manager configuration file (see + systemd-system.conf5). + + + If a service of Type=notify handles SIGABRT itself (instead of relying + on the kernel to write a core dump) it can send EXTEND_TIMEOUT_USEC=… to + extended the abort time beyond TimeoutAbortSec=. The first receipt of this message + must occur before TimeoutAbortSec= is exceeded, and once the abort time has extended beyond + TimeoutAbortSec=, the service manager will allow the service to continue to abort, provided + the service repeats EXTEND_TIMEOUT_USEC=… within the interval specified, or terminates itself + (see sd_notify3). + + + + + TimeoutSec= + A shorthand for configuring both + TimeoutStartSec= and + TimeoutStopSec= to the specified value. + + + + + TimeoutStartFailureMode= + TimeoutStopFailureMode= + + These options configure the action that is taken in case a daemon service does not signal + start-up within its configured TimeoutStartSec=, respectively if it does not stop within + TimeoutStopSec=. Takes one of , and + . Both options default to . + + If is set the service will be gracefully terminated by sending the signal + specified in KillSignal= (defaults to SIGTERM, see + systemd.kill5). If the + service does not terminate the FinalKillSignal= is sent after + TimeoutStopSec=. If is set, WatchdogSignal= is sent + instead and TimeoutAbortSec= applies before sending FinalKillSignal=. + This setting may be used to analyze services that fail to start-up or shut-down intermittently. + By using the service is immediately terminated by sending + FinalKillSignal= without any further timeout. This setting can be used to expedite the + shutdown of failing services. + + + + + RuntimeMaxSec= + + Configures a maximum time for the service to run. If this is used and the service has been + active for longer than the specified time it is terminated and put into a failure state. Note that this setting + does not have any effect on Type=oneshot services, as they terminate immediately after + activation completed. Pass infinity (the default) to configure no runtime + limit. + + If a service of Type=notify sends EXTEND_TIMEOUT_USEC=…, this may cause + the runtime to be extended beyond RuntimeMaxSec=. The first receipt of this message + must occur before RuntimeMaxSec= is exceeded, and once the runtime has extended beyond + RuntimeMaxSec=, the service manager will allow the service to continue to run, provided + the service repeats EXTEND_TIMEOUT_USEC=… within the interval specified until the service + shutdown is achieved by STOPPING=1 (or termination). (see + sd_notify3). + + + + + RuntimeRandomizedExtraSec= + + This option modifies RuntimeMaxSec= by increasing the maximum runtime by an + evenly distributed duration between 0 and the specified value (in seconds). If RuntimeMaxSec= is + unspecified, then this feature will be disabled. + + + + + WatchdogSec= + Configures the watchdog timeout for a service. + The watchdog is activated when the start-up is completed. The + service must call + sd_notify3 + regularly with WATCHDOG=1 (i.e. the + "keep-alive ping"). If the time between two such calls is + larger than the configured time, then the service is placed in + a failed state and it will be terminated with + SIGABRT (or the signal specified by + WatchdogSignal=). By setting + Restart= to , + , or + , the service will be automatically + restarted. The time configured here will be passed to the + executed service process in the + WATCHDOG_USEC= environment variable. This + allows daemons to automatically enable the keep-alive pinging + logic if watchdog support is enabled for the service. If this + option is used, NotifyAccess= (see below) + should be set to open access to the notification socket + provided by systemd. If NotifyAccess= is + not set, it will be implicitly set to . + Defaults to 0, which disables this feature. The service can + check whether the service manager expects watchdog keep-alive + notifications. See + sd_watchdog_enabled3 + for details. + sd_event_set_watchdog3 + may be used to enable automatic watchdog notification support. + + + + + Restart= + Configures whether the service shall be + restarted when the service process exits, is killed, or a + timeout is reached. The service process may be the main + service process, but it may also be one of the processes + specified with ExecStartPre=, + ExecStartPost=, + ExecStop=, + ExecStopPost=, or + ExecReload=. When the death of the process + is a result of systemd operation (e.g. service stop or + restart), the service will not be restarted. Timeouts include + missing the watchdog "keep-alive ping" deadline and a service + start, reload, and stop operation timeouts. + + Takes one of + , + , + , + , + , + , or + . + If set to (the default), the service will + not be restarted. If set to , it + will be restarted only when the service process exits cleanly. + In this context, a clean exit means any of the following: + + exit code of 0; + for types other than + Type=oneshot, one of the signals + SIGHUP, + SIGINT, + SIGTERM, or + SIGPIPE; + exit statuses and signals specified in + SuccessExitStatus=. + + If set to + , the service will be restarted + when the process exits with a non-zero exit code, is + terminated by a signal (including on core dump, but excluding + the aforementioned four signals), when an operation (such as + service reload) times out, and when the configured watchdog + timeout is triggered. If set to , + the service will be restarted when the process is terminated + by a signal (including on core dump, excluding the + aforementioned four signals), when an operation times out, or + when the watchdog timeout is triggered. If set to + , the service will be restarted only + if the service process exits due to an uncaught signal not + specified as a clean exit status. If set to + , the service will be restarted + only if the watchdog timeout for the service expires. If set + to , the service will be restarted + regardless of whether it exited cleanly or not, got terminated + abnormally by a signal, or hit a timeout. + + + Exit causes and the effect of the <varname>Restart=</varname> settings + + + + + + + Restart settings/Exit causes + + + + + + + + + + + + Clean exit code or signal + + X + X + + + + + + + Unclean exit code + + X + + X + + + + + + Unclean signal + + X + + X + X + X + + + + Timeout + + X + + X + X + + + + + Watchdog + + X + + X + X + + X + + + +
+ + As exceptions to the setting above, the service will not + be restarted if the exit code or signal is specified in + RestartPreventExitStatus= (see below) or + the service is stopped with systemctl stop + or an equivalent operation. Also, the services will always be + restarted if the exit code or signal is specified in + RestartForceExitStatus= (see below). + + Note that service restart is subject to unit start rate + limiting configured with StartLimitIntervalSec= + and StartLimitBurst=, see + systemd.unit5 + for details. + + Setting this to is the + recommended choice for long-running services, in order to + increase reliability by attempting automatic recovery from + errors. For services that shall be able to terminate on their + own choice (and avoid immediate restarting), + is an alternative choice. + + + + + SuccessExitStatus= + + Takes a list of exit status definitions that, when returned by the main service + process, will be considered successful termination, in addition to the normal successful exit status + 0 and, except for Type=oneshot, the signals SIGHUP, SIGINT, + SIGTERM, and SIGPIPE. Exit status definitions can be + numeric termination statuses, termination status names, or termination signal names, separated by + spaces. See the Process Exit Codes section in + systemd.exec5 for + a list of termination status names (for this setting only the part without the + EXIT_ or EX_ prefix should be used). See signal7 for + a list of signal names. + + Note that this setting does not change the mapping between numeric exit statuses and their + names, i.e. regardless how this setting is used 0 will still be mapped to SUCCESS + (and thus typically shown as 0/SUCCESS in tool outputs) and 1 to + FAILURE (and thus typically shown as 1/FAILURE), and so on. It + only controls what happens as effect of these exit statuses, and how it propagates to the state of + the service as a whole. + + This option may appear more than once, in which case the list of successful exit statuses is + merged. If the empty string is assigned to this option, the list is reset, all prior assignments of + this option will have no effect. + + + A service with the <varname>SuccessExitStatus=</varname> setting + + SuccessExitStatus=TEMPFAIL 250 SIGKILL + + Exit status 75 (TEMPFAIL), 250, and the termination signal + SIGKILL are considered clean service terminations. + + + Note: systemd-analyze exit-status may be used to list exit statuses and + translate between numerical status values and names. + + + + RestartPreventExitStatus= + + Takes a list of exit status definitions that, when returned by the main service + process, will prevent automatic service restarts, regardless of the restart setting configured with + Restart=. Exit status definitions can either be numeric exit codes or termination + signal names, and are separated by spaces. Defaults to the empty list, so that, by default, no exit + status is excluded from the configured restart logic. For example: + + RestartPreventExitStatus=1 6 SIGABRT + + ensures that exit codes 1 and 6 and the termination signal SIGABRT will not + result in automatic service restarting. This option may appear more than once, in which case the list + of restart-preventing statuses is merged. If the empty string is assigned to this option, the list is + reset and all prior assignments of this option will have no effect. + + Note that this setting has no effect on processes configured via + ExecStartPre=, ExecStartPost=, ExecStop=, + ExecStopPost= or ExecReload=, but only on the main service + process, i.e. either the one invoked by ExecStart= or (depending on + Type=, PIDFile=, …) the otherwise configured main + process. + + + + RestartForceExitStatus= + Takes a list of exit status definitions that, + when returned by the main service process, will force automatic + service restarts, regardless of the restart setting configured + with Restart=. The argument format is + similar to + RestartPreventExitStatus=. + + + + RootDirectoryStartOnly= + Takes a boolean argument. If true, the root + directory, as configured with the + RootDirectory= option (see + systemd.exec5 + for more information), is only applied to the process started + with ExecStart=, and not to the various + other ExecStartPre=, + ExecStartPost=, + ExecReload=, ExecStop=, + and ExecStopPost= commands. If false, the + setting is applied to all configured commands the same way. + Defaults to false. + + + + NonBlocking= + Set the O_NONBLOCK flag for all file descriptors passed via + socket-based activation. If true, all file descriptors >= 3 (i.e. all except stdin, stdout, stderr), + excluding those passed in via the file descriptor storage logic (see + FileDescriptorStoreMax= for details), will have the + O_NONBLOCK flag set and hence are in non-blocking mode. This option is only + useful in conjunction with a socket unit, as described in + systemd.socket5 + and has no effect on file descriptors which were previously saved in the file-descriptor store for + example. Defaults to false. + + Note that if the same socket unit is configured to be passed to multiple service units (via the + Sockets= setting, see below), and these services have different + NonBlocking= configurations, the precise state of O_NONBLOCK + depends on the order in which these services are invoked, and will possibly change after service code + already took possession of the socket file descriptor, simply because the + O_NONBLOCK state of a socket is shared by all file descriptors referencing + it. Hence it is essential that all services sharing the same socket use the same + NonBlocking= configuration, and do not change the flag in service code + either. + + + + NotifyAccess= + Controls access to the service status notification socket, as accessible via the + sd_notify3 call. Takes one + of (the default), , or + . If , no daemon status updates are accepted from the service + processes, all status update messages are ignored. If , only service updates sent from the + main process of the service are accepted. If , only service updates sent from any of the + main or control processes originating from one of the Exec*= commands are accepted. If + , all services updates from all members of the service's control group are accepted. This + option should be set to open access to the notification socket when using Type=notify or + WatchdogSec= (see above). If those options are used but NotifyAccess= is + not configured, it will be implicitly set to . + + Note that sd_notify() notifications may be attributed to units correctly only if + either the sending process is still around at the time PID 1 processes the message, or if the sending process + is explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally + forked off the process, i.e. on all processes that match or + . Conversely, if an auxiliary process of the unit sends an + sd_notify() message and immediately exits, the service manager might not be able to + properly attribute the message to the unit, and thus will ignore it, even if + NotifyAccess= is set for it. + + Hence, to eliminate all race conditions involving lookup of the client's unit and attribution of notifications + to units correctly, sd_notify_barrier() may be used. This call acts as a synchronization point + and ensures all notifications sent before this call have been picked up by the service manager when it returns + successfully. Use of sd_notify_barrier() is needed for clients which are not invoked by the + service manager, otherwise this synchronization mechanism is unnecessary for attribution of notifications to the + unit. + + + + Sockets= + Specifies the name of the socket units this + service shall inherit socket file descriptors from when the + service is started. Normally, it should not be necessary to use + this setting, as all socket file descriptors whose unit shares + the same name as the service (subject to the different unit + name suffix of course) are passed to the spawned + process. + + Note that the same socket file descriptors may be passed + to multiple processes simultaneously. Also note that a + different service may be activated on incoming socket traffic + than the one which is ultimately configured to inherit the + socket file descriptors. Or, in other words: the + Service= setting of + .socket units does not have to match the + inverse of the Sockets= setting of the + .service it refers to. + + This option may appear more than once, in which case the list of socket units is merged. Note + that once set, clearing the list of sockets again (for example, by assigning the empty string to this + option) is not supported. + + + + FileDescriptorStoreMax= + Configure how many file descriptors may be stored in the service manager for the + service using + sd_pid_notify_with_fds3's + FDSTORE=1 messages. This is useful for implementing services that can restart + after an explicit request or a crash without losing state. Any open sockets and other file + descriptors which should not be closed during the restart may be stored this way. Application state + can either be serialized to a file in /run/, or better, stored in a + memfd_create2 + memory file descriptor. Defaults to 0, i.e. no file descriptors may be stored in the service + manager. All file descriptors passed to the service manager from a specific service are passed back + to the service's main process on the next service restart (see + sd_listen_fds3 for + details about the precise protocol used and the order in which the file descriptors are passed). Any + file descriptors passed to the service manager are automatically closed when + POLLHUP or POLLERR is seen on them, or when the service is + fully stopped and no job is queued or being executed for it. If this option is used, + NotifyAccess= (see above) should be set to open access to the notification socket + provided by systemd. If NotifyAccess= is not set, it will be implicitly set to + . + + + + USBFunctionDescriptors= + Configure the location of a file containing + USB + FunctionFS descriptors, for implementation of USB + gadget functions. This is used only in conjunction with a + socket unit with ListenUSBFunction= + configured. The contents of this file are written to the + ep0 file after it is + opened. + + + + USBFunctionStrings= + Configure the location of a file containing + USB FunctionFS strings. Behavior is similar to + USBFunctionDescriptors= + above. + + + + OOMPolicy= + + Configure the out-of-memory (OOM) kernel killer policy. Note that the userspace OOM + killer + systemd-oomd.service8 + is a more flexible solution that aims to prevent out-of-memory situations for the userspace, not just + the kernel. + + On Linux, when memory becomes scarce to the point that the kernel has trouble allocating memory + for itself, it might decide to kill a running process in order to free up memory and reduce memory + pressure. This setting takes one of continue, stop or + kill. If set to continue and a process of the service is + killed by the OOM killer, this is logged but the unit continues running. If set to + stop the event is logged but the unit is terminated cleanly by the service + manager. If set to kill and one of the unit's processes is killed by the OOM + killer the kernel is instructed to kill all remaining processes of the unit too, by setting the + memory.oom.group attribute to 1; also see kernel documentation. + + Defaults to the setting DefaultOOMPolicy= in + systemd-system.conf5 + is set to, except for units where Delegate= is turned on, where it defaults to + continue. + + Use the OOMScoreAdjust= setting to configure whether processes of the unit + shall be considered preferred or less preferred candidates for process termination by the Linux OOM + killer logic. See + systemd.exec5 for + details. + + This setting also applies to systemd-oomd. Similarly to the kernel OOM + kills, this setting determines the state of the unit after systemd-oomd kills a + cgroup associated with it. + + + + Check + systemd.unit5, + systemd.exec5, and + systemd.kill5 for more + settings. + + + + Command lines + + This section describes command line parsing and + variable and specifier substitutions for + ExecStart=, + ExecStartPre=, + ExecStartPost=, + ExecReload=, + ExecStop=, and + ExecStopPost= options. + + Multiple command lines may be concatenated in a single directive by separating them with semicolons + (these semicolons must be passed as separate words). Lone semicolons may be escaped as + \;. + + Each command line is unquoted using the rules described in "Quoting" section in + systemd.syntax7. The + first item becomes the command to execute, and the subsequent items the arguments. + + This syntax is inspired by shell syntax, but only the meta-characters and expansions + described in the following paragraphs are understood, and the expansion of variables is + different. Specifically, redirection using + <, + <<, + >, and + >>, pipes using + |, running programs in the background using + &, and other elements of shell + syntax are not supported. + + The command to execute may contain spaces, but control characters are not allowed. + + The command line accepts % specifiers as described in + systemd.unit5. + + Basic environment variable substitution is supported. Use + ${FOO} as part of a word, or as a word of its + own, on the command line, in which case it will be erased and replaced + by the exact value of the environment variable (if any) including all + whitespace it contains, always resulting in exactly a single argument. + Use $FOO as a separate word on the command line, in + which case it will be replaced by the value of the environment + variable split at whitespace, resulting in zero or more arguments. + For this type of expansion, quotes are respected when splitting + into words, and afterwards removed. + + If the command is not a full (absolute) path, it will be resolved to a full path using a + fixed search path determined at compilation time. Searched directories include + /usr/local/bin/, /usr/bin/, /bin/ + on systems using split /usr/bin/ and /bin/ + directories, and their sbin/ counterparts on systems using split + bin/ and sbin/. It is thus safe to use just the + executable name in case of executables located in any of the "standard" directories, and an + absolute path must be used in other cases. Using an absolute path is recommended to avoid + ambiguity. Hint: this search path may be queried using + systemd-path search-binaries-default. + + Example: + + Environment="ONE=one" 'TWO=two two' +ExecStart=echo $ONE $TWO ${TWO} + + This will execute /bin/echo with four + arguments: one, two, + two, and two two. + + Example: + Environment=ONE='one' "TWO='two two' too" THREE= +ExecStart=/bin/echo ${ONE} ${TWO} ${THREE} +ExecStart=/bin/echo $ONE $TWO $THREE + This results in /bin/echo being + called twice, the first time with arguments + 'one', + 'two two' too, , + and the second time with arguments + one, two two, + too. + + + To pass a literal dollar sign, use $$. + Variables whose value is not known at expansion time are treated + as empty strings. Note that the first argument (i.e. the program + to execute) may not be a variable. + + Variables to be used in this fashion may be defined through + Environment= and + EnvironmentFile=. In addition, variables listed + in the section "Environment variables in spawned processes" in + systemd.exec5, + which are considered "static configuration", may be used (this + includes e.g. $USER, but not + $TERM). + + Note that shell command lines are not directly supported. If + shell command lines are to be used, they need to be passed + explicitly to a shell implementation of some kind. Example: + ExecStart=sh -c 'dmesg | tac' + + Example: + + ExecStart=echo one ; echo "two two" + + This will execute echo two times, + each time with one argument: one and + two two, respectively. Because two commands are + specified, Type=oneshot must be used. + + Example: + + ExecStart=echo / >/dev/null & \; \ +ls + + This will execute echo + with five arguments: /, + >/dev/null, + &, ;, and + ls. + + + + Examples + + + Simple service + + The following unit file creates a service that will + execute /usr/sbin/foo-daemon. Since no + Type= is specified, the default + Type= will be assumed. + systemd will assume the unit to be started immediately after the + program has begun executing. + + [Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +[Install] +WantedBy=multi-user.target + + Note that systemd assumes here that the process started by + systemd will continue running until the service terminates. If + the program daemonizes itself (i.e. forks), please use + Type= instead. + + Since no ExecStop= was specified, + systemd will send SIGTERM to all processes started from this + service, and after a timeout also SIGKILL. This behavior can be + modified, see + systemd.kill5 + for details. + + Note that this unit type does not include any type of + notification when a service has completed initialization. For + this, you should use other unit types, such as + Type= if the service + understands systemd's notification protocol, + Type= if the service + can background itself or + Type= if the unit + acquires a DBus name once initialization is complete. See + below. + + + + Oneshot service + + Sometimes, units should just execute an action without + keeping active processes, such as a filesystem check or a + cleanup action on boot. For this, + Type= exists. Units + of this type will wait until the process specified terminates + and then fall back to being inactive. The following unit will + perform a cleanup action: + + [Unit] +Description=Cleanup old Foo data + +[Service] +Type=oneshot +ExecStart=/usr/sbin/foo-cleanup + +[Install] +WantedBy=multi-user.target + + Note that systemd will consider the unit to be in the + state "starting" until the program has terminated, so ordered + dependencies will wait for the program to finish before starting + themselves. The unit will revert to the "inactive" state after + the execution is done, never reaching the "active" state. That + means another request to start the unit will perform the action + again. + + Type= are the + only service units that may have more than one + ExecStart= specified. For units with multiple + commands (Type=oneshot), all commands will be run again. + For Type=oneshot, Restart= + and Restart= are not allowed. + + + + Stoppable oneshot service + + Similarly to the oneshot services, there are sometimes + units that need to execute a program to set up something and + then execute another to shut it down, but no process remains + active while they are considered "started". Network + configuration can sometimes fall into this category. Another use + case is if a oneshot service shall not be executed each time + when they are pulled in as a dependency, but only the first + time. + + For this, systemd knows the setting + RemainAfterExit=, which + causes systemd to consider the unit to be active if the start + action exited successfully. This directive can be used with all + types, but is most useful with + Type= and + Type=. With + Type=, systemd waits + until the start action has completed before it considers the + unit to be active, so dependencies start only after the start + action has succeeded. With + Type=, dependencies + will start immediately after the start action has been + dispatched. The following unit provides an example for a simple + static firewall. + + [Unit] +Description=Simple firewall + +[Service] +Type=oneshot +RemainAfterExit=yes +ExecStart=/usr/local/sbin/simple-firewall-start +ExecStop=/usr/local/sbin/simple-firewall-stop + +[Install] +WantedBy=multi-user.target + + Since the unit is considered to be running after the start + action has exited, invoking systemctl start + on that unit again will cause no action to be taken. + + + + Traditional forking services + + Many traditional daemons/services background (i.e. fork, + daemonize) themselves when starting. Set + Type= in the + service's unit file to support this mode of operation. systemd + will consider the service to be in the process of initialization + while the original program is still running. Once it exits + successfully and at least a process remains (and + RemainAfterExit=), the + service is considered started. + + Often, a traditional daemon only consists of one process. + Therefore, if only one process is left after the original + process terminates, systemd will consider that process the main + process of the service. In that case, the + $MAINPID variable will be available in + ExecReload=, ExecStop=, + etc. + + In case more than one process remains, systemd will be + unable to determine the main process, so it will not assume + there is one. In that case, $MAINPID will not + expand to anything. However, if the process decides to write a + traditional PID file, systemd will be able to read the main PID + from there. Please set PIDFile= accordingly. + Note that the daemon should write that file before finishing + with its initialization. Otherwise, systemd might try to read the + file before it exists. + + The following example shows a simple daemon that forks and + just starts one process in the background: + + [Unit] +Description=Some simple daemon + +[Service] +Type=forking +ExecStart=/usr/sbin/my-simple-daemon -d + +[Install] +WantedBy=multi-user.target + + Please see + systemd.kill5 + for details on how you can influence the way systemd terminates + the service. + + + + DBus services + + For services that acquire a name on the DBus system bus, + use Type= and set + BusName= accordingly. The service should not + fork (daemonize). systemd will consider the service to be + initialized once the name has been acquired on the system bus. + The following example shows a typical DBus service: + + [Unit] +Description=Simple DBus service + +[Service] +Type=dbus +BusName=org.example.simple-dbus-service +ExecStart=/usr/sbin/simple-dbus-service + +[Install] +WantedBy=multi-user.target + + For bus-activatable services, do not + include a [Install] section in the systemd + service file, but use the SystemdService= + option in the corresponding DBus service file, for example + (/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service): + + [D-BUS Service] +Name=org.example.simple-dbus-service +Exec=/usr/sbin/simple-dbus-service +User=root +SystemdService=simple-dbus-service.service + + Please see + systemd.kill5 + for details on how you can influence the way systemd terminates + the service. + + + + Services that notify systemd about their initialization + + Type= services + are really easy to write, but have the major disadvantage of + systemd not being able to tell when initialization of the given + service is complete. For this reason, systemd supports a simple + notification protocol that allows daemons to make systemd aware + that they are done initializing. Use + Type= for this. A + typical service file for such a daemon would look like + this: + + [Unit] +Description=Simple notifying service + +[Service] +Type=notify +ExecStart=/usr/sbin/simple-notifying-service + +[Install] +WantedBy=multi-user.target + + Note that the daemon has to support systemd's notification + protocol, else systemd will think the service has not started yet + and kill it after a timeout. For an example of how to update + daemons to support this protocol transparently, take a look at + sd_notify3. + systemd will consider the unit to be in the 'starting' state + until a readiness notification has arrived. + + Please see + systemd.kill5 + for details on how you can influence the way systemd terminates + the service. + + + + + See Also + + systemd1, + systemctl1, + systemd-system.conf5, + systemd.unit5, + systemd.exec5, + systemd.resource-control5, + systemd.kill5, + systemd.directives7, + systemd-run1 + + + + diff --git a/man/systemd.slice.xml b/man/systemd.slice.xml new file mode 100644 index 0000000..5e61199 --- /dev/null +++ b/man/systemd.slice.xml @@ -0,0 +1,122 @@ + + + + + + + systemd.slice + systemd + + + + systemd.slice + 5 + + + + systemd.slice + Slice unit configuration + + + + slice.slice + + + + Description + + A unit configuration file whose name ends in .slice encodes information about a slice + unit. A slice unit is a concept for hierarchically managing resources of a group of processes. This management is + performed by creating a node in the Linux Control Group (cgroup) tree. Units that manage processes (primarily scope + and service units) may be assigned to a specific slice. For each slice, certain resource limits may be set that + apply to all processes of all units contained in that slice. Slices are organized hierarchically in a tree. The + name of the slice encodes the location in the tree. The name consists of a dash-separated series of names, which + describes the path to the slice from the root slice. The root slice is named -.slice. Example: + foo-bar.slice is a slice that is located within foo.slice, which in turn + is located in the root slice -.slice. + + + Note that slice units cannot be templated, nor is possible to add multiple names to a slice unit by creating + additional symlinks to its unit file. + + By default, service and scope units are placed in + system.slice, virtual machines and containers + registered with + systemd-machined8 + are found in machine.slice, and user sessions + handled by + systemd-logind8 + in user.slice. See + systemd.special7 + for more information. + + See + systemd.unit5 + for the common options of all unit configuration + files. The common configuration items are configured + in the generic [Unit] and [Install] sections. The + slice specific configuration options are configured in + the [Slice] section. Currently, only generic resource control settings + as described in + systemd.resource-control5 are allowed. + + + See the New + Control Group Interfaces for an introduction on how to make + use of slice units from programs. + + + + Automatic Dependencies + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + Slice units automatically gain dependencies of type + After= and Requires= on + their immediate parent slice unit. + + + + + Default Dependencies + + The following dependencies are added unless DefaultDependencies=no is set: + + + Slice units will automatically have dependencies of type Conflicts= and + Before= on + shutdown.target. These ensure that slice units are removed prior to system shutdown. + Only slice units involved with late system shutdown should disable + DefaultDependencies= option. + + + + + + Options + + Slice unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + No options specific to this file type are supported. + + + + See Also + + systemd1, + systemd.unit5, + systemd.resource-control5, + systemd.service5, + systemd.scope5, + systemd.special7, + systemd.directives7 + + + + diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml new file mode 100644 index 0000000..69aa9f3 --- /dev/null +++ b/man/systemd.socket.xml @@ -0,0 +1,875 @@ + + + + + + + systemd.socket + systemd + + + + systemd.socket + 5 + + + + systemd.socket + Socket unit configuration + + + + socket.socket + + + + Description + + A unit configuration file whose name ends in + .socket encodes information about an IPC or + network socket or a file system FIFO controlled and supervised by + systemd, for socket-based activation. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The socket specific configuration options are + configured in the [Socket] section. + + Additional options are listed in + systemd.exec5, + which define the execution environment the + , , + and + commands are executed in, and in + systemd.kill5, + which define the way the processes are terminated, and in + systemd.resource-control5, + which configure resource control settings for the processes of the + socket. + + For each socket unit, a matching service unit must exist, + describing the service to start on incoming traffic on the socket + (see + systemd.service5 + for more information about .service units). The name of the + .service unit is by default the same as the name of the .socket + unit, but can be altered with the option + described below. Depending on the setting of the + option described below, this .service + unit must either be named like the .socket unit, but with the + suffix replaced, unless overridden with ; + or it must be a template unit named the same way. Example: a + socket file foo.socket needs a matching + service foo.service if + is set. If + is set, a service template + foo@.service must exist from which services + are instantiated for each incoming connection. + + No implicit WantedBy= or + RequiredBy= dependency from the socket to the + service is added. This means that the service may be started + without the socket, in which case it must be able to open sockets + by itself. To prevent this, an explicit + Requires= dependency may be added. + + Socket units may be used to implement on-demand starting of + services, as well as parallelized starting of services. See the + blog stories linked at the end for an introduction. + + Note that the daemon software configured for socket activation with socket units needs to be able + to accept sockets from systemd, either via systemd's native socket passing interface (see + sd_listen_fds3 for + details about the precise protocol used and the order in which the file descriptors are passed) or via + traditional inetd8-style + socket passing (i.e. sockets passed in via standard input and output, using + StandardInput=socket in the service file). + + All network sockets allocated through .socket units are allocated in the host's network + namespace (see network_namespaces7). This + does not mean however that the service activated by a configured socket unit has to be part of the host's network + namespace as well. It is supported and even good practice to run services in their own network namespace (for + example through PrivateNetwork=, see + systemd.exec5), receiving only + the sockets configured through socket-activation from the host's namespace. In such a set-up communication within + the host's network namespace is only permitted through the activation sockets passed in while all sockets allocated + from the service code itself will be associated with the service's own namespace, and thus possibly subject to a + restrictive configuration. + + + + Automatic Dependencies + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + Socket units automatically gain a Before= + dependency on the service units they activate. + + Socket units referring to file system paths (such as AF_UNIX + sockets or FIFOs) implicitly gain Requires= and After= + dependencies on all mount units necessary to access those paths. + + Socket units using the BindToDevice= + setting automatically gain a BindsTo= and + After= dependency on the device unit + encapsulating the specified network interface. + + + Additional implicit dependencies may be added as result of + execution and resource control parameters as documented in + systemd.exec5 + and + systemd.resource-control5. + + + + Default Dependencies + + The following dependencies are added unless + DefaultDependencies=no is set: + + + Socket units automatically gain a + Before= dependency on + sockets.target. + + Socket units automatically gain a pair of + After= and Requires= + dependency on sysinit.target, and a pair of + Before= and Conflicts= + dependencies on shutdown.target. These + dependencies ensure that the socket unit is started before normal + services at boot, and is stopped on shutdown. Only sockets + involved with early boot or late system shutdown should disable + DefaultDependencies= option. + + + + + + Options + + Socket unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + + + Socket unit files must include a [Socket] section, which carries + information about the socket or FIFO it supervises. A number of + options that may be used in this section are shared with other + unit types. These options are documented in + systemd.exec5 + and + systemd.kill5. + The options specific to the [Socket] section of socket units are + the following: + + + + ListenStream= + ListenDatagram= + ListenSequentialPacket= + Specifies an address to listen on for a stream + (SOCK_STREAM), datagram + (SOCK_DGRAM), or sequential packet + (SOCK_SEQPACKET) socket, respectively. + The address can be written in various formats: + + If the address starts with a slash + (/), it is read as file system socket in + the AF_UNIX socket family. + + If the address starts with an at symbol + (@), it is read as abstract namespace + socket in the AF_UNIX family. The + @ is replaced with a + NUL character before binding. For + details, see + unix7. + + If the address string is a single number, it is read as + port number to listen on via IPv6. Depending on the value of + BindIPv6Only= (see below) this might result + in the service being available via both IPv6 and IPv4 + (default) or just via IPv6. + + + If the address string is a string in the format + v.w.x.y:z, it is interpreted + as IPv4 address v.w.x.y and port z. + + If the address string is a string in the format + [x]:y, it is interpreted as + IPv6 address x and port y. An optional + interface scope (interface name or number) may be specified after a % symbol: + [x]:y%dev. + Interface scopes are only useful with link-local addresses, because the kernel ignores them in other + cases. Note that if an address is specified as IPv6, it might still make the service available via + IPv4 too, depending on the BindIPv6Only= setting (see below). + + If the address string is a string in the format + vsock:x:y, it is read as CID + x on a port y address in the + AF_VSOCK family. The CID is a unique 32-bit integer identifier in + AF_VSOCK analogous to an IP address. Specifying the CID is optional, and may be + set to the empty string. + + Note that SOCK_SEQPACKET (i.e. + ListenSequentialPacket=) is only available + for AF_UNIX sockets. + SOCK_STREAM (i.e. + ListenStream=) when used for IP sockets + refers to TCP sockets, SOCK_DGRAM (i.e. + ListenDatagram=) to UDP. + + These options may be specified more than once, in which + case incoming traffic on any of the sockets will trigger + service activation, and all listed sockets will be passed to + the service, regardless of whether there is incoming traffic + on them or not. If the empty string is assigned to any of + these options, the list of addresses to listen on is reset, + all prior uses of any of these options will have no + effect. + + It is also possible to have more than one socket unit + for the same service when using Service=, + and the service will receive all the sockets configured in all + the socket units. Sockets configured in one unit are passed in + the order of configuration, but no ordering between socket + units is specified. + + If an IP address is used here, it is often desirable to + listen on it before the interface it is configured on is up + and running, and even regardless of whether it will be up and + running at any point. To deal with this, it is recommended to + set the FreeBind= option described + below. + + + + ListenFIFO= + Specifies a file system FIFO (see fifo7 for + details) to listen on. This expects an absolute file system path as argument. Behavior otherwise is + very similar to the ListenDatagram= directive above. + + + + ListenSpecial= + Specifies a special file in the file system to + listen on. This expects an absolute file system path as + argument. Behavior otherwise is very similar to the + ListenFIFO= directive above. Use this to + open character device nodes as well as special files in + /proc/ and + /sys/. + + + + ListenNetlink= + Specifies a Netlink family to create a socket + for to listen on. This expects a short string referring to the + AF_NETLINK family name (such as + audit or kobject-uevent) + as argument, optionally suffixed by a whitespace followed by a + multicast group integer. Behavior otherwise is very similar to + the ListenDatagram= directive + above. + + + + ListenMessageQueue= + Specifies a POSIX message queue name to listen on (see mq_overview7 + for details). This expects a valid message queue name (i.e. beginning with + /). Behavior otherwise is very similar to the ListenFIFO= + directive above. On Linux message queue descriptors are actually file descriptors and can be + inherited between processes. + + + + ListenUSBFunction= + Specifies a USB + FunctionFS endpoints location to listen on, for + implementation of USB gadget functions. This expects an + absolute file system path of a FunctionFS mount point as the argument. + Behavior otherwise is very similar to the ListenFIFO= + directive above. Use this to open the FunctionFS endpoint + ep0. When using this option, the + activated service has to have the + USBFunctionDescriptors= and + USBFunctionStrings= options set. + + + + + SocketProtocol= + Takes one of + or . The socket will use the UDP-Lite + (IPPROTO_UDPLITE) or SCTP + (IPPROTO_SCTP) protocol, respectively. + + + + + BindIPv6Only= + Takes one of , + or . Controls + the IPV6_V6ONLY socket option (see + ipv67 + for details). If , IPv6 sockets bound + will be accessible via both IPv4 and IPv6. If + , they will be accessible via IPv6 + only. If (which is the default, + surprise!), the system wide default setting is used, as + controlled by + /proc/sys/net/ipv6/bindv6only, which in + turn defaults to the equivalent of + . + + + + + Backlog= + Takes an unsigned 32bit integer argument. Specifies the number of connections to + queue that have not been accepted yet. This setting matters only for stream and sequential packet + sockets. See + listen2 for + details. Note that this value is silently capped by the net.core.somaxconn sysctl, + which typically defaults to 4096. By default this is set to 4294967295, so that the sysctl takes full + effect. + + + + BindToDevice= + Specifies a network interface name to bind this socket to. If set, traffic will only + be accepted from the specified network interfaces. This controls the + SO_BINDTODEVICE socket option (see socket7 for + details). If this option is used, an implicit dependency from this socket unit on the network + interface device unit is created + (see systemd.device5). + Note that setting this parameter might result in additional dependencies to be added to the unit (see + above). + + + + SocketUser= + SocketGroup= + + Takes a UNIX user/group name. When specified, all AF_UNIX + sockets and FIFO nodes in the file system are owned by the specified user and group. If unset (the + default), the nodes are owned by the root user/group (if run in system context) or the invoking + user/group (if run in user context). If only a user is specified but no group, then the group is + derived from the user's default group. + + + + SocketMode= + If listening on a file system socket or FIFO, + this option specifies the file system access mode used when + creating the file node. Takes an access mode in octal + notation. Defaults to 0666. + + + + DirectoryMode= + If listening on a file system socket or FIFO, + the parent directories are automatically created if needed. + This option specifies the file system access mode used when + creating these directories. Takes an access mode in octal + notation. Defaults to 0755. + + + + Accept= + Takes a boolean argument. If yes, a service instance is spawned for each incoming + connection and only the connection socket is passed to it. If no, all listening sockets themselves + are passed to the started service unit, and only one service unit is spawned for all connections + (also see above). This value is ignored for datagram sockets and FIFOs where a single service unit + unconditionally handles all incoming traffic. Defaults to . For performance + reasons, it is recommended to write new daemons only in a way that is suitable for + . A daemon listening on an AF_UNIX socket may, but + does not need to, call + close2 on the + received socket before exiting. However, it must not unlink the socket from a file system. It should + not invoke + shutdown2 on + sockets it got with Accept=no, but it may do so for sockets it got with + Accept=yes set. Setting Accept=yes is mostly useful to allow + daemons designed for usage with inetd8 to work + unmodified with systemd socket activation. + + Note that depending on this setting the services activated by units of this type are either + regular services (in case of Accept=) or instances of templated + services (in case of Accept=). See the Description section + above for a more detailed discussion of the naming rules of triggered services. + + For IPv4 and IPv6 connections, the REMOTE_ADDR environment variable will + contain the remote IP address, and REMOTE_PORT will contain the remote port. This + is the same as the format used by CGI. For SOCK_RAW, the port is the IP + protocol. + + It is recommended to set CollectMode=inactive-or-failed for service + instances activated via Accept=yes, to ensure that failed connection services are + cleaned up and released from memory, and do not accumulate. + + + + Writable= + Takes a boolean argument. May only be used in + conjunction with ListenSpecial=. If true, + the specified special file is opened in read-write mode, if + false, in read-only mode. Defaults to false. + + + + FlushPending= + Takes a boolean argument. May only be used when + . If yes, the socket's buffers are cleared after the + triggered service exited. This causes any pending data to be + flushed and any pending incoming connections to be rejected. If no, the + socket's buffers won't be cleared, permitting the service to handle any + pending connections after restart, which is the usually expected behaviour. + Defaults to . + + + + + MaxConnections= + The maximum number of connections to + simultaneously run services instances for, when + is set. If more concurrent + connections are coming in, they will be refused until at least + one existing connection is terminated. This setting has no + effect on sockets configured with + or datagram sockets. Defaults to + 64. + + + + MaxConnectionsPerSource= + The maximum number of connections for a service per source IP address. + This is very similar to the MaxConnections= directive + above. Disabled by default. + + + + + KeepAlive= + Takes a boolean argument. If true, the TCP/IP stack will send a keep alive message + after 2h (depending on the configuration of + /proc/sys/net/ipv4/tcp_keepalive_time) for all TCP streams accepted on this + socket. This controls the SO_KEEPALIVE socket option (see socket7 and + the TCP Keepalive + HOWTO for details.) Defaults to . + + + + KeepAliveTimeSec= + Takes time (in seconds) as argument. The connection needs to remain + idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE + socket option (see + socket7 + and the TCP + Keepalive HOWTO for details.) + Defaults value is 7200 seconds (2 hours). + + + + KeepAliveIntervalSec= + Takes time (in seconds) as argument between individual keepalive probes, if the + socket option SO_KEEPALIVE has been set on this socket. This controls the + TCP_KEEPINTVL socket option (see socket7 and + the TCP Keepalive + HOWTO for details.) Defaults value is 75 seconds. + + + + KeepAliveProbes= + Takes an integer as argument. It is the number of + unacknowledged probes to send before considering the + connection dead and notifying the application layer. This + controls the TCP_KEEPCNT socket option (see + socket7 + and the TCP + Keepalive HOWTO for details.) Defaults value is + 9. + + + + NoDelay= + Takes a boolean argument. TCP Nagle's + algorithm works by combining a number of small outgoing + messages, and sending them all at once. This controls the + TCP_NODELAY socket option (see + tcp7). + Defaults to . + + + + Priority= + Takes an integer argument controlling the priority for all traffic sent from this + socket. This controls the SO_PRIORITY socket option (see socket7 for + details.). + + + + DeferAcceptSec= + + Takes time (in seconds) as argument. If set, + the listening process will be awakened only when data arrives + on the socket, and not immediately when connection is + established. When this option is set, the + TCP_DEFER_ACCEPT socket option will be + used (see + tcp7), + and the kernel will ignore initial ACK packets without any + data. The argument specifies the approximate amount of time + the kernel should wait for incoming data before falling back + to the normal behavior of honoring empty ACK packets. This + option is beneficial for protocols where the client sends the + data first (e.g. HTTP, in contrast to SMTP), because the + server process will not be woken up unnecessarily before it + can take any action. + + + If the client also uses the + TCP_DEFER_ACCEPT option, the latency of + the initial connection may be reduced, because the kernel will + send data in the final packet establishing the connection (the + third packet in the "three-way handshake"). + + Disabled by default. + + + + + ReceiveBuffer= + SendBuffer= + Takes an integer argument controlling the receive or send buffer sizes of this + socket, respectively. This controls the SO_RCVBUF and + SO_SNDBUF socket options (see socket7 for + details.). The usual suffixes K, M, G are supported and are understood to the base of + 1024. + + + + IPTOS= + Takes an integer argument controlling the IP Type-Of-Service field for packets + generated from this socket. This controls the IP_TOS socket option (see + ip7 for + details.). Either a numeric string or one of , , + or may be specified. + + + + IPTTL= + Takes an integer argument controlling the IPv4 Time-To-Live/IPv6 Hop-Count field for + packets generated from this socket. This sets the + IP_TTL/IPV6_UNICAST_HOPS socket options (see ip7 and + ipv67 for + details.) + + + + Mark= + Takes an integer value. Controls the firewall mark of packets generated by this + socket. This can be used in the firewall logic to filter packets from this socket. This sets the + SO_MARK socket option. See iptables8 for + details. + + + + ReusePort= + Takes a boolean value. If true, allows multiple + bind2s to this TCP + or UDP port. This controls the SO_REUSEPORT socket option. See socket7 for + details. + + + + SmackLabel= + SmackLabelIPIn= + SmackLabelIPOut= + Takes a string value. Controls the extended + attributes security.SMACK64, + security.SMACK64IPIN and + security.SMACK64IPOUT, respectively, i.e. + the security label of the FIFO, or the security label for the + incoming or outgoing connections of the socket, respectively. + See Smack + for details. + + + + SELinuxContextFromNet= + Takes a boolean argument. When true, systemd + will attempt to figure out the SELinux label used for the + instantiated service from the information handed by the peer + over the network. Note that only the security level is used + from the information provided by the peer. Other parts of the + resulting SELinux context originate from either the target + binary that is effectively triggered by socket unit or from + the value of the SELinuxContext= option. + This configuration option applies only when activated service + is passed in single socket file descriptor, i.e. service + instances that have standard input connected to a socket or + services triggered by exactly one socket unit. Also note + that this option is useful only when MLS/MCS SELinux policy + is deployed. Defaults to + false. + + + + PipeSize= + Takes a size in bytes. Controls the pipe + buffer size of FIFOs configured in this socket unit. See + fcntl2 + for details. The usual suffixes K, M, G are supported and are + understood to the base of 1024. + + + + MessageQueueMaxMessages=, + MessageQueueMessageSize= + These two settings take integer values and + control the mq_maxmsg field or the mq_msgsize field, + respectively, when creating the message queue. Note that + either none or both of these variables need to be set. See + mq_setattr3 + for details. + + + + FreeBind= + Takes a boolean value. Controls whether the socket can be bound to non-local IP + addresses. This is useful to configure sockets listening on specific IP addresses before those IP + addresses are successfully configured on a network interface. This sets the + IP_FREEBIND/IPV6_FREEBIND socket option. For robustness + reasons it is recommended to use this option whenever you bind a socket to a specific IP + address. Defaults to . + + + + Transparent= + Takes a boolean value. Controls the + IP_TRANSPARENT/IPV6_TRANSPARENT socket option. Defaults to + . + + + + Broadcast= + Takes a boolean value. This controls the SO_BROADCAST socket + option, which allows broadcast datagrams to be sent from this socket. Defaults to + . + + + + PassCredentials= + Takes a boolean value. This controls the SO_PASSCRED socket + option, which allows AF_UNIX sockets to receive the credentials of the sending + process in an ancillary message. Defaults to . + + + + PassSecurity= + Takes a boolean value. This controls the SO_PASSSEC socket + option, which allows AF_UNIX sockets to receive the security context of the + sending process in an ancillary message. Defaults to . + + + + PassPacketInfo= + Takes a boolean value. This controls the IP_PKTINFO, + IPV6_RECVPKTINFO, NETLINK_PKTINFO or + PACKET_AUXDATA socket options, which enable reception of additional per-packet + metadata as ancillary message, on AF_INET, AF_INET6, + AF_UNIX and AF_PACKET sockets. Defaults to + . + + + + Timestamping= + Takes one of off, us (alias: + usec, µs) or ns (alias: + nsec). This controls the SO_TIMESTAMP or + SO_TIMESTAMPNS socket options, and enables whether ingress network traffic shall + carry timestamping metadata. Defaults to . + + + + TCPCongestion= + Takes a string value. Controls the TCP congestion algorithm used by this + socket. Should be one of westwood, veno, + cubic, lp or any other available algorithm supported by the IP + stack. This setting applies only to stream sockets. + + + + ExecStartPre= + ExecStartPost= + Takes one or more command lines, which are + executed before or after the listening sockets/FIFOs are + created and bound, respectively. The first token of the + command line must be an absolute filename, then followed by + arguments for the process. Multiple command lines may be + specified following the same scheme as used for + ExecStartPre= of service unit + files. + + + + ExecStopPre= + ExecStopPost= + Additional commands that are executed before + or after the listening sockets/FIFOs are closed and removed, + respectively. Multiple command lines may be specified + following the same scheme as used for + ExecStartPre= of service unit + files. + + + + TimeoutSec= + Configures the time to wait for the commands + specified in ExecStartPre=, + ExecStartPost=, + ExecStopPre= and + ExecStopPost= to finish. If a command does + not exit within the configured time, the socket will be + considered failed and be shut down again. All commands still + running will be terminated forcibly via + SIGTERM, and after another delay of this + time with SIGKILL. (See + in + systemd.kill5.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass 0 to disable the + timeout logic. Defaults to + DefaultTimeoutStartSec= from the manager + configuration file (see + systemd-system.conf5). + + + + + Service= + Specifies the service unit name to activate on + incoming traffic. This setting is only allowed for sockets + with Accept=no. It defaults to the service + that bears the same name as the socket (with the suffix + replaced). In most cases, it should not be necessary to use + this option. Note that setting this parameter might result in + additional dependencies to be added to the unit (see + above). + + + + RemoveOnStop= + Takes a boolean argument. If enabled, any file nodes created by this socket unit are + removed when it is stopped. This applies to AF_UNIX sockets in the file system, + POSIX message queues, FIFOs, as well as any symlinks to them configured with + Symlinks=. Normally, it should not be necessary to use this option, and is not + recommended as services might continue to run after the socket unit has been terminated and it should + still be possible to communicate with them via their file system node. Defaults to + off. + + + + Symlinks= + Takes a list of file system paths. The specified paths will be created as symlinks to the + AF_UNIX socket path or FIFO path of this socket unit. If this setting is used, only one + AF_UNIX socket in the file system or one FIFO may be configured for the socket unit. Use + this option to manage one or more symlinked alias names for a socket, binding their lifecycle together. Note + that if creation of a symlink fails this is not considered fatal for the socket unit, and the socket unit may + still start. If an empty string is assigned, the list of paths is reset. Defaults to an empty + list. + + + + FileDescriptorName= + Assigns a name to all file descriptors this + socket unit encapsulates. This is useful to help activated + services identify specific file descriptors, if multiple fds + are passed. Services may use the + sd_listen_fds_with_names3 + call to acquire the names configured for the received file + descriptors. Names may contain any ASCII character, but must + exclude control characters and :, and must + be at most 255 characters in length. If this setting is not + used, the file descriptor name defaults to the name of the + socket unit, including its .socket + suffix. + + + + TriggerLimitIntervalSec= + TriggerLimitBurst= + + Configures a limit on how often this socket unit may be activated within a specific time + interval. The TriggerLimitIntervalSec= may be used to configure the length of the time + interval in the usual time units us, ms, s, + min, h, … and defaults to 2s (See + systemd.time7 for details on + the various time units understood). The TriggerLimitBurst= setting takes a positive integer + value and specifies the number of permitted activations per time interval, and defaults to 200 for + Accept=yes sockets (thus by default permitting 200 activations per 2s), and 20 otherwise (20 + activations per 2s). Set either to 0 to disable any form of trigger rate limiting. If the limit is hit, the + socket unit is placed into a failure mode, and will not be connectible anymore until restarted. Note that this + limit is enforced before the service activation is enqueued. + + + + + + + + + See Also + + systemd1, + systemctl1, + systemd-system.conf5, + systemd.unit5, + systemd.exec5, + systemd.kill5, + systemd.resource-control5, + systemd.service5, + systemd.directives7, + sd_listen_fds3, + sd_listen_fds_with_names3 + + + For more extensive descriptions see the "systemd for Developers" series: + Socket Activation, + Socket Activation, part II, + Converting inetd Services, + Socket Activated Internet Services and OS Containers. + + + + diff --git a/man/systemd.special.xml b/man/systemd.special.xml new file mode 100644 index 0000000..85eb8ad --- /dev/null +++ b/man/systemd.special.xml @@ -0,0 +1,1391 @@ + + + + + + + + systemd.special + systemd + + + + systemd.special + 7 + + + + systemd.special + Special systemd units + + + + basic.target, + bluetooth.target, + cryptsetup-pre.target, + cryptsetup.target, + veritysetup-pre.target, + veritysetup.target, + ctrl-alt-del.target, + blockdev@.target, + boot-complete.target, + default.target, + emergency.target, + exit.target, + factory-reset.target, + final.target, + first-boot-complete.target, + getty.target, + getty-pre.target, + graphical.target, + halt.target, + hibernate.target, + hybrid-sleep.target, + suspend-then-hibernate.target, + initrd.target, + initrd-fs.target, + initrd-root-device.target, + initrd-root-fs.target, + initrd-usr-fs.target, + integritysetup-pre.target, + integritysetup.target, + kbrequest.target, + kexec.target, + local-fs-pre.target, + local-fs.target, + machines.target + multi-user.target, + network-online.target, + network-pre.target, + network.target, + nss-lookup.target, + nss-user-lookup.target, + paths.target, + poweroff.target, + printer.target, + reboot.target, + remote-cryptsetup.target, + remote-veritysetup.target, + remote-fs-pre.target, + remote-fs.target, + rescue.target, + rpcbind.target, + runlevel2.target, + runlevel3.target, + runlevel4.target, + runlevel5.target, + shutdown.target, + sigpwr.target, + sleep.target, + slices.target, + smartcard.target, + sockets.target, + sound.target, + suspend.target, + swap.target, + sysinit.target, + system-update.target, + system-update-pre.target, + time-set.target, + time-sync.target, + timers.target, + umount.target, + usb-gadget.target, + -.slice, + system.slice, + user.slice, + machine.slice, + -.mount, + dbus.service, + dbus.socket, + display-manager.service, + init.scope, + syslog.socket, + system-update-cleanup.service + + + + Description + + A few units are treated specially by systemd. Many of them have + special internal semantics and cannot be renamed, while others simply + have a standard meaning and should be present on all systems. + + + + Units managed by the system service manager + + + Special System Units + + + + -.mount + + The root mount point, i.e. the mount unit for the / + path. This unit is unconditionally active, during the entire time the system is up, as + this mount point is where the basic userspace is running from. + + + + + basic.target + + A special target unit covering basic boot-up. + + systemd automatically adds dependency of the type + After= for this target unit to all + services (except for those with + DefaultDependencies=no). + + Usually, this should pull-in all local mount points plus + /var/, /tmp/ and + /var/tmp/, swap devices, sockets, timers, + path units and other basic initialization necessary for general + purpose daemons. The mentioned mount points are special cased + to allow them to be remote. + + + This target usually does not pull in any non-target units + directly, but rather does so indirectly via other early boot targets. + It is instead meant as a synchronization point for late boot + services. Refer to + bootup7 + for details on the targets involved. + + + + + boot-complete.target + + This target is intended as generic synchronization point for services that shall determine or act on + whether the boot process completed successfully. Order units that are required to succeed for a boot process + to be considered successful before this unit, and add a Requires= dependency from the + target unit to them. Order units that shall only run when the boot process is considered successful after the + target unit and pull in the target from it, also with Requires=. Note that by default this + target unit is not part of the initial boot transaction, but is supposed to be pulled in only if required by + units that want to run only on successful boots. + + See + systemd-boot-check-no-failures.service8 + for a service that implements a generic system health check and orders itself before + boot-complete.target. + + See + systemd-bless-boot.service8 + for a service that propagates boot success information to the boot loader, and orders itself after + boot-complete.target. + + + + ctrl-alt-del.target + + systemd starts this target whenever Control+Alt+Del is + pressed on the console. Usually, this should be aliased + (symlinked) to reboot.target. + + + + cryptsetup.target + + A target that pulls in setup services for all + encrypted block devices. + + + + veritysetup.target + + A target that pulls in setup services for all + verity integrity protected block devices. + + + + dbus.service + + A special unit for the D-Bus bus daemon. As soon as + this service is fully started up systemd will connect to it + and register its service. + + + + dbus.socket + + A special unit for the D-Bus system bus socket. All + units with Type=dbus automatically gain a + dependency on this unit. + + + + default.target + + The default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to + multi-user.target or graphical.target. See + bootup7 for + more discussion. + + The default unit systemd starts at bootup can be overridden with the + systemd.unit= kernel command line option, or more conveniently, with the short + names like single, rescue, 1, + 3, 5, …; see + systemd1. + + + + display-manager.service + + The display manager service. Usually, this should be + aliased (symlinked) to gdm.service or a + similar display manager service. + + + + emergency.target + + A special target unit that starts an emergency shell on the main console. This + target does not pull in other services or mounts. It is the most minimal version of + starting the system in order to acquire an interactive shell; the only processes running + are usually just the system manager (PID 1) and the shell process. This unit may be used + by specifying emergency on the kernel command line; it is + also used when a file system check on a required file system fails and boot-up cannot + continue. Compare with rescue.target, which serves a similar + purpose, but also starts the most basic services and mounts all file systems. + + In many ways booting into emergency.target is similar to the + effect of booting with init=/bin/sh on the kernel command line, + except that emergency mode provides you with the full system and service manager, and + allows starting individual units in order to continue the boot process in steps. + + Note that depending on how emergency.target is reached, the root file + system might be mounted read-only or read-write (no remounting is done specially for this + target). For example, the system may boot with root mounted read-only when ro + is used on the kernel command line and remain this way for emergency.target, + or the system may transition to emergency.target after the system has been + partially booted and disks have already been remounted read-write. + + + + exit.target + + A special service unit for shutting down the system or + user service manager. It is equivalent to + poweroff.target on non-container + systems, and also works in containers. + + systemd will start this unit when it receives the + SIGTERM or SIGINT + signal when running as user service daemon. + + Normally, this (indirectly) pulls in + shutdown.target, which in turn should be + conflicted by all units that want to be scheduled for + shutdown when the service manager starts to exit. + + + + factory-reset.target + + A special target to trigger a factory reset. + + + + final.target + + A special target unit that is used during the shutdown + logic and may be used to pull in late services after all + normal services are already terminated and all mounts + unmounted. + + + + + getty.target + + A special target unit that pulls in statically + configured local TTY getty instances. + + + + + graphical.target + + A special target unit for setting up a graphical login + screen. This pulls in + multi-user.target. + + Units that are needed for graphical logins shall add + Wants= dependencies for their unit to + this unit (or multi-user.target) during + installation. This is best configured via + WantedBy=graphical.target in the unit's + [Install] section. + + + + hibernate.target + + A special target unit for hibernating the system. This + pulls in sleep.target. + + + + hybrid-sleep.target + + A special target unit for hibernating and suspending + the system at the same time. This pulls in + sleep.target. + + + + suspend-then-hibernate.target + + A special target unit for suspending the system for a period + of time, waking it and putting it into hibernate. This pulls in + sleep.target. + + + + + halt.target + + A special target unit for shutting down and halting + the system. Note that this target is distinct from + poweroff.target in that it generally + really just halts the system rather than powering it + down. + + Applications wanting to halt the system should not start this unit + directly, but should instead execute systemctl halt + (possibly with the option) or call + systemd1's + org.freedesktop.systemd1.Manager.Halt D-Bus method + directly. + + + + init.scope + + This scope unit is where the system and service manager (PID 1) itself resides. It + is active as long as the system is running. + + + + initrd.target + + This is the default target in the initrd, similar to default.target in + the main system. It is used to mount the real root and transition to it. See + bootup7 for + more discussion. + + + + initrd-fs.target + + systemd-fstab-generator3 + automatically adds dependencies of type Before= to + sysroot-usr.mount and all mount points found in + /etc/fstab that have the mount option set + and do not have the mount option set. It is also indirectly ordered after + sysroot.mount. Thus, once this target is reached the + /sysroot/ hierarchy is fully set up, in preparation for the transition to + the host OS. + + + + initrd-root-device.target + + A special initrd target unit that is reached when the root filesystem device is available, but before + it has been mounted. + systemd-fstab-generator3 + and + systemd-gpt-auto-generator3 + automatically setup the appropriate dependencies to make this happen. + + + + + initrd-root-fs.target + + systemd-fstab-generator3 + automatically adds dependencies of type Before= to the + sysroot.mount unit, which is generated from the kernel command line's + root= setting (or equivalent). + + + + initrd-usr-fs.target + + systemd-fstab-generator3 + automatically adds dependencies of type Before= to the + sysusr-usr.mount unit, which is generated from the kernel command line's + usr= switch. Services may order themselves after this target unit in order to + run once the /sysusr/ hierarchy becomes available, on systems that come up + initially without a root file system, but with an initialized /usr/ and need + to access that before setting up the root file system to ultimately switch to. On systems where + usr= is not used this target is ordered after + sysroot.mount and thus mostly equivalent to + initrd-root-fs.target. In effect on any system once this target is reached + the file system backing /usr/ is mounted, though possibly at two different + locations, either below the /sysusr/ or the /sysroot/ + hierarchies. + + + + kbrequest.target + + systemd starts this target whenever Alt+ArrowUp is + pressed on the console. Note that any user with physical access + to the machine will be able to do this, without authentication, + so this should be used carefully. + + + + kexec.target + + A special target unit for shutting down and rebooting + the system via kexec. + + Applications wanting to reboot the system should not start this unit + directly, but should instead execute systemctl kexec + (possibly with the option) or call + systemd1's + org.freedesktop.systemd1.Manager.KExec D-Bus method + directly. + + + + local-fs.target + + systemd-fstab-generator3 + automatically adds dependencies of type + Before= to all mount units that refer to + local mount points for this target unit. In addition, it + adds dependencies of type Wants= to this + target unit for those mounts listed in + /etc/fstab that have the + mount option set. + + + + machines.target + + A standard target unit for starting all the containers + and other virtual machines. See systemd-nspawn@.service + for an example. + + + + multi-user.target + + A special target unit for setting up a multi-user + system (non-graphical). This is pulled in by + graphical.target. + + Units that are needed for a multi-user system shall + add Wants= dependencies for their unit to + this unit during installation. This is best configured via + WantedBy=multi-user.target in the unit's + [Install] section. + + + + network-online.target + + Units that strictly require a configured network + connection should pull in + network-online.target (via a + Wants= type dependency) and order + themselves after it. This target unit is intended to pull in + a service that delays further execution until the network is + sufficiently set up. What precisely this requires is left to + the implementation of the network managing service. + + Note the distinction between this unit and network.target. This unit + is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) + and pulls in a service which possibly adds substantial delays to further execution. In contrast, + network.target is a passive unit (i.e. pulled in by the provider of the + functionality, rather than the consumer) that usually does not delay execution much. Usually, + network.target is part of the boot of most systems, while + network-online.target is not, except when at least one unit requires + it. Also see Running Services After the Network Is + Up for more information. + + All mount units for remote network file systems automatically pull in this unit, and order + themselves after it. Note that networking daemons that simply provide + functionality to other hosts (as opposed to consume functionality of other + hosts) generally do not need to pull this in. + + systemd automatically adds dependencies of type Wants= and + After= for this target unit to all SysV init script service units + with an LSB header referring to the $network facility. + + Note that this unit is only useful during the original system start-up + logic. After the system has completed booting up, it will not track the online state of + the system anymore. Due to this it cannot be used as a network connection monitor + concept, it is purely a one-time system start-up concept. + + + + paths.target + + A special target unit that sets up all path units (see + systemd.path5 + for details) that shall be active after boot. + + It is recommended that path units installed by + applications get pulled in via Wants= + dependencies from this unit. This is best configured via a + WantedBy=paths.target in the path unit's + [Install] section. + + + + poweroff.target + + A special target unit for shutting down and powering + off the system. + + Applications wanting to power off the system should not start this unit + directly, but should instead execute systemctl poweroff + (possibly with the option) or call + systemd-logind8's + org.freedesktop.login1.Manager.PowerOff D-Bus method + directly. + + runlevel0.target is an alias for + this target unit, for compatibility with SysV. + + + + reboot.target + + A special target unit for shutting down and rebooting + the system. + + Applications wanting to reboot the system should not start this unit + directly, but should instead execute systemctl reboot + (possibly with the option) or call + systemd-logind8's + org.freedesktop.login1.Manager.Reboot D-Bus method + directly. + + runlevel6.target is an alias for + this target unit, for compatibility with SysV. + + + + remote-cryptsetup.target + + Similar to cryptsetup.target, but for encrypted + devices which are accessed over the network. It is used for + crypttab8 + entries marked with . + + + + remote-veritysetup.target + + Similar to veritysetup.target, but for verity + integrity protected devices which are accessed over the network. It is used for + veritytab8 + entries marked with . + + + + remote-fs.target + + Similar to local-fs.target, but + for remote mount points. + + systemd automatically adds dependencies of type + After= for this target unit to all SysV + init script service units with an LSB header referring to + the $remote_fs facility. + + + + rescue.target + + A special target unit that pulls in the base system (including system mounts) and + spawns a rescue shell. Isolate to this target in order to administer the system in + single-user mode with all file systems mounted but with no services running, except for + the most basic. Compare with emergency.target, which is much more + reduced and does not provide the file systems or most basic services. Compare with + multi-user.target, this target could be seen as + single-user.target. + + runlevel1.target is an alias for this target unit, for + compatibility with SysV. + + Use the systemd.unit=rescue.target kernel command line option + to boot into this mode. A short alias for this kernel command line option is + 1, for compatibility with SysV. + + + + runlevel2.target + runlevel3.target + runlevel4.target + runlevel5.target + + These are targets that are called whenever the SysV + compatibility code asks for runlevel 2, 3, 4, 5, + respectively. It is a good idea to make this an alias for + (i.e. symlink to) graphical.target + (for runlevel 5) or multi-user.target + (the others). + + + + shutdown.target + + A special target unit that terminates the services on + system shutdown. + + Services that shall be terminated on system shutdown + shall add Conflicts= and + Before= dependencies to this unit for + their service unit, which is implicitly done when + DefaultDependencies=yes is set (the + default). + + + + sigpwr.target + + A special target that is started when systemd receives + the SIGPWR process signal, which is normally sent by the + kernel or UPS daemons when power fails. + + + + sleep.target + + A special target unit that is pulled in by + suspend.target, + hibernate.target and + hybrid-sleep.target and may be used to + hook units into the sleep state logic. + + + + slices.target + + A special target unit that sets up all slice units (see + systemd.slice5 + for details) that shall always be active after boot. By default the generic + system.slice slice unit as well as the root slice unit + -.slice are pulled in and ordered before this unit (see + below). + + Adding slice units to slices.target is generally not + necessary. Instead, when some unit that uses Slice= is started, the + specified slice will be started automatically. Adding + WantedBy=slices.target lines to the [Install] + section should only be done for units that need to be always active. In that case care + needs to be taken to avoid creating a loop through the automatic dependencies on + "parent" slices. + + + + sockets.target + + A special target unit that sets up all socket + units (see + systemd.socket5 + for details) that shall be active after boot. + + Services that can be socket-activated shall add + Wants= dependencies to this unit for + their socket unit during installation. This is best + configured via a WantedBy=sockets.target + in the socket unit's [Install] + section. + + + + suspend.target + + A special target unit for suspending the system. This + pulls in sleep.target. + + + + swap.target + + Similar to local-fs.target, but + for swap partitions and swap files. + + + + sysinit.target + + systemd automatically adds dependencies of the types + Requires= and After= + for this target unit to all services (except for those with + DefaultDependencies=no). + + This target pulls in the services required for system + initialization. System services pulled in by this target should + declare DefaultDependencies=no and specify + all their dependencies manually, including access to anything + more than a read only root filesystem. For details on the + dependencies of this target, refer to + bootup7. + + + + + syslog.socket + + The socket unit syslog implementations should listen + on. All userspace log messages will be made available on + this socket. For more information about syslog integration, + please consult the Syslog + Interface document. + + + + system-update.target + system-update-pre.target + system-update-cleanup.service + + A special target unit that is used for offline system updates. + systemd-system-update-generator8 + will redirect the boot process to this target if /system-update + exists. For more information see + systemd.offline-updates7. + + + Updates should happen before the system-update.target is + reached, and the services which implement them should cause the machine to reboot. The + main units executing the update should order themselves after + system-update-pre.target but not pull it in. Services which want to + run during system updates only, but before the actual system update is executed should + order themselves before this unit and pull it in. As a safety measure, if this does not + happen, and /system-update still exists after + system-update.target is reached, + system-update-cleanup.service will remove this symlink and reboot + the machine. + + + + timers.target + + A special target unit that sets up all timer units + (see + systemd.timer5 + for details) that shall be active after boot. + + It is recommended that timer units installed by + applications get pulled in via Wants= + dependencies from this unit. This is best configured via + WantedBy=timers.target in the timer + unit's [Install] section. + + + + umount.target + + A special target unit that unmounts all mount and + automount points on system shutdown. + + Mounts that shall be unmounted on system shutdown + shall add Conflicts dependencies to this unit for their + mount unit, which is implicitly done when + DefaultDependencies=yes is set (the + default). + + + + + + + + Special System Units for Devices + + Some target units are automatically pulled in as devices of + certain kinds show up in the system. These may be used to + automatically activate various services based on the specific type + of the available hardware. + + + + bluetooth.target + + This target is started automatically as soon as a + Bluetooth controller is plugged in or becomes available at + boot. + + This may be used to pull in Bluetooth management + daemons dynamically when Bluetooth hardware is found. + + + + printer.target + + This target is started automatically as soon as a + printer is plugged in or becomes available at boot. + + This may be used to pull in printer management daemons + dynamically when printer hardware is found. + + + + smartcard.target + + This target is started automatically as soon as a + smartcard controller is plugged in or becomes available at + boot. + + This may be used to pull in smartcard management + daemons dynamically when smartcard hardware is found. + + + + sound.target + + This target is started automatically as soon as a + sound card is plugged in or becomes available at + boot. + + This may be used to pull in audio management daemons + dynamically when audio hardware is found. + + + + usb-gadget.target + + This target is started automatically as soon as a + USB Device Controller becomes available at boot. + + This may be used to pull in usb gadget + dynamically when UDC hardware is found. + + + + + + + Special Passive System Units + + A number of special system targets are defined that can be + used to properly order boot-up of optional services. These targets + are generally not part of the initial boot transaction, unless + they are explicitly pulled in by one of the implementing services. + Note specifically that these passive target + units are generally not pulled in by the consumer of a service, + but by the provider of the service. This means: a consuming + service should order itself after these targets (as appropriate), + but not pull it in. A providing service should order itself before + these targets (as appropriate) and pull it in (via a + Wants= type dependency). + + Note that these passive units cannot be started manually, + i.e. systemctl start time-sync.target will fail + with an error. They can only be pulled in by dependency. This is + enforced since they exist for ordering purposes only and thus are + not useful as only unit within a transaction. + + + + blockdev@.target + This template unit is used to order mount units and other consumers of block + devices after services that synthesize these block devices. In particular, this is intended to be + used with storage services (such as + systemd-cryptsetup@.service5/ + systemd-veritysetup@.service5) + that allocate and manage a virtual block device. Storage services are ordered before an instance of + blockdev@.target, and the consumer units after it. The ordering is + particularly relevant during shutdown, as it ensures that the mount is deactivated first and the + service backing the mount later. The blockdev@.target instance should be + pulled in via a dependency of the storage daemon and thus generally not be + part of any transaction unless a storage daemon is used. The instance name for instances of this + template unit must be a properly escaped block device node path, e.g. + blockdev@dev-mapper-foobar.target for the storage device + /dev/mapper/foobar. + + + cryptsetup-pre.target + + This passive target unit may be pulled in by services + that want to run before any encrypted block device is set + up. All encrypted block devices are set up after this target + has been reached. Since the shutdown order is implicitly the + reverse start-up order between units, this target is + particularly useful to ensure that a service is shut down + only after all encrypted block devices are fully + stopped. + + + + veritysetup-pre.target + + This passive target unit may be pulled in by services + that want to run before any verity integrity protected block + device is set up. All verity integrity protected block + devices are set up after this target has been reached. Since + the shutdown order is implicitly the reverse start-up order + between units, this target is particularly useful to ensure + that a service is shut down only after all verity integrity + protected block devices are fully stopped. + + + + first-boot-complete.target + + This passive target is intended as a synchronization point for units that need to run once + during the first boot. Only after all units ordered before this target have finished, will the + machine-id5 + be committed to disk, marking the first boot as completed. If the boot is aborted at any time + before that, the next boot will re-run any units with ConditionFirstBoot=yes. + + + + + getty-pre.target + + A special passive target unit. Users of this target + are expected to pull it in the boot transaction via + a dependency (e.g. Wants=). Order your + unit before this unit if you want to make use of the console + just before getty is started. + + + + + local-fs-pre.target + + This target unit is + automatically ordered before + all local mount points marked + with + (see above). It can be used to + execute certain units before + all local mounts. + + + + network.target + + This unit is supposed to indicate when network functionality is available, but it is only + very weakly defined what that is supposed to mean. However, the following should apply at + minimum: + + + At start-up, any configured synthetic network devices (i.e. not physical ones + that require hardware to show up and be probed, but virtual ones like bridge devices and + similar which are created programmatically) that do not depend on any underlying hardware + should be allocated by the time this target is reached. It is not necessary for these + interfaces to also have completed IP level configuration by the time + network.target is reached. + + At shutdown, a unit that is ordered after network.target + will be stopped before the network — to whatever level it might be set up by then — is shut + down. It is hence useful when writing service files that require network access on shutdown, + which should order themselves after this target, but not pull it in. Also see Running Services After the Network Is Up for + more information. + + + It must emphasized that at start-up there's no guarantee that hardware-based devices have + shown up by the time this target is reached, or even acquired complete IP configuration. For that + purpose use network-online.target as described above. + + + + network-pre.target + + This passive target unit may be pulled in by services that want to run before any network + is set up, for example for the purpose of setting up a firewall. All network management software + orders itself after this target, but does not pull it in. Also see Running Services After the Network Is Up for more + information. + + + + nss-lookup.target + + A target that should be used as synchronization point for all host/network name + service lookups. Note that this is independent of UNIX user/group name lookups for which + nss-user-lookup.target should be used. All services for which the + availability of full host/network name resolution is essential should be ordered after + this target, but not pull it in. systemd automatically adds dependencies of type + After= for this target unit to all SysV init script service units + with an LSB header referring to the $named facility. + + + + nss-user-lookup.target + + A target that should be used as synchronization point for all regular UNIX + user/group name service lookups. Note that this is independent of host/network name + lookups for which nss-lookup.target should be used. All services + for which the availability of the full user/group database is essential should be + ordered after this target, but not pull it in. All services which provide parts of the + user/group database should be ordered before this target, and pull it in. Note that this + unit is only relevant for regular users and groups — system users and groups are + required to be resolvable during earliest boot already, and hence do not need any + special ordering against this target. + + + + remote-fs-pre.target + + This target unit is automatically ordered before all + mount point units (see above) and cryptsetup/veritysetup devices + marked with the . It can be used to run + certain units before remote encrypted devices and mounts are established. + Note that this unit is generally not part of the initial + transaction, unless the unit that wants to be ordered before + all remote mounts pulls it in via a + Wants= type dependency. If the unit wants + to be pulled in by the first remote mount showing up, it + should use network-online.target (see + above). + + + + rpcbind.target + + The portmapper/rpcbind pulls in this target and orders + itself before it, to indicate its availability. systemd + automatically adds dependencies of type + After= for this target unit to all SysV + init script service units with an LSB header referring to + the $portmap facility. + + + + time-set.target + + Services responsible for setting the system clock (CLOCK_REALTIME) + from a local source (such as a maintained timestamp file or imprecise real-time clock) should + pull in this target and order themselves before it. Services where approximate, roughly monotonic + time is desired should be ordered after this unit, but not pull it in. + + This target does not provide the accuracy guarantees of + time-sync.target (see below), however does not depend on remote clock + sources to be reachable, i.e. the target is typically not delayed by network problems and + similar. Use of this target is recommended for services where approximate clock accuracy and + rough monotonicity is desired but activation shall not be delayed for possibly unreliable network + communication. + + The service manager automatically adds dependencies of type After= for + this target unit to all timer units with at least one OnCalendar= + directive. + + The + systemd-timesyncd.service8 + service is a simple daemon that pulls in this target and orders itself before it. Besides + implementing the SNTP network protocol it maintains a timestamp file on disk whose modification + time is regularlary updated. At service start-up the local system clock is set from that modification time, + ensuring it increases roughly monotonically. + + Note that ordering a unit after time-set.target only has effect if + there's actually a service ordered before it that delays it until the clock is adjusted for rough + monotonicity. Otherwise, this target might get reached before the clock is adjusted to be roughly + monotonic. Enable + systemd-timesyncd.service8, + or an alternative NTP implementation to delay the target. + + + + time-sync.target + + Services indicating completed synchronization of the system clock + (CLOCK_REALTIME) to a remote source should pull in this target and order + themselves before it. Services where accurate time is essential should be ordered after this + unit, but not pull it in. + + The service manager automatically adds dependencies of type After= for + this target unit to all SysV init script service units with an LSB header referring to the + $time facility, as well to all timer units with at least one + OnCalendar= directive. + + This target provides stricter clock accuracy guarantees than + time-set.target (see above), but likely requires + network communication and thus introduces unpredictable delays. + Services that require clock accuracy and where network + communication delays are acceptable should use this target. Services that require a less accurate + clock, and only approximate and roughly monotonic clock behaviour should use + time-set.target instead. + + Note that ordering a unit after time-sync.target only has effect if + there's actually a service ordered before it that delays it until clock synchronization is + reached. Otherwise, this target might get reached before the clock is synchronized to any remote + accurate reference clock. When using + systemd-timesyncd.service8, + enable + systemd-time-wait-sync.service8 + to delay the target; or use an equivalent service for other NTP implementations. + + + Comparison + + + + + + time-set.target + time-sync.target + + + + + "quick" to reach + "slow" to reach + + + typically uses local clock sources, boot process not affected by availability of external resources + typically uses remote clock sources, inserts dependencies on remote resources into boot process + + + reliable, because local + unreliable, because typically network involved + + + typically guarantees an approximate and roughly monotonic clock only + typically guarantees an accurate clock + + + implemented by systemd-timesyncd.service + implemented by systemd-time-wait-sync.service + + + +
+ + + + + + + + Special Slice Units + + There are four .slice units which form the basis of the hierarchy for + assignment of resources for services, users, and virtual machines or containers. See + systemd.slice7 + for details about slice units. + + + + -.slice + + The root slice is the root of the slice hierarchy. It usually does not contain + units directly, but may be used to set defaults for the whole tree. + + + + + system.slice + + By default, all system services started by + systemd are found in this slice. + + + + + user.slice + + By default, all user processes and services started on + behalf of the user, including the per-user systemd instance + are found in this slice. This is pulled in by + systemd-logind.service. + + + + + machine.slice + + By default, all virtual machines and containers + registered with systemd-machined are + found in this slice. This is pulled in by + systemd-machined.service. + + + + + + + + Units managed by the user service manager + + + Special User Units + + When systemd runs as a user instance, the following special + units are available: + + + + default.target + + This is the main target of the user session, started by default. Various services that + compose the normal user session should be pulled into this target. In this regard, + default.target is similar to multi-user.target in the + system instance, but it is a real unit, not an alias. + + + + + In addition, the following units are available which have definitions similar to their + system counterparts: + exit.target, + shutdown.target, + sockets.target, + timers.target, + paths.target, + bluetooth.target, + printer.target, + smartcard.target, + sound.target. + + + + Special Passive User Units + + + + graphical-session.target + + This target is active whenever any graphical session is running. It is used to + stop user services which only apply to a graphical (X, Wayland, etc.) session when the + session is terminated. Such services should have + PartOf=graphical-session.target in their [Unit] + section. A target for a particular session (e. g. + gnome-session.target) starts and stops + graphical-session.target with + BindsTo=graphical-session.target. + + Which services are started by a session target is determined by the + Wants= and Requires= dependencies. For services + that can be enabled independently, symlinks in .wants/ and + .requires/ should be used, see + systemd.unit5. + Those symlinks should either be shipped in packages, or should be added dynamically + after installation, for example using systemctl add-wants, see + systemctl1. + + + + Nautilus as part of a GNOME session + + gnome-session.target pulls in Nautilus as top-level service: + + [Unit] +Description=User systemd services for GNOME graphical session +Wants=nautilus.service +BindsTo=graphical-session.target + + nautilus.service gets stopped when the session stops: + + [Unit] +Description=Render the desktop icons with Nautilus +PartOf=graphical-session.target + +[Service] +… + + + + + + graphical-session-pre.target + + This target contains services which set up the environment or global configuration + of a graphical session, such as SSH/GPG agents (which need to export an environment + variable into all desktop processes) or migration of obsolete d-conf keys after an OS + upgrade (which needs to happen before starting any process that might use them). This + target must be started before starting a graphical session like + gnome-session.target. + + + + + xdg-desktop-autostart.target + + The XDG specification defines a way to autostart applications using XDG desktop files. + systemd ships + systemd-xdg-autostart-generator8 + for the XDG desktop files in autostart directories. Desktop Environments can opt-in to use this + service by adding a Wants= dependency on + xdg-desktop-autostart.target. + + + + + + + Special User Slice Units + + There are four .slice units which form the basis of the user hierarchy for + assignment of resources for user applications and services. See + systemd.slice7 + for details about slice units and the documentation about + Desktop Environments + for further information. + + + + -.slice + + The root slice is the root of the user's slice hierarchy. + It usually does not contain units directly, but may be used to set defaults for the whole tree. + + + + + app.slice + + By default, all user services and applications managed by + systemd are found in this slice. + All interactively launched applications like web browsers and text editors + as well as non-critical services should be placed into this slice. + + + + + session.slice + + All essential services and applications required for the + session should use this slice. + These are services that either cannot be restarted easily + or where latency issues may affect the interactivity of the system and applications. + This includes the display server, screen readers and other services such as DBus or XDG portals. + Such services should be configured to be part of this slice by + adding Slice=session.slice to their unit files. + + + + + background.slice + + All services running low-priority background tasks should use this slice. + This permits resources to be preferentially assigned to the other slices. + Examples include non-interactive tasks like file indexing or backup operations + where latency is not important. + + + + + + + + See Also + + systemd1, + systemd.unit5, + systemd.service5, + systemd.socket5, + systemd.target5, + systemd.slice5, + bootup7, + systemd-fstab-generator8, + user@.service5 + + + + diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml new file mode 100644 index 0000000..8287382 --- /dev/null +++ b/man/systemd.swap.xml @@ -0,0 +1,261 @@ + + + + + + + systemd.swap + systemd + + + + systemd.swap + 5 + + + + systemd.swap + Swap unit configuration + + + + swap.swap + + + + Description + + A unit configuration file whose name ends in + .swap encodes information about a swap device + or file for memory paging controlled and supervised by + systemd. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The swap specific configuration options are + configured in the [Swap] section. + + Additional options are listed in + systemd.exec5, + which define the execution environment the swapon8 + program is executed in, in + systemd.kill5, + which define the way these processes are + terminated, and in + systemd.resource-control5, + which configure resource control settings for these processes of the + unit. + + Swap units must be named after the devices or files they control. Example: the swap device /dev/sda5 must be configured in a unit file dev-sda5.swap. For + details about the escaping logic used to convert a file system path to a unit name, see + systemd.unit5. Note that swap + units cannot be templated, nor is possible to add multiple names to a swap unit by creating additional symlinks to + it. + + Note that swap support on Linux is privileged, swap units are hence only available in the system + service manager (and root's user service manager), but not in unprivileged user's service manager. + + + + Automatic Dependencies + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + All swap units automatically get the + BindsTo= and After= + dependencies on the device units or the mount units of the files + they are activated from. + + + Additional implicit dependencies may be added as result of + execution and resource control parameters as documented in + systemd.exec5 + and + systemd.resource-control5. + + + + Default Dependencies + + The following dependencies are added unless DefaultDependencies=no is set: + + + Swap units automatically acquire a Conflicts= and a + Before= dependency on umount.target so that they are deactivated at + shutdown as well as a Before=swap.target dependency. + + + + + + <filename>fstab</filename> + + Swap units may either be configured via unit files, or via + /etc/fstab (see + fstab5 + for details). Swaps listed in /etc/fstab will + be converted into native units dynamically at boot and when the + configuration of the system manager is reloaded. See + systemd-fstab-generator8 + for details about the conversion. + + If a swap device or file is configured in both + /etc/fstab and a unit file, the configuration + in the latter takes precedence. + + When reading /etc/fstab, a few special + options are understood by systemd which influence how dependencies + are created for swap units. + + + + + + + With , the swap unit + will not be added as a dependency for + swap.target. This means that it will not + be activated automatically during boot, unless it is pulled in + by some other unit. The option has the + opposite meaning and is the default. + + + + + + + With , the swap unit + will be only wanted, not required by + swap.target. This means that the boot + will continue even if this swap device is not activated + successfully. + + + + + + + + + The swap structure will be initialized on the device. If the device is not + "empty", i.e. it contains any signature, the operation will be skipped. It is hence expected + that this option remains set even after the device has been initialized. + + Note that this option can only be used in /etc/fstab, and will be + ignored when part of the Options= setting in a unit file. + + See + systemd-mkswap@.service8 + and the discussion of + wipefs8 + in systemd.mount5. + + + + + + + Options + + Swap unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + + + Swap unit files must include a [Swap] section, which carries + information about the swap device it supervises. A number of + options that may be used in this section are shared with other + unit types. These options are documented in + systemd.exec5 + and + systemd.kill5. + The options specific to the [Swap] section of swap units are the + following: + + + + + What= + Takes an absolute path of a device node or file to use for paging. See swapon8 for + details. If this refers to a device node, a dependency on the respective device unit is automatically + created. (See + systemd.device5 + for more information.) If this refers to a file, a dependency on the respective mount unit is + automatically created. (See + systemd.mount5 for + more information.) This option is mandatory. Note that the usual specifier expansion is applied to + this setting, literal percent characters should hence be written as + %%. + + + + Priority= + + Swap priority to use when activating the swap + device or file. This takes an integer. This setting is + optional and ignored when the priority is set by in the + Options= key. + + + + Options= + + May contain an option string for the swap device. This may be used for controlling discard + options among other functionality, if the swap backing device supports the discard or trim operation. (See + swapon8 + for more information.) Note that the usual specifier expansion is applied to this setting, literal percent + characters should hence be written as %%. + + + + TimeoutSec= + Configures the time to wait for the swapon + command to finish. If a command does not exit within the + configured time, the swap will be considered failed and be + shut down again. All commands still running will be terminated + forcibly via SIGTERM, and after another + delay of this time with SIGKILL. (See + in + systemd.kill5.) + Takes a unit-less value in seconds, or a time span value such + as "5min 20s". Pass 0 to disable the + timeout logic. Defaults to + DefaultTimeoutStartSec= from the manager + configuration file (see + systemd-system.conf5). + + + + + + + + + See Also + + systemd1, + systemctl1, + systemd-system.conf5, + systemd.unit5, + systemd.exec5, + systemd.kill5, + systemd.resource-control5, + systemd.device5, + systemd.mount5, + swapon8, + systemd-fstab-generator8, + systemd.directives7 + + + + diff --git a/man/systemd.syntax.xml b/man/systemd.syntax.xml new file mode 100644 index 0000000..1441b2b --- /dev/null +++ b/man/systemd.syntax.xml @@ -0,0 +1,229 @@ + + +%entities; +]> + + + + + + systemd.syntax + systemd + + + + systemd.syntax + 7 + + + + systemd.syntax + General syntax of systemd configuration files + + + + Introduction + + This page describes the basic principles of configuration files used by + systemd1 + and related programs for: + + systemd unit files, see + systemd.unit5, + systemd.service5, + systemd.socket5, + systemd.device5, + systemd.mount5, + systemd.automount5, + systemd.swap5, + systemd.target5, + systemd.path5, + systemd.timer5, + systemd.slice5, + systemd.scope5, + systemd.nspawn5 + + + link files, see + systemd.link5 + + + netdev and network files, see + systemd.netdev5, + systemd.network5 + + + daemon config files, see + systemd-system.conf5, + systemd-user.conf5, + logind.conf5, + journald.conf5, + journal-remote.conf5, + journal-upload.conf5, + systemd-sleep.conf5, + timesyncd.conf5 + + + + + The syntax is inspired by + XDG Desktop Entry Specification + .desktop files, which are in turn inspired by Microsoft Windows + .ini files. + + + Each file is a plain text file divided into sections, with configuration entries in the style + key=value. Whitespace immediately before or after + the = is ignored. Empty lines and lines starting with # or + ; are ignored, which may be used for commenting. + + Lines ending in a backslash are concatenated with the following line while reading and the + backslash is replaced by a space character. This may be used to wrap long lines. The limit on + line length is very large (currently 1 MB), but it is recommended to avoid such long lines and + use multiple directives, variable substitution, or other mechanism as appropriate for the given + file type. When a comment line or lines follow a line ending with a backslash, the comment block + is ignored, so the continued line is concatenated with whatever follows the comment block. + + [Section A] +KeyOne=value 1 +KeyTwo=value 2 + +# a comment + +[Section B] +Setting="something" "some thing" "…" +KeyTwo=value 2 \ + value 2 continued + +[Section C] +KeyThree=value 3\ +# this line is ignored +; this line is ignored too + value 3 continued + + + Boolean arguments used in configuration files can be written in + various formats. For positive settings the strings + , , + and are equivalent. For negative settings, the + strings , , + and are + equivalent. + + Time span values encoded in configuration files can be written in various formats. A stand-alone + number specifies a time in seconds. If suffixed with a time unit, the unit is honored. A + concatenation of multiple values with units is supported, in which case the values are added + up. Example: 50 refers to 50 seconds; 2min 200ms refers to + 2 minutes and 200 milliseconds, i.e. 120200 ms. The following time units are understood: + s, min, h, d, + w, ms, us. For details see + systemd.time7. + + Various settings are allowed to be specified more than once, in which case the + interpretation depends on the setting. Often, multiple settings form a list, and setting to an + empty value "resets", which means that previous assignments are ignored. When this is allowed, + it is mentioned in the description of the setting. Note that using multiple assignments to the + same value makes the file incompatible with parsers for the XDG .desktop + file format. + + + + Quoting + + For settings where quoting is allowed, the following general rules apply: double quotes ("…") and + single quotes ('…') may be used to wrap a whole item (the opening quote may appear only at the beginning + or after whitespace that is not quoted, and the closing quote must be followed by whitespace or the end + of line), in which case everything until the next matching quote becomes part of the same item. Quotes + themselves are removed. C-style escapes are supported. The table below contains the list of known escape + patterns. Only escape patterns which match the syntax in the table are allowed; other patterns may be + added in the future and unknown patterns will result in a warning. In particular, any backslashes should + be doubled. Finally, a trailing backslash (\) may be used to merge lines, as described + above. UTF-8 is accepted, and hence typical unicode characters do not need to be escaped. + + + Supported escapes + + + + + + Literal + Actual value + + + + + \a + bell + + + \b + backspace + + + \f + form feed + + + \n + newline + + + \r + carriage return + + + \t + tab + + + \v + vertical tab + + + \\ + backslash + + + \" + double quotation mark + + + \' + single quotation mark + + + \s + space + + + \xxx + character number xx in hexadecimal encoding + + + \nnn + character number nnn in octal encoding + + + \unnnn + unicode code point nnnn in hexadecimal encoding + + + \Unnnnnnnn + unicode code point nnnnnnnn in hexadecimal encoding + + + +
+ + + + See Also + + systemd.time7 + + + + diff --git a/man/systemd.system-credentials.xml b/man/systemd.system-credentials.xml new file mode 100644 index 0000000..44c553c --- /dev/null +++ b/man/systemd.system-credentials.xml @@ -0,0 +1,191 @@ + + + + + + + + systemd.system-credentials + systemd + + + + systemd.system-credentials + 7 + + + + systemd.system-credentials + System Credentials + + + + Description + + System and Service Credentials are data objects + that may be passed into booted systems or system services as they are invoked. They can be acquired from + various external sources, and propagated into the system and from there into system services. Credentials + may optionally be encrypted with a machine-specific key and/or locked to the local TPM2 device, and are + only decrypted when the consuming service is invoked. + + System credentials may be used to provision and configure various aspects of the system. Depending + on the consuming component credentials are only used on initial invocations or are needed for all + invocations. + + Credentials may be used for any kind of data, binary or text, and may carry passwords, secrets, + certificates, cryptographic key material, identity information, configuration, and more. + + + + Well known system credentials + + + + firstboot.keymap + + The console key mapping to set (e.g. de). Read by + systemd-firstboot1, + and only honoured if no console keymap has been configured before. + + + + + firstboot.locale + firstboot.locale-message + + The system locale to set (e.g. de_DE.UTF-8). Read by + systemd-firstboot1, + and only honoured if no locale has been configured before. firstboot.locale sets + LANG, while firstboot.locale-message sets + LC_MESSAGES. + + + + + firstboot.timezone + + The system timezone to set (e.g. Europe/Berlin). Read by + systemd-firstboot1, + and only honoured if no system timezone has been configured before. + + + + + login.issue + + The data of this credential is written to + /etc/issue.d/50-provision.conf, if the file doesn't exist yet. + agetty8 + reads this file and shows its contents at the login prompt of terminal logins. See + issue5 + for details. + + Consumed by /usr/lib/tmpfiles.d/provision.conf, see + tmpfiles.d5. + + + + + login.motd + + The data of this credential is written to /etc/motd.d/50-provision.conf, + if the file doesn't exist yet. + pam_motd8 + reads this file and shows its contents as "message of the day" during terminal logins. See + motd5 + for details. + + Consumed by /usr/lib/tmpfiles.d/provision.conf, see + tmpfiles.d5. + + + + + network.hosts + + The data of this credential is written to /etc/hosts, if the file + doesn't exist yet. See + hosts5 + for details. + + Consumed by /usr/lib/tmpfiles.d/provision.conf, see + tmpfiles.d5. + + + + + passwd.hashed-password.root + passwd.plaintext-password.root + + May contain the password (either in UNIX hashed format, or in plaintext) for the root users. + Read by both + systemd-firstboot1 + and + systemd-sysusers1, + and only honoured if no root password has been configured before. + + + + + passwd.shell.root + + The path to the shell program (e.g. /bin/bash) for the root user. Read by + both + systemd-firstboot1 + and + systemd-sysusers1, + and only honoured if no root shell has been configured before. + + + + + ssh.authorized_keys.root + + The data of this credential is written to /root/.ssh/authorized_keys, if + the file doesn't exist yet. This allows provisioning SSH access for the system's root user. + + Consumed by /usr/lib/tmpfiles.d/provision.conf, see + tmpfiles.d5. + + + + + sysusers.extra + + Additional + sysusers.d5 + lines to process during boot. + + + + + sysctl.extra + + Additional + sysctl.d5 lines + to process during boot. + + + + + tmpfiles.extra + + Additional + tmpfiles.d5 + lines to process during boot. + + + + + + + + See Also + + systemd1, + kernel-command-line7 + + + + diff --git a/man/systemd.target.xml b/man/systemd.target.xml new file mode 100644 index 0000000..604b14e --- /dev/null +++ b/man/systemd.target.xml @@ -0,0 +1,143 @@ + + + + + + + systemd.target + systemd + + + + systemd.target + 5 + + + + systemd.target + Target unit configuration + + + + target.target + + + + Description + + A unit configuration file whose name ends in + .target encodes information about a target unit + of systemd, which is used for grouping units and as well-known + synchronization points during start-up. + + This unit type has no specific options. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. A separate [Target] section does not exist, + since no target-specific options may be configured. + + Target units do not offer any additional functionality on + top of the generic functionality provided by units. They exist + merely to group units via dependencies (useful as boot targets), + and to establish standardized names for synchronization points + used in dependencies between units. Among other things, target + units are a more flexible replacement for SysV runlevels in the + classic SysV init system. (And for compatibility reasons special + target units such as runlevel3.target exist + which are used by the SysV runlevel compatibility code in systemd. + See + systemd.special7 + for details). + + + + Automatic Dependencies + + + Implicit Dependencies + + There are no implicit dependencies for target units. + + + + Default Dependencies + + The following dependencies are added unless + DefaultDependencies=no is set: + + + Target units will automatically complement all + configured dependencies of type Wants= or + Requires= with dependencies of type + After= unless DefaultDependencies=no + is set in the specified units. Note that Wants= or + Requires= must be defined in the target unit itself — if + you for example define Wants=some.target in + some.service, the automatic ordering will not be added. + + Target units automatically gain Conflicts= + and Before= dependencies against + shutdown.target. + + + + + + Options + + Target unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + No options specific to this file type are supported. + + + + Example + + + Simple standalone target + + # emergency-net.target + +[Unit] +Description=Emergency Mode with Networking +Requires=emergency.target systemd-networkd.service +After=emergency.target systemd-networkd.service +AllowIsolate=yes + + When adding dependencies to other units, it's important to check if they set + DefaultDependencies=. Service units, unless they set + DefaultDependencies=no, automatically get a dependency on + sysinit.target. In this case, both + emergency.target and systemd-networkd.service + have DefaultDependencies=no, so they are suitable for use + in this target, and do not pull in sysinit.target. + + You can now switch into this emergency mode by running systemctl + isolate emergency-net.target or by passing the option + systemd.unit=emergency-net.target on the kernel command + line. + + Other units can have WantedBy=emergency-net.target in the + [Install] section. After they are enabled using + systemctl enable, they will be started before + emergency-net.target is started. It is also possible to add + arbitrary units as dependencies of emergency.target without + modifying them by using systemctl add-wants. + + + + + + See Also + + systemd1, + systemctl1, + systemd.unit5, + systemd.special7, + systemd.directives7 + + + + diff --git a/man/systemd.time.xml b/man/systemd.time.xml new file mode 100644 index 0000000..643ff7d --- /dev/null +++ b/man/systemd.time.xml @@ -0,0 +1,311 @@ + + + + + + + + systemd.time + systemd + + + + systemd.time + 7 + + + + systemd.time + Time and date specifications + + + + Description + + In systemd, timestamps, time spans, and calendar events are + displayed and may be specified in closely related syntaxes. + + + + Displaying Time Spans + + Time spans refer to time durations. On display, systemd will present time spans as a space-separated series + of time values each suffixed by a time unit. Example: + + 2h 30min + + All specified time values are meant to be added up. The above hence refers to 150 minutes. Display is + locale-independent, only English names for the time units are used. + + + + Parsing Time Spans + + When parsing, systemd will accept the same time span syntax. + Separating spaces may be omitted. The following time units are + understood: + + + usec, us, µs + msec, ms + seconds, second, sec, s + minutes, minute, min, m + hours, hour, hr, h + days, day, d + weeks, week, w + months, month, M (defined as 30.44 days) + years, year, y (defined as 365.25 days) + + + If no time unit is specified, generally seconds are assumed, but some exceptions exist and are marked as + such. In a few cases ns, nsec is accepted too, where the granularity of the + time span permits this. Parsing is generally locale-independent, non-English names for the time units are not + accepted. + + Examples for valid time span specifications: + + 2 h +2hours +48hr +1y 12month +55s500ms +300ms20s 5day + + One can use the timespan command of + systemd-analyze1 + to normalise a textual time span for testing and validation purposes. + + Internally, systemd generally operates with microsecond time granularity, while the default time + unit in user-configurable time spans is usually seconds (see above). This disparity becomes visible when + comparing the same settings in the (high-level) unit file syntax with the matching (more low-level) D-Bus + properties (which are what + systemctl1's + show command displays). The former typically are suffixed with …Sec + to indicate the default unit of seconds, the latter are typically suffixed with …USec + to indicate the underlying low-level time unit, even if they both encapsulate the very same + settings. + + + + Displaying Timestamps + + Timestamps refer to specific, unique points in time. On + display, systemd will format these in the local timezone as + follows: + + Fri 2012-11-23 23:02:15 CET + + The weekday is printed in the abbreviated English language form. The formatting is locale-independent. + + In some cases timestamps are shown in the UTC timezone instead of the local timezone, which is indicated via + the UTC timezone specifier in the output. + + In some cases timestamps are shown with microsecond granularity. In this case the sub-second remainder is + separated by a full stop from the seconds component. + + + + Parsing Timestamps + + When parsing, systemd will accept a similar syntax, but expects no timezone specification, unless + it is given as the literal string UTC (for the UTC timezone), or is specified to be + the locally configured timezone, or the timezone name in the IANA timezone database format. The complete + list of timezones supported on your system can be obtained using the timedatectl + list-timezones (see + timedatectl1). Using + IANA format is recommended over local timezone names, as less prone to errors (e.g. with local timezone + it's possible to specify daylight saving time in winter, even though that is not correct). The weekday + specification is optional, but when the weekday is specified, it must either be in the abbreviated + (Wed) or non-abbreviated (Wednesday) English language form (case + does not matter), and is not subject to the locale choice of the user. Either the date, or the time part + may be omitted, in which case the current date or 00:00:00, respectively, is assumed. The seconds + component of the time may also be omitted, in which case ":00" is assumed. Year numbers may be specified + in full or may be abbreviated (omitting the century). + + A timestamp is considered invalid if a weekday is specified and the date does not match the specified day of + the week. + + When parsing, systemd will also accept a few special + placeholders instead of timestamps: now may be + used to refer to the current time (or of the invocation of the + command that is currently executed). today, + yesterday, and tomorrow refer to + 00:00:00 of the current day, the day before, or the next day, + respectively. + + When parsing, systemd will also accept relative time + specifications. A time span (see above) that is prefixed with + + is evaluated to the current time plus the + specified time span. Correspondingly, a time span that is prefixed + with - is evaluated to the current time minus + the specified time span. Instead of prefixing the time span with + + or -, it may also be + suffixed with a space and the word left or + ago. + + Finally, a timespan prefixed with @ is + evaluated relative to the UNIX time epoch 1st Jan, 1970, + 00:00. + + Examples for valid timestamps and their normalized form (assuming the current time was 2012-11-23 + 18:15:22 and the timezone was UTC+8, for example TZ=:Asia/Shanghai): + + Fri 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13 + 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13 + 2012-11-23 11:12:13 UTC → Fri 2012-11-23 19:12:13 + 2012-11-23 → Fri 2012-11-23 00:00:00 + 12-11-23 → Fri 2012-11-23 00:00:00 + 11:12:13 → Fri 2012-11-23 11:12:13 + 11:12 → Fri 2012-11-23 11:12:00 + now → Fri 2012-11-23 18:15:22 + today → Fri 2012-11-23 00:00:00 + today UTC → Fri 2012-11-23 16:00:00 + yesterday → Fri 2012-11-22 00:00:00 + tomorrow → Fri 2012-11-24 00:00:00 +tomorrow Pacific/Auckland → Thu 2012-11-23 19:00:00 + +3h30min → Fri 2012-11-23 21:45:22 + -5s → Fri 2012-11-23 18:15:17 + 11min ago → Fri 2012-11-23 18:04:22 + @1395716396 → Tue 2014-03-25 03:59:56 + + Note that timestamps displayed by remote systems with a non-matching timezone are usually not parsable + locally, as the timezone component is not understood (unless it happens to be UTC). + + Timestamps may also be specified with microsecond granularity. The sub-second remainder is expected separated + by a full stop from the seconds component. Example: + + 2014-03-25 03:59:56.654563 + + In some cases, systemd will display a relative timestamp (relative to the current time, or the time of + invocation of the command) instead of or in addition to an absolute timestamp as described above. A relative + timestamp is formatted as follows: + + 2 months 5 days ago + + Note that a relative timestamp is also accepted where a timestamp is expected (see above). + + Use the timestamp command of + systemd-analyze1 to + validate and normalize timestamps for testing purposes. + + + + Calendar Events + + Calendar events may be used to refer to one or more points + in time in a single expression. They form a superset of the + absolute timestamps explained above: + + Thu,Fri 2012-*-1,5 11:12:13 + + The above refers to 11:12:13 of the first or fifth day of + any month of the year 2012, but only if that day is a Thursday or + Friday. + + The weekday specification is optional. If specified, it + should consist of one or more English language weekday names, + either in the abbreviated (Wed) or non-abbreviated (Wednesday) + form (case does not matter), separated by commas. Specifying two + weekdays separated by .. refers to a range of + continuous weekdays. , and .. + may be combined freely. + + In the date and time specifications, any component may be specified as * in + which case any value will match. Alternatively, each component can be specified as a list of values + separated by commas. Values may be suffixed with / and a repetition value, which + indicates that the value itself and the value plus all multiples of the repetition value are matched. + Two values separated by .. may be used to indicate a range of values; ranges may also + be followed with / and a repetition value, in which case the expression matches all + times starting with the start value, and continuing with all multiples of the repetition value relative + to the start value, ending at the end value the latest. + + A date specification may use ~ to indicate the last day in a month. For example, + *-02~03 means "the third last day in February," and Mon *-05~07/1 + means "the last Monday in May." + + The seconds component may contain decimal fractions both in + the value and the repetition. All fractions are rounded to 6 + decimal places. + + Either time or date specification may be omitted, in which + case the current day and 00:00:00 is implied, respectively. If the + second component is not specified, :00 is + assumed. + + Timezone can be specified as the literal string UTC, or + the local timezone, similar to the supported syntax of timestamps (see above), or the timezone + in the IANA timezone database format (also see above). + + The following special expressions may be used as shorthands for longer normalized forms: + + minutely → *-*-* *:*:00 + hourly → *-*-* *:00:00 + daily → *-*-* 00:00:00 + monthly → *-*-01 00:00:00 + weekly → Mon *-*-* 00:00:00 + yearly → *-01-01 00:00:00 + quarterly → *-01,04,07,10-01 00:00:00 +semiannually → *-01,07-01 00:00:00 + + + Examples for valid timestamps and their + normalized form: + + Sat,Thu,Mon..Wed,Sat..Sun → Mon..Thu,Sat,Sun *-*-* 00:00:00 + Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00 + Wed *-1 → Wed *-*-01 00:00:00 + Wed..Wed,Wed *-1 → Wed *-*-01 00:00:00 + Wed, 17:48 → Wed *-*-* 17:48:00 +Wed..Sat,Tue 12-10-15 1:2:3 → Tue..Sat 2012-10-15 01:02:03 + *-*-7 0:0:0 → *-*-07 00:00:00 + 10-15 → *-10-15 00:00:00 + monday *-12-* 17:00 → Mon *-12-* 17:00:00 + Mon,Fri *-*-3,1,2 *:30:45 → Mon,Fri *-*-01,02,03 *:30:45 + 12,14,13,12:20,10,30 → *-*-* 12,13,14:10,20,30:00 + 12..14:10,20,30 → *-*-* 12..14:10,20,30:00 + mon,fri *-1/2-1,3 *:30:45 → Mon,Fri *-01/2-01,03 *:30:45 + 03-05 08:05:40 → *-03-05 08:05:40 + 08:05:40 → *-*-* 08:05:40 + 05:40 → *-*-* 05:40:00 + Sat,Sun 12-05 08:05:40 → Sat,Sun *-12-05 08:05:40 + Sat,Sun 08:05:40 → Sat,Sun *-*-* 08:05:40 + 2003-03-05 05:40 → 2003-03-05 05:40:00 + 05:40:23.4200004/3.1700005 → *-*-* 05:40:23.420000/3.170001 + 2003-02..04-05 → 2003-02..04-05 00:00:00 + 2003-03-05 05:40 UTC → 2003-03-05 05:40:00 UTC + 2003-03-05 → 2003-03-05 00:00:00 + 03-05 → *-03-05 00:00:00 + hourly → *-*-* *:00:00 + daily → *-*-* 00:00:00 + daily UTC → *-*-* 00:00:00 UTC + monthly → *-*-01 00:00:00 + weekly → Mon *-*-* 00:00:00 + weekly Pacific/Auckland → Mon *-*-* 00:00:00 Pacific/Auckland + yearly → *-01-01 00:00:00 + annually → *-01-01 00:00:00 + *:2/3 → *-*-* *:02/3:00 + + Calendar events are used by timer units, see + systemd.timer5 + for details. + + Use the calendar command of + systemd-analyze1 to validate + and normalize calendar time specifications for testing purposes. The tool also calculates when a specified + calendar event would occur next. + + + + See Also + + systemd1, + journalctl1, + systemd.timer5, + systemd.unit5, + systemd.directives7, + systemd-analyze1 + + + + diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml new file mode 100644 index 0000000..903e258 --- /dev/null +++ b/man/systemd.timer.xml @@ -0,0 +1,398 @@ + + + + + + + systemd.timer + systemd + + + + systemd.timer + 5 + + + + systemd.timer + Timer unit configuration + + + + timer.timer + + + + Description + + A unit configuration file whose name ends in + .timer encodes information about a timer + controlled and supervised by systemd, for timer-based + activation. + + This man page lists the configuration options specific to + this unit type. See + systemd.unit5 + for the common options of all unit configuration files. The common + configuration items are configured in the generic [Unit] and + [Install] sections. The timer specific configuration options are + configured in the [Timer] section. + + For each timer file, a matching unit file must exist, + describing the unit to activate when the timer elapses. By + default, a service by the same name as the timer (except for the + suffix) is activated. Example: a timer file + foo.timer activates a matching service + foo.service. The unit to activate may be + controlled by Unit= (see below). + + Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, + but simply left running. There is no concept of spawning new service instances in this case. Due to this, services + with RemainAfterExit= set (which stay around continuously even after the service's main process + exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and + then stay around forever. + + + + Automatic Dependencies + + + Implicit Dependencies + + The following dependencies are implicitly added: + + + Timer units automatically gain a Before= + dependency on the service they are supposed to activate. + + + + + Default Dependencies + + The following dependencies are added unless DefaultDependencies=no is set: + + + Timer units will automatically have dependencies of type Requires= and + After= on sysinit.target, a dependency of type Before= + on timers.target, as well as Conflicts= and Before= on + shutdown.target to ensure that they are stopped cleanly prior to system shutdown. Only timer + units involved with early boot or late system shutdown should disable the + DefaultDependencies= option. + + Timer units with at least one OnCalendar= directive acquire a pair + of additional After= dependencies on time-set.target and + time-sync.target, in order to avoid being started before the system clock has + been correctly set. See + systemd.special7 + for details on these two targets. + + + + + + Options + + Timer unit files may include [Unit] and [Install] sections, which are described in + systemd.unit5. + + + Timer unit files must include a [Timer] section, which carries + information about the timer it defines. The options specific to + the [Timer] section of timer units are the following: + + + + OnActiveSec= + OnBootSec= + OnStartupSec= + OnUnitActiveSec= + OnUnitInactiveSec= + + Defines monotonic timers relative to different + starting points: + + + Settings and their starting points + + + + + Setting + Meaning + + + + + OnActiveSec= + Defines a timer relative to the moment the timer unit itself is activated. + + + OnBootSec= + Defines a timer relative to when the machine was booted up. In containers, for the system manager instance, this is mapped to OnStartupSec=, making both equivalent. + + + OnStartupSec= + Defines a timer relative to when the service manager was first started. For system timer units this is very similar to OnBootSec= as the system service manager is generally started very early at boot. It's primarily useful when configured in units running in the per-user service manager, as the user service manager is generally started on first login only, not already during boot. + + + OnUnitActiveSec= + Defines a timer relative to when the unit the timer unit is activating was last activated. + + + OnUnitInactiveSec= + Defines a timer relative to when the unit the timer unit is activating was last deactivated. + + + +
+ + Multiple directives may be combined of the same and of different types, in which case the timer + unit will trigger whenever any of the specified timer expressions elapse. For example, by combining + OnBootSec= and OnUnitActiveSec=, it is possible to define a + timer that elapses in regular intervals and activates a specific service each time. Moreover, both + monotonic time expressions and OnCalendar= calendar expressions may be combined in + the same timer unit. + + The arguments to the directives are time spans + configured in seconds. Example: "OnBootSec=50" means 50s after + boot-up. The argument may also include time units. Example: + "OnBootSec=5h 30min" means 5 hours and 30 minutes after + boot-up. For details about the syntax of time spans, see + systemd.time7. + + If a timer configured with OnBootSec= + or OnStartupSec= is already in the past + when the timer unit is activated, it will immediately elapse + and the configured unit is started. This is not the case for + timers defined in the other directives. + + These are monotonic timers, independent of wall-clock time and timezones. If the computer is + temporarily suspended, the monotonic clock generally pauses, too. Note that if + WakeSystem= is used, a different monotonic clock is selected that continues to + advance while the system is suspended and thus can be used as the trigger to resume the + system. + + If the empty string is assigned to any of these options, the list of timers is reset (both + monotonic timers and OnCalendar= timers, see below), and all prior assignments + will have no effect. + + Note that timers do not necessarily expire at the + precise time configured with these settings, as they are + subject to the AccuracySec= setting + below. + + + + OnCalendar= + + Defines realtime (i.e. wallclock) timers with calendar event expressions. See + systemd.time7 for + more information on the syntax of calendar event expressions. Otherwise, the semantics are similar to + OnActiveSec= and related settings. + + Note that timers do not necessarily expire at the precise time configured with this setting, as + it is subject to the AccuracySec= setting below. + + May be specified more than once, in which case the timer unit will trigger whenever any of the + specified expressions elapse. Moreover calendar timers and monotonic timers (see above) may be + combined within the same timer unit. + + If the empty string is assigned to any of these options, the list of timers is reset (both + OnCalendar= timers and monotonic timers, see above), and all prior assignments + will have no effect. + + Note that calendar timers might be triggered at unexpected times if the system's realtime clock + is not set correctly. Specifically, on systems that lack a battery-buffered Realtime Clock (RTC) it + might be wise to enable systemd-time-wait-sync.service to ensure the clock is + adjusted to a network time source before the timer event is set up. Timer units + with at least one OnCalendar= expression are automatically ordered after + time-sync.target, which systemd-time-wait-sync.service is + ordered before. + + When a system is temporarily put to sleep (i.e. system suspend or hibernation) the realtime + clock does not pause. When a calendar timer elapses while the system is sleeping it will not be acted + on immediately, but once the system is later resumed it will catch up and process all timers that + triggered while the system was sleeping. Note that if a calendar timer elapsed more than once while + the system was continously sleeping the timer will only result in a single service activation. If + WakeSystem= (see below) is enabled a calendar time event elapsing while the system + is suspended will cause the system to wake up (under the condition the system's hardware supports + time-triggered wake-up functionality). + + + + AccuracySec= + + Specify the accuracy the timer shall elapse + with. Defaults to 1min. The timer is scheduled to elapse + within a time window starting with the time specified in + OnCalendar=, + OnActiveSec=, + OnBootSec=, + OnStartupSec=, + OnUnitActiveSec= or + OnUnitInactiveSec= and ending the time + configured with AccuracySec= later. Within + this time window, the expiry time will be placed at a + host-specific, randomized, but stable position that is + synchronized between all local timer units. This is done in + order to optimize power consumption to suppress unnecessary + CPU wake-ups. To get best accuracy, set this option to + 1us. Note that the timer is still subject to the timer slack + configured via + systemd-system.conf5's + TimerSlackNSec= setting. See + prctl2 + for details. To optimize power consumption, make sure to set + this value as high as possible and as low as + necessary. + + Note that this setting is primarily a power saving option that allows coalescing CPU + wake-ups. It should not be confused with RandomizedDelaySec= (see below) which + adds a random value to the time the timer shall elapse next and whose purpose is the opposite: to + stretch elapsing of timer events over a longer period to reduce workload spikes. For further details + and explanations and how both settings play together, see below. + + + + RandomizedDelaySec= + + Delay the timer by a randomly selected, evenly distributed amount of time between 0 + and the specified time value. Defaults to 0, indicating that no randomized delay shall be applied. + Each timer unit will determine this delay randomly before each iteration, and the delay will simply + be added on top of the next determined elapsing time, unless modified with + FixedRandomDelay=, see below. + + This setting is useful to stretch dispatching of similarly configured timer events over a + certain time interval, to prevent them from firing all at the same time, possibly resulting in + resource congestion. + + Note the relation to AccuracySec= above: the latter allows the service + manager to coalesce timer events within a specified time range in order to minimize wakeups, while + this setting does the opposite: it stretches timer events over an interval, to make it unlikely that + they fire simultaneously. If RandomizedDelaySec= and + AccuracySec= are used in conjunction, first the randomized delay is added, and + then the result is possibly further shifted to coalesce it with other timer events happening on the + system. As mentioned above AccuracySec= defaults to 1 minute and + RandomizedDelaySec= to 0, thus encouraging coalescing of timer events. In order to + optimally stretch timer events over a certain range of time, set + AccuracySec=1us and RandomizedDelaySec= to some higher value. + + + + + FixedRandomDelay= + + Takes a boolean argument. When enabled, the randomized offset specified by + RandomizedDelaySec= is reused for all firings of the same timer. For a given timer + unit, the offset depends on the machine ID, user identifier and timer name, which means that it is + stable between restarts of the manager. This effectively creates a fixed offset for an individual + timer, reducing the jitter in firings of this timer, while still avoiding firing at the same time as + other similarly configured timers. + + This setting has no effect if RandomizedDelaySec= is set to 0. Defaults to + . + + + + OnClockChange= + OnTimezoneChange= + + These options take boolean arguments. When true, the service unit will be triggered + when the system clock (CLOCK_REALTIME) jumps relative to the monotonic clock + (CLOCK_MONOTONIC), or when the local system timezone is modified. These options + can be used alone or in combination with other timer expressions (see above) within the same timer + unit. These options default to . + + + + Unit= + + The unit to activate when this timer elapses. + The argument is a unit name, whose suffix is not + .timer. If not specified, this value + defaults to a service that has the same name as the timer + unit, except for the suffix. (See above.) It is recommended + that the unit name that is activated and the unit name of the + timer unit are named identically, except for the + suffix. + + + + Persistent= + + Takes a boolean argument. If true, the time when the service unit was last triggered + is stored on disk. When the timer is activated, the service unit is triggered immediately if it + would have been triggered at least once during the time when the timer was inactive. Such triggering + is nonetheless subject to the delay imposed by RandomizedDelaySec=. + This is useful to catch up on missed runs of the service when the system was powered down. Note that + this setting only has an effect on timers configured with OnCalendar=. Defaults to + . + + Use systemctl clean --what=state … on the timer unit to remove the timestamp + file maintained by this option from disk. In particular, use this command before uninstalling a timer + unit. See + systemctl1 for + details. + + + + WakeSystem= + + Takes a boolean argument. If true, an elapsing timer will cause the system to resume + from suspend, should it be suspended and if the system supports this. Note that this option will only + make sure the system resumes on the appropriate times, it will not take care of suspending it again + after any work that is to be done is finished. Defaults to + . + + Note that this functionality requires privileges and is thus generally only available in the + system service manager. + + Note that behaviour of monotonic clock timers (as configured with + OnActiveSec=, OnBootSec=, OnStartupSec=, + OnUnitActiveSec=, OnUnitInactiveSec=, see above) is altered + depending on this option. If false, a monotonic clock is used that is paused during system suspend + (CLOCK_MONOTONIC), if true a different monotonic clock is used that continues + advancing during system suspend (CLOCK_BOOTTIME), see + clock_getres2 for + details. + + + + RemainAfterElapse= + + Takes a boolean argument. If true, a timer will stay loaded, and its state remains + queryable even after it elapsed and the associated unit (as configured with Unit=, + see above) deactivated again. If false, an elapsed timer unit that cannot elapse anymore is unloaded + once its associated unit deactivated again. Turning this off is particularly useful for transient + timer units. Note that this setting has an effect when repeatedly starting a timer unit: if + RemainAfterElapse= is on, starting the timer a second time has no effect. However, + if RemainAfterElapse= is off and the timer unit was already unloaded, it can be + started again, and thus the service can be triggered multiple times. Defaults to + . + + + + + + + + See Also + Environment variables with details on the trigger will be set for triggered units. See the + Environment Variables Set on Triggered Units section in + systemd.exec1 + for more details. + + systemd1, + systemctl1, + systemd.unit5, + systemd.service5, + systemd.time7, + systemd.directives7, + systemd-system.conf5, + prctl2 + + + + diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml new file mode 100644 index 0000000..295f295 --- /dev/null +++ b/man/systemd.unit.xml @@ -0,0 +1,2432 @@ + + +%entities; +]> + + + + + + systemd.unit + systemd + + + + systemd.unit + 5 + + + + systemd.unit + Unit configuration + + + + service.service, + socket.socket, + device.device, + mount.mount, + automount.automount, + swap.swap, + target.target, + path.path, + timer.timer, + slice.slice, + scope.scope + + + System Unit Search Path + + /etc/systemd/system.control/* +/run/systemd/system.control/* +/run/systemd/transient/* +/run/systemd/generator.early/* +/etc/systemd/system/* +/etc/systemd/system.attached/* +/run/systemd/system/* +/run/systemd/system.attached/* +/run/systemd/generator/* +… +/usr/lib/systemd/system/* +/run/systemd/generator.late/* + + + + User Unit Search Path + ~/.config/systemd/user.control/* +$XDG_RUNTIME_DIR/systemd/user.control/* +$XDG_RUNTIME_DIR/systemd/transient/* +$XDG_RUNTIME_DIR/systemd/generator.early/* +~/.config/systemd/user/* +$XDG_CONFIG_DIRS/systemd/user/* +/etc/systemd/user/* +$XDG_RUNTIME_DIR/systemd/user/* +/run/systemd/user/* +$XDG_RUNTIME_DIR/systemd/generator/* +$XDG_DATA_HOME/systemd/user/* +$XDG_DATA_DIRS/systemd/user/* +… +/usr/lib/systemd/user/* +$XDG_RUNTIME_DIR/systemd/generator.late/* + + + + + + Description + + A unit file is a plain text ini-style file that encodes information about a service, a + socket, a device, a mount point, an automount point, a swap file or partition, a start-up + target, a watched file system path, a timer controlled and supervised by + systemd1, a + resource management slice or a group of externally created processes. See + systemd.syntax7 + for a general description of the syntax. + + This man page lists the common configuration options of all + the unit types. These options need to be configured in the [Unit] + or [Install] sections of the unit files. + + In addition to the generic [Unit] and [Install] sections + described here, each unit may have a type-specific section, e.g. + [Service] for a service unit. See the respective man pages for + more information: + systemd.service5, + systemd.socket5, + systemd.device5, + systemd.mount5, + systemd.automount5, + systemd.swap5, + systemd.target5, + systemd.path5, + systemd.timer5, + systemd.slice5, + systemd.scope5. + + + Unit files are loaded from a set of paths determined during compilation, described in the next + section. + + Valid unit names consist of a "unit name prefix", and a suffix specifying the unit type which + begins with a dot. The "unit name prefix" must consist of one or more valid characters (ASCII letters, + digits, :, -, _, ., and + \). The total length of the unit name including the suffix must not exceed 255 + characters. The unit type suffix must be one of .service, .socket, + .device, .mount, .automount, + .swap, .target, .path, + .timer, .slice, or .scope. + + Unit names can be parameterized by a single argument called the "instance name". The unit is then + constructed based on a "template file" which serves as the definition of multiple services or other + units. A template unit must have a single @ at the end of the unit name prefix (right + before the type suffix). The name of the full unit is formed by inserting the instance name between + @ and the unit type suffix. In the unit file itself, the instance parameter may be + referred to using %i and other specifiers, see below. + + Unit files may contain additional options on top of those listed here. If systemd encounters an + unknown option, it will write a warning log message but continue loading the unit. If an option or + section name is prefixed with , it is ignored completely by systemd. Options within an + ignored section do not need the prefix. Applications may use this to include additional information in + the unit files. To access those options, applications need to parse the unit files on their own. + + Units can be aliased (have an alternative name), by creating a symlink from the new name to the + existing name in one of the unit search paths. For example, systemd-networkd.service + has the alias dbus-org.freedesktop.network1.service, created during installation as + a symlink, so when systemd is asked through D-Bus to load + dbus-org.freedesktop.network1.service, it'll load + systemd-networkd.service. As another example, default.target — + the default system target started at boot — is commonly aliased to either + multi-user.target or graphical.target to select what is started + by default. Alias names may be used in commands like disable, + start, stop, status, and similar, and in all + unit dependency directives, including Wants=, Requires=, + Before=, After=. Aliases cannot be used with the + preset command. + + Aliases obey the following restrictions: a unit of a certain type (.service, + .socket, …) can only be aliased by a name with the same type suffix. A plain unit (not + a template or an instance), may only be aliased by a plain name. A template instance may only be aliased + by another template instance, and the instance part must be identical. A template may be aliased by + another template (in which case the alias applies to all instances of the template). As a special case, a + template instance (e.g. alias@inst.service) may be a symlink to different template + (e.g. template@inst.service). In that case, just this specific instance is aliased, + while other instances of the template (e.g. alias@foo.service, + alias@bar.service) are not aliased. Those rules preserve the requirement that the + instance (if any) is always uniquely defined for a given unit and all its aliases. The target of alias + symlink must point to a valid unit file location, i.e. the symlink target name must match the symlink + source name as described, and the destination path must be in one of the unit search paths, see UNIT FILE + LOAD PATH section below for more details. Note that the target file may not exist, i.e. the symlink may + be dangling. + + Unit files may specify aliases through the Alias= directive in the [Install] + section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is + disabled. For example, reboot.target specifies + Alias=ctrl-alt-del.target, so when enabled, the symlink + /etc/systemd/system/ctrl-alt-del.service pointing to the + reboot.target file will be created, and when + CtrlAltDel is invoked, + systemd will look for the ctrl-alt-del.service and execute + reboot.service. systemd does not look at the [Install] section at + all during normal operation, so any directives in that section only have an effect through the symlinks + created during enablement. + + Along with a unit file foo.service, the directory + foo.service.wants/ may exist. All unit files symlinked from such a directory are + implicitly added as dependencies of type Wants= to the unit. Similar functionality + exists for Requires= type dependencies as well, the directory suffix is + .requires/ in this case. This functionality is useful to hook units into the + start-up of other units, without having to modify their unit files. For details about the semantics of + Wants= and Requires=, see below. The preferred way to create + symlinks in the .wants/ or .requires/ directories is by + specifying the dependency in [Install] section of the target unit, and creating the symlink in the file + system with the enable or preset commands of + systemctl1. The + target can be a normal unit (either plain or a specific instance of a template unit). In case when the + source unit is a template, the target can also be a template, in which case the instance will be + "propagated" to the target unit to form a valid unit instance. The target of symlinks in + .wants/ or .requires/ must thus point to a valid unit file + location, i.e. the symlink target name must satisfy the described requirements, and the destination path + must be in one of the unit search paths, see UNIT FILE LOAD PATH section below for more details. Note + that the target file may not exist, i.e. the symlink may be dangling. + + Along with a unit file foo.service, a "drop-in" directory + foo.service.d/ may exist. All files with the suffix + .conf from this directory will be merged in the alphanumeric order and parsed + after the main unit file itself has been parsed. This is useful to alter or add configuration + settings for a unit, without having to modify unit files. Each drop-in file must contain appropriate + section headers. For instantiated units, this logic will first look for the instance + .d/ subdirectory (e.g. foo@bar.service.d/) and read its + .conf files, followed by the template .d/ subdirectory (e.g. + foo@.service.d/) and the .conf files there. Moreover for unit + names containing dashes (-), the set of directories generated by repeatedly + truncating the unit name after all dashes is searched too. Specifically, for a unit name + foo-bar-baz.service not only the regular drop-in directory + foo-bar-baz.service.d/ is searched but also both foo-bar-.service.d/ and + foo-.service.d/. This is useful for defining common drop-ins for a set of related units, whose + names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose + systematic naming structure is built around dashes as component separators. Note that equally named drop-in files + further down the prefix hierarchy override those further up, + i.e. foo-bar-.service.d/10-override.conf overrides + foo-.service.d/10-override.conf. + + In cases of unit aliases (described above), dropins for the aliased name and all aliases are + loaded. In the example of default.target aliasing + graphical.target, default.target.d/, + default.target.wants/, default.target.requires/, + graphical.target.d/, graphical.target.wants/, + graphical.target.requires/ would all be read. For templates, dropins for the + template, any template aliases, the template instance, and all alias instances are read. When just a + specific template instance is aliased, then the dropins for the target template, the target template + instance, and the alias template instance are read. + + In addition to /etc/systemd/system, the drop-in .d/ + directories for system services can be placed in /usr/lib/systemd/system or + /run/systemd/system directories. Drop-in files in /etc/ + take precedence over those in /run/ which in turn take precedence over those + in /usr/lib/. Drop-in files under any of these directories take precedence + over unit files wherever located. Multiple drop-in files with different names are applied in + lexicographic order, regardless of which of the directories they reside in. + + Units also support a top-level drop-in with type.d/, + where type may be e.g. service or socket, + that allows altering or adding to the settings of all corresponding unit files on the system. + The formatting and precedence of applying drop-in configurations follow what is defined above. + Files in type.d/ have lower precedence compared + to files in name-specific override directories. The usual rules apply: multiple drop-in files + with different names are applied in lexicographic order, regardless of which of the directories + they reside in, so a file in type.d/ applies + to a unit only if there are no drop-ins or masks with that name in directories with higher + precedence. See Examples. + + Note that while systemd offers a flexible dependency system + between units it is recommended to use this functionality only + sparingly and instead rely on techniques such as bus-based or + socket-based activation which make dependencies implicit, + resulting in a both simpler and more flexible system. + + As mentioned above, a unit may be instantiated from a template file. This allows creation + of multiple units from a single configuration file. If systemd looks for a unit configuration + file, it will first search for the literal unit name in the file system. If that yields no + success and the unit name contains an @ character, systemd will look for a + unit template that shares the same name but with the instance string (i.e. the part between the + @ character and the suffix) removed. Example: if a service + getty@tty3.service is requested and no file by that name is found, systemd + will look for getty@.service and instantiate a service from that + configuration file if it is found. + + To refer to the instance string from within the + configuration file you may use the special %i + specifier in many of the configuration options. See below for + details. + + If a unit file is empty (i.e. has the file size 0) or is + symlinked to /dev/null, its configuration + will not be loaded and it appears with a load state of + masked, and cannot be activated. Use this as an + effective way to fully disable a unit, making it impossible to + start it even manually. + + The unit file format is covered by the + Interface + Portability and Stability Promise. + + + + + String Escaping for Inclusion in Unit Names + + Sometimes it is useful to convert arbitrary strings into unit names. To facilitate this, a method of string + escaping is used, in order to map strings containing arbitrary byte values (except NUL) into + valid unit names and their restricted character set. A common special case are unit names that reflect paths to + objects in the file system hierarchy. Example: a device unit dev-sda.device refers to a device + with the device node /dev/sda in the file system. + + The escaping algorithm operates as follows: given a string, any / character is + replaced by -, and all other characters which are not ASCII alphanumerics, + :, _ or . are replaced by C-style + \x2d escapes. In addition, . is replaced with such a C-style escape + when it would appear as the first character in the escaped string. + + When the input qualifies as absolute file system path, this algorithm is extended slightly: the path to the + root directory / is encoded as single dash -. In addition, any leading, + trailing or duplicate / characters are removed from the string before transformation. Example: + /foo//bar/baz/ becomes foo-bar-baz. + + This escaping is fully reversible, as long as it is known whether the escaped string was a path (the + unescaping results are different for paths and non-path strings). The + systemd-escape1 command may be + used to apply and reverse escaping on arbitrary strings. Use systemd-escape --path to escape + path strings, and systemd-escape without otherwise. + + + + Automatic dependencies + + + Implicit Dependencies + + A number of unit dependencies are implicitly established, depending on unit type and + unit configuration. These implicit dependencies can make unit configuration file cleaner. For + the implicit dependencies in each unit type, please refer to section "Implicit Dependencies" + in respective man pages. + + For example, service units with Type=dbus automatically acquire + dependencies of type Requires= and After= on + dbus.socket. See + systemd.service5 + for details. + + + + Default Dependencies + + Default dependencies are similar to implicit dependencies, but can be turned on and off + by setting DefaultDependencies= to yes (the default) and + no, while implicit dependencies are always in effect. See section "Default + Dependencies" in respective man pages for the effect of enabling + DefaultDependencies= in each unit types. + + For example, target units will complement all configured dependencies of type + Wants= or Requires= with dependencies of type + After=. See + systemd.target5 + for details. Note that this behavior can be opted out by setting + DefaultDependencies=no in the specified units, or it can be selectively + overridden via an explicit Before= dependency. + + + + + Unit File Load Path + + Unit files are loaded from a set of paths determined during + compilation, described in the two tables below. Unit files found + in directories listed earlier override files with the same name in + directories lower in the list. + + When the variable $SYSTEMD_UNIT_PATH is set, + the contents of this variable overrides the unit load path. If + $SYSTEMD_UNIT_PATH ends with an empty component + (:), the usual unit load path will be appended + to the contents of the variable. + + + + Load path when running in system mode (<option>--system</option>). + + + + + + + + Path + Description + + + + + /etc/systemd/system.control + Persistent and transient configuration created using the dbus API + + + /run/systemd/system.control + + + /run/systemd/transient + Dynamic configuration for transient units + + + /run/systemd/generator.early + Generated units with high priority (see early-dir in systemd.generator7) + + + /etc/systemd/system + System units created by the administrator + + + /run/systemd/system + Runtime units + + + /run/systemd/generator + Generated units with medium priority (see normal-dir in systemd.generator7) + + + /usr/local/lib/systemd/system + System units installed by the administrator + + + /usr/lib/systemd/system + System units installed by the distribution package manager + + + /run/systemd/generator.late + Generated units with low priority (see late-dir in systemd.generator7) + + + +
+ + + + Load path when running in user mode (<option>--user</option>). + + + + + + + + Path + Description + + + + + $XDG_CONFIG_HOME/systemd/user.control or ~/.config/systemd/user.control + Persistent and transient configuration created using the dbus API ($XDG_CONFIG_HOME is used if set, ~/.config otherwise) + + + $XDG_RUNTIME_DIR/systemd/user.control + + + $XDG_RUNTIME_DIR/systemd/transient + Dynamic configuration for transient units + + + $XDG_RUNTIME_DIR/systemd/generator.early + Generated units with high priority (see early-dir in systemd.generator7) + + + $XDG_CONFIG_HOME/systemd/user or $HOME/.config/systemd/user + User configuration ($XDG_CONFIG_HOME is used if set, ~/.config otherwise) + + + $XDG_CONFIG_DIRS/systemd/user or /etc/xdg/systemd/user + Additional configuration directories as specified by the XDG base directory specification ($XDG_CONFIG_DIRS is used if set, /etc/xdg otherwise) + + + /etc/systemd/user + User units created by the administrator + + + $XDG_RUNTIME_DIR/systemd/user + Runtime units (only used when $XDG_RUNTIME_DIR is set) + + + /run/systemd/user + Runtime units + + + $XDG_RUNTIME_DIR/systemd/generator + Generated units with medium priority (see normal-dir in systemd.generator7) + + + $XDG_DATA_HOME/systemd/user or $HOME/.local/share/systemd/user + Units of packages that have been installed in the home directory ($XDG_DATA_HOME is used if set, ~/.local/share otherwise) + + + $XDG_DATA_DIRS/systemd/user or /usr/local/share/systemd/user and /usr/share/systemd/user + Additional data directories as specified by the XDG base directory specification ($XDG_DATA_DIRS is used if set, /usr/local/share and /usr/share otherwise) + + + $dir/systemd/user for each $dir in $XDG_DATA_DIRS + Additional locations for installed user units, one for each entry in $XDG_DATA_DIRS + + + /usr/local/lib/systemd/user + User units installed by the administrator + + + /usr/lib/systemd/user + User units installed by the distribution package manager + + + $XDG_RUNTIME_DIR/systemd/generator.late + Generated units with low priority (see late-dir in systemd.generator7) + + + +
+ + The set of load paths for the user manager instance may be augmented or + changed using various environment variables. And environment variables may in + turn be set using environment generators, see + systemd.environment-generator7. + In particular, $XDG_DATA_HOME and + $XDG_DATA_DIRS may be easily set using + systemd-environment-d-generator8. + Thus, directories listed here are just the defaults. To see the actual list that + would be used based on compilation options and current environment use + systemd-analyze --user unit-paths + + + Moreover, additional units might be loaded into systemd from directories not on the unit load path + by creating a symlink pointing to a unit file in the directories. You can use systemctl + link for this; see + systemctl1. The file + system where the linked unit files are located must be accessible when systemd is started (e.g. anything + underneath /home/ or /var/ is not allowed, unless those + directories are located on the root file system). + + It is important to distinguish "linked unit files" from "unit file aliases": any symlink where the + symlink target is within the unit load path becomes an alias: the source name and + the target file name must satisfy specific constraints listed above in the discussion of aliases, but the + symlink target doesn't have to exist, and in fact the symlink target path is not used, except to check + whether the target is within the unit load path. In contrast, a symlink which goes outside of the unit + load path signifies a linked unit file. The symlink is followed when loading the file, but the + destination name is otherwise unused (and may even not be a valid unit file name). For example, symlinks + /etc/systemd/system/alias1.service → service1.service, + /etc/systemd/system/alias2.service → /usr/lib/systemd/service1.service, + /etc/systemd/system/alias3.service → /etc/systemd/system/service1.service + are all valid aliases and service1.service will have + four names, even if the unit file is located at + /run/systemd/system/service1.service. In contrast, + a symlink /etc/systemd/system/link1.service → ../link1_service_file + means that link1.service is a "linked unit" and the contents of + /etc/systemd/link1_service_file provide its configuration. + + + + Unit Garbage Collection + + The system and service manager loads a unit's configuration automatically when a unit is referenced for the + first time. It will automatically unload the unit configuration and state again when the unit is not needed anymore + ("garbage collection"). A unit may be referenced through a number of different mechanisms: + + + Another loaded unit references it with a dependency such as After=, + Wants=, … + + The unit is currently starting, running, reloading or stopping. + + The unit is currently in the failed state. (But see below.) + + A job for the unit is pending. + + The unit is pinned by an active IPC client program. + + The unit is a special "perpetual" unit that is always active and loaded. Examples for perpetual + units are the root mount unit -.mount or the scope unit init.scope that + the service manager itself lives in. + + The unit has running processes associated with it. + + + The garbage collection logic may be altered with the CollectMode= option, which allows + configuration whether automatic unloading of units that are in failed state is permissible, + see below. + + Note that when a unit's configuration and state is unloaded, all execution results, such as exit codes, exit + signals, resource consumption and other statistics are lost, except for what is stored in the log subsystem. + + Use systemctl daemon-reload or an equivalent command to reload unit configuration while + the unit is already loaded. In this case all configuration settings are flushed out and replaced with the new + configuration (which however might not be in effect immediately), however all runtime state is + saved/restored. + + + + [Unit] Section Options + + The unit file may include a [Unit] section, which carries + generic information about the unit that is not dependent on the + type of unit: + + + + Description= + A short human readable title of the unit. This may be used by + systemd (and other UIs) as a user-visible label for the unit, so this string + should identify the unit rather than describe it, despite the name. This string also shouldn't just + repeat the unit name. Apache2 Web Server is a good example. Bad examples are + high-performance light-weight HTTP server (too generic) or + Apache2 (meaningless for people who do not know Apache, duplicates the unit + name). systemd may use this string as a noun in status messages (Starting + description..., Started + description., Reached target + description., Failed to start + description.), so it should be capitalized, and should not be a + full sentence, or a phrase with a continuous verb. Bad examples include exiting the + container or updating the database once per day.. + + + + + Documentation= + A space-separated list of URIs referencing + documentation for this unit or its configuration. Accepted are + only URIs of the types http://, + https://, file:, + info:, man:. For more + information about the syntax of these URIs, see uri7. + The URIs should be listed in order of relevance, starting with + the most relevant. It is a good idea to first reference + documentation that explains what the unit's purpose is, + followed by how it is configured, followed by any other + related documentation. This option may be specified more than + once, in which case the specified list of URIs is merged. If + the empty string is assigned to this option, the list is reset + and all prior assignments will have no + effect. + + + + Wants= + + Configures (weak) requirement dependencies on other units. This option may be + specified more than once or multiple space-separated units may be specified in one option in which + case dependencies for all listed names will be created. Dependencies of this type may also be + configured outside of the unit configuration file by adding a symlink to a + .wants/ directory accompanying the unit file. For details, see above. + + Units listed in this option will be started if the configuring unit is. However, if the listed + units fail to start or cannot be added to the transaction, this has no impact on the validity of the + transaction as a whole, and this unit will still be started. This is the recommended way to hook + the start-up of one unit to the start-up of another unit. + + Note that requirement dependencies do not influence the order in which services are started or + stopped. This has to be configured independently with the After= or + Before= options. If unit foo.service pulls in unit + bar.service as configured with Wants= and no ordering is + configured with After= or Before=, then both units will be + started simultaneously and without any delay between them if foo.service is + activated. + + + + Requires= + + Similar to Wants=, but declares a stronger requirement + dependency. Dependencies of this type may also be configured by adding a symlink to a + .requires/ directory accompanying the unit file. + + If this unit gets activated, the units listed will be activated as well. If one of + the other units fails to activate, and an ordering dependency After= on the + failing unit is set, this unit will not be started. Besides, with or without specifying + After=, this unit will be stopped (or restarted) if one of the other units is + explicitly stopped (or restarted). + + Often, it is a better choice to use Wants= instead of + Requires= in order to achieve a system that is more robust when dealing with + failing services. + + Note that this dependency type does not imply that the other unit always has to be in active state when + this unit is running. Specifically: failing condition checks (such as ConditionPathExists=, + ConditionPathIsSymbolicLink=, … — see below) do not cause the start job of a unit with a + Requires= dependency on it to fail. Also, some unit types may deactivate on their own (for + example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not + propagated to units having a Requires= dependency. Use the BindsTo= + dependency type together with After= to ensure that a unit may never be in active state + without a specific other unit also in active state (see below). + + + + Requisite= + + Similar to Requires=. However, if the units listed here + are not started already, they will not be started and the starting of this unit will fail + immediately. Requisite= does not imply an ordering dependency, even if + both units are started in the same transaction. Hence this setting should usually be + combined with After=, to ensure this unit is not started before the other + unit. + + When Requisite=b.service is used on + a.service, this dependency will show as + RequisiteOf=a.service in property listing of + b.service. RequisiteOf= + dependency cannot be specified directly. + + + + + BindsTo= + + Configures requirement dependencies, very similar in style to + Requires=. However, this dependency type is stronger: in addition to the effect of + Requires= it declares that if the unit bound to is stopped, this unit will be stopped + too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too. + Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit + might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of + a mount unit might be unmounted without involvement of the system and service manager. + + When used in conjunction with After= on the same unit the behaviour of + BindsTo= is even stronger. In this case, the unit bound to strictly has to be in active + state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly + enters inactive state, but also one that is bound to another unit that gets skipped due to an unmet condition + check (such as ConditionPathExists=, ConditionPathIsSymbolicLink=, … — + see below) will be stopped, should it be running. Hence, in many cases it is best to combine + BindsTo= with After=. + + When BindsTo=b.service is used on + a.service, this dependency will show as + BoundBy=a.service in property listing of + b.service. BoundBy= + dependency cannot be specified directly. + + + + + PartOf= + + Configures dependencies similar to + Requires=, but limited to stopping and + restarting of units. When systemd stops or restarts the units + listed here, the action is propagated to this unit. Note that + this is a one-way dependency — changes to this unit do not + affect the listed units. + + When PartOf=b.service is used on + a.service, this dependency will show as + ConsistsOf=a.service in property listing of + b.service. ConsistsOf= + dependency cannot be specified directly. + + + + + Upholds= + + Configures dependencies similar to Wants=, but as long as this unit + is up, all units listed in Upholds= are started whenever found to be inactive or + failed, and no job is queued for them. While a Wants= dependency on another unit + has a one-time effect when this units started, a Upholds= dependency on it has a + continuous effect, constantly restarting the unit if necessary. This is an alternative to the + Restart= setting of service units, to ensure they are kept running whatever + happens. + + When Upholds=b.service is used on a.service, this + dependency will show as UpheldBy=a.service in the property listing of + b.service. The UpheldBy= dependency cannot be specified + directly. + + + + + Conflicts= + + A space-separated list of unit names. Configures negative requirement + dependencies. If a unit has a Conflicts= setting on another unit, starting the + former will stop the latter and vice versa. + + Note that this setting does not imply an ordering dependency, similarly to the + Wants= and Requires= dependencies described above. This means + that to ensure that the conflicting unit is stopped before the other unit is started, an + After= or Before= dependency must be declared. It doesn't + matter which of the two ordering dependencies is used, because stop jobs are always ordered before + start jobs, see the discussion in Before=/After= below. + + If unit A that conflicts with unit B is scheduled to + be started at the same time as B, the transaction will either + fail (in case both are required parts of the transaction) or be + modified to be fixed (in case one or both jobs are not a + required part of the transaction). In the latter case, the job + that is not required will be removed, or in case both are + not required, the unit that conflicts will be started and the + unit that is conflicted is stopped. + + + + Before= + After= + + These two settings expect a space-separated list of unit names. They may be specified + more than once, in which case dependencies for all listed names are created. + + Those two settings configure ordering dependencies between units. If unit + foo.service contains the setting and both + units are being started, bar.service's start-up is delayed until + foo.service has finished starting up. After= is the inverse + of Before=, i.e. while Before= ensures that the configured unit + is started before the listed unit begins starting up, After= ensures the opposite, + that the listed unit is fully started up before the configured unit is started. + + When two units with an ordering dependency between them are shut down, the inverse of the + start-up order is applied. I.e. if a unit is configured with After= on another + unit, the former is stopped before the latter if both are shut down. Given two units with any + ordering dependency between them, if one unit is shut down and the other is started up, the shutdown + is ordered before the start-up. It doesn't matter if the ordering dependency is + After= or Before=, in this case. It also doesn't matter which + of the two is shut down, as long as one is shut down and the other is started up; the shutdown is + ordered before the start-up in all cases. If two units have no ordering dependencies between them, + they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit + type when precisely a unit has finished starting up. Most importantly, for service units start-up is + considered completed for the purpose of Before=/After= when all + its configured start-up commands have been invoked and they either failed or reported start-up + success. Note that this does includes ExecStartPost= (or + ExecStopPost= for the shutdown case). + + Note that those settings are independent of and orthogonal to the requirement dependencies as + configured by Requires=, Wants=, Requisite=, + or BindsTo=. It is a common pattern to include a unit name in both the + After= and Wants= options, in which case the unit listed will + be started before the unit that is configured with these options. + + Note that Before= dependencies on device units have no effect and are not + supported. Devices generally become available as a result of an external hotplug event, and systemd + creates the corresponding device unit without delay. + + + + OnFailure= + + A space-separated list of one or more units that are activated when this unit enters + the failed state. + + + + OnSuccess= + + A space-separated list of one or more units that are activated when this unit enters + the inactive state. + + + + PropagatesReloadTo= + ReloadPropagatedFrom= + + A space-separated list of one or more units to which reload requests from this unit + shall be propagated to, or units from which reload requests shall be propagated to this unit, + respectively. Issuing a reload request on a unit will automatically also enqueue reload requests on + all units that are linked to it using these two settings. + + + + PropagatesStopTo= + StopPropagatedFrom= + + A space-separated list of one or more units to which stop requests from this unit + shall be propagated to, or units from which stop requests shall be propagated to this unit, + respectively. Issuing a stop request on a unit will automatically also enqueue stop requests on all + units that are linked to it using these two settings. + + + + JoinsNamespaceOf= + + For units that start processes (such as service units), lists one or more other units + whose network and/or temporary file namespace to join. This only applies to unit types which support + the PrivateNetwork=, NetworkNamespacePath=, + PrivateIPC=, IPCNamespacePath=, and + PrivateTmp= directives (see + systemd.exec5 for + details). If a unit that has this setting set is started, its processes will see the same + /tmp/, /var/tmp/, IPC namespace and network namespace as + one listed unit that is started. If multiple listed units are already started, it is not defined + which namespace is joined. Note that this setting only has an effect if + PrivateNetwork=/NetworkNamespacePath=, + PrivateIPC=/IPCNamespacePath= and/or + PrivateTmp= is enabled for both the unit that joins the namespace and the unit + whose namespace is joined. + + + + RequiresMountsFor= + + Takes a space-separated list of absolute + paths. Automatically adds dependencies of type + Requires= and After= for + all mount units required to access the specified path. + + Mount points marked with are not + mounted automatically through local-fs.target, + but are still honored for the purposes of this option, i.e. they + will be pulled in by this unit. + + + + OnSuccessJobMode= + OnFailureJobMode= + + Takes a value of + fail, + replace, + replace-irreversibly, + isolate, + flush, + ignore-dependencies or + ignore-requirements. Defaults to + replace. Specifies how the units listed in + OnSuccess=/OnFailure= will be enqueued. See + systemctl1's + option for details on the + possible values. If this is set to isolate, + only a single unit may be listed in + OnSuccess=/OnFailure=. + + + + IgnoreOnIsolate= + + Takes a boolean argument. If , this unit will not be stopped + when isolating another unit. Defaults to for service, target, socket, timer, + and path units, and for slice, scope, device, swap, mount, and automount + units. + + + + StopWhenUnneeded= + + Takes a boolean argument. If + , this unit will be stopped when it is no + longer used. Note that, in order to minimize the work to be + executed, systemd will not stop units by default unless they + are conflicting with other units, or the user explicitly + requested their shut down. If this option is set, a unit will + be automatically cleaned up if no other active unit requires + it. Defaults to . + + + + RefuseManualStart= + RefuseManualStop= + + Takes a boolean argument. If + , this unit can only be activated or + deactivated indirectly. In this case, explicit start-up or + termination requested by the user is denied, however if it is + started or stopped as a dependency of another unit, start-up + or termination will succeed. This is mostly a safety feature + to ensure that the user does not accidentally activate units + that are not intended to be activated explicitly, and not + accidentally deactivate units that are not intended to be + deactivated. These options default to + . + + + + AllowIsolate= + + Takes a boolean argument. If + , this unit may be used with the + systemctl isolate command. Otherwise, this + will be refused. It probably is a good idea to leave this + disabled except for target units that shall be used similar to + runlevels in SysV init systems, just as a precaution to avoid + unusable system states. This option defaults to + . + + + + DefaultDependencies= + + Takes a boolean argument. If + , (the default), a few default + dependencies will implicitly be created for the unit. The + actual dependencies created depend on the unit type. For + example, for service units, these dependencies ensure that the + service is started only after basic system initialization is + completed and is properly terminated on system shutdown. See + the respective man pages for details. Generally, only services + involved with early boot or late shutdown should set this + option to . It is highly recommended to + leave this option enabled for the majority of common units. If + set to , this option does not disable + all implicit dependencies, just non-essential + ones. + + + + CollectMode= + + Tweaks the "garbage collection" algorithm for this unit. Takes one of + or . If set to the unit will be unloaded if it is + in the inactive state and is not referenced by clients, jobs or other units — however it + is not unloaded if it is in the failed state. In mode, failed + units are not unloaded until the user invoked systemctl reset-failed on them to reset the + failed state, or an equivalent command. This behaviour is altered if this option is set to + : in this case the unit is unloaded even if the unit is in a + failed state, and thus an explicitly resetting of the failed state is + not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed + resources, …) are flushed out immediately after the unit completed, except for what is stored in the logging + subsystem. Defaults to . + + + + + FailureAction= + SuccessAction= + + Configure the action to take when the unit stops and enters a failed state or inactive state. + Takes one of , , , + , , , + , , and . In system mode, + all options are allowed. In user mode, only , , and + are allowed. Both options default to . + + If is set, no action will be triggered. causes a reboot + following the normal shutdown procedure (i.e. equivalent to systemctl reboot). + causes a forced reboot which will terminate all processes forcibly but should + cause no dirty file systems on reboot (i.e. equivalent to systemctl reboot -f) and + causes immediate execution of the + reboot2 system call, which + might result in data loss (i.e. equivalent to systemctl reboot -ff). Similarly, + , , have the effect + of powering down the system with similar semantics. causes the manager to exit following + the normal shutdown procedure, and causes it terminate without shutting down + services. When or is used by default the exit status of the + main process of the unit (if this applies) is returned from the service manager. However, this may be overridden + with FailureActionExitStatus=/SuccessActionExitStatus=, see + below. + + + + FailureActionExitStatus= + SuccessActionExitStatus= + + Controls the exit status to propagate back to an invoking container manager (in case of a + system service) or service manager (in case of a user manager) when the + FailureAction=/SuccessAction= are set to or + and the action is triggered. By default the exit status of the main process of the + triggering unit (if this applies) is propagated. Takes a value in the range 0…255 or the empty string to + request default behaviour. + + + + JobTimeoutSec= + JobRunningTimeoutSec= + + JobTimeoutSec= specifies a timeout for the whole job that starts + running when the job is queued. JobRunningTimeoutSec= specifies a timeout that + starts running when the queued job is actually started. If either limit is reached, the job will be + cancelled, the unit however will not change state or even enter the failed mode. + + + Both settings take a time span with the default unit of seconds, but other units may be + specified, see + systemd.time5. + The default is infinity (job timeouts disabled), except for device units where + JobRunningTimeoutSec= defaults to DefaultDeviceTimeoutSec=. + + + Note: these timeouts are independent from any unit-specific timeouts (for example, the timeout + set with TimeoutStartSec= in service units). The job timeout has no effect on the + unit itself. Or in other words: unit-specific timeouts are useful to abort unit state changes, and + revert them. The job timeout set with this option however is useful to abort only the job waiting for + the unit state to change. + + + + + JobTimeoutAction= + JobTimeoutRebootArgument= + + JobTimeoutAction= optionally configures an additional action to + take when the timeout is hit, see description of JobTimeoutSec= and + JobRunningTimeoutSec= above. It takes the same values as + StartLimitAction=. Defaults to . + + JobTimeoutRebootArgument= configures an optional reboot string to pass to + the reboot2 system + call. + + + + StartLimitIntervalSec=interval + StartLimitBurst=burst + + Configure unit start rate limiting. Units which are started more than + burst times within an interval time span are + not permitted to start any more. Use StartLimitIntervalSec= to configure the + checking interval and StartLimitBurst= to configure how many starts per interval + are allowed. + + interval is a time span with the default unit of seconds, but other + units may be specified, see + systemd.time5. + Defaults to DefaultStartLimitIntervalSec= in manager configuration file, and may + be set to 0 to disable any kind of rate limiting. burst is a number and + defaults to DefaultStartLimitBurst= in manager configuration file. + + These configuration options are particularly useful in conjunction with the service setting + Restart= (see + systemd.service5); + however, they apply to all kinds of starts (including manual), not just those triggered by the + Restart= logic. + + Note that units which are configured for Restart=, and which reach the start + limit are not attempted to be restarted anymore; however, they may still be restarted manually or + from a timer or socket at a later point, after the interval has passed. + From that point on, the restart logic is activated again. systemctl reset-failed + will cause the restart rate counter for a service to be flushed, which is useful if the administrator + wants to manually start a unit and the start limit interferes with that. Rate-limiting is enforced + after any unit condition checks are executed, and hence unit activations with failing conditions do + not count towards the rate limit. + + When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters + are flushed out too. This means that configuring start rate limiting for a unit that is not + referenced continuously has no effect. + + This setting does not apply to slice, target, device, and scope units, since they are unit + types whose activation may either never fail, or may succeed only a single time. + + + + StartLimitAction= + + Configure an additional action to take if the rate limit configured with + StartLimitIntervalSec= and StartLimitBurst= is hit. Takes the same + values as the FailureAction=/SuccessAction= settings. If + is set, hitting the rate limit will trigger no action except that + the start will not be permitted. Defaults to . + + + + RebootArgument= + Configure the optional argument for the + reboot2 system call if + StartLimitAction= or FailureAction= is a reboot action. This + works just like the optional argument to systemctl reboot command. + + + + SourcePath= + A path to a configuration file this unit has + been generated from. This is primarily useful for + implementation of generator tools that convert configuration + from an external configuration file format into native unit + files. This functionality should not be used in normal + units. + + + + + Conditions and Asserts + + Unit files may also include a number of Condition…= and Assert…= settings. Before the unit is started, systemd will verify that the + specified conditions and asserts are true. If not, the starting of the unit will be (mostly silently) + skipped (in case of conditions), or aborted with an error message (in case of asserts). Failing + conditions or asserts will not result in the unit being moved into the failed + state. The conditions and asserts are checked at the time the queued start job is to be executed. The + ordering dependencies are still respected, so other units are still pulled in and ordered as if this + unit was successfully activated, and the conditions and asserts are executed the precise moment the + unit would normally start and thus can validate system state after the units ordered before completed + initialization. Use condition expressions for skipping units that do not apply to the local system, for + example because the kernel or runtime environment doesn't require their functionality. + + + If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a + logical AND is applied). Condition checks can use a pipe symbol (|) after the equals + sign (Condition…=|…), which causes the condition to become a + triggering condition. If at least one triggering condition is defined for a unit, + then the unit will be started if at least one of the triggering conditions of the unit applies and all + of the regular (i.e. non-triggering) conditions apply. If you prefix an argument with the pipe symbol + and an exclamation mark, the pipe symbol must be passed first, the exclamation second. If any of these + options is assigned the empty string, the list of conditions is reset completely, all previous + condition settings (of any kind) will have no effect. + + The AssertArchitecture=, AssertVirtualization=, … options + are similar to conditions but cause the start job to fail (instead of being skipped). The failed check + is logged. Units with unmet conditions are considered to be in a clean state and will be garbage + collected if they are not referenced. This means that when queried, the condition failure may or may + not show up in the state of the unit. + + Note that neither assertion nor condition expressions result in unit state changes. Also note + that both are checked at the time the job is to be executed, i.e. long after depending jobs and it + itself were queued. Thus, neither condition nor assertion expressions are suitable for conditionalizing + unit dependencies. + + The condition verb of + systemd-analyze1 can + be used to test condition and assert expressions. + + Except for ConditionPathIsSymbolicLink=, all path checks follow symlinks. + + + + ConditionArchitecture= + + Check whether the system is running on a specific architecture. Takes one of + x86, + x86-64, + ppc, + ppc-le, + ppc64, + ppc64-le, + ia64, + parisc, + parisc64, + s390, + s390x, + sparc, + sparc64, + mips, + mips-le, + mips64, + mips64-le, + alpha, + arm, + arm-be, + arm64, + arm64-be, + sh, + sh64, + m68k, + tilegx, + cris, + arc, + arc-be, or + native. + + The architecture is determined from the information returned by + uname2 + and is thus subject to + personality2. + Note that a Personality= setting in the same unit file has no effect on this + condition. A special architecture name native is mapped to the architecture the + system manager itself is compiled for. The test may be negated by prepending an exclamation + mark. + + + + + ConditionFirmware= + + Check whether the system's firmware is of a certain type. The following values are + possible: + + + uefi matches systems with EFI. + + device-tree matches systems with a device tree. + + + device-tree-compatible(value) + matches systems with a device tree that is compatible with value. + + + smbios-field(field + operator value) matches systems + with a SMBIOS field containing a certain value. field is the name of + the SMBIOS field exposed as sysfs attribute file below + /sys/class/dmi/id/. operator is one of + <, <=, >=, + >, ==, <> for version + comparisons, = and != for literal string comparisons, or + $=, !$= for shell-style glob comparisons. + value is the expected value of the SMBIOS field value (possibly + containing shell style globs in case $=/!$= is used). + + + + + + ConditionVirtualization= + + Check whether the system is executed in a virtualized environment and optionally + test whether it is a specific implementation. Takes either boolean value to check if being executed + in any virtualized environment, or one of + vm and + container to test against a generic type of virtualization solution, or one of + qemu, + kvm, + amazon, + zvm, + vmware, + microsoft, + oracle, + powervm, + xen, + bochs, + uml, + bhyve, + qnx, + apple, + sre, + openvz, + lxc, + lxc-libvirt, + systemd-nspawn, + docker, + podman, + rkt, + wsl, + proot, + pouch, + acrn to test + against a specific implementation, or + private-users to check whether we are running in a user namespace. See + systemd-detect-virt1 + for a full list of known virtualization technologies and their identifiers. If multiple + virtualization technologies are nested, only the innermost is considered. The test may be negated + by prepending an exclamation mark. + + + + + ConditionHost= + + ConditionHost= may be used to match against the hostname or + machine ID of the host. This either takes a hostname string (optionally with shell style globs) + which is tested against the locally set hostname as returned by + gethostname2, or + a machine ID formatted as string (see + machine-id5). + The test may be negated by prepending an exclamation mark. + + + + + ConditionKernelCommandLine= + + ConditionKernelCommandLine= may be used to check whether a + specific kernel command line option is set (or if prefixed with the exclamation mark — unset). The + argument must either be a single word, or an assignment (i.e. two words, separated by + =). In the former case the kernel command line is searched for the word + appearing as is, or as left hand side of an assignment. In the latter case, the exact assignment is + looked for with right and left hand side matching. This operates on the kernel command line + communicated to userspace via /proc/cmdline, except when the service manager + is invoked as payload of a container manager, in which case the command line of PID + 1 is used instead (i.e. /proc/1/cmdline). + + + + + ConditionKernelVersion= + + ConditionKernelVersion= may be used to check whether the kernel + version (as reported by uname -r) matches a certain expression, or if prefixed + with the exclamation mark, does not match. The argument must be a list of (potentially quoted) + expressions. Each expression starts with one of = or != for + string comparisons, <, <=, ==, + <>, >=, > for version + comparisons, or $=, !$= for a shell-style glob match. If no + operator is specified, $= is implied. + + Note that using the kernel version string is an unreliable way to determine which features + are supported by a kernel, because of the widespread practice of backporting drivers, features, and + fixes from newer upstream kernels into older versions provided by distributions. Hence, this check + is inherently unportable and should not be used for units which may be used on different + distributions. + + + + + ConditionCredential= + + ConditionCredential= may be used to check whether a credential + by the specified name was passed into the service manager. See System and Service Credentials for details about + credentials. If used in services for the system service manager this may be used to conditionalize + services based on system credentials passed in. If used in services for the per-user service + manager this may be used to conditionalize services based on credentials passed into the + unit@.service service instance belonging to the user. The argument must be a + valid credential name. + + + + ConditionEnvironment= + + ConditionEnvironment= may be used to check whether a specific + environment variable is set (or if prefixed with the exclamation mark — unset) in the service + manager's environment block. + + The argument may be a single word, to check if the variable with this name is defined in the + environment block, or an assignment + (name=value), to check if + the variable with this exact value is defined. Note that the environment block of the service + manager itself is checked, i.e. not any variables defined with Environment= or + EnvironmentFile=, as described above. This is particularly useful when the + service manager runs inside a containerized environment or as per-user service manager, in order to + check for variables passed in by the enclosing container manager or PAM. + + + + + ConditionSecurity= + + ConditionSecurity= may be used to check whether the given + security technology is enabled on the system. Currently, the recognized values are + selinux, apparmor, tomoyo, + ima, smack, audit, + uefi-secureboot and tpm2. The test may be negated by prepending + an exclamation mark. + + + + + ConditionCapability= + + Check whether the given capability exists in the capability bounding set of the + service manager (i.e. this does not check whether capability is actually available in the permitted + or effective sets, see + capabilities7 + for details). Pass a capability name such as CAP_MKNOD, possibly prefixed with + an exclamation mark to negate the check. + + + + + ConditionACPower= + + Check whether the system has AC power, or is exclusively battery powered at the + time of activation of the unit. This takes a boolean argument. If set to true, + the condition will hold only if at least one AC connector of the system is connected to a power + source, or if no AC connectors are known. Conversely, if set to false, the + condition will hold only if there is at least one AC connector known and all AC connectors are + disconnected from a power source. + + + + + ConditionNeedsUpdate= + + Takes one of /var/ or /etc/ as argument, + possibly prefixed with a ! (to invert the condition). This condition may be + used to conditionalize units on whether the specified directory requires an update because + /usr/'s modification time is newer than the stamp file + .updated in the specified directory. This is useful to implement offline + updates of the vendor operating system resources in /usr/ that require updating + of /etc/ or /var/ on the next following boot. Units making + use of this condition should order themselves before + systemd-update-done.service8, + to make sure they run before the stamp file's modification time gets reset indicating a completed + update. + + If the systemd.condition-needs-update= option is specified on the kernel + command line (taking a boolean), it will override the result of this condition check, taking + precedence over any file modification time checks. If the kernel command line option is used, + systemd-update-done.service will not have immediate effect on any following + ConditionNeedsUpdate= checks, until the system is rebooted where the kernel + command line option is not specified anymore. + + Note that to make this scheme effective, the timestamp of /usr/ should + be explicitly updated after its contents are modified. The kernel will automatically update + modification timestamp on a directory only when immediate children of a directory are modified; an + modification of nested files will not automatically result in mtime of /usr/ + being updated. + + Also note that if the update method includes a call to execute appropriate post-update steps + itself, it should not touch the timestamp of /usr/. In a typical distribution + packaging scheme, packages will do any required update steps as part of the installation or + upgrade, to make package contents immediately usable. ConditionNeedsUpdate= + should be used with other update mechanisms where such an immediate update does not + happen. + + + + ConditionFirstBoot= + + Takes a boolean argument. This condition may be used to conditionalize units on + whether the system is booting up for the first time. This roughly means that /etc/ + was unpopulated when the system started booting (for details, see "First Boot Semantics" in + machine-id5). + First boot is considered finished (this condition will evaluate as false) after the manager + has finished the startup phase. + + This condition may be used to populate /etc/ on the first boot after + factory reset, or when a new system instance boots up for the first time. + + For robustness, units with ConditionFirstBoot=yes should order themselves + before first-boot-complete.target and pull in this passive target with + Wants=. This ensures that in a case of an aborted first boot, these units will + be re-run during the next system startup. + + If the systemd.condition-first-boot= option is specified on the kernel + command line (taking a boolean), it will override the result of this condition check, taking + precedence over /etc/machine-id existence checks. + + + + + ConditionPathExists= + + Check for the existence of a file. If the specified absolute path name does not exist, + the condition will fail. If the absolute path name passed to + ConditionPathExists= is prefixed with an exclamation mark + (!), the test is negated, and the unit is only started if the path does not + exist. + + + + + ConditionPathExistsGlob= + + ConditionPathExistsGlob= is similar to + ConditionPathExists=, but checks for the existence of at least one file or + directory matching the specified globbing pattern. + + + + + ConditionPathIsDirectory= + + ConditionPathIsDirectory= is similar to + ConditionPathExists= but verifies that a certain path exists and is a + directory. + + + + + ConditionPathIsSymbolicLink= + + ConditionPathIsSymbolicLink= is similar to + ConditionPathExists= but verifies that a certain path exists and is a symbolic + link. + + + + + ConditionPathIsMountPoint= + + ConditionPathIsMountPoint= is similar to + ConditionPathExists= but verifies that a certain path exists and is a mount + point. + + + + + ConditionPathIsReadWrite= + + ConditionPathIsReadWrite= is similar to + ConditionPathExists= but verifies that the underlying file system is readable + and writable (i.e. not mounted read-only). + + + + + ConditionPathIsEncrypted= + + ConditionPathIsEncrypted= is similar to + ConditionPathExists= but verifies that the underlying file system's backing + block device is encrypted using dm-crypt/LUKS. Note that this check does not cover ext4 + per-directory encryption, and only detects block level encryption. Moreover, if the specified path + resides on a file system on top of a loopback block device, only encryption above the loopback device is + detected. It is not detected whether the file system backing the loopback block device is encrypted. + + + + + ConditionDirectoryNotEmpty= + + ConditionDirectoryNotEmpty= is similar to + ConditionPathExists= but verifies that a certain path exists and is a non-empty + directory. + + + + + ConditionFileNotEmpty= + + ConditionFileNotEmpty= is similar to + ConditionPathExists= but verifies that a certain path exists and refers to a + regular file with a non-zero size. + + + + + ConditionFileIsExecutable= + + ConditionFileIsExecutable= is similar to + ConditionPathExists= but verifies that a certain path exists, is a regular file, + and marked executable. + + + + + ConditionUser= + + ConditionUser= takes a numeric UID, a UNIX + user name, or the special value @system. This condition may be used to check + whether the service manager is running as the given user. The special value + @system can be used to check if the user id is within the system user + range. This option is not useful for system services, as the system manager exclusively runs as the + root user, and thus the test result is constant. + + + + + ConditionGroup= + + ConditionGroup= is similar to ConditionUser= + but verifies that the service manager's real or effective group, or any of its auxiliary groups, + match the specified group or GID. This setting does not support the special value + @system. + + + + + ConditionControlGroupController= + + Check whether given cgroup controllers (e.g. cpu) are available + for use on the system or whether the legacy v1 cgroup or the modern v2 cgroup hierarchy is used. + + + Multiple controllers may be passed with a space separating them; in this case the condition + will only pass if all listed controllers are available for use. Controllers unknown to systemd are + ignored. Valid controllers are cpu, io, + memory, and pids. Even if available in the kernel, a + particular controller may not be available if it was disabled on the kernel command line with + cgroup_disable=controller. + + Alternatively, two special strings v1 and v2 may be + specified (without any controller names). v2 will pass if the unified v2 cgroup + hierarchy is used, and v1 will pass if the legacy v1 hierarchy or the hybrid + hierarchy are used. Note that legacy or hybrid hierarchies have been deprecated. See + systemd1 for + more information. + + + + + ConditionMemory= + + Verify that the specified amount of system memory is available to the current + system. Takes a memory size in bytes as argument, optionally prefixed with a comparison operator + <, <=, = (or ==), + != (or <>), >=, + >. On bare-metal systems compares the amount of physical memory in the system + with the specified size, adhering to the specified comparison operator. In containers compares the + amount of memory assigned to the container instead. + + + + + ConditionCPUs= + + Verify that the specified number of CPUs is available to the current system. Takes + a number of CPUs as argument, optionally prefixed with a comparison operator + <, <=, = (or ==), + != (or <>), >=, + >. Compares the number of CPUs in the CPU affinity mask configured of the + service manager itself with the specified number, adhering to the specified comparison operator. On + physical systems the number of CPUs in the affinity mask of the service manager usually matches the + number of physical CPUs, but in special and virtual environments might differ. In particular, in + containers the affinity mask usually matches the number of CPUs assigned to the container and not + the physically available ones. + + + + ConditionCPUFeature= + + Verify that a given CPU feature is available via the CPUID + instruction. This condition only does something on i386 and x86-64 processors. On other + processors it is assumed that the CPU does not support the given feature. It checks the leaves + 1, 7, 0x80000001, and + 0x80000007. Valid values are: + fpu, + vme, + de, + pse, + tsc, + msr, + pae, + mce, + cx8, + apic, + sep, + mtrr, + pge, + mca, + cmov, + pat, + pse36, + clflush, + mmx, + fxsr, + sse, + sse2, + ht, + pni, + pclmul, + monitor, + ssse3, + fma3, + cx16, + sse4_1, + sse4_2, + movbe, + popcnt, + aes, + xsave, + osxsave, + avx, + f16c, + rdrand, + bmi1, + avx2, + bmi2, + rdseed, + adx, + sha_ni, + syscall, + rdtscp, + lm, + lahf_lm, + abm, + constant_tsc. + + + + + ConditionOSRelease= + + Verify that a specific key=value pair is set in the host's + os-release5. + + Other than exact string matching (with = and !=), + relative comparisons are supported for versioned parameters (e.g. VERSION_ID; + with <, <=, ==, + <>, >=, >), and shell-style + wildcard comparisons (*, ?, []) are + supported with the $= (match) and !$= (non-match). + + + + + ConditionMemoryPressure= + ConditionCPUPressure= + ConditionIOPressure= + + Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold. + This setting takes a threshold value as argument. It can be specified as a simple percentage value, + suffixed with %, in which case the pressure will be measured as an average over the last + five minutes before the attempt to start the unit is performed. + Alternatively, the average timespan can also be specified using / as a separator, for + example: 10%/1min. The supported timespans match what the kernel provides, and are + limited to 10sec, 1min and 5min. The + full PSI will be checked first, and if not found some will be + checked. For more details, see the documentation on PSI (Pressure Stall Information) + . + + Optionally, the threshold value can be prefixed with the slice unit under which the pressure will be checked, + followed by a :. If the slice unit is not specified, the overall system pressure will be measured, + instead of a particular cgroup's. + + + + + AssertArchitecture= + AssertVirtualization= + AssertHost= + AssertKernelCommandLine= + AssertKernelVersion= + AssertCredential= + AssertEnvironment= + AssertSecurity= + AssertCapability= + AssertACPower= + AssertNeedsUpdate= + AssertFirstBoot= + AssertPathExists= + AssertPathExistsGlob= + AssertPathIsDirectory= + AssertPathIsSymbolicLink= + AssertPathIsMountPoint= + AssertPathIsReadWrite= + AssertPathIsEncrypted= + AssertDirectoryNotEmpty= + AssertFileNotEmpty= + AssertFileIsExecutable= + AssertUser= + AssertGroup= + AssertControlGroupController= + AssertMemory= + AssertCPUs= + AssertCPUFeature= + AssertOSRelease= + AssertMemoryPressure= + AssertCPUPressure= + AssertIOPressure= + + Similar to the ConditionArchitecture=, + ConditionVirtualization=, …, condition settings described above, these settings + add assertion checks to the start-up of the unit. However, unlike the conditions settings, any + assertion setting that is not met results in failure of the start job (which means this is logged + loudly). Note that hitting a configured assertion does not cause the unit to enter the + failed state (or in fact result in any state change of the unit), it affects + only the job queued for it. Use assertion expressions for units that cannot operate when specific + requirements are not met, and when this is something the administrator or user should look + into. + + + + + + + + Mapping of unit properties to their inverses + + Unit settings that create a relationship with a second unit usually show up + in properties of both units, for example in systemctl show + output. In some cases the name of the property is the same as the name of the + configuration setting, but not always. This table lists the properties + that are shown on two units which are connected through some dependency, and shows + which property on "source" unit corresponds to which property on the "target" unit. + + + + + "Forward" and "reverse" unit properties + + + + + + + + + + "Forward" property + "Reverse" property + Where used + + + + + Before= + After= + [Unit] section + + + After= + Before= + + + Requires= + RequiredBy= + [Unit] section + [Install] section + + + Wants= + WantedBy= + [Unit] section + [Install] section + + + PartOf= + ConsistsOf= + [Unit] section + an automatic property + + + BindsTo= + BoundBy= + [Unit] section + an automatic property + + + Requisite= + RequisiteOf= + [Unit] section + an automatic property + + + Conflicts= + ConflictedBy= + [Unit] section + an automatic property + + + Triggers= + TriggeredBy= + Automatic properties, see notes below + + + PropagatesReloadTo= + ReloadPropagatedFrom= + [Unit] section + + + ReloadPropagatedFrom= + PropagatesReloadTo= + + + PropagatesStopTo= + StopPropagatedFrom= + [Unit] section + + + StopPropagatedFrom= + PropagatesStopTo= + + + Following= + n/a + An automatic property + + + +
+ + Note: WantedBy= and RequiredBy= are + used in the [Install] section to create symlinks in .wants/ + and .requires/ directories. They cannot be used directly as a + unit configuration setting. + + Note: ConsistsOf=, BoundBy=, + RequisiteOf=, ConflictedBy= are created + implicitly along with their reverses and cannot be specified directly. + + Note: Triggers= is created implicitly between a socket, + path unit, or an automount unit, and the unit they activate. By default a unit + with the same name is triggered, but this can be overridden using + Sockets=, Service=, and Unit= + settings. See + systemd.service5, + systemd.socket5, + systemd.path5, + and + systemd.automount5 + for details. TriggeredBy= is created implicitly on the + triggered unit. + + Note: Following= is used to group device aliases and points to the + "primary" device unit that systemd is using to track device state, usually corresponding to a + sysfs path. It does not show up in the "target" unit. + + + + [Install] Section Options + + Unit files may include an [Install] section, which carries installation information for + the unit. This section is not interpreted by + systemd1 during runtime; it is + used by the enable and disable commands of the + systemctl1 tool during + installation of a unit. + + + + Alias= + + A space-separated list of additional names this unit shall be installed under. The names listed + here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once, + in which case all listed names are used. At installation time, systemctl enable will create + symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this + setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support + aliasing. + + + + WantedBy= + RequiredBy= + + This option may be used more than once, or a space-separated list of unit names may + be given. A symbolic link is created in the .wants/ or + .requires/ directory of each of the listed units when this unit is installed by + systemctl enable. This has the effect of a dependency of type + Wants= or Requires= being added from the listed unit to the + current unit. The primary result is that the current unit will be started when the listed unit is + started, see the description of Wants= and Requires= in the + [Unit] section for details. + + In case of template units listing non template units, the listing unit must have + DefaultInstance= set, or systemctl enable must be called with + an instance name. The instance (default or specified) will be added to the + .wants/ or .requires/ list of the listed unit. For example, + WantedBy=getty.target in a service getty@.service will result + in systemctl enable getty@tty2.service creating a + getty.target.wants/getty@tty2.service link to + getty@.service. This also applies to listing specific instances of templated + units: this specific instance will gain the dependency. A template unit may also list a template + unit, in which case a generic dependency will be added where each instance of the listing unit will + have a dependency on an instance of the listed template with the same instance value. For example, + WantedBy=container@.target in a service monitor@.service will + result in systemctl enable monitor@.service creating a + container@.target.wants/monitor@.service link to + monitor@.service, which applies to all instances of + container@.target. + + + + Also= + + Additional units to install/deinstall when + this unit is installed/deinstalled. If the user requests + installation/deinstallation of a unit with this option + configured, systemctl enable and + systemctl disable will automatically + install/uninstall units listed in this option as well. + + This option may be used more than once, or a + space-separated list of unit names may be + given. + + + + DefaultInstance= + + In template unit files, this specifies for + which instance the unit shall be enabled if the template is + enabled without any explicitly set instance. This option has + no effect in non-template unit files. The specified string + must be usable as instance identifier. + + + + The following specifiers are interpreted in the Install section: + %a, %b, %B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %%. + For their meaning see the next section. + + + + Specifiers + + Many settings resolve specifiers which may be used to write + generic unit files referring to runtime or unit parameters that + are replaced when the unit files are loaded. Specifiers must be known + and resolvable for the setting to be valid. The following + specifiers are understood: + + + Specifiers available in unit files + + + + + + + Specifier + Meaning + Details + + + + + + %a + Architecture + A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= above for a full list. + + + + + + %C + Cache directory root + This is either /var/cache (for the system manager) or the path $XDG_CACHE_HOME resolves to (for user managers). + + + %d + Credentials directory + This is the value of the $CREDENTIALS_DIRECTORY environment variable if available. See section "Credentials" in systemd.exec5 for more information. + + + %E + Configuration directory root + This is either /etc/ (for the system manager) or the path $XDG_CONFIG_HOME resolves to (for user managers). + + + %f + Unescaped filename + This is either the unescaped instance name (if applicable) with / prepended (if applicable), or the unescaped prefix name prepended with /. This implements unescaping according to the rules for escaping absolute file system paths discussed above. + + + %g + User group + This is the name of the group running the service manager instance. In case of the system manager this resolves to root. + + + %G + User GID + This is the numeric GID of the user running the service manager instance. In case of the system manager this resolves to 0. + + + %h + User home directory + This is the home directory of the user running the service manager instance. In case of the system manager this resolves to /root. + +Note that this setting is not influenced by the User= setting configurable in the [Service] section of the service unit. + + + + %H + Host name + The hostname of the running system at the point in time the unit configuration is loaded. + + + %i + Instance name + For instantiated units this is the string between the first @ character and the type suffix. Empty for non-instantiated units. + + + %I + Unescaped instance name + Same as %i, but with escaping undone. + + + %j + Final component of the prefix + This is the string between the last - and the end of the prefix name. If there is no -, this is the same as %p. + + + %J + Unescaped final component of the prefix + Same as %j, but with escaping undone. + + + %l + + Short host name + The hostname of the running system at the point in time the unit configuration is loaded, truncated at the first dot to remove any domain component. + + + %L + Log directory root + This is either /var/log (for the system manager) or the path $XDG_CONFIG_HOME resolves to with /log appended (for user managers). + + + + + %n + Full unit name + + + + %N + Full unit name + Same as %n, but with the type suffix removed. + + + + %p + Prefix name + For instantiated units, this refers to the string before the first @ character of the unit name. For non-instantiated units, same as %N. + + + %P + Unescaped prefix name + Same as %p, but with escaping undone. + + + + %q + Pretty host name + The pretty hostname of the running system at the point in time the unit configuration is loaded, as read from the PRETTY_HOSTNAME= field of /etc/machine-info. If not set, resolves to the short hostname. See machine-info5 for more information. + + + %s + User shell + This is the shell of the user running the service manager instance. + + + %S + State directory root + This is either /var/lib (for the system manager) or the path $XDG_CONFIG_HOME resolves to (for user managers). + + + %t + Runtime directory root + This is either /run/ (for the system manager) or the path $XDG_RUNTIME_DIR resolves to (for user managers). + + + + %u + User name + This is the name of the user running the service manager instance. In case of the system manager this resolves to root. + +Note that this setting is not influenced by the User= setting configurable in the [Service] section of the service unit. + + + %U + User UID + This is the numeric UID of the user running the service manager instance. In case of the system manager this resolves to 0. + +Note that this setting is not influenced by the User= setting configurable in the [Service] section of the service unit. + + + + + + + %y + The path to the fragment + This is the path where the main part of the unit file is located. For linked unit files, the real path outside of the unit search directories is used. For units that don't have a fragment file, this specifier will raise an error. + + + %Y + The directory of the fragment + This is the directory part of %y. + + + + +
+ + + + Examples + + + Allowing units to be enabled + + The following snippet (highlighted) allows a unit (e.g. + foo.service) to be enabled via + systemctl enable: + + [Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +[Install] +WantedBy=multi-user.target + + After running systemctl enable, a + symlink + /etc/systemd/system/multi-user.target.wants/foo.service + linking to the actual unit will be created. It tells systemd to + pull in the unit when starting + multi-user.target. The inverse + systemctl disable will remove that symlink + again. + + + + Overriding vendor settings + + There are two methods of overriding vendor settings in + unit files: copying the unit file from + /usr/lib/systemd/system to + /etc/systemd/system and modifying the + chosen settings. Alternatively, one can create a directory named + unit.d/ within + /etc/systemd/system and place a drop-in + file name.conf + there that only changes the specific settings one is interested + in. Note that multiple such drop-in files are read if + present, processed in lexicographic order of their filename. + + The advantage of the first method is that one easily + overrides the complete unit, the vendor unit is not parsed at + all anymore. It has the disadvantage that improvements to the + unit file by the vendor are not automatically incorporated on + updates. + + The advantage of the second method is that one only + overrides the settings one specifically wants, where updates to + the unit by the vendor automatically apply. This has the + disadvantage that some future updates by the vendor might be + incompatible with the local changes. + + This also applies for user instances of systemd, but with + different locations for the unit files. See the section on unit + load paths for further details. + + Suppose there is a vendor-supplied unit + /usr/lib/systemd/system/httpd.service with + the following contents: + + [Unit] +Description=Some HTTP server +After=remote-fs.target sqldb.service +Requires=sqldb.service +AssertPathExists=/srv/webserver + +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +Nice=5 + +[Install] +WantedBy=multi-user.target + + Now one wants to change some settings as an administrator: + firstly, in the local setup, /srv/webserver + might not exist, because the HTTP server is configured to use + /srv/www instead. Secondly, the local + configuration makes the HTTP server also depend on a memory + cache service, memcached.service, that + should be pulled in (Requires=) and also be + ordered appropriately (After=). Thirdly, in + order to harden the service a bit more, the administrator would + like to set the PrivateTmp= setting (see + systemd.exec5 + for details). And lastly, the administrator would like to reset + the niceness of the service to its default value of 0. + + The first possibility is to copy the unit file to + /etc/systemd/system/httpd.service and + change the chosen settings: + + [Unit] +Description=Some HTTP server +After=remote-fs.target sqldb.service memcached.service +Requires=sqldb.service memcached.service +AssertPathExists=/srv/www + +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +Nice=0 +PrivateTmp=yes + +[Install] +WantedBy=multi-user.target + + Alternatively, the administrator could create a drop-in + file + /etc/systemd/system/httpd.service.d/local.conf + with the following contents: + + [Unit] +After=memcached.service +Requires=memcached.service +# Reset all assertions and then re-add the condition we want +AssertPathExists= +AssertPathExists=/srv/www + +[Service] +Nice=0 +PrivateTmp=yes + + Note that for drop-in files, if one wants to remove + entries from a setting that is parsed as a list (and is not a + dependency), such as AssertPathExists= (or + e.g. ExecStart= in service units), one needs + to first clear the list before re-adding all entries except the + one that is to be removed. Dependencies (After=, etc.) + cannot be reset to an empty list, so dependencies can only be + added in drop-ins. If you want to remove dependencies, you have + to override the entire unit. + + + + + Top level drop-ins with template units + + Top level per-type drop-ins can be used to change some aspect of + all units of a particular type. For example by creating the + /etc/systemd/system/service.d/ + directory with a drop-in file, the contents of the drop-in file can be + applied to all service units. We can take this further by having the + top-level drop-in instantiate a secondary helper unit. Consider for + example the following set of units and drop-in files where we install + an OnFailure= dependency for all service units. + + + /etc/systemd/system/failure-handler@.service: + + [Unit] +Description=My failure handler for %i + +[Service] +Type=oneshot +# Perform some special action for when %i exits unexpectedly. +ExecStart=/usr/sbin/myfailurehandler %i + + + We can then add an instance of + failure-handler@.service as an + OnFailure= dependency for all service units. + + + /etc/systemd/system/service.d/10-all.conf: + + [Unit] +OnFailure=failure-handler@%N.service + + + Now, after running systemctl daemon-reload all + services will have acquired an OnFailure= dependency on + failure-handler@%N.service. The + template instance units will also have gained the dependency which results + in the creation of a recursive dependency chain. systemd will try to detect + these recursive dependency chains where a template unit directly and + recursively depends on itself and will remove such dependencies + automatically if it finds them. If systemd doesn't detect the recursive + dependency chain, we can break the chain ourselves by disabling the drop-in + for the template instance units via a symlink to + /dev/null: + + +mkdir /etc/systemd/system/failure-handler@.service.d/ +ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf +systemctl daemon-reload + + + This ensures that if a failure-handler@.service instance fails it will not trigger an instance named + failure-handler@failure-handler.service. + + + + + + + See Also + + systemd1, + systemctl1, + systemd-system.conf5, + systemd.special7, + systemd.service5, + systemd.socket5, + systemd.device5, + systemd.mount5, + systemd.automount5, + systemd.swap5, + systemd.target5, + systemd.path5, + systemd.timer5, + systemd.scope5, + systemd.slice5, + systemd.time7, + systemd-analyze1, + capabilities7, + systemd.directives7, + uname1 + + + + diff --git a/man/systemd.xml b/man/systemd.xml new file mode 100644 index 0000000..d292ceb --- /dev/null +++ b/man/systemd.xml @@ -0,0 +1,1289 @@ + + + + + + + + systemd + systemd + + + + systemd + 1 + + + + systemd + init + systemd system and service manager + + + + + /usr/lib/systemd/systemd + OPTIONS + + + init + OPTIONS + COMMAND + + + + + Description + + systemd is a system and service manager for Linux operating systems. When run as first process on + boot (as PID 1), it acts as init system that brings up and maintains userspace services. Separate + instances are started for logged-in users to start their services. + + systemd is usually not invoked directly by the user, but is installed as the + /sbin/init symlink and started during early boot. The user manager instances are + started automatically through the + user@.service5 + service. + + For compatibility with SysV, if the binary is called as init and is not the + first process on the machine (PID is not 1), it will execute telinit and pass all + command line arguments unmodified. That means init and telinit are + mostly equivalent when invoked from normal login sessions. See + telinit8 for more + information. + + When run as a system instance, systemd interprets the + configuration file system.conf and the files + in system.conf.d directories; when run as a + user instance, systemd interprets the configuration file + user.conf and the files in + user.conf.d directories. See + systemd-system.conf5 + for more information. + + + + Concepts + + systemd provides a dependency system between various + entities called "units" of 11 different types. Units encapsulate + various objects that are relevant for system boot-up and + maintenance. The majority of units are configured in unit + configuration files, whose syntax and basic set of options is + described in + systemd.unit5, + however some are created automatically from other configuration + files, dynamically from system state or programmatically at runtime. + Units may be "active" (meaning started, bound, plugged in, …, + depending on the unit type, see below), or "inactive" (meaning + stopped, unbound, unplugged, …), as well as in the process of + being activated or deactivated, i.e. between the two states (these + states are called "activating", "deactivating"). A special + "failed" state is available as well, which is very similar to + "inactive" and is entered when the service failed in some way + (process returned error code on exit, or crashed, an operation + timed out, or after too many restarts). If this state is entered, + the cause will be logged, for later reference. Note that the + various unit types may have a number of additional substates, + which are mapped to the five generalized unit states described + here. + + The following unit types are available: + + + Service units, which start and control daemons + and the processes they consist of. For details, see + systemd.service5. + + Socket units, which encapsulate local IPC or + network sockets in the system, useful for socket-based + activation. For details about socket units, see + systemd.socket5, + for details on socket-based activation and other forms of + activation, see + daemon7. + + Target units are useful to group units, or + provide well-known synchronization points during boot-up, see + systemd.target5. + + Device units expose kernel devices in systemd + and may be used to implement device-based activation. For + details, see + systemd.device5. + + Mount units control mount points in the file + system, for details see + systemd.mount5. + + Automount units provide automount capabilities, + for on-demand mounting of file systems as well as parallelized + boot-up. See + systemd.automount5. + + Timer units are useful for triggering activation + of other units based on timers. You may find details in + systemd.timer5. + + Swap units are very similar to mount units and + encapsulate memory swap partitions or files of the operating + system. They are described in + systemd.swap5. + + Path units may be used to activate other + services when file system objects change or are modified. See + systemd.path5. + + Slice units may be used to group units which + manage system processes (such as service and scope units) in a + hierarchical tree for resource management purposes. See + systemd.slice5. + + Scope units are similar to service units, but + manage foreign processes instead of starting them as well. See + systemd.scope5. + + + + Units are named as their configuration files. Some units + have special semantics. A detailed list is available in + systemd.special7. + + systemd knows various kinds of dependencies, including + positive and negative requirement dependencies (i.e. + Requires= and Conflicts=) as + well as ordering dependencies (After= and + Before=). NB: ordering and requirement + dependencies are orthogonal. If only a requirement dependency + exists between two units (e.g. foo.service + requires bar.service), but no ordering + dependency (e.g. foo.service after + bar.service) and both are requested to start, + they will be started in parallel. It is a common pattern that both + requirement and ordering dependencies are placed between two + units. Also note that the majority of dependencies are implicitly + created and maintained by systemd. In most cases, it should be + unnecessary to declare additional dependencies manually, however + it is possible to do this. + + Application programs and units (via dependencies) may + request state changes of units. In systemd, these requests are + encapsulated as 'jobs' and maintained in a job queue. Jobs may + succeed or can fail, their execution is ordered based on the + ordering dependencies of the units they have been scheduled + for. + + On boot systemd activates the target unit + default.target whose job is to activate + on-boot services and other on-boot units by pulling them in via + dependencies. Usually, the unit name is just an alias (symlink) for + either graphical.target (for fully-featured + boots into the UI) or multi-user.target (for + limited console-only boots for use in embedded or server + environments, or similar; a subset of graphical.target). However, + it is at the discretion of the administrator to configure it as an + alias to any other target unit. See + systemd.special7 + for details about these target units. + + On first boot, systemd will enable or disable units according to preset policy. + See systemd.preset5 + and "First Boot Semantics" in + machine-id5. + + systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are + kept loaded into memory are those for which at least one of the following conditions is true: + + + It is in an active, activating, deactivating or failed state (i.e. in any unit state except for inactive) + It has a job queued for it + It is a dependency of at least one other unit that is loaded into memory + It has some form of resource still allocated (e.g. a service unit that is inactive but for which + a process is still lingering that ignored the request to be terminated) + It has been pinned into memory programmatically by a D-Bus call + + + systemd will automatically and implicitly load units from disk — if they are not loaded yet — as soon as + operations are requested for them. Thus, in many respects, the fact whether a unit is loaded or not is invisible to + clients. Use systemctl list-units --all to comprehensively list all units currently loaded. Any + unit for which none of the conditions above applies is promptly unloaded. Note that when a unit is unloaded from + memory its accounting data is flushed out too. However, this data is generally not lost, as a journal log record + is generated declaring the consumed resources whenever a unit shuts down. + + Processes systemd spawns are placed in individual Linux control groups named after the unit which + they belong to in the private systemd hierarchy. (see Control Groups v2 for more information + about control groups, or short "cgroups"). systemd uses this to effectively keep track of + processes. Control group information is maintained in the kernel, and is accessible via the file system + hierarchy (beneath /sys/fs/cgroup/), or in tools such as systemd-cgls1 or + ps1 (ps + xawf -eo pid,user,cgroup,args is particularly useful to list all processes and the systemd + units they belong to.). + + systemd is compatible with the SysV init system to a large + degree: SysV init scripts are supported and simply read as an + alternative (though limited) configuration file format. The SysV + /dev/initctl interface is provided, and + compatibility implementations of the various SysV client tools are + available. In addition to that, various established Unix + functionality such as /etc/fstab or the + utmp database are supported. + + systemd has a minimal transaction system: if a unit is + requested to start up or shut down it will add it and all its + dependencies to a temporary transaction. Then, it will verify if + the transaction is consistent (i.e. whether the ordering of all + units is cycle-free). If it is not, systemd will try to fix it up, + and removes non-essential jobs from the transaction that might + remove the loop. Also, systemd tries to suppress non-essential + jobs in the transaction that would stop a running service. Finally + it is checked whether the jobs of the transaction contradict jobs + that have already been queued, and optionally the transaction is + aborted then. If all worked out and the transaction is consistent + and minimized in its impact it is merged with all already + outstanding jobs and added to the run queue. Effectively this + means that before executing a requested operation, systemd will + verify that it makes sense, fixing it if possible, and only + failing if it really cannot work. + + Note that transactions are generated independently of a unit's + state at runtime, hence, for example, if a start job is requested on an + already started unit, it will still generate a transaction and wake up any + inactive dependencies (and cause propagation of other jobs as per the + defined relationships). This is because the enqueued job is at the time of + execution compared to the target unit's state and is marked successful and + complete when both satisfy. However, this job also pulls in other + dependencies due to the defined relationships and thus leads to, in our + example, start jobs for any of those inactive units getting queued as + well. + + systemd contains native implementations of various tasks + that need to be executed as part of the boot process. For example, + it sets the hostname or configures the loopback network device. It + also sets up and mounts various API file systems, such as + /sys/ or /proc/. + + For more information about the concepts and + ideas behind systemd, please refer to the + Original Design Document. + + Note that some but not all interfaces provided by systemd are covered by the + Interface Portability and Stability Promise. + + Units may be generated dynamically at boot and system + manager reload time, for example based on other configuration + files or parameters passed on the kernel command line. For details, see + systemd.generator7. + + The D-Bus API of systemd is described in + org.freedesktop.systemd15 + and + org.freedesktop.LogControl15. + + + Systems which invoke systemd in a container or initrd environment should implement the Container Interface or + initrd Interface + specifications, respectively. + + + + Directories + + + + System unit directories + + The systemd system manager reads unit + configuration from various directories. Packages that want to + install unit files shall place them in the directory returned + by pkg-config systemd + --variable=systemdsystemunitdir. Other directories + checked are /usr/local/lib/systemd/system + and /usr/lib/systemd/system. User + configuration always takes precedence. pkg-config + systemd --variable=systemdsystemconfdir returns the + path of the system configuration directory. Packages should + alter the content of these directories only with the + enable and disable + commands of the + systemctl1 + tool. Full list of directories is provided in + systemd.unit5. + + + + + + + User unit directories + + Similar rules apply for the user unit + directories. However, here the + XDG + Base Directory specification is followed to find + units. Applications should place their unit files in the + directory returned by pkg-config systemd + --variable=systemduserunitdir. Global configuration + is done in the directory reported by pkg-config + systemd --variable=systemduserconfdir. The + enable and disable + commands of the + systemctl1 + tool can handle both global (i.e. for all users) and private + (for one user) enabling/disabling of units. Full list of + directories is provided in + systemd.unit5. + + + + + + + SysV init scripts directory + + The location of the SysV init script directory + varies between distributions. If systemd cannot find a native + unit file for a requested service, it will look for a SysV + init script of the same name (with the + .service suffix + removed). + + + + + + SysV runlevel link farm directory + + The location of the SysV runlevel link farm + directory varies between distributions. systemd will take the + link farm into account when figuring out whether a service + shall be enabled. Note that a service unit with a native unit + configuration file cannot be started by activating it in the + SysV runlevel link farm. + + + + + + Signals + + + + SIGTERM + + Upon receiving this signal the systemd system + manager serializes its state, reexecutes itself and + deserializes the saved state again. This is mostly equivalent + to systemctl daemon-reexec. + + systemd user managers will start the + exit.target unit when this signal is + received. This is mostly equivalent to systemctl + --user start exit.target + --job-mode=replace-irreversibly. + + + + SIGINT + + Upon receiving this signal the systemd system manager will start the + ctrl-alt-del.target unit. This is mostly equivalent to + systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly. If + this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note + that pressing + CtrlAltDel on the + console will trigger this signal. Hence, if a reboot is hanging, pressing + CtrlAltDel more than + 7 times in 2 seconds is a relatively safe way to trigger an immediate reboot. + + systemd user managers treat this signal the same way as + SIGTERM. + + + + SIGWINCH + + When this signal is received the systemd + system manager will start the + kbrequest.target unit. This is mostly + equivalent to systemctl start + kbrequest.target. + + This signal is ignored by systemd user + managers. + + + + SIGPWR + + When this signal is received the systemd + manager will start the sigpwr.target + unit. This is mostly equivalent to systemctl start + sigpwr.target. + + + + SIGUSR1 + + When this signal is received the systemd + manager will try to reconnect to the D-Bus + bus. + + + + SIGUSR2 + + When this signal is received the systemd + manager will log its complete state in human-readable form. + The data logged is the same as printed by + systemd-analyze dump. + + + + SIGHUP + + Reloads the complete daemon configuration. + This is mostly equivalent to systemctl + daemon-reload. + + + + SIGRTMIN+0 + + Enters default mode, starts the + default.target unit. This is mostly + equivalent to systemctl isolate + default.target. + + + + SIGRTMIN+1 + + Enters rescue mode, starts the + rescue.target unit. This is mostly + equivalent to systemctl isolate + rescue.target. + + + + SIGRTMIN+2 + + Enters emergency mode, starts the + emergency.service unit. This is mostly + equivalent to systemctl isolate + emergency.service. + + + + SIGRTMIN+3 + + Halts the machine, starts the + halt.target unit. This is mostly + equivalent to systemctl start halt.target + --job-mode=replace-irreversibly. + + + + + SIGRTMIN+4 + + Powers off the machine, starts the + poweroff.target unit. This is mostly + equivalent to systemctl start poweroff.target + --job-mode=replace-irreversibly. + + + + + SIGRTMIN+5 + + Reboots the machine, starts the + reboot.target unit. This is mostly + equivalent to systemctl start reboot.target + --job-mode=replace-irreversibly. + + + + + SIGRTMIN+6 + + Reboots the machine via kexec, starts the + kexec.target unit. This is mostly + equivalent to systemctl start kexec.target + --job-mode=replace-irreversibly. + + + + + SIGRTMIN+13 + + Immediately halts the machine. + + + + SIGRTMIN+14 + + Immediately powers off the machine. + + + + SIGRTMIN+15 + + Immediately reboots the machine. + + + + SIGRTMIN+16 + + Immediately reboots the machine with kexec. + + + + SIGRTMIN+20 + + Enables display of status messages on the + console, as controlled via + systemd.show_status=1 on the kernel command + line. + + + + SIGRTMIN+21 + + Disables display of + status messages on the console, as + controlled via + systemd.show_status=0 + on the kernel command + line. + + + + SIGRTMIN+22 + + Sets the service manager's log level to debug, in a fashion equivalent to + systemd.log_level=debug on the kernel command line. + + + + SIGRTMIN+23 + + Restores the log level to its configured value. The configured value is derived from – in order + of priority – the value specified with systemd.log-level= on the kernel command line, or the + value specified with in the configuration file, or the built-in default of + info. + + + + SIGRTMIN+24 + + Immediately exits the manager (only available + for --user instances). + + + + SIGRTMIN+25 + + Upon receiving this signal the systemd manager will reexecute itself. This + is mostly equivalent to systemctl daemon-reexec except that it will be + done asynchronously. + + The systemd system manager treats this signal the same way as + SIGTERM. + + + + SIGRTMIN+26 + + Restores the log target to its configured value. The configured value is derived from – in + order of priority – the value specified with systemd.log-target= on the kernel command line, + or the value specified with in the configuration file, or the built-in + default. + + + + SIGRTMIN+27 + SIGRTMIN+28 + + Sets the log target to console on SIGRTMIN+27 (or + kmsg on SIGRTMIN+28), in a fashion equivalent to + systemd.log_target=console (or systemd.log_target=kmsg on + SIGRTMIN+28) on the kernel command line. + + + + + + Environment + + The environment block for the system manager is initially set by the kernel. (In particular, + key=value assignments on the kernel command line are turned into environment + variables for PID 1). For the user manager, the system manager sets the environment as described in the + "Environment Variables in Spawned Processes" section of + systemd.exec5. The + DefaultEnvironment= setting in the system manager applies to all services including + user@.service. Additional entries may be configured (as for any other service) + through the Environment= and EnvironmentFile= settings for + user@.service (see + systemd.exec5). Also, + additional environment variables may be set through the ManagerEnvironment= setting in + systemd-system.conf5 + and + systemd-user.conf5. + + + Some of the variables understood by systemd: + + + + $SYSTEMD_LOG_LEVEL + + + This can be overridden with . + + + + $SYSTEMD_LOG_COLOR + + + This can be overridden with . + + + + $SYSTEMD_LOG_TIME + + + This can be overridden with . + + + + $SYSTEMD_LOG_LOCATION + + + This can be overridden with . + + + + $SYSTEMD_LOG_TID + + + + + $SYSTEMD_LOG_TARGET + + + This can be overridden with . + + + + $XDG_CONFIG_HOME + $XDG_CONFIG_DIRS + $XDG_DATA_HOME + $XDG_DATA_DIRS + + The systemd user manager uses these variables + in accordance to the XDG + Base Directory specification to find its + configuration. + + + + $SYSTEMD_UNIT_PATH + $SYSTEMD_GENERATOR_PATH + $SYSTEMD_ENVIRONMENT_GENERATOR_PATH + + Controls where systemd looks for unit files and + generators. + These variables may contain a list of paths, separated by colons + (:). When set, if the list ends with an empty + component (...:), this list is prepended to the + usual set of paths. Otherwise, the specified list replaces the usual + set of paths. + + + + + + + + + + + + $LISTEN_PID + $LISTEN_FDS + $LISTEN_FDNAMES + + Set by systemd for supervised processes during + socket-based activation. See + sd_listen_fds3 + for more information. + + + + $NOTIFY_SOCKET + + Set by systemd for supervised processes for + status and start-up completion notification. See + sd_notify3 + for more information. + + + + For further environment variables understood by systemd and its various components, see Known Environment Variables. + + + + Kernel Command Line + + When run as the system instance, systemd parses a number of options listed below. They can be + specified as kernel command line arguments which are parsed from a number of sources depending on the + environment in which systemd is executed. If run inside a Linux container, these options are parsed from + the command line arguments passed to systemd itself, next to any of the command line options listed in + the Options section above. If run outside of Linux containers, these arguments are parsed from + /proc/cmdline and from the SystemdOptions EFI variable + (on EFI systems) instead. Options from /proc/cmdline have higher priority. The + following variables are understood: + + + + systemd.unit= + rd.systemd.unit= + + Overrides the unit to activate on boot. Defaults to + default.target. This may be used to temporarily boot into a different boot unit, + for example rescue.target or emergency.service. See + systemd.special7 + for details about these units. The option prefixed with rd. is honored only in the + initrd, while the one that is not prefixed only in the main system. + + + + systemd.dump_core + + Takes a boolean argument or enables the option if specified + without an argument. If enabled, the systemd manager (PID 1) dumps core when + it crashes. Otherwise, no core dump is created. Defaults to enabled. + + + + + systemd.crash_chvt + + Takes a positive integer, or a boolean argument. Can be also specified without an + argument, with the same effect as a positive boolean. If a positive integer (in the range 1–63) is + specified, the system manager (PID 1) will activate the specified virtual terminal when it crashes. + Defaults to disabled, meaning that no such switch is attempted. If set to enabled, the virtual + terminal the kernel messages are written to is used instead. + + + + systemd.crash_shell + + Takes a boolean argument or enables the option if specified + without an argument. If enabled, the system manager (PID 1) spawns a shell + when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults + to disabled, for security reasons, as the shell is not protected by password + authentication. + + + + systemd.crash_reboot + + Takes a boolean argument or enables the option if specified + without an argument. If enabled, the system manager (PID 1) will reboot the + machine automatically when it crashes, after a 10s delay. Otherwise, the + system will hang indefinitely. Defaults to disabled, in order to avoid a + reboot loop. If combined with systemd.crash_shell, the + system is rebooted after the shell exits. + + + + systemd.confirm_spawn + + Takes a boolean argument or a path to the virtual console + where the confirmation messages should be emitted. Can be also specified + without an argument, with the same effect as a positive boolean. If enabled, + the system manager (PID 1) asks for confirmation when spawning processes + using . If a path or a console name (such as + ttyS0) is provided, the virtual console pointed to by this + path or described by the give name will be used instead. Defaults to disabled. + + + + + systemd.service_watchdogs= + + Takes a boolean argument. If disabled, all service runtime + watchdogs () and emergency actions (e.g. + or ) are + ignored by the system manager (PID 1); see + systemd.service5. + Defaults to enabled, i.e. watchdogs and failure actions are processed + normally. The hardware watchdog is not affected by this + option. + + + + systemd.show_status + + Takes a boolean argument or the constants error and + auto. Can be also specified without an argument, with the same effect as a + positive boolean. If enabled, the systemd manager (PID 1) shows terse service status updates on the + console during bootup. With error, only messages about failures are shown, but + boot is otherwise quiet. auto behaves like until there is + a significant delay in boot. Defaults to enabled, unless is passed as kernel + command line option, in which case it defaults to error. If specified overrides + the system manager configuration file option , see + systemd-system.conf5. + + + + + systemd.status_unit_format= + + Takes , or + as the value. If , the system manager will use unit + names in status messages. If , the system manager will use unit names and + description in status messages. When specified, overrides the system manager configuration file + option , see + systemd-system.conf5. + + + + + systemd.log_color + systemd.log_level= + systemd.log_location + systemd.log_target= + systemd.log_time + systemd.log_tid + + Controls log output, with the same effect as the + $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LEVEL, + $SYSTEMD_LOG_LOCATION, $SYSTEMD_LOG_TARGET, + $SYSTEMD_LOG_TIME, and $SYSTEMD_LOG_TID environment variables + described above. systemd.log_color, systemd.log_location, + systemd.log_time, and systemd.log_tid= can be specified without + an argument, with the same effect as a positive boolean. + + + + systemd.default_standard_output= + systemd.default_standard_error= + + Controls default standard output and error output for services and sockets. That is, + controls the default for and (see + systemd.exec5 for + details). Takes one of , , , + , , , + . If the argument is omitted + systemd.default-standard-output= defaults to and + systemd.default-standard-error= to . + + + + systemd.setenv= + + Takes a string argument in the form + VARIABLE=VALUE. May be used to set default environment + variables to add to forked child processes. May be used more + than once to set multiple variables. + + + + systemd.machine_id= + + Takes a 32 character hex value to be + used for setting the machine-id. Intended mostly for + network booting where the same machine-id is desired + for every boot. + + + + systemd.set_credential= + + Sets a system credential, which can then be propagated to system services using the + LoadCredential= setting, see + systemd.exec5 for + details. Takes a pair of credential name and value, separated by a colon. Note that the kernel + command line is typically accessible by unprivileged programs in + /proc/cmdline. Thus, this mechanism is not suitable for transferring sensitive + data. Use it only for data that is not sensitive (e.g. public keys/certificates, rather than private + keys), or in testing/debugging environments. + + For further information see System and Service + Credentials documentation. + + + + systemd.import_credentials= + + Takes a boolean argument. If false disables importing credentials from the kernel + command line, the DMI/SMBIOS OEM string table, the qemu_fw_cfg subsystem or the EFI kernel + stub. + + + + quiet + + Turn off status output at boot, much like + systemd.show_status=no would. Note that + this option is also read by the kernel itself and disables + kernel log output. Passing this option hence turns off the + usual output from both the system manager and the kernel. + + + + + debug + + Turn on debugging output. This is equivalent + to systemd.log_level=debug. Note that this + option is also read by the kernel itself and enables kernel + debug output. Passing this option hence turns on the debug + output from both the system manager and the + kernel. + + + + emergency + rd.emergency + -b + + Boot into emergency mode. This is equivalent + to systemd.unit=emergency.target or + rd.systemd.unit=emergency.target, respectively, and + provided for compatibility reasons and to be easier to type. + + + + rescue + rd.rescue + single + s + S + 1 + + Boot into rescue mode. This is equivalent to + systemd.unit=rescue.target or + rd.systemd.unit=rescue.target, respectively, and + provided for compatibility reasons and to be easier to type. + + + + 2 + 3 + 4 + 5 + + Boot into the specified legacy SysV runlevel. + These are equivalent to + systemd.unit=runlevel2.target, + systemd.unit=runlevel3.target, + systemd.unit=runlevel4.target, and + systemd.unit=runlevel5.target, + respectively, and provided for compatibility reasons and to be + easier to type. + + + + locale.LANG= + locale.LANGUAGE= + locale.LC_CTYPE= + locale.LC_NUMERIC= + locale.LC_TIME= + locale.LC_COLLATE= + locale.LC_MONETARY= + locale.LC_MESSAGES= + locale.LC_PAPER= + locale.LC_NAME= + locale.LC_ADDRESS= + locale.LC_TELEPHONE= + locale.LC_MEASUREMENT= + locale.LC_IDENTIFICATION= + + Set the system locale to use. This overrides + the settings in /etc/locale.conf. For + more information, see + locale.conf5 + and + locale7. + + + + + For other kernel command line parameters understood by + components of the core OS, please refer to + kernel-command-line7. + + + + Options + + systemd is only very rarely invoked directly, since it is started early and is + already running by the time users may interact with it. Normally, tools like + systemctl1 are used to + give commands to the manager. Since systemd is usually not invoked directly, the + options listed below are mostly useful for debugging and special purposes. + + + Introspection and debugging options + + Those options are used for testing and introspection, and systemd may + be invoked with them at any time: + + + + + + Dump understood unit configuration items. This outputs a terse but complete list of + configuration items understood in unit definition files. + + + + + + Dump exposed bus properties. This outputs a terse but complete list of properties + exposed on D-Bus. + + + + + + Determine the initial start-up transaction (i.e. the list of jobs enqueued at + start-up), dump it and exit — without actually executing any of the determined jobs. This option is + useful for debugging only. Note that during regular service manager start-up additional units not + shown by this operation may be started, because hardware, socket, bus or other kinds of activation + might add additional jobs as the transaction is executed. Use to request + the initial transaction of the system service manager (this is also the implied default), combine + with to request the initial transaction of the per-user service manager + instead. + + + + + + + When used in conjunction with , selects whether to calculate + the initial transaction for the system instance or for a per-user instance. These options have no + effect when invoked without , as during regular + (i.e. non-) invocations the service manager will automatically detect + whether it shall operate in system or per-user mode, by checking whether the PID it is run as is 1 + or not. Note that it is not supported booting and maintaining a system with the service manager + running in mode but with a PID other than 1. + + + + + + + + + Options that duplicate kernel command line settings + + Those options correspond directly to options listed above in "Kernel Command Line". Both forms + may be used equivalently for the system manager, but it is recommended to use the forms listed above in + this context, because they are properly namespaced. When an option is specified both on the kernel + command line and as a normal command line argument, the latter has higher precedence. + + When systemd is used as a user manager, the kernel command line is ignored and + only the options described below are understood. Nevertheless, systemd is usually + started in this mode through the + user@.service5 + service, which is shared between all users. It may be more convenient to use configuration files to + modify settings (see + systemd-user.conf5), + or environment variables. See the "Environment" section above for a discussion of how the environment + block is set. + + + + + + Set default unit to activate on startup. If not specified, defaults to + default.target. See systemd.unit= above. + + + + + + Enable core dumping on crash. This switch has no effect when running as user + instance. Same as systemd.dump_core= above. + + + + VT + + Switch to a specific virtual console (VT) on crash. This switch has no effect when + running as user instance. Same as systemd.crash_chvt= above (but not the + different spelling!). + + + + + + Run a shell on crash. This switch has no effect when running as user instance. See + systemd.crash_shell= above. + + + + + + Automatically reboot the system on crash. This switch has no effect when running as + user instance. See systemd.crash_reboot above. + + + + + + Ask for confirmation when spawning processes. This switch has no effect when run as + user instance. See systemd.confirm_spawn above. + + + + + + Show terse unit status information on the console during boot-up and shutdown. See + systemd.show_status above. + + + + + + Highlight important log messages. See systemd.log_color above. + + + + + + + Set log level. See systemd.log_level above. + + + + + + Include code location in log messages. See systemd.log_location + above. + + + + + + Set log target. See systemd.log_target above. + + + + + + Prefix console messages with timestamp. See systemd.log_time above. + + + + + + + Override the machine-id set on the hard drive. See + systemd.machine_id= above. + + + + + + Globally enable/disable all service watchdog timeouts and emergency actions. See + systemd.service_watchdogs above. + + + + + + + Sets the default output or error output for all services and sockets, + respectively. See systemd.default_standard_output= and + systemd.default_standard_error= above. + + + + + + + Sockets and FIFOs + + + + /run/systemd/notify + + Daemon status notification socket. This is an + AF_UNIX datagram socket and is used to + implement the daemon notification logic as implemented by + sd_notify3. + + + + + /run/systemd/private + + Used internally as communication channel + between + systemctl1 + and the systemd process. This is an + AF_UNIX stream socket. This interface is + private to systemd and should not be used in external + projects. + + + + /dev/initctl + + Limited compatibility support for the SysV + client interface, as implemented by the + systemd-initctl.service unit. This is a + named pipe in the file system. This interface is obsolete and + should not be used in new applications. + + + + + + History + + + + systemd 252 + Kernel command-line arguments systemd.unified_cgroup_hierarchy + and systemd.legacy_systemd_cgroup_controller were deprecated. Please switch to + the unified cgroup hierarchy. + + + + + + See Also + + The systemd Homepage, + systemd-system.conf5, + locale.conf5, + systemctl1, + journalctl1, + systemd-notify1, + daemon7, + sd-daemon3, + org.freedesktop.systemd15, + systemd.unit5, + systemd.special7, + pkg-config1, + kernel-command-line7, + bootup7, + systemd.directives7 + + + + diff --git a/man/sysupdate.d.xml b/man/sysupdate.d.xml new file mode 100644 index 0000000..d57fbf0 --- /dev/null +++ b/man/sysupdate.d.xml @@ -0,0 +1,885 @@ + + + + + + + + sysupdate.d + systemd + + + + sysupdate.d + 5 + + + + sysupdate.d + Transfer Definition Files for Automatic Updates + + + + /etc/sysupdate.d/*.conf +/run/sysupdate.d/*.conf +/usr/lib/sysupdate.d/*.conf + + + + + Description + + sysupdate.d/*.conf files describe how specific resources on the local system + shall be updated from a remote source. Each such file defines one such transfer: typically a remote + HTTP/HTTPS resource as source; and a local file, directory or partition as target. This may be used as a + simple, automatic, atomic update mechanism for the OS itself, for containers, portable services or system + extension images — but in fact may be used to update any kind of file from a remote source. + + The + systemd-sysupdate8 + command reads these files and uses them to determine which local resources should be updated, and then + executes the update. + + Both the remote HTTP/HTTPS source and the local target typically exist in multiple, concurrent + versions, in order to implement flexible update schemes, e.g. A/B updating (or a superset thereof, + e.g. A/B/C, A/B/C/D, …). + + Each *.conf file defines one transfer, i.e. describes one resource to + update. Typically, multiple of these files (i.e. multiple of such transfers) are defined together, and + are bound together by a common version identifier in order to update multiple resources at once on each + update operation, for example to update a kernel, a root file system and a Verity partition in a single, + combined, synchronized operation, so that only a combined update of all three together constitutes a + complete update. + + Each *.conf file contains three sections: [Transfer], [Source] and [Target]. + + + + Basic Mode of Operation + + Disk-image based OS updates typically consist of multiple different resources that need to be + updated together, for example a secure OS update might consist of a root file system image to drop into a + partition, a matching Verity integrity data partition image, and a kernel image prepared to boot into the + combination of the two partitions. The first two resources are files that are downloaded and placed in a + disk partition, the latter is a file that is downloaded and placed in a regular file in the boot file + system (e.g. EFI system partition). Hence, during an update of a hypothetical operating system "foobarOS" + to a hypothetical version 47 the following operations should take place: + + + A file https://download.example.com/foobarOS_47.root.xz should be + downloaded, decompressed and written to a previously unused partition with GPT partition type UUID + 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 for x86-64, as per Discoverable Partitions + Specification. + + Similarly, a file https://download.example.com/foobarOS_47.verity.xz + should be downloaded, decompressed and written to a previously empty partition with GPT partition type + UUID of 2c7357ed-ebd2-46d9-aec1-23d437ec2bf5 (i.e. the partition type for Verity integrity information + for x86-64 root file systems). + + Finally, a file https://download.example.com/foobarOS_47.efi.xz (a + unified kernel, as per Boot Loader + Specification Type #2) should be downloaded, decompressed and written to the ESP file system, + i.e. to EFI/Linux/foobarOS_47.efi in the ESP. + + + The version-independent generalization of this would be (using the special marker + @v as wildcard for the version identifier): + + + A transfer of a file https://download.example.com/foobarOS_@v.root.xz + → a local, previously empty GPT partition of type 4f68bce3-e8cd-4db1-96e7-fbcaf984b709, with the label to + be set to foobarOS_@v. + + A transfer of a file https://download.example.com/foobarOS_@v.verity.xz + → a local, previously empty GPT partition of type 2c7357ed-ebd2-46d9-aec1-23d437ec2bf5, with the label to be + set to foobarOS_@v_verity. + + A transfer of a file https://download.example.com/foobarOS_@v.efi.xz + → a local file /efi/EFI/Linux/foobarOS_@v.efi. + + + An update can only complete if the relevant URLs provide their resources for the same version, + i.e. for the same value of @v. + + The above may be translated into three *.conf files in + sysupdate.d/, one for each resource to transfer. The *.conf + files configure the type of download, and what place to write the download to (i.e. whether to a + partition or a file in the file system). Most importantly these files contain the URL, partition name and + filename patterns shown above that describe how these resources are called on the source and how they + shall be called on the target. + + In order to enumerate available versions and figuring out candidates to update to, a mechanism is + necessary to list suitable files: + + + For partitions: the surrounding GPT partition table contains a list of defined + partitions, including a partition type UUID and a partition label (in this scheme the partition label + plays a role for the partition similar to the filename for a regular file). + + For regular files: the directory listing of the directory the files are contained in + provides a list of existing files in a straightforward way. + + For HTTP/HTTPS sources a simple scheme is used: a manifest file + SHA256SUMS, following the format defined by sha256sum1, + lists file names and their SHA256 hashes. + + + Transfers are done in the alphabetical order of the .conf file names they are + defined in. First, the resource data is downloaded directly into a target file/directory/partition. Once + this is completed for all defined transfers, in a second step the files/directories/partitions are + renamed to their final names as defined by the target MatchPattern=, again in the + order the .conf transfer file names dictate. This step is not atomic, however it is + guaranteed to be executed strictly in order with suitable disk synchronization in place. Typically, when + updating an OS one of the transfers defines the entry point when booting. Thus it is generally a good idea + to order the resources via the transfer configuration file names so that the entry point is written + last, ensuring that any abnormal termination does not leave an entry point around whose backing is not + established yet. In the example above it would hence make sense to establish the EFI kernel image last + and thus give its transfer configuration file the alphabetically last name. + + See below for an extended, more specific example based on the above. + + + + Resource Types + + Each transfer file defines one source resource to transfer to one target resource. The following + resource types are supported: + + + + Resources of type url-file encapsulate a file on a web server, + referenced via a HTTP or HTTPS URL. When an update takes place, the file is downloaded and decompressed + and then written to the target file or partition. This resource type is only available for sources, not + for targets. The list of available versions of resources of this type is encoded in + SHA256SUMS manifest files, accompanied by + SHA256SUMS.gpg detached signatures. + + The url-tar resource type is similar, but the file must be a + .tar archive. When an update takes place, the file is decompressed and unpacked + into a directory or btrfs subvolume. This resource type is only available for sources, not for + targets. Just like url-file, url-tar version enumeration makes + use of SHA256SUMS files, authenticated via + SHA256SUMS.gpg. + + The regular-file resource type encapsulates a local regular file on + disk. During updates the file is uncompressed and written to the target file or partition. This + resource type is available both as source and as target. When updating no integrity or authentication + verification is done for resources of this type. + + The partition resource type is similar to + regular-file, and encapsulates a GPT partition on disk. When updating, the partition + must exist already, and have the correct GPT partition type. A partition whose GPT partition label is + set to _empty is considered empty, and a candidate to place a newly downloaded + resource in. The GPT partition label is used to store version information, once a partition is + updated. This resource type is only available for target resources. + + The tar resource type encapsulates local .tar + archive files. When an update takes place, the files are uncompressed and unpacked into a target + directory or btrfs subvolume. Behaviour of tar and url-tar is + generally similar, but the latter downloads from remote sources, and does integrity and authentication + checks while the former does not. The tar resource type is only available for source + resources. + + The directory resource type encapsulates local directory trees. This + type is available both for source and target resources. If an update takes place on a source resource + of this type, a recursive copy of the directory is done. + + The subvolume resource type is identical to + directory, except when used as the target, in which case the file tree is placed in + a btrfs subvolume instead of a plain directory, if the backing file system supports it (i.e. is + btrfs). + + + As already indicated, only a subset of source and target resource type combinations are + supported: + + + Resource Types + + + + + + + + Identifier + Description + Usable as Source + When Used as Source: Compatible Targets + When Used as Source: Integrity + Authentication + When Used as Source: Decompression + Usable as Target + When Used as Target: Compatible Sources + + + + + + url-file + HTTP/HTTPS files + yes + regular-file, partition + yes + yes + no + - + + + + url-tar + HTTP/HTTPS .tar archives + yes + directory, subvolume + yes + yes + no + - + + + + regular-file + Local files + yes + regular-file, partition + no + yes + yes + url-file, regular-file + + + + partition + Local GPT partitions + no + - + - + - + yes + url-file, regular-file + + + + tar + Local .tar archives + yes + directory, subvolume + no + yes + no + - + + + + directory + Local directories + yes + directory, subvolume + no + no + yes + url-tar, tar, directory, subvolume + + + + subvolume + Local btrfs subvolumes + yes + directory, subvolume + no + no + yes + url-tar, tar, directory, subvolume + + + + +
+ + + + Match Patterns + + Both the source and target resources typically exist in multiple versions concurrently. An update + operation is done whenever the newest of the source versions is newer than the newest of the target + versions. To determine the newest version of the resources a directory listing, partition listing or + manifest listing is used, a subset of qualifying entries selected from that, and the version identifier + extracted from the file names or partition labels of these selected entries. Subset selection and + extraction of the version identifier (plus potentially other metadata) is done via match patterns, + configured in MatchPattern= in the [Source] and [Target] sections. These patterns are + strings that describe how files or partitions are named, with named wildcards for specific fields such as + the version identifier. The following wildcards are defined: + + + Match Pattern Wildcards + + + + + + + + Wildcard + Description + Format + Notes + + + + + + @v + Version identifier + Valid version string + Mandatory + + + + @u + GPT partition UUID + Valid 128-Bit UUID string + Only relevant if target resource type chosen as partition + + + + @f + GPT partition flags + Formatted hexadecimal integer + Only relevant if target resource type chosen as partition + + + + @a + GPT partition flag NoAuto + Either 0 or 1 + Controls NoAuto bit of the GPT partition flags, as per Discoverable Partitions Specification; only relevant if target resource type chosen as partition + + + + @g + GPT partition flag GrowFileSystem + Either 0 or 1 + Controls GrowFileSystem bit of the GPT partition flags, as per Discoverable Partitions Specification; only relevant if target resource type chosen as partition + + + + @r + Read-only flag + Either 0 or 1 + Controls ReadOnly bit of the GPT partition flags, as per Discoverable Partitions Specification and other output read-only flags, see ReadOnly= below + + + + @t + File modification time + Formatted decimal integer, µs since UNIX epoch Jan 1st 1970 + Only relevant if target resource type chosen as regular-file + + + + @m + File access mode + Formatted octal integer, in UNIX fashion + Only relevant if target resource type chosen as regular-file + + + + @s + File size after decompression + Formatted decimal integer + Useful for measuring progress and to improve partition allocation logic + + + + @d + Tries done + Formatted decimal integer + Useful when operating with kernel image files, as per Automatic Boot Assessment + + + + @l + Tries left + Formatted decimal integer + Useful when operating with kernel image files, as per Automatic Boot Assessment + + + + @h + SHA256 hash of compressed file + 64 hexadecimal characters + The SHA256 hash of the compressed file; not useful for url-file or url-tar where the SHA256 hash is already included in the manifest file anyway + + + +
+ + Of these wildcards only @v must be present in a valid pattern, all other + wildcards are optional. Each wildcard may be used at most once in each pattern. A typical wildcard + matching a file system source image could be MatchPattern=foobar_@v.raw.xz, i.e. any file + whose name begins with foobar_, followed by a version ID and suffixed by + .raw.xz. + + Do not confuse the @ pattern matching wildcard prefix with the + % specifier expansion prefix. The former encapsulate a variable part of a match + pattern string, the latter are simple shortcuts that are expanded while the drop-in files are + parsed. For details about specifiers, see below. + + + + [Transfer] Section Options + + This section defines general properties of this transfer: + + + + MinVersion= + + Specifies the minimum version to require for this transfer to take place. If the + source or target patterns in this transfer definition match files older than this version they will + be considered obsolete, and never be considered for the update operation. + + + + ProtectVersion= + + Takes one or more version strings to mark as "protected". Protected versions are + never removed while making room for new, updated versions. This is useful to ensure that the + currently booted OS version (or auxiliary resources associated with it) is not replaced/overwritten + during updates, in order to avoid runtime file system corruptions. + + Like many of the settings in these configuration files this setting supports specifier + expansion. It's particularly useful to set this setting to one of the %A, + %B or %w specifiers to automatically refer to the current OS + version of the running system. See below for details on supported specifiers. + + + + Verify= + + Takes a boolean, defaults to yes. Controls whether to cryptographically verify + downloaded resources (specifically: validate the GPG signatures for downloaded + SHA256SUMS manifest files, via their detached signature files + SHA256SUMS.gpg in combination with the system keyring + /usr/lib/systemd/import-pubring.gpg or + /etc/systemd/import-pubring.gpg). + + This option is essential to provide integrity guarantees for downloaded resources and thus + should be left enabled, outside of test environments. + + Note that the downloaded payload files are unconditionally checked against the SHA256 hashes + listed in the manifest. This option only controls whether the signatures of these manifests are + verified. + + This option only has an effect if the source resource type is selected as + url-file or url-tar, as integrity and authentication + checking is only available for transfers from remote sources. + + + + + + + [Source] Section Options + + This section defines properties of the transfer source: + + + + Type= + + Specifies the resource type of the source for the transfer. Takes one of + url-file, url-tar, tar, + regular-file, directory or + subvolume. For details about the resource types, see above. This option is + mandatory. + + Note that only some combinations of source and target resource types are supported, see + above. + + + + + + Path= + + Specifies where to find source versions of this resource. + + If the source type is selected as url-file or + url-tar this must be a HTTP/HTTPS URL. The URL is suffixed with + /SHA256SUMS to acquire the manifest file, with + /SHA256SUMS.gpg to acquire the detached signature file for it, and with the file + names listed in the manifest file in case an update is executed and a resource shall be + downloaded. + + For all other source resource types this must be a local path in the file system, referring to + a local directory to find the versions of this resource in. + + + + MatchPattern= + + Specifies one or more file name match patterns that select the subset of files that + are update candidates as source for this transfer. See above for details on match patterns. + + This option is mandatory. Any pattern listed must contain at least the @v + wildcard, so that a version identifier may be extracted from the filename. All other wildcards are + optional. + + + + + + [Target] Section Options + + This section defines properties of the transfer target: + + + + Type= + + Specifies the resource type of the target for the transfer. Takes one of + partition, regular-file, directory or + subvolume. For details about the resource types, see above. This option is + mandatory. + + Note that only some combinations of source and target resource types are supported, see above. + + + + Path= + + Specifies a file system path where to look for already installed versions or place + newly downloaded versions of this configured resource. If Type= is set to + partition, expects a path to a (whole) block device node, or the special string + auto in which case the block device which contains the root file system of the + currently booted system is automatically determined and used. If Type= is set to + regular-file, directory or subvolume, + must refer to a path in the local file system referencing the directory to find or place the version + files or directories under. + + Note that this mechanism cannot be used to create or remove partitions, in case + Type= is set to partition. Partitions must exist already, and + a special partition label _empty is used to indicate empty partitions. To + automatically generate suitable partitions on first boot, use a tool such as + systemd-repart8. + + + + MatchPattern= + + Specifies one or more file name or partition label match patterns that select the + subset of files or partitions that are update candidates as targets for this transfer. See above for + details on match patterns. + + This option is mandatory. Any pattern listed must contain at least the @v + wildcard, so that a version identifier may be extracted from the filename. All other wildcards are + optional. + + This pattern is both used for matching existing installed versions and for determining the name + of new versions to install. If multiple patterns are specified, the first specified is used for + naming newly installed versions. + + + + MatchPartitionType= + + When the target Type= is chosen as partition, + specifies the GPT partition type to look for. Only partitions of this type are considered, all other + partitions are ignored. If not specified, the GPT partition type linux-generic + is used. Accepts either a literal type UUID or a symbolic type identifier. For a list of supported + type identifiers, see the Type= setting in + repart.d5. + + + + PartitionUUID= + PartitionFlags= + PartitionNoAuto= + PartitionGrowFileSystem= + + When the target Type= is picked as partition, + selects the GPT partition UUID and partition flags to use for the updated partition. Expects a valid + UUID string, a hexadecimal integer, or booleans, respectively. If not set, but the source match + pattern includes wildcards for these fields (i.e. @u, @f, + @a, or @g), the values from the patterns are used. If neither + configured with wildcards or these explicit settings, the values are left untouched. If both the + overall PartitionFlags= flags setting and the individual flag settings + PartitionNoAuto= and PartitionGrowFileSystem= are used (or the + wildcards for them), then the latter override the former, i.e. the individual flag bit overrides the + overall flags value. See Discoverable + Partitions Specification for details about these flags. + + Note that these settings are not used for matching, they only have effect on newly written + partitions in case a transfer takes place. + + + + ReadOnly= + + Controls whether to mark the resulting file, subvolume or partition read-only. If the + target type is partition this controls the ReadOnly partition flag, as per + Discoverable Partitions + Specification, similar to the PartitionNoAuto= and + PartitionGrowFileSystem= flags described above. If the target type is + regular-file, the writable bit is removed from the access mode. If the the + target type is subvolume, the subvolume will be marked read-only as a + whole. Finally, if the target Type= is selected as directory, + the "immutable" file attribute is set, see chattr1 for + details. + + + + Mode= + + The UNIX file access mode to use for newly created files in case the target resource + type is picked as regular-file. Expects an octal integer, in typical UNIX + fashion. If not set, but the source match pattern includes a wildcard for this field + (i.e. @t), the value from the pattern is used. + + Note that this setting is not used for matching, it only has an effect on newly written + files when a transfer takes place. + + + + TriesDone= + TriesLeft= + + These options take positive, decimal integers, and control the number of attempts + done and left for this file. These settings are useful for managing kernel images, following the + scheme defined in Automatic Boot + Assessment, and only have an effect if the target pattern includes the @d + or @l wildcards. + + + + InstancesMax= + + Takes a decimal integer equal to or greater than 2. This configures how many concurrent + versions of the resource to keep. Whenever a new update is initiated it is made sure that no more + than the number of versions specified here minus one exist in the target. Any excess versions are + deleted (in case the target Type= of regular-file, + directory, subvolume is used) or emptied (in case the + target Type= of partition is used; emptying in this case + simply means to set the partition label to the special string _empty; note that no + partitions are actually removed). After an update is completed the number of concurrent versions of + the target resources is equal to or below the number specified here. + + Note that this setting may be set differently for each transfer. However, it generally is + advisable to keep this setting the same for all transfers, since otherwise incomplete combinations of + files or partitions will be left installed. + + If the target Type= is selected as partition, the number + of concurrent versions to keep is additionally restricted by the number of partition slots of the + right type in the partition table. i.e. if there are only 2 partition slots for the selected + partition type, setting this value larger than 2 is without effect, since no more than 2 concurrent + versions could be stored in the image anyway. + + + + RemoveTemporary= + + Takes a boolean argument. If this option is enabled (which is the default) before + initiating an update, all left-over, incomplete updates from a previous attempt are removed from the + target directory. This only has an effect if the target resource Type= is selected + as regular-file, directory or + subvolume. + + + + CurrentSymlink= + + Takes a symlink name as argument. If this option is used, as the last step of the + update a symlink under the specified name is created/updated pointing to the completed update. This + is useful in to provide a stable name always pointing to the newest version of the resource. This is + only supported if the target resource Type= is selected as + regular-file, directory or + subvolume. + + + + + + + Specifiers + + Specifiers may be used in the MinVersion=, ProtectVersion=, + Path=, MatchPattern= and CurrentSymlink= + settings. The following expansions are understood: + + Specifiers available + + + + + + + Specifier + Meaning + Details + + + + + + + + + + + + + + + + + + + + +
+ + Do not confuse the % specifier expansion prefix with the @ + pattern matching wildcard prefix. The former are simple shortcuts that are expanded while the drop-in + files are parsed, the latter encapsulate a variable part of a match pattern string. For details about + pattern matching wildcards, see above. + + + + Examples + + + Updates for a Verity Enabled Secure OS + + With the following three files we define a root file system partition, a matching Verity + partition, and a unified kernel image to update as one. This example is an extension of the example + discussed earlier in this man page. + + # /usr/lib/sysupdate.d/50-verity.conf +[Transfer] +ProtectVersion=%A + +[Source] +Type=url-file +Path=https://download.example.com/ +MatchPattern=foobarOS_@v_@u.verity.xz + +[Target] +Type=partition +Path=auto +MatchPattern=foobarOS_@v_verity +MatchPartitionType=root-verity +PartitionFlags=0 +PartitionReadOnly=1 + + The above defines the update mechanism for the Verity partition of the root file system. Verity + partition images are downloaded from + https://download.example.com/foobarOS_@v_@u.verity.xz and written to a suitable + local partition, which is marked read-only. Under the assumption this update is run from the image + itself the current image version (i.e. the %A specifier) is marked as protected, to + ensure it is not corrupted while booted. Note that the partition UUID for the target partition is + encoded in the source file name. Fixating the partition UUID can be useful to ensure that + roothash= on the kernel command line is sufficient to pinpoint both the Verity and + root file system partition, and also encode the Verity root level hash (under the assumption the UUID + in the file names match their top-level hash, the way + systemd-gpt-auto-generator8 + suggests). + + # /usr/lib/sysupdate.d/60-root.conf +[Transfer] +ProtectVersion=%A + +[Source] +Type=url-file +Path=https://download.example.com/ +MatchPattern=foobarOS_@v_@u.root.xz + +[Target] +Type=partition +Path=auto +MatchPattern=foobarOS_@v +MatchPartitionType=root +PartitionFlags=0 +PartitionReadOnly=1 + + The above defines a matching transfer definition for the root file system. + + # /usr/lib/sysupdate.d/70-kernel.conf +[Transfer] +ProtectVersion=%A + +[Source] +Type=url-file +Path=https://download.example.com/ +MatchPattern=foobarOS_@v.efi.xz + +[Target] +Type=regular-file +Path=/efi/EFI/Linux +MatchPattern=foobarOS_@v+@l-@d.efi \ + foobarOS_@v+@l.efi \ + foobarOS_@v.efi +Mode=0444 +TriesLeft=3 +TriesDone=0 +InstancesMax=2 + + The above installs a unified kernel image into the ESP (which is mounted to + /efi/), as per Boot + Loader Specification Type #2. This defines three possible patterns for the names of the + kernel images, as per Automatic Boot + Assessment, and ensures when installing new kernels, they are set up with 3 tries left. No + more than two parallel kernels are kept. + + With this setup the web server would serve the following files, for a hypothetical version 7 of + the OS: + + + SHA256SUMS – The manifest file, containing available files and their SHA256 hashes + SHA256SUMS.gpg – The detached cryptographic signature for the manifest file + foobarOS_7_8b8186b1-2b4e-4eb6-ad39-8d4d18d2a8fb.verity.xz – The Verity image for version 7 + foobarOS_7_f4d1234f-3ebf-47c4-b31d-4052982f9a2f.root.xz – The root file system image for version 7 + foobarOS_7_efi.xz – The unified kernel image for version 7 + + + For each new OS release a new set of the latter three files would be added, each time with an + updated version. The SHA256SUMS manifest should then be updated accordingly, + listing all files for all versions that shall be offered for download. + + + + Updates for Plain Directory Container Image + + +[Source] +Type=url-tar +Path=https://download.example.com/ +MatchPattern=myContainer_@v.tar.gz + +[Target] +Type=subvolume +Path=/var/lib/machines +MatchPattern=myContainer_@v +CurrentSymlink=myContainer + + On updates this downloads https://download.example.com/myContainer_@v.tar.gz + and decompresses/unpacks it to /var/lib/machines/myContainer_@v. After each update + a symlink /var/lib/machines/myContainer is created/updated always pointing to the + most recent update. + + + + + See Also + + systemd1, + systemd-sysupdate8, + systemd-repart8 + + + + diff --git a/man/sysusers.d.xml b/man/sysusers.d.xml new file mode 100644 index 0000000..fd67c1f --- /dev/null +++ b/man/sysusers.d.xml @@ -0,0 +1,299 @@ + + + + + + + + sysusers.d + systemd + + + + sysusers.d + 5 + + + + sysusers.d + Declarative allocation of system users and groups + + + + /etc/sysusers.d/*.conf + /run/sysusers.d/*.conf + /usr/lib/sysusers.d/*.conf + + +#Type Name ID GECOS Home directory Shell +u user_name uid "User Description" /home/dir /path/to/shell +u user_name uid:gid "User Description" /home/dir /path/to/shell +u user_name /file/owned/by/user "User Description" /home/dir /path/to/shell +g group_name gid +g group_name /file/owned/by/group +m user_name group_name +r - lowest-highest + + + + Description + + systemd-sysusers uses the files from + sysusers.d directory to create system users and groups and + to add users to groups, at package installation or boot time. This tool may be + used to allocate system users and groups only, it is not useful for creating + non-system (i.e. regular, "human") users and groups, as it accesses + /etc/passwd and /etc/group directly, + bypassing any more complex user databases, for example any database involving NIS + or LDAP. + + + + Configuration Directories and Precedence + + Each configuration file shall be named in the style of + package.conf or + package-part.conf. + The second variant should be used when it is desirable to make it + easy to override just this part of configuration. + + Files in /etc/sysusers.d override files + with the same name in /usr/lib/sysusers.d and + /run/sysusers.d. Files in + /run/sysusers.d override files with the same + name in /usr/lib/sysusers.d. Packages should + install their configuration files in + /usr/lib/sysusers.d. Files in + /etc/sysusers.d are reserved for the local + administrator, who may use this logic to override the + configuration files installed by vendor packages. All + configuration files are sorted by their filename in lexicographic + order, regardless of which of the directories they reside in. If + multiple files specify the same path, the entry in the file with + the lexicographically earliest name will be applied. All later + entries for the same user and group names will be logged as warnings. + + + If the administrator wants to disable a configuration file + supplied by the vendor, the recommended way is to place a symlink + to /dev/null in + /etc/sysusers.d/ bearing the same filename. + + + + + Configuration File Format + + The file format is one line per user or group containing name, ID, GECOS + field description, home directory, and login shell: + + #Type Name ID GECOS Home directory Shell +u httpd 404 "HTTP User" +u _authd /usr/bin/authd "Authorization user" +u postgres - "Postgresql Database" /var/lib/pgsql /usr/libexec/postgresdb +g input - - +m _authd input +u root 0 "Superuser" /root /bin/zsh +r - 500-900 + + + Empty lines and lines beginning with the # character are ignored, and may be used for + commenting. + + + Type + + The type consists of a single letter. The following line + types are understood: + + + + u + Create a system user and group of the specified name should + they not exist yet. The user's primary group will be set to the group + bearing the same name unless the ID field specifies it. The account will be + created disabled, so that logins are not allowed. + + + + g + Create a system group of the specified name + should it not exist yet. Note that u + implicitly creates a matching group. The group will be + created with no password set. + + + + m + Add a user to a group. If the user or group + do not exist yet, they will be implicitly + created. + + + + r + Add a range of numeric UIDs/GIDs to the pool + to allocate new UIDs and GIDs from. If no line of this type + is specified, the range of UIDs/GIDs is set to some + compiled-in default. Note that both UIDs and GIDs are + allocated from the same pool, in order to ensure that users + and groups of the same name are likely to carry the same + numeric UID and GID. + + + + + + + Name + + The name field specifies the user or group name. The specified name must consist only of the characters a-z, + A-Z, 0-9, _ and -, except for the first character which must be one of a-z, + A-Z or _ (i.e. numbers and - are not permitted as first character). The + user/group name must have at least one character, and at most 31. + + For further details about the syntax of user/group names, see User/Group Name Syntax. + + It is strongly recommended to pick user and group names that are unlikely to clash with normal users + created by the administrator. A good scheme to guarantee this is by prefixing all system and group names with the + underscore, and avoiding too generic names. + + For m lines, this field should contain + the user name to add to a group. + + For lines of type r, this field should + be set to -. + + + + ID + + For u and g, the + numeric 32-bit UID or GID of the user/group. Do not use IDs 65535 + or 4294967295, as they have special placeholder meanings. + Specify - for automatic UID/GID allocation + for the user or group (this is strongly recommended unless it is strictly + necessary to use a specific UID or GID). Alternatively, specify an absolute path + in the file system. In this case, the UID/GID is read from the + path's owner/group. This is useful to create users whose UID/GID + match the owners of pre-existing files (such as SUID or SGID + binaries). + The syntaxes uid:gid and + uid:groupname are supported to + allow creating users with specific primary groups. The given group must be created explicitly, or it + must already exist. Specifying - for the UID in these syntaxes is also supported. + + + For m lines, this field should contain + the group name to add to a user to. + + For lines of type r, this field should + be set to a UID/GID range in the format + FROM-TO, where both values are formatted as + decimal ASCII numbers. Alternatively, a single UID/GID may be + specified formatted as decimal ASCII numbers. + + + + GECOS + + A short, descriptive string for users to be created, enclosed in + quotation marks. Note that this field may not contain colons. + + Only applies to lines of type u and should otherwise + be left unset (or -). + + + + Home Directory + + The home directory for a new system user. If omitted, defaults to the + root directory. + + Only applies to lines of type u and should otherwise + be left unset (or -). It is recommended to omit this, unless + software strictly requires a home directory to be set. + + systemd-sysusers only sets the home directory record in the + user database. To actually create the directory, consider adding a corresponding + tmpfiles.d5 + fragment. + + + + Shell + + The login shell of the user. If not specified, this will be set to + /usr/sbin/nologin, except if the UID of the user is 0, in + which case /bin/sh will be used. + + Only applies to lines of type u and should otherwise + be left unset (or -). It is recommended to omit this, unless + a shell different /usr/sbin/nologin must be used. + + + + + Specifiers + + Specifiers can be used in the Name, ID, + GECOS, Home directory, and Shell fields. An + unknown or unresolvable specifier is treated as invalid configuration. The following expansions are + understood: + + + Specifiers available + + + + + + + Specifier + Meaning + Details + + + + + + + + + + + + + + + + + + + + +
+ + + + Idempotence + + Note that systemd-sysusers will do nothing if the + specified users or groups already exist or the users are members of specified + groups, so normally there is no reason to override + sysusers.d vendor configuration, except to block certain + users or groups from being created. + + + + See Also + + systemd1, + systemd-sysusers8 + + + + diff --git a/man/tc.xml b/man/tc.xml new file mode 100644 index 0000000..e5c70d4 --- /dev/null +++ b/man/tc.xml @@ -0,0 +1,48 @@ + + + + + + + + + Parent= + + Configures the parent Queueing Discipline (qdisc). Takes one of root, + clsact, ingress or a class identifier. The class identifier is + specified as the major and minor numbers in hexadecimal in the range 0x1–Oxffff separated with a + colon (major:minor). Defaults to root. + + + + + Handle= + + Configures the major number of unique identifier of the qdisc, known as the handle. + Takes a hexadecimal number in the range 0x1–0xffff. Defaults to unset. + + + + + Parent= + + Configures the parent Queueing Discipline (qdisc). Takes one of root, or a + qdisc identifier. The qdisc identifier is specified as the major and minor numbers in hexadecimal in + the range 0x1–Oxffff separated with a colon (major:minor). Defaults to + root. + + + + + + ClassId= + + Configures the unique identifier of the class. It is specified as the major and minor numbers in + hexadecimal in the range 0x1–Oxffff separated with a colon (major:minor). + Defaults to unset. + + + + diff --git a/man/telinit.xml b/man/telinit.xml new file mode 100644 index 0000000..294b359 --- /dev/null +++ b/man/telinit.xml @@ -0,0 +1,151 @@ + + + + + + + + telinit + systemd + + + + telinit + 8 + + + + telinit + Change SysV runlevel + + + + + telinit OPTIONS COMMAND + + + + + Description + + telinit may be used to change the SysV + system runlevel. Since the concept of SysV runlevels is obsolete + the runlevel requests will be transparently translated into + systemd unit activation requests. + + + + + Options + + The following options are understood: + + + + + + + + + + + + Do not send wall message before + reboot/halt/power-off. + + + + The following commands are understood: + + + + 0 + + Power-off the machine. This is translated into + an activation request for poweroff.target + and is equivalent to systemctl + poweroff. + + + + 6 + + Reboot the machine. This is translated into an + activation request for reboot.target and + is equivalent to systemctl + reboot. + + + + 2 + 3 + 4 + 5 + + Change the SysV runlevel. This is translated + into an activation request for + runlevel2.target, + runlevel3.target, … and is equivalent + to systemctl isolate runlevel2.target, + systemctl isolate runlevel3.target, + … + + + + 1 + s + S + + Change into system rescue mode. This is + translated into an activation request for + rescue.target and is equivalent to + systemctl rescue. + + + + q + Q + + Reload daemon configuration. This is + equivalent to systemctl + daemon-reload. + + + + u + U + + Serialize state, reexecute daemon and + deserialize state again. This is equivalent to + systemctl daemon-reexec. + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure + code otherwise. + + + + Notes + + This is a legacy command available for compatibility only. + It should not be used anymore, as the concept of runlevels is + obsolete. + + + + See Also + + systemd1, + systemctl1, + wall1 + + + diff --git a/man/threads-aware.xml b/man/threads-aware.xml new file mode 100644 index 0000000..fb38d07 --- /dev/null +++ b/man/threads-aware.xml @@ -0,0 +1,15 @@ + + + + + + +All functions listed here are thread-agnostic and only a single specific thread may operate on a +given object during its entire lifetime. It's safe to allocate multiple independent objects and use each from a +specific thread in parallel. However, it's not safe to allocate such an object in one thread, and operate or free it +from any other, even if locking is used to ensure these threads don't operate on it at the very same time. + +All functions listed here are thread-safe and may be called in parallel from multiple threads. + + diff --git a/man/timedatectl.xml b/man/timedatectl.xml new file mode 100644 index 0000000..974431f --- /dev/null +++ b/man/timedatectl.xml @@ -0,0 +1,326 @@ + + + + + + + + timedatectl + systemd + + + + timedatectl + 1 + + + + timedatectl + Control the system time and date + + + + + timedatectl + OPTIONS + COMMAND + + + + + Description + + timedatectl may be used to query and change the system clock and its settings, + and enable or disable time synchronization services. + + Use + systemd-firstboot1 + to initialize the system time zone for mounted (but not booted) + system images. + + timedatectl may be used to show the current status of time synchronization + services, for example + systemd-timesyncd.service8. + + + + + + Commands + + The following commands are understood: + + + + status + + Show current settings of the system clock and RTC, including whether network time + synchronization is active. If no command is specified, this is the implied default. + + + + + show + + Show the same information as , but in machine readable form. + This command is intended to be used whenever computer-parsable output is required. + Use if you are looking for formatted human-readable output. + By default, empty properties are suppressed. Use to show those too. + To select specific properties to show, use . + + + + set-time [TIME] + + Set the system clock to the specified time. + This will also update the RTC time accordingly. The time may + be specified in the format "2012-10-30 + 18:17:16". + + + + set-timezone [TIMEZONE] + + Set the system time zone to the specified + value. Available timezones can be listed with + list-timezones. If the RTC is configured to + be in the local time, this will also update the RTC time. This + call will alter the /etc/localtime + symlink. See + localtime5 + for more information. + + + + list-timezones + + List available time zones, one per line. + Entries from the list can be set as the system timezone with + set-timezone. + + + + set-local-rtc [BOOL] + + Takes a boolean argument. If + 0, the system is configured to maintain the + RTC in universal time. If 1, it will + maintain the RTC in local time instead. Note that maintaining + the RTC in the local timezone is not fully supported and will + create various problems with time zone changes and daylight + saving adjustments. If at all possible, keep the RTC in UTC + mode. Note that invoking this will also synchronize the RTC + from the system clock, unless + is passed (see above). + This command will change the 3rd line of + /etc/adjtime, as documented in + hwclock8. + + + + + set-ntp [BOOL] + + Takes a boolean argument. Controls whether network time synchronization is active and + enabled (if available). If the argument is true, this enables and starts the first existing network + synchronization service. If the argument is false, then this disables and stops the known network + synchronization services. The way that the list of services is built is described in + systemd-timedated.service8. + + + + + + + systemd-timesyncd Commands + + The following commands are specific to + systemd-timesyncd.service8. + + + + + timesync-status + + Show current status of + systemd-timesyncd.service8. + If is specified, then this will monitor the status updates. + + + + show-timesync + + Show the same information as , but in machine readable form. + This command is intended to be used whenever computer-parsable output is required. + Use if you are looking for formatted human-readable output. + By default, empty properties are suppressed. Use to show those too. + To select specific properties to show, use . + + + + ntp-servers INTERFACE SERVER… + + Set the interface specific NTP servers. This command can be used only when the + interface is managed by systemd-networkd. + + + + revert INTERFACE + + Revert the interface specific NTP servers. This command can be used only when + the interface is managed by systemd-networkd. + + + + + + + + + Options + + The following options are understood: + + + + + + Do not query the user for authentication for + privileged operations. + + + + + + If set-local-rtc is invoked + and this option is passed, the system clock is synchronized + from the RTC again, taking the new setting into account. + Otherwise, the RTC is synchronized from the system + clock. + + + + + + If timesync-status is invoked and this option is passed, then + timedatectl monitors the status of + systemd-timesyncd.service8 + and updates the outputs. Use CtrlC to terminate the + monitoring. + + + + + + + When showing properties of + systemd-timesyncd.service8, + show all properties regardless of whether they are set or not. + + + + + + + When showing properties of + systemd-timesyncd.service8, + limit display to certain properties as specified as argument. If not specified, all set properties are shown. + The argument should be a property name, such as ServerName. If specified more than once, + all properties with the specified names are shown. + + + + + + + When printing properties with show-timesync, only print the value, and skip the + property name and =. + + + + + + + + + + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + + + Examples + Show current settings: + $ timedatectl + Local time: Thu 2017-09-21 16:08:56 CEST + Universal time: Thu 2017-09-21 14:08:56 UTC + RTC time: Thu 2017-09-21 14:08:56 + Time zone: Europe/Warsaw (CEST, +0200) +System clock synchronized: yes + NTP service: active + RTC in local TZ: no + + + Enable network time synchronization: + $ timedatectl set-ntp true +==== AUTHENTICATING FOR org.freedesktop.timedate1.set-ntp === +Authentication is required to control whether network time synchronization shall be enabled. +Authenticating as: user +Password: ******** +==== AUTHENTICATION COMPLETE === + + $ systemctl status systemd-timesyncd.service +● systemd-timesyncd.service - Network Time Synchronization + Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled) + Active: active (running) since Mo 2015-03-30 14:20:38 CEST; 5s ago + Docs: man:systemd-timesyncd.service(8) + Main PID: 595 (systemd-timesyn) + Status: "Using Time Server 216.239.38.15:123 (time4.google.com)." + CGroup: /system.slice/systemd-timesyncd.service + └─595 /usr/lib/systemd/systemd-timesyncd +… + + + Show current status of + systemd-timesyncd.service8: + $ timedatectl timesync-status + Server: 216.239.38.15 (time4.google.com) +Poll interval: 1min 4s (min: 32s; max 34min 8s) + Leap: normal + Version: 4 + Stratum: 1 + Reference: GPS + Precision: 1us (-20) +Root distance: 335us (max: 5s) + Offset: +316us + Delay: 349us + Jitter: 0 + Packet count: 1 + Frequency: -8.802ppm + + + + + + See Also + + systemd1, + hwclock8, + date1, + localtime5, + systemctl1, + systemd-timedated.service8, + systemd-timesyncd.service8, + systemd-firstboot1 + + + + diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml new file mode 100644 index 0000000..07472cd --- /dev/null +++ b/man/timesyncd.conf.xml @@ -0,0 +1,130 @@ + + + + + + + timesyncd.conf + systemd + + + + timesyncd.conf + 5 + + + + timesyncd.conf + timesyncd.conf.d + Network Time Synchronization configuration files + + + + /etc/systemd/timesyncd.conf + /etc/systemd/timesyncd.conf.d/*.conf + /run/systemd/timesyncd.conf.d/*.conf + /usr/lib/systemd/timesyncd.conf.d/*.conf + + + + Description + + These configuration files control NTP network time synchronization. See + systemd.syntax7 + for a general description of the syntax. + + + + + + Options + + The following settings are configured in the [Time] section: + + + + + NTP= + A space-separated list of NTP server host names or IP addresses. During runtime this + list is combined with any per-interface NTP servers acquired from + systemd-networkd.service8. + systemd-timesyncd will contact all configured system or per-interface servers in + turn, until one responds. When the empty string is assigned, the list of NTP servers is reset, and + all prior assignments will have no effect. This setting defaults to an empty list. + + + + FallbackNTP= + A space-separated list of NTP server host names or IP addresses to be used as the + fallback NTP servers. Any per-interface NTP servers obtained from + systemd-networkd.service8 + take precedence over this setting, as do any servers set via NTP= above. This + setting is hence only relevant if no other NTP server information is known. When the empty string is + assigned, the list of NTP servers is reset, and all prior assignments will have no effect. If this + option is not given, a compiled-in list of NTP servers is used. + + + + RootDistanceMaxSec= + Maximum acceptable root distance, i.e. the maximum estimated time required for a + packet to travel to the server we are connected to from the server with the reference clock. If + the current server does not satisfy this limit, systemd-timesyncd will switch + to a different server. + + Takes a time span value. The default unit is seconds, but other units may be specified, see + systemd.time5. + Defaults to 5 seconds. + + + + PollIntervalMinSec= + PollIntervalMaxSec= + The minimum and maximum poll intervals for NTP messages. Polling starts at the + minimum poll interval, and is adjusted within the specified limits in response to received packets. + + + Each setting takes a time span value. The default unit is seconds, but other units may be + specified, see + systemd.time5. + PollIntervalMinSec= defaults to 32 seconds and must not be smaller than + 16 seconds. PollIntervalMaxSec= defaults to 34 min 8 s (2048 seconds) and must be + larger than PollIntervalMinSec=. + + + + ConnectionRetrySec= + Specifies the minimum delay before subsequent attempts to contact a new NTP server + are made. + + Takes a time span value. The default unit is seconds, but other units may be specified, see + systemd.time5. + Defaults to 30 seconds and must not be smaller than 1 second. + + + + SaveIntervalSec= + The interval at which the current time is periodically saved to disk, in the absence + of any recent synchronisation from an NTP server. This is especially useful for offline systems + with no local RTC, as it will guarantee that the system clock remains roughly monotonic across + reboots. + + Takes a time interval value. The default unit is seconds, but other units may be specified, see + systemd.time5. + Defaults to 60 seconds. + + + + + + + See Also + + systemd1, + systemd-timesyncd.service8, + systemd-networkd.service8 + + + + diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml new file mode 100644 index 0000000..e1c0201 --- /dev/null +++ b/man/tmpfiles.d.xml @@ -0,0 +1,872 @@ + + + + + + + tmpfiles.d + systemd + + + + tmpfiles.d + 5 + + + + tmpfiles.d + Configuration for creation, deletion and cleaning of + volatile and temporary files + + + + /etc/tmpfiles.d/*.conf +/run/tmpfiles.d/*.conf +/usr/lib/tmpfiles.d/*.conf + + + ~/.config/user-tmpfiles.d/*.conf +$XDG_RUNTIME_DIR/user-tmpfiles.d/*.conf +~/.local/share/user-tmpfiles.d/*.conf +… +/usr/share/user-tmpfiles.d/*.conf + + + #Type Path Mode User Group Age Argument +f /file/to/create mode user group - content +f+ /file/to/create-or-truncate mode user group - content +w /file/to/write-to - - - - content +w+ /file/to/append-to - - - - content +d /directory/to/create-and-clean-up mode user group cleanup-age - +D /directory/to/create-and-remove mode user group cleanup-age - +e /directory/to/clean-up mode user group cleanup-age - +v /subvolume-or-directory/to/create mode user group cleanup-age - +q /subvolume-or-directory/to/create mode user group cleanup-age - +Q /subvolume-or-directory/to/create mode user group cleanup-age - +p /fifo/to/create mode user group - - +p+ /fifo/to/[re]create mode user group - - +L /symlink/to/create - - - - symlink/target/path +L+ /symlink/to/[re]create - - - - symlink/target/path +c /dev/char-device-to-create mode user group - major:minor +c+ /dev/char-device-to-[re]create mode user group - major:minor +b /dev/block-device-to-create mode user group - major:minor +b+ /dev/block-device-to-[re]create mode user group - major:minor +C /target/to/create - - - cleanup-age /source/to/copy +x /path-or-glob/to/ignore/recursively - - - cleanup-age - +X /path-or-glob/to/ignore - - - cleanup-age - +r /path-or-glob/to/remove - - - - - +R /path-or-glob/to/remove/recursively - - - - - +z /path-or-glob/to/adjust/mode mode user group - - +Z /path-or-glob/to/adjust/mode/recursively mode user group - - +t /path-or-glob/to/set/xattrs - - - - xattrs +T /path-or-glob/to/set/xattrs/recursively - - - - xattrs +h /path-or-glob/to/set/attrs - - - - file attrs +H /path-or-glob/to/set/attrs/recursively - - - - file attrs +a /path-or-glob/to/set/acls - - - - POSIX ACLs +a+ /path-or-glob/to/append/acls - - - - POSIX ACLs +A /path-or-glob/to/set/acls/recursively - - - - POSIX ACLs +A+ /path-or-glob/to/append/acls/recursively - - - - POSIX ACLs + + + + + + Description + + tmpfiles.d configuration files provide a generic mechanism to define the + creation of regular files, directories, pipes, and device nodes, adjustments to + their access mode, ownership, attributes, quota assignments, and contents, and + finally their time-based removal. It is mostly commonly used for volatile and + temporary files and directories (such as those located under /run/, + /tmp/, /var/tmp/, the API file systems such as + /sys/ or /proc/, as well as some other directories below + /var/). + + systemd-tmpfiles uses this configuration to create volatile files and + directories during boot and to do periodic cleanup afterwards. See + systemd-tmpfiles8 for + the description of systemd-tmpfiles-setup.service, + systemd-tmpfiles-clean.service, and associated units. + + System daemons frequently require private runtime directories below /run/ to + store communication sockets and similar. For these, it is better to use + RuntimeDirectory= in their unit files (see + systemd.exec5 for + details), if the flexibility provided by tmpfiles.d is not required. The advantages + are that the configuration required by the unit is centralized in one place, and that the lifetime of the + directory is tied to the lifetime of the service itself. Similarly, StateDirectory=, + CacheDirectory=, LogsDirectory=, and + ConfigurationDirectory= should be used to create directories under + /var/lib/, /var/cache/, /var/log/, and + /etc/. tmpfiles.d should be used for files whose lifetime is + independent of any service or requires more complicated configuration. + + + + Configuration Directories and Precedence + + Each configuration file shall be named in the style of + package.conf or + package-part.conf. + The second variant should be used when it is desirable to make it + easy to override just this part of configuration. + + Files in /etc/tmpfiles.d override files with the same name in + /usr/lib/tmpfiles.d and /run/tmpfiles.d. Files in + /run/tmpfiles.d override files with the same name in + /usr/lib/tmpfiles.d. Packages should install their configuration files in + /usr/lib/tmpfiles.d. Files in /etc/tmpfiles.d are reserved for + the local administrator, who may use this logic to override the configuration files installed by vendor + packages. All configuration files are sorted by their filename in lexicographic order, regardless of + which of the directories they reside in. If multiple files specify the same path, the entry in the file + with the lexicographically earliest name will be applied (note that lines suppressed due to the + ! are filtered before application, meaning that if an early line carries the + exclamation mark and is suppressed because of that, a later line matching in path will be applied). All + other conflicting entries will be logged as errors. When two lines are prefix path and suffix path of + each other, then the prefix line is always created first, the suffix later (and if removal applies to the + line, the order is reversed: the suffix is removed first, the prefix later). Lines that take globs are + applied after those accepting no globs. If multiple operations shall be applied on the same file (such as + ACL, xattr, file attribute adjustments), these are always done in the same fixed order. Except for those + cases, the files/directories are processed in the order they are listed. + + If the administrator wants to disable a configuration file + supplied by the vendor, the recommended way is to place a symlink + to /dev/null in + /etc/tmpfiles.d/ bearing the same filename. + + + + + Configuration File Format + + The configuration format is one line per path, containing type, path, mode, ownership, age, and + argument fields. The lines are separated by newlines, the fields by whitespace: + + #Type Path Mode User Group Age Argument… +d /run/user 0755 root root 10d - +L /tmp/foobar - - - - /dev/null + + Fields may contain C-style escapes. With the exception of the seventh field (the "argument") all + fields may be enclosed in quotes. Note that any whitespace found in the line after the beginning of the + argument field will be considered part of the argument field. To begin the argument field with a + whitespace character, use C-style escapes (e.g. \x20). + + + Type + + The type consists of a single letter and optionally one or emore modifier characters: a plus sign + (+), exclamation mark (!), minus sign (-), + equals sign (=), tilde character (~) and/or caret + (^). + + The following line types are understood: + + + + f + f+ + f will create a file if it does not exist yet. If the argument + parameter is given and the file did not exist yet, it will be written to the file. + f+ will create or truncate the file. If the argument parameter is given, it will + be written to the file. Does not follow symlinks. + + + + w + w+ + Write the argument parameter to a file, if the file exists. + If suffixed with +, the line will be appended to the file. + If your configuration writes multiple lines to the same file, use w+. + Lines of this type accept shell-style globs in place of normal path names. + The argument parameter will be written without a trailing newline. + C-style backslash escapes are interpreted. Follows symlinks. + + + + d + Create a directory. The mode and ownership will be adjusted if specified. Contents + of this directory are subject to time-based cleanup if the age argument is specified. + + + + + D + Similar to d, but in addition the contents of the directory will + be removed when is used. + + + + e + Adjust the mode and ownership of existing directories and remove their contents + based on age. + Lines of this type accept shell-style globs in place of normal path names. Contents of the + directories are subject to time-based cleanup if the age argument is specified. If the age argument + is 0, contents will be unconditionally deleted every time + systemd-tmpfiles --clean is run. + + For this entry to be useful, at least one of the mode, user, group, or age arguments must be + specified, since otherwise this entry has no effect. As an exception, an entry with no effect may + be useful when combined with !, see the examples. + + + + v + Create a subvolume if the path does not exist yet, the file system supports + subvolumes (btrfs), and the system itself is installed into a subvolume (specifically: the root + directory / is itself a subvolume). Otherwise, create a normal directory, in + the same way as d. + + A subvolume created with this line type is not assigned to any higher-level quota group. For + that, use q or Q, which allow creating simple quota group + hierarchies, see below. + + + + q + Create a subvolume or directory the same as v, but assign the + subvolume to the same higher-level quota groups as the parent. This ensures that higher-level + limits and accounting applied to the parent subvolume also include the specified subvolume. On + non-btrfs file systems, this line type is identical to d. + + If the subvolume already exists, no change to the quota hierarchy is made, regardless of whether the + subvolume is already attached to a quota group or not. Also see Q below. See btrfs-qgroup8 for + details about the btrfs quota group concept. + + + + Q + Create the subvolume or directory the same as v, but assign the + new subvolume to a new leaf quota group. Instead of copying the higher-level quota group + assignments from the parent as is done with q, the lowest quota group of the + parent subvolume is determined that is not the leaf quota group. Then, an "intermediary" quota + group is inserted that is one level below this level, and shares the same ID part as the specified + subvolume. If no higher-level quota group exists for the parent subvolume, a new quota group at + level 255 sharing the same ID as the specified subvolume is inserted instead. This new intermediary + quota group is then assigned to the parent subvolume's higher-level quota groups, and the specified + subvolume's leaf quota group is assigned to it. + + Effectively, this has a similar effect as q, however introduces a new higher-level + quota group for the specified subvolume that may be used to enforce limits and accounting to the specified + subvolume and children subvolume created within it. Thus, by creating subvolumes only via + q and Q, a concept of "subtree quotas" is implemented. Each subvolume + for which Q is set will get a "subtree" quota group created, and all child subvolumes + created within it will be assigned to it. Each subvolume for which q is set will not get + such a "subtree" quota group, but it is ensured that they are added to the same "subtree" quota group as + their immediate parents. + + It is recommended to use Q for subvolumes that typically contain further subvolumes, + and where it is desirable to have accounting and quota limits on all child subvolumes together. Examples for + Q are typically /home/ or /var/lib/machines/. In + contrast, q should be used for subvolumes that either usually do not include further + subvolumes or where no accounting and quota limits are needed that apply to all child subvolumes + together. Examples for q are typically /var/ or + /var/tmp/. + + As with q, Q has no effect on the quota group hierarchy if the + subvolume already exists, regardless of whether the subvolume already belong to a quota group or not. + + + + + p + p+ + Create a named pipe (FIFO) if it does not + exist yet. If suffixed with + and a file + already exists where the pipe is to be created, it will be + removed and be replaced by the pipe. + + + + L + L+ + Create a symlink if it does not exist + yet. If suffixed with + and a file or + directory already exists where the symlink is to be created, + it will be removed and be replaced by the symlink. If the + argument is omitted, symlinks to files with the same name + residing in the directory + /usr/share/factory/ are created. Note + that permissions and ownership on symlinks are ignored. + + + + + c + c+ + Create a character device node if it does + not exist yet. If suffixed with + and a + file already exists where the device node is to be created, + it will be removed and be replaced by the device node. It is + recommended to suffix this entry with an exclamation mark to + only create static device nodes at boot, as udev will not + manage static device nodes that are created at runtime. + + + + + b + b+ + Create a block device node if it does not + exist yet. If suffixed with + and a file + already exists where the device node is to be created, it + will be removed and be replaced by the device node. It is + recommended to suffix this entry with an exclamation mark to + only create static device nodes at boot, as udev will not + manage static device nodes that are created at runtime. + + + + + C + Recursively copy a file or directory, if the + destination files or directories do not exist yet or the + destination directory is empty. Note that this command will not + descend into subdirectories if the destination directory already + exists and is not empty. Instead, the entire copy operation is + skipped. If the argument is omitted, files from the source directory + /usr/share/factory/ with the same name + are copied. Does not follow symlinks. Contents of the directories + are subject to time-based cleanup if the age argument is specified. + + + + + x + Ignore a path during cleaning. Use this type + to exclude paths from clean-up as controlled with the Age + parameter. Note that lines of this type do not influence the + effect of r or R + lines. Lines of this type accept shell-style globs in place + of normal path names. + + + + X + Ignore a path during cleaning. Use this type + to exclude paths from clean-up as controlled with the Age + parameter. Unlike x, this parameter will + not exclude the content if path is a directory, but only + directory itself. Note that lines of this type do not + influence the effect of r or + R lines. Lines of this type accept + shell-style globs in place of normal path names. + + + + + r + Remove a file or directory if it exists. + This may not be used to remove non-empty directories, use + R for that. Lines of this type accept + shell-style globs in place of normal path + names. Does not follow symlinks. + + + + R + Recursively remove a path and all its + subdirectories (if it is a directory). Lines of this type + accept shell-style globs in place of normal path + names. Does not follow symlinks. + + + + z + Adjust the access mode, user and group ownership, and restore the SELinux security + context of a file or directory, if it exists. Lines of this type accept shell-style globs in place + of normal path names. Does not follow symlinks. + + + + Z + Recursively set the access mode, user and group ownership, and restore the SELinux + security context of a file or directory if it exists, as well as of its subdirectories and the + files contained therein (if applicable). Lines of this type accept shell-style globs in place of + normal path names. Does not follow symlinks. + + + + t + Set extended attributes, see attr + 5 for details. The argument field should take one or more + assignment expressions in the form + namespace.attribute=value, + for examples see below. Lines of this type accept shell-style globs in place of normal path + names. This can be useful for setting SMACK labels. Does not follow symlinks. + + Please note that extended attributes settable with this line type are a different concept + from the Linux file attributes settable with h/H, see + below. + + + + T + Same as t, but operates recursively. + + + + h + Set Linux file/directory attributes. Lines of this type accept shell-style globs in + place of normal path names. + + The format of the argument field is [+-=][aAcCdDeijPsStTu]. The prefix + + (the default one) causes the attributes to be added; - + causes the attributes to be removed; = causes the attributes to be set exactly + as the following letters. The letters aAcCdDeijPsStTu select the new attributes + for the files, see chattr + 1 for further information. + + + Passing only = as argument resets all the file attributes listed above. It + has to be pointed out that the = prefix limits itself to the attributes + corresponding to the letters listed here. All other attributes will be left untouched. Does not + follow symlinks. + + Please note that the Linux file attributes settable with this line type are a different + concept from the extended attributes settable with t/T, + see above. + + + + H + Sames as h, but operates recursively. + + + + a + a+ + Set POSIX ACLs (access control lists), see acl + 5. If suffixed with +, the specified + entries will be added to the existing set. systemd-tmpfiles will automatically + add the required base entries for user and group based on the access mode of the file, unless base + entries already exist or are explicitly specified. The mask will be added if not specified + explicitly or already present. Lines of this type accept shell-style globs in place of normal path + names. This can be useful for allowing additional access to certain files. Does not follow + symlinks. + + + + A + A+ + Same as a and + a+, but recursive. Does not follow + symlinks. + + + + + + Type Modifiers + + If the exclamation mark (!) is used, this line is only safe to execute during + boot, and can break a running system. Lines without the exclamation mark are presumed to be safe to + execute at any time, e.g. on package upgrades. systemd-tmpfiles will take lines with + an exclamation mark only into consideration, if the option is given. + + For example: + # Make sure these are created by default so that nobody else can +d /tmp/.X11-unix 1777 root root 10d + +# Unlink the X11 lock files +r! /tmp/.X[0-9]*-lock + The second line in contrast to the first one would break a + running system, and will only be executed with + . + + If the minus sign (-) is used, this line failing to run successfully during + create (and only create) will not cause the execution of systemd-tmpfiles to return + an error. + + For example: + # Modify sysfs but don't fail if we are in a container with a read-only /proc +w- /proc/sys/vm/swappiness - - - - 10 + + If the equals sign (=) is used, the file types of existing objects in the specified path + are checked, and removed if they do not match. This includes any implicitly created parent directories (which can + be either directories or directory symlinks). For example, if there is a FIFO in place of one of the parent path + components it will be replaced with a directory. + + If the tilde character (~) is used, the argument (i.e. 6th) column is Base64 decoded before use. This modifier is + only supported on line types that can write file contents, i.e. f, + f+, w, +. This is useful for writing arbitrary + binary data (including newlines and NUL bytes) to files. Note that if this switch is used, the argument + is not subject to specifier expansion, neither before nor after Base64 decoding. + + If the caret character (^) is used, the argument (i.e. 6th) column takes a + service credential name to read the argument data from. See System and Service Credentials for details about the + credentials concept. This modifier is only supported on line types that can write file contents, + i.e. f, f+, w, w+. This is + useful for writing arbitrary files with contents sourced from elsewhere, including from VM or container + managers further up. If the specified credential is not set for the systemd-tmpfiles + service, the line is silently skipped. If ^ and ~ are combined + Base64 decoding is applied to the credential contents. + + Note that for all line types that result in creation of any kind of file node + (i.e. f/F, + d/D/v/q/Q, + p, L, c/b and C) + leading directories are implicitly created if needed, owned by root with an access mode of 0755. In order to + create them with different modes or ownership make sure to add appropriate d lines. + + + + Path + + The file system path specification supports simple + specifier expansion, see below. The path (after expansion) must be + absolute. + + + + Mode + + The file access mode to use when creating this file or directory. If omitted or when set to + -, the default is used: 0755 for directories, 0644 for all other file objects. For + z, Z lines, if omitted or when set to -, the + file access mode will not be modified. This parameter is ignored for x, + r, R, L, t, and + a lines. + + Optionally, if prefixed with ~, the access mode is masked based on the already + set access bits for existing file or directories: if the existing file has all executable bits unset, + all executable bits are removed from the new access mode, too. Similarly, if all read bits are removed + from the old access mode, they will be removed from the new access mode too, and if all write bits are + removed, they will be removed from the new access mode too. In addition, the sticky/SUID/SGID bit is + removed unless applied to a directory. This functionality is particularly useful in conjunction with + Z. + + By default the access mode of listed inodes is set to the specified mode regardless if it is + created anew, or already existed. Optionally, if prefixed with :, the configured + access mode is only applied when creating new inodes, and if the inode the line refers to + already exists, its access mode is left in place unmodified. + + + + User, Group + + The user and group to use for this file or directory. This may either be a numeric ID or a + user/group name. If omitted or when set to -, the user and group of the user who + invokes systemd-tmpfiles is used. For z and Z + lines, when omitted or when set to -, the file ownership will not be modified. These + parameters are ignored for x, r, R, + L, t, and a lines. + + This field should generally only reference system users/groups, i.e. users/groups that are + guaranteed to be resolvable during early boot. If this field references users/groups that only become + resolveable during later boot (i.e. after NIS, LDAP or a similar networked directory service become + available), execution of the operations declared by the line will likely fail. Also see Notes on + Resolvability of User and Group Names for more information on requirements on system user/group + definitions. + + By default the ownership of listed inodes is set to the specified user/group regardless if it is + created anew, or already existed. Optionally, if prefixed with :, the configured + user/group information is only applied when creating new inodes, and if the inode the line refers to + already exists, its user/group is left in place unmodified. + + + + Age + + The date field, when set, is used to decide what files to + delete when cleaning. If a file or directory is older than the + current time minus the age field, it is deleted. The field + format is a series of integers each followed by one of the + following suffixes for the respective time units: + s, + m or min, + h, + d, + w, + ms, and + us, + meaning seconds, minutes, hours, days, weeks, + milliseconds, and microseconds, respectively. Full names of the time units can + be used too. + + + If multiple integers and units are specified, the time + values are summed. If an integer is given without a unit, + s is assumed. + + + When the age is set to zero, the files are cleaned + unconditionally. + + The age field only applies to lines starting with + d, D, e, + v, q, + Q, C, x + and X. If omitted or set to + -, no automatic clean-up is done. + + If the age field starts with a tilde character ~, clean-up is only applied to + files and directories one level inside the directory specified, but not the files and directories + immediately inside it. + + The age of a file system entry is determined from its last + modification timestamp (mtime), its last access timestamp (atime), + and (except for directories) its last status change timestamp + (ctime). By default, any of these three (or two) values will + prevent cleanup if it is more recent than the current time minus + the age field. To restrict the deletion based on particular type + of file timestamps, the age-by argument can be used. + + The age-by argument overrides the timestamp types to be used for the age check. It can be + specified by prefixing the age argument with a sequence of characters to specify the timestamp types + and a colon (:): + age-by...:cleanup-age. The + argument can consist of a (A for directories), + b (B for directories), c + (C for directories), or m (M for + directories). Those respectively indicate access, creation, last status change, and last modification + time of a file system entry. The lower-case letter signifies that the given timestamp type should be + considered for files, while the upper-case letter signifies that the given timestamp type should be + considered for directories. See statx2 file + timestamp fields for more details about timestamp types. + + If not specified, the age-by field defaults to abcmABM, i.e. by default all + file timestamps are taken into consideration, with the exception of the last status change timestamp + (ctime) for directories. This is because the aging logic itself will alter the ctime whenever it + deletes a file inside it. To ensure that running the aging logic does not feed back into the next + iteration of itself, ctime for directories is ignored by default. + + For example: +# Files created and modified, and directories accessed more than +# an hour ago in "/tmp/foo/bar", are subject to time-based cleanup. +d /tmp/foo/bar - - - bmA:1h - + + Note that while the aging algorithm is run a 'shared' BSD file lock (see flock2) is + taken on each directory the algorithm descends into (and each directory below that, and so on). If the + aging algorithm finds a lock is already taken on some directory, it (and everything below it) is + skipped. Applications may use this to temporarily exclude certain directory subtrees from the aging + algorithm: the applications can take a BSD file lock themselves, and as long as they keep it aging of + the directory and everything below it is disabled. + + + + Argument + + For L lines determines the destination path of the symlink. For c and + b, determines the major/minor of the device node, with major and minor formatted as integers, + separated by :, e.g. 1:3. For f, F, + and w, the argument may be used to specify a short string that is written to the file, + suffixed by a newline. For C, specifies the source file or directory. For t + and T, determines extended attributes to be set. For a and + A, determines ACL attributes to be set. For h and H, + determines the file attributes to set. Ignored for all other lines. + + This field can contain specifiers, see below. + + + + + Specifiers + + Specifiers can be used in the "path" and "argument" fields. + An unknown or unresolvable specifier is treated as invalid configuration. + The following expansions are understood: + + Specifiers available + + + + + + + Specifier + Meaning + Details + + + + + + + + + %C + System or user cache directory + In mode, this is the same as $XDG_CACHE_HOME, and /var/cache otherwise. + + + %g + User group + This is the name of the group running the command. In case of the system instance this resolves to root. + + + %G + User GID + This is the numeric GID of the group running the command. In case of the system instance this resolves to 0. + + + %h + User home directory + This is the home directory of the user running the command. In case of the system instance this resolves to /root. + + + + + %L + System or user log directory + In mode, this is the same as $XDG_CONFIG_HOME with /log appended, and /var/log otherwise. + + + + + + %S + System or user state directory + In mode, this is the same as $XDG_CONFIG_HOME, and /var/lib otherwise. + + + %t + System or user runtime directory + In mode, this is the same $XDG_RUNTIME_DIR, and /run/ otherwise. + + + + %u + User name + This is the name of the user running the command. In case of the system instance this resolves to root. + + + %U + User UID + This is the numeric UID of the user running the command. In case of the system instance this resolves to 0. + + + + + + + + +
+ + + + Examples + + Create directories with specific mode and ownership + + screen1, + needs two directories created at boot with specific modes and ownership: + + # /usr/lib/tmpfiles.d/screen.conf +d /run/screens 1777 root screen 10d +d /run/uscreens 0755 root screen 10d12h + + + Contents of /run/screens and /run/uscreens will + be cleaned up after 10 and 10½ days, respectively. + + + + Create a directory with a SMACK attribute + D /run/cups - - - - +t /run/cups - - - - security.SMACK64=printing user.attr-with-spaces="foo bar" + + + The directory will be owned by root and have default mode. Its contents are + not subject to time-based cleanup, but will be obliterated when + systemd-tmpfiles --remove runs. + + + + Create a directory and prevent its contents from cleanup + + abrt1, + needs a directory created at boot with specific mode and ownership and its content + should be preserved from the automatic cleanup applied to the contents of + /var/tmp: + + # /usr/lib/tmpfiles.d/tmp.conf +d /var/tmp 1777 root root 30d + + + # /usr/lib/tmpfiles.d/abrt.conf +d /var/tmp/abrt 0755 abrt abrt - + + + + + Apply clean up during boot and based on time + + # /usr/lib/tmpfiles.d/dnf.conf +r! /var/cache/dnf/*/*/download_lock.pid +r! /var/cache/dnf/*/*/metadata_lock.pid +r! /var/lib/dnf/rpmdb_lock.pid +e /var/cache/dnf/ - - - 30d + + + The lock files will be removed during boot. Any files and directories in + /var/cache/dnf/ will be removed after they have not been + accessed in 30 days. + + + + Empty the contents of a cache directory on boot + + # /usr/lib/tmpfiles.d/krb5rcache.conf +e! /var/cache/krb5rcache - - - 0 + + + Any files and subdirectories in /var/cache/krb5rcache/ + will be removed on boot. The directory will not be created. + + + + + Provision SSH public key access for root user via Credentials in QEMU + + -smbios type=11,value=io.systemd.credential.binary:tmpfiles.extra=$(echo "f~ /root/.ssh/authorized_keys 700 root root - $(ssh-add -L | base64 -w 0)" | base64 -w 0) + + + By passing this line to QEMU, the public key of the current user will be encoded in + base64, added to a tmpfiles.d line that tells systemd-tmpfiles to decode it into + /root/.ssh/authorized_keys, encode that line itself in base64 and + pass it as a Credential that will be picked up by systemd from SMBIOS on boot. + + + + + + <filename>/run/</filename> and <filename>/var/run/</filename> + /var/run/ is a deprecated symlink to /run/, and + applications should use the latter. systemd-tmpfiles will warn if + /var/run/ is used. + + + + See Also + + systemd1, + systemd-tmpfiles8, + systemd-delta1, + systemd.exec5, + attr5, + getfattr1, + setfattr1, + setfacl1, + getfacl1, + chattr1, + btrfs-subvolume8, + btrfs-qgroup8 + + + + diff --git a/man/tpm2-crypttab.sh b/man/tpm2-crypttab.sh new file mode 100644 index 0000000..d109eb4 --- /dev/null +++ b/man/tpm2-crypttab.sh @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: MIT-0 + +# Enroll the TPM2 security chip in the LUKS2 volume, and bind it to PCR 7 +# only. Replace /dev/sdXn by the partition to use (e.g. /dev/sda1). +sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdXn + +# Test: Let's run systemd-cryptsetup to test if this worked. +sudo /usr/lib/systemd/systemd-cryptsetup attach mytest /dev/sdXn - tpm2-device=auto + +# If that worked, let's now add the same line persistently to /etc/crypttab, +# for the future. +sudo bash -c 'echo "mytest /dev/sdXn - tpm2-device=auto" >> /etc/crypttab' diff --git a/man/udev.conf.xml b/man/udev.conf.xml new file mode 100644 index 0000000..0f51a1a --- /dev/null +++ b/man/udev.conf.xml @@ -0,0 +1,127 @@ + + + + + + + + udev.conf + systemd + + + + udev.conf + 5 + + + + udev.conf + Configuration for device event managing daemon + + + + /etc/udev/udev.conf + + + + Description + + + systemd-udevd8 + expects its main configuration file at + /etc/udev/udev.conf. It consists of a set + of variables allowing the user to override default udev + values. All empty lines or lines beginning with '#' are + ignored. The following variables can be set: + + + + + udev_log= + + + The log level. Valid values are the numerical + syslog priorities or their textual representations: + , and + . + + + + + children_max= + + + An integer. The maximum number of events executed in parallel. + + This is the same as the option. + + + + + exec_delay= + + + An integer. Delay the execution of each RUN{program} + parameter by the given number of seconds. This option + might be useful when debugging system crashes during + coldplug caused by loading non-working kernel + modules. + + This is the same as the option. + + + + + event_timeout= + + + An integer. The number of seconds to wait for events to finish. After + this time, the event will be terminated. The default is 180 seconds. + + This is the same as the option. + + + + + resolve_names= + + + Specifies when systemd-udevd should resolve names of users and groups. When set to + (the default), names will be resolved when the rules are parsed. + When set to , names will be resolved for every event. When set to + , names will never be resolved and all devices will be owned by + root. + + This is the same as the option. + + + + + timeout_signal= + + + Specifies a signal that systemd-udevd will send on worker + timeouts. Note that both workers and spawned processes will be killed using this + signal. Defaults to . + + + + + + In addition, systemd-udevd can be configured + by command line options and the kernel command line (see + systemd-udevd8). + + + + + See Also + + systemd-udevd8, + udev7, + udevadm8 + + + diff --git a/man/udev.xml b/man/udev.xml new file mode 100644 index 0000000..332c7ac --- /dev/null +++ b/man/udev.xml @@ -0,0 +1,860 @@ + + + + + + + + udev + systemd + + + + udev + 7 + + + + udev + Dynamic device management + + + + Description + udev supplies the system software with device events, manages permissions + of device nodes and may create additional symlinks in the /dev/ + directory, or renames network interfaces. The kernel usually just assigns unpredictable + device names based on the order of discovery. Meaningful symlinks or network device + names provide a way to reliably identify devices based on their properties or + current configuration. + + The udev daemon, systemd-udevd.service + 8, receives device uevents directly from + the kernel whenever a device is added or removed from the system, or it changes its + state. When udev receives a device event, it matches its configured set of rules + against various device attributes to identify the device. Rules that match may + provide additional device information to be stored in the udev database or + to be used to create meaningful symlink names. + + All device information udev processes is stored in the udev database and + sent out to possible event subscribers. Access to all stored data and the event + sources is provided by the library libudev. + + + + Rules Files + The udev rules are read from the files located in the system rules directories + /usr/lib/udev/rules.d and /usr/local/lib/udev/rules.d, the + volatile runtime directory /run/udev/rules.d and the local administration + directory /etc/udev/rules.d. All rules files are collectively sorted and + processed in lexical order, regardless of the directories in which they live. However, files with + identical filenames replace each other. Files in /etc/ have the highest priority, + files in /run/ take precedence over files with the same name under + /usr/. This can be used to override a system-supplied rules file with a local + file if needed; a symlink in /etc/ with the same name as a rules file in + /usr/lib/, pointing to /dev/null, disables the rules file + entirely. Rule files must have the extension .rules; other extensions are + ignored. + + Every line in the rules file contains at least one key-value pair. + Except for empty lines or lines beginning with #, which are ignored. + There are two kinds of keys: match and assignment. + If all match keys match against their values, the rule gets applied and the + assignment keys get the specified values assigned. + + A matching rule may rename a network interface, add symlinks + pointing to the device node, or run a specified program as part of + the event handling. + + A rule consists of a comma-separated list of one or more key-operator-value expressions. + Each expression has a distinct effect, depending on the key and operator used. + + + Operators + + + == + + Compare for equality. (The specified key has the specified value.) + + + + + != + + Compare for inequality. (The specified key doesn't have the specified value, or the + specified key is not present at all.) + + + + + + = + + Assign a value to a key. Keys that represent a list are reset + and only this single value is assigned. + + + + + += + + Add the value to a key that holds a list of entries. + + + + + -= + + Remove the value from a key that holds a list of entries. + + + + + := + + Assign a value to a key finally; disallow any later changes. + + + + + + + Values + Values are written as double quoted strings, such as ("string"). + To include a quotation mark (") in the value, precede it by a backslash (\"). + Any other occurrences of a backslash followed by a character are not unescaped. + That is, "\t\n" is treated as four characters: + backslash, lowercase t, backslash, lowercase n. + + The string can be prefixed with a lowercase e (e"string\n") to mark the string as + C-style escaped. + For example, e"string\n" is parsed as 7 characters: 6 lowercase letters and a newline. + This can be useful for writing special characters when a kernel driver requires them. + + Please note that NUL is not allowed in either string variant. + + + + Keys + The following key names can be used to match against device properties. + Some of the keys also match against properties of the parent devices in sysfs, + not only the device that has generated the event. If multiple keys that match + a parent device are specified in a single rule, all these keys must match at + one and the same parent device. + + + ACTION + + Match the name of the event action. + + + + + DEVPATH + + Match the devpath of the event device. + + + + + KERNEL + + Match the name of the event device. + + + + + KERNELS + + Search the devpath upwards for a matching device name. + + + + + NAME + + Match the name of a network interface. It can be used once the + NAME key has been set in one of the preceding rules. + + + + + SYMLINK + + Match the name of a symlink targeting the node. It can be used once a SYMLINK key has + been set in one of the preceding rules. There may be multiple symlinks; only one needs to + match. If the operator is !=, the token returns true only if there is no + symlink matched. + + + + + SUBSYSTEM + + Match the subsystem of the event device. + + + + + SUBSYSTEMS + + Search the devpath upwards for a matching device subsystem name. + + + + + DRIVER + + Match the driver name of the event device. Only set this key for devices + which are bound to a driver at the time the event is generated. + + + + + DRIVERS + + Search the devpath upwards for a matching device driver name. + + + + + ATTR{filename} + + Match sysfs attribute value of the event device. + + Trailing whitespace in the attribute values is ignored unless the specified match value + itself contains trailing whitespace. + + + + + ATTRS{filename} + + Search the devpath upwards for a device with matching sysfs attribute values. If + multiple ATTRS matches are specified, all of them must match on the same + device. + + Trailing whitespace in the attribute values is ignored unless the specified match value + itself contains trailing whitespace. + + + + + SYSCTL{kernel parameter} + + Match a kernel parameter value. + + + + + ENV{key} + + Match against a device property value. + + + + + CONST{key} + + Match against a system-wide constant. Supported keys are: + + + arch + + System's architecture. See in + systemd.unit5 + for possible values. + + + + virt + + System's virtualization environment. See + systemd-detect-virt1 + for possible values. + + + + Unknown keys will never match. + + + + + TAG + + Match against one of device tags. It can be used once a TAG key has been set in one of + the preceding rules. There may be multiple tags; only one needs to match. If the operator is + !=, the token returns true only if there is no tag matched. + + + + + TAGS + + Search the devpath upwards for a device with matching tag. If the operator is + !=, the token returns true only if there is no tag matched. + + + + + TEST{octal mode mask} + + Test the existence of a file. An octal mode mask can be specified + if needed. + + + + + PROGRAM + + Execute a program to determine whether there is a match; the key is true if the program + returns successfully. The device properties are made available to the executed program in the + environment. The program's standard output is available in the RESULT + key. + + This can only be used for very short-running foreground tasks. For details, see + RUN. + + Note that multiple PROGRAM keys may be specified in one rule, and + =, :=, and += have the same effect as + ==. + + + + + RESULT + + Match the returned string of the last PROGRAM call. + This key can be used in the same or in any later rule after a + PROGRAM call. + + + + + Most of the fields support shell glob pattern matching and + alternate patterns. The following special characters are supported: + + + * + + Matches zero or more characters. + + + + ? + + Matches any single character. + + + + [] + + Matches any single character specified within the brackets. For + example, the pattern string tty[SR] + would match either ttyS or ttyR. + Ranges are also supported via the - character. + For example, to match on the range of all digits, the pattern + [0-9] could be used. If the first character + following the [ is a !, + any characters not enclosed are matched. + + + + | + + Separates alternative patterns. For example, the pattern string + abc|x* would match either abc + or x*. + + + + + The following keys can get values assigned: + + + NAME + + The name to use for a network interface. See + systemd.link5 + for a higher-level mechanism for setting the interface name. + The name of a device node cannot be changed by udev, only additional + symlinks can be created. + + + + + SYMLINK + + The name of a symlink targeting the node. Every matching rule adds + this value to the list of symlinks to be created. + The set of characters to name a symlink is limited. Allowed + characters are 0-9A-Za-z#+-.:=@_/, valid UTF-8 character + sequences, and \x00 hex encoding. All other + characters are replaced by a _ character. + Multiple symlinks may be specified by separating the names by the + space character. In case multiple devices claim the same name, the link + always points to the device with the highest link_priority. If the current + device goes away, the links are re-evaluated and the device with the + next highest link_priority becomes the owner of the link. If no + link_priority is specified, the order of the devices (and which one of + them owns the link) is undefined. + Symlink names must never conflict with the kernel's default device + node names, as that would result in unpredictable behavior. + + + + + + OWNER, GROUP, MODE + + The permissions for the device node. Every specified value overrides + the compiled-in default value. + + + + + SECLABEL{module} + + Applies the specified Linux Security Module label to the device node. + + + + + ATTR{key} + + The value that should be written to a sysfs attribute of the + event device. + + + + + SYSCTL{kernel parameter} + + The value that should be written to kernel parameter. + + + + + ENV{key} + + Set a device property value. Property names with a leading . + are neither stored in the database nor exported to events or + external tools (run by, for example, the PROGRAM + match key). + + + + + TAG + + Attach a tag to a device. This is used to filter events for users + of libudev's monitor functionality, or to enumerate a group of tagged + devices. The implementation can only work efficiently if only a few + tags are attached to a device. It is only meant to be used in + contexts with specific device filter requirements, and not as a + general-purpose flag. Excessive use might result in inefficient event + handling. + + + + + RUN{type} + + Specify a program to be executed after processing of all the rules for the event. With + +=, this invocation is added to the list, and with = or + :=, it replaces any previous contents of the list. Please note that both + program and builtin types described below share a common + list, so clearing the list with := and = affects both + types. + + type may be: + + + program + + Execute an external program specified as the assigned + value. If no absolute path is given, the program is expected + to live in /usr/lib/udev; otherwise, the + absolute path must be specified. + This is the default if no type + is specified. + + + + builtin + + As program, but use one of the + built-in programs rather than an external one. + + + + + The program name and following arguments are separated by spaces. Single quotes can be + used to specify arguments with spaces. + + This can only be used for very short-running foreground tasks. Running an event process for + a long period of time may block all further events for this or a dependent device. + + Note that running programs that access the network or mount/unmount filesystems is not + allowed inside of udev rules, due to the default sandbox that is enforced on + systemd-udevd.service. + + Starting daemons or other long-running processes is not allowed; the forked processes, + detached or not, will be unconditionally killed after the event handling has finished. In order + to activate long-running processes from udev rules, provide a service unit and pull it in from a + udev device using the SYSTEMD_WANTS device property. See + systemd.device5 + for details. + + + + + LABEL + + A named label to which a GOTO may jump. + + + + + GOTO + + Jumps to the next LABEL with a matching name. + + + + + IMPORT{type} + + Import a set of variables as device properties, depending on + type: + + + + program + + Execute an external program specified as the assigned + value and, if it returns successfully, + import its output, which must be in environment key + format. Path specification, command/argument separation, + and quoting work like in RUN. + + + + builtin + + Similar to program, but use one of the + built-in programs rather than an external one. + + + + file + + Import a text file specified as the assigned value, the content + of which must be in environment key format. + + + + db + + Import a single property specified as the assigned value from the + current device database. This works only if the database is already populated + by an earlier event. + + + + cmdline + + Import a single property from the kernel command line. For simple flags + the value of the property is set to 1. + + + + parent + + Import the stored keys from the parent device by reading + the database entry of the parent device. The value assigned to + is used as a filter of key names + to import (with the same shell glob pattern matching used for + comparisons). + + + + + This can only be used for very short-running foreground tasks. For details see + . + + Note that multiple IMPORT{} keys may be specified in one rule, and + =, :=, and += have the same effect as + ==. The key is true if the import is successful, unless != + is used as the operator which causes the key to be true if the import failed. + + + + + OPTIONS + + Rule and device options: + + + + + Specify the priority of the created symlinks. Devices with higher + priorities overwrite existing symlinks of other devices. The default is 0. + + + + + + When replace, possibly unsafe characters in strings + assigned to NAME, SYMLINK, and + ENV{key} are replaced. When + none, no replacement is performed. When unset, the replacement + is performed for NAME, SYMLINK, but not for + ENV{key}. Defaults to unset. + + + + + + Apply the permissions specified in this rule to the + static device node with the specified name. Also, for every + tag specified in this rule, create a symlink + in the directory + /run/udev/static_node-tags/tag + pointing at the static device node with the specified name. + Static device node creation is performed by systemd-tmpfiles + before systemd-udevd is started. The static nodes might not + have a corresponding kernel device; they are used to trigger + automatic kernel module loading when they are accessed. + + + + + + Watch the device node with inotify; when the node is + closed after being opened for writing, a change uevent is + synthesized. + + + + + + Disable the watching of a device node with inotify. + + + + + + Set the flag (sticky bit) on the udev database entry of the event device. Device + properties are then kept in the database even when udevadm info + --cleanup-db is called. This option can be useful in certain cases + (e.g. Device Mapper devices) for persisting device state on the transition from + initrd. + + + + + + Takes a log level name like debug or + info, or a special value reset. When a log + level name is specified, the maximum log level is changed to that level. When + reset is set, then the previously specified log level is + revoked. Defaults to the log level of the main process of + systemd-udevd. + This may be useful when debugging events for certain devices. Note that the + log level is applied when the line including this rule is processed. So, for + debugging, it is recommended that this is specified at earlier place, e.g., the + first line of 00-debug.rules. + Example for debugging uevent processing for network interfaces: + # /etc/udev/rules.d/00-debug-net.rules +SUBSYSTEM=="net", OPTIONS="log_level=debug" + + + + + + + + The NAME, SYMLINK, + PROGRAM, OWNER, + GROUP, MODE, SECLABEL, + and RUN fields support simple string substitutions. + The RUN substitutions are performed after all rules + have been processed, right before the program is executed, allowing for + the use of device properties set by earlier matching rules. For all other + fields, substitutions are performed while the individual rule is being + processed. The available substitutions are: + + + , + + The kernel name for this device. + + + + + , + + The kernel number for this device. For example, sda3 has kernel number + 3. + + + + + , + + The devpath of the device. + + + + + , + + The name of the device matched while searching the devpath + upwards for , , + , and . + + + + + + + + The driver name of the device matched while searching the + devpath upwards for , + , , and + . + + + + + + , + + The value of a sysfs attribute found at the device where + all keys of the rule have matched. If the matching device does not + have such an attribute, and a previous , + , , or + test selected a parent device, then the + attribute from that parent device is used. + + If the attribute is a symlink, the last element of the + symlink target is returned as the value. + + + + + + , + + A device property value. + + + + + , + + The kernel major number for the device. + + + + + , + + The kernel minor number for the device. + + + + + , + + The string returned by the external program requested with + PROGRAM. + A single part of the string, separated by a space character, may be selected + by specifying the part number as an attribute: %c{N}. + If the number is followed by the + character, this part plus all remaining parts + of the result string are substituted: %c{N+}. + + + + + , + + The node name of the parent device. + + + + + + + The current name of the device. If not changed by a rule, it is the + name of the kernel device. + + + + + + + A space-separated list of the current symlinks. The value is + only set during a remove event or if an earlier rule assigned a value. + + + + + , + + The udev_root value. + + + + + , + + The sysfs mount point. + + + + + , + + The name of the device node. + + + + + + + The % character itself. + + + + + + + The $ character itself. + + + + + + + + See Also + + + systemd-udevd.service8 + , + + udevadm8 + , + + systemd.link5 + + + + diff --git a/man/udev_device_get_syspath.xml b/man/udev_device_get_syspath.xml new file mode 100644 index 0000000..f2d712f --- /dev/null +++ b/man/udev_device_get_syspath.xml @@ -0,0 +1,180 @@ + + +%entities; +]> + + + + + + udev_device_get_syspath + systemd + + + + udev_device_get_syspath + 3 + + + + udev_device_get_syspath + udev_device_get_sysname + udev_device_get_sysnum + udev_device_get_devpath + udev_device_get_devnode + udev_device_get_devnum + udev_device_get_devtype + udev_device_get_subsystem + udev_device_get_driver + udev_device_get_udev + udev_device_get_parent + udev_device_get_parent_with_subsystem_devtype + udev_device_get_is_initialized + udev_device_get_action + + Query device properties + + + + + #include <libudev.h> + + + const char *udev_device_get_syspath + struct udev_device *udev_device + + + + const char *udev_device_get_sysname + struct udev_device *udev_device + + + + const char *udev_device_get_sysnum + struct udev_device *udev_device + + + + const char *udev_device_get_devpath + struct udev_device *udev_device + + + + const char *udev_device_get_devnode + struct udev_device *udev_device + + + + dev_t udev_device_get_devnum + struct udev_device *udev_device + + + + const char *udev_device_get_devtype + struct udev_device *udev_device + + + + const char *udev_device_get_subsystem + struct udev_device *udev_device + + + + const char *udev_device_get_driver + struct udev_device *udev_device + + + + struct udev *udev_device_get_udev + struct udev_device *udev_device + + + + struct udev_device *udev_device_get_parent + struct udev_device *udev_device + + + + struct udev_device *udev_device_get_parent_with_subsystem_devtype + struct udev_device *udev_device + const char *subsystem + const char *devtype + + + + int udev_device_get_is_initialized + struct udev_device *udev_device + + + + const char *udev_device_get_action + struct udev_device *udev_device + + + + + + + + + Return Value + + On success, udev_device_get_syspath(), + udev_device_get_sysname(), + udev_device_get_sysnum(), + udev_device_get_devpath(), + udev_device_get_devnode(), + udev_device_get_devtype(), + udev_device_get_subsystem(), + udev_device_get_driver() and + udev_device_get_action() return a pointer + to a constant string that describes the requested property. The + lifetime of this string is bound to the device it was requested + on. On failure, each function may return + NULL. + + On success, udev_device_get_devnum() + returns the device type of the passed device. On failure, a + device type with minor and major number set to + 0 is returned. + + udev_device_get_udev() always returns + a valid pointer to the udev context that this device belongs + to. + + On success, udev_device_get_parent() + and + udev_device_get_parent_with_subsystem_devtype() + return a pointer to the parent device. No additional reference + to this device is acquired, but the child device owns a reference + to such a parent device. On failure, NULL + is returned. + + On success, udev_device_get_is_initialized() returns either 1 or + 0, depending on whether the passed device has already been initialized by udev or not. On + failure, a negative error code is returned. Note that devices for which no udev rules are defined are never + reported initialized. + + + + See Also + + + udev_new3, + udev_device_new_from_syspath3, + udev_device_has_tag3, + udev_enumerate_new3, + udev_monitor_new_from_netlink3, + udev_list_entry3, + systemd1 + + + + diff --git a/man/udev_device_has_tag.xml b/man/udev_device_has_tag.xml new file mode 100644 index 0000000..19bad4f --- /dev/null +++ b/man/udev_device_has_tag.xml @@ -0,0 +1,170 @@ + + +%entities; +]> + + + + + + udev_device_has_tag + systemd + + + + udev_device_has_tag + 3 + + + + udev_device_has_tag + udev_device_has_current_tag + udev_device_get_devlinks_list_entry + udev_device_get_properties_list_entry + udev_device_get_tags_list_entry + udev_device_get_current_tags_list_entry + udev_device_get_sysattr_list_entry + udev_device_get_property_value + udev_device_get_sysattr_value + udev_device_set_sysattr_value + + Retrieve or set device attributes + + + + + #include <libudev.h> + + + int udev_device_has_tag + struct udev_device *udev_device + const char *tag + + + + int udev_device_has_current_tag + struct udev_device *udev_device + const char *tag + + + + struct udev_list_entry *udev_device_get_devlinks_list_entry + struct udev_device *udev_device + + + + struct udev_list_entry *udev_device_get_properties_list_entry + struct udev_device *udev_device + + + + struct udev_list_entry *udev_device_get_tags_list_entry + struct udev_device *udev_device + + + + struct udev_list_entry *udev_device_get_current_tags_list_entry + struct udev_device *udev_device + + + + struct udev_list_entry *udev_device_get_sysattr_list_entry + struct udev_device *udev_device + + + + const char *udev_device_get_property_value + struct udev_device *udev_device + const char *key + + + + const char *udev_device_get_sysattr_value + struct udev_device *udev_device + const char *sysattr + + + + int udev_device_set_sysattr_value + struct udev_device *udev_device + const char *sysattr + const char *value + + + + + + + Description + + udev_device_has_tag() returns a valuer larger than zero if the specified + device object has the indicated tag assigned to it, and zero otherwise. See + udev7 for details on + the tags concept. udev_device_has_current_tag() executes a similar check, however + only determines whether the indicated tag was set as result of the most recent event seen for the + device. Tags are "sticky", i.e. once set for a device they remain on the device until the device is + unplugged, even if the rules run for later events of the same device do not set them anymore. Any tag for + which udev_device_has_current_tag() returns true will hence also return true when + passed to udev_device_has_tag(), but the opposite might not be true, in case a tag is + no longer configured by the rules applied to the most recent device even. + + udev_device_get_tags_list_entry() returns a + udev_list_entry object, encapsulating a list of tags set for the specified + device. Similar, udev_device_get_current_tags_list_entry() returns a list of tags + set for the specified device as effect of the most recent device event seen (see above for details on the + difference). + + + + Return Value + + On success, udev_device_has_tag() and + udev_device_has_current_tag() return positive or 0, depending + on whether the device has the given tag or not. On failure, a negative error code is returned. + + On success, udev_device_get_devlinks_list_entry(), + udev_device_get_properties_list_entry(), + udev_device_get_tags_list_entry(), + udev_device_get_current_tags_list_entry() and + udev_device_get_sysattr_list_entry() return a pointer to the first entry of the + retrieved list. If that list is empty, or if an error occurred, NULL is + returned. + + On success, + udev_device_get_property_value() and + udev_device_get_sysattr_value() return a + pointer to a constant string of the requested value. On error, + NULL is returned. Attributes that may + contain NUL bytes should not be retrieved + with udev_device_get_sysattr_value(); + instead, read them directly from the files within the device's + syspath. + + On success, + udev_device_set_sysattr_value() returns + an integer greater than, or equal to, 0. + On failure, a negative error code is returned. Values that + contain NUL bytes should not be set with + this function; instead, write them directly to the files within + the device's syspath. + + + + See Also + + + udev7, + udev_new3, + udev_device_new_from_syspath3, + udev_device_get_syspath3, + udev_enumerate_new3, + udev_monitor_new_from_netlink3, + udev_list_entry3, + systemd1, + + + + diff --git a/man/udev_device_new_from_syspath.xml b/man/udev_device_new_from_syspath.xml new file mode 100644 index 0000000..f5ec03d --- /dev/null +++ b/man/udev_device_new_from_syspath.xml @@ -0,0 +1,187 @@ + + +%entities; +]> + + + + + + udev_device_new_from_syspath + systemd + + + + udev_device_new_from_syspath + 3 + + + + udev_device_new_from_syspath + udev_device_new_from_devnum + udev_device_new_from_subsystem_sysname + udev_device_new_from_device_id + udev_device_new_from_environment + udev_device_ref + udev_device_unref + + Create, acquire and release a udev device object + + + + + #include <libudev.h> + + + struct udev_device *udev_device_new_from_syspath + struct udev *udev + const char *syspath + + + + struct udev_device *udev_device_new_from_devnum + struct udev *udev + char type + dev_t devnum + + + + struct udev_device *udev_device_new_from_subsystem_sysname + struct udev *udev + const char *subsystem + const char *sysname + + + + struct udev_device *udev_device_new_from_device_id + struct udev *udev + const char *id + + + + struct udev_device *udev_device_new_from_environment + struct udev *udev + + + + struct udev_device *udev_device_ref + struct udev_device *udev_device + + + + struct udev_device *udev_device_unref + struct udev_device *udev_device + + + + + + + Description + + udev_device_new_from_syspath(), + udev_device_new_from_devnum(), + udev_device_new_from_subsystem_sysname(), + udev_device_new_from_device_id(), and + udev_device_new_from_environment() + allocate a new udev device object and returns a pointer to it. This + object is opaque and must not be accessed by the caller via different + means than functions provided by libudev. Initially, the reference count + of the device is 1. You can acquire further references, and drop + gained references via udev_device_ref() and + udev_device_unref(). Once the reference count hits 0, + the device object is destroyed and freed. + + udev_device_new_from_syspath(), + udev_device_new_from_devnum(), + udev_device_new_from_subsystem_sysname(), and + udev_device_new_from_device_id() + create the device object based on information found in + /sys/, annotated with properties from the udev-internal + device database. A syspath is any subdirectory of /sys/, + with the restriction that a subdirectory of /sys/devices + (or a symlink to one) represents a real device and as such must contain + a uevent file. udev_device_new_from_devnum() + takes a device type, which can be b for block devices or + c for character devices, as well as a devnum (see + makedev3). + udev_device_new_from_subsystem_sysname() looks up devices based + on the provided subsystem and sysname + (see udev_device_get_subsystem3 + and + udev_device_get_sysname3) + and udev_device_new_from_device_id() looks up devices based on the provided + device ID, which is a special string in one of the following four forms: + + Device ID strings + + + + + + Example + Explanation + + + b8:2 + block device major:minor + + c128:1 + char device major:minor + + n3 + network device ifindex + + +sound:card29 + kernel driver core subsystem:device name + + +
+ + + udev_device_new_from_environment() + creates a device from the current environment (see + environ7). + Each key-value pair is interpreted in the same way as if it was + received in an uevent (see + udev_monitor_receive_device3). + The keys DEVPATH, SUBSYSTEM, + ACTION, and SEQNUM are mandatory. + + + + + Return Value + + On success, udev_device_new_from_syspath(), + udev_device_new_from_devnum(), + udev_device_new_from_subsystem_sysname(), + udev_device_new_from_device_id() and + udev_device_new_from_environment() return a + pointer to the allocated udev device. On failure, + NULL is returned, + and errno is set appropriately. + udev_device_ref() returns the argument + that it was passed, unmodified. + udev_device_unref() always returns + NULL. + + + + See Also + + + udev_new3, + udev_device_get_syspath3, + udev_device_has_tag3, + udev_enumerate_new3, + udev_monitor_new_from_netlink3, + udev_list_entry3, + systemd1, + + + + diff --git a/man/udev_enumerate_add_match_subsystem.xml b/man/udev_enumerate_add_match_subsystem.xml new file mode 100644 index 0000000..455aabd --- /dev/null +++ b/man/udev_enumerate_add_match_subsystem.xml @@ -0,0 +1,136 @@ + + +%entities; +]> + + + + + + udev_enumerate_add_match_subsystem + systemd + + + + udev_enumerate_add_match_subsystem + 3 + + + + udev_enumerate_add_match_subsystem + udev_enumerate_add_nomatch_subsystem + udev_enumerate_add_match_sysattr + udev_enumerate_add_nomatch_sysattr + udev_enumerate_add_match_property + udev_enumerate_add_match_sysname + udev_enumerate_add_match_tag + udev_enumerate_add_match_parent + udev_enumerate_add_match_is_initialized + + Modify filters + + + + + #include <libudev.h> + + + int udev_enumerate_add_match_subsystem + struct udev_enumerate *udev_enumerate + const char *subsystem + + + + int udev_enumerate_add_nomatch_subsystem + struct udev_enumerate *udev_enumerate + const char *subsystem + + + + int udev_enumerate_add_match_sysattr + struct udev_enumerate *udev_enumerate + const char *sysattr + const char *value + + + + int udev_enumerate_add_nomatch_sysattr + struct udev_enumerate *udev_enumerate + const char *sysattr + const char *value + + + + int udev_enumerate_add_match_property + struct udev_enumerate *udev_enumerate + const char *property + const char *value + + + + int udev_enumerate_add_match_sysname + struct udev_enumerate *udev_enumerate + const char *sysname + + + + int udev_enumerate_add_match_tag + struct udev_enumerate *udev_enumerate + const char *tag + + + + int udev_enumerate_add_match_parent + struct udev_enumerate *udev_enumerate + struct udev_device *parent + + + + int udev_enumerate_add_match_is_initialized + struct udev_enumerate *udev_enumerate + + + + + + + + + Return Value + + On success, + udev_enumerate_add_match_subsystem(), + udev_enumerate_add_nomatch_subsystem(), + udev_enumerate_add_match_sysattr(), + udev_enumerate_add_nomatch_sysattr(), + udev_enumerate_add_match_property(), + udev_enumerate_add_match_sysname(), + udev_enumerate_add_match_tag(), + udev_enumerate_add_match_parent() and + udev_enumerate_add_match_is_initialized() + return an integer greater than, or equal to, + 0. + + + + See Also + + + udev_new3, + udev_device_new_from_syspath3, + udev_enumerate_new3, + udev_enumerate_scan_devices3, + udev_monitor_new_from_netlink3, + udev_list_entry3, + systemd1, + + + + diff --git a/man/udev_enumerate_new.xml b/man/udev_enumerate_new.xml new file mode 100644 index 0000000..3360cf0 --- /dev/null +++ b/man/udev_enumerate_new.xml @@ -0,0 +1,84 @@ + + +%entities; +]> + + + + + + udev_enumerate_new + systemd + + + + udev_enumerate_new + 3 + + + + udev_enumerate_new + udev_enumerate_ref + udev_enumerate_unref + + Create, acquire and release a udev enumerate object + + + + + #include <libudev.h> + + + struct udev_enumerate *udev_enumerate_new + struct udev *udev + + + + struct udev_enumerate *udev_enumerate_ref + struct udev_enumerate *udev_enumerate + + + + struct udev_enumerate *udev_enumerate_unref + struct udev_enumerate *udev_enumerate + + + + + + + + + Return Value + + On success, udev_enumerate_new() returns a + pointer to the allocated udev monitor. On failure, + NULL is returned. + udev_enumerate_ref() returns the argument + that it was passed, unmodified. + udev_enumerate_unref() always returns + NULL. + + + + See Also + + + udev_new3, + udev_device_new_from_syspath3, + udev_enumerate_add_match_subsystem3, + udev_enumerate_scan_devices3, + udev_monitor_new_from_netlink3, + udev_list_entry3, + systemd1, + + + + diff --git a/man/udev_enumerate_scan_devices.xml b/man/udev_enumerate_scan_devices.xml new file mode 100644 index 0000000..22151a5 --- /dev/null +++ b/man/udev_enumerate_scan_devices.xml @@ -0,0 +1,106 @@ + + +%entities; +]> + + + + + + udev_enumerate_scan_devices + systemd + + + + udev_enumerate_scan_devices + 3 + + + + udev_enumerate_scan_devices + udev_enumerate_scan_subsystems + udev_enumerate_get_list_entry + udev_enumerate_add_syspath + udev_enumerate_get_udev + + Query or modify a udev enumerate object + + + + + #include <libudev.h> + + + int udev_enumerate_scan_devices + struct udev_enumerate *udev_enumerate + + + + int udev_enumerate_scan_subsystems + struct udev_enumerate *udev_enumerate + + + + struct udev_list_entry *udev_enumerate_get_list_entry + struct udev_enumerate *udev_enumerate + + + + int udev_enumerate_add_syspath + struct udev_enumerate *udev_enumerate + const char *syspath + + + + struct udev *udev_enumerate_get_udev + struct udev_enumerate *udev_enumerate + + + + + + + + + Return Value + + On success, + udev_enumerate_scan_devices(), + udev_enumerate_scan_subsystems() and + udev_enumerate_add_syspath() + return an integer greater than, or equal to, + 0. + + On success, + udev_enumerate_get_list_entry() + returns a pointer to the first entry in the list of found + devices. If the list is empty, or on failure, + NULL is returned. + + udev_enumerate_get_udev() always + returns a pointer to the udev context that this enumerated + object is associated with. + + + + See Also + + + udev_new3, + udev_device_new_from_syspath3, + udev_enumerate_new3, + udev_enumerate_add_match_subsystem3, + udev_monitor_new_from_netlink3, + udev_list_entry3, + systemd1, + + + + diff --git a/man/udev_list_entry.xml b/man/udev_list_entry.xml new file mode 100644 index 0000000..94273ce --- /dev/null +++ b/man/udev_list_entry.xml @@ -0,0 +1,96 @@ + + +%entities; +]> + + + + + + udev_list_entry + systemd + + + + udev_list_entry + 3 + + + + udev_list_entry + udev_list_entry_get_next + udev_list_entry_get_by_name + udev_list_entry_get_name + udev_list_entry_get_value + + Iterate and access udev lists + + + + + #include <libudev.h> + + + struct udev_list_entry *udev_list_entry_get_next + struct udev_list_entry *list_entry + + + + struct udev_list_entry *udev_list_entry_get_by_name + struct udev_list_entry *list_entry + const char *name + + + + const char *udev_list_entry_get_name + struct udev_list_entry *list_entry + + + + const char *udev_list_entry_get_value + struct udev_list_entry *list_entry + + + + + + + + + Return Value + + On success, + udev_list_entry_get_next() and + udev_list_entry_get_by_name() return + a pointer to the requested list entry. If no such entry can + be found, or on failure, NULL is + returned. + + On success, + udev_list_entry_get_name() and + udev_list_entry_get_value() return a + pointer to a constant string representing the requested value. + The string is bound to the lifetime of the list entry itself. + On failure, NULL is returned. + + + + See Also + + + udev_new3, + udev_device_new_from_syspath3, + udev_enumerate_new3, + udev_monitor_new_from_netlink3, + systemd1, + + + + diff --git a/man/udev_monitor_filter_update.xml b/man/udev_monitor_filter_update.xml new file mode 100644 index 0000000..4e77db4 --- /dev/null +++ b/man/udev_monitor_filter_update.xml @@ -0,0 +1,95 @@ + + +%entities; +]> + + + + + + udev_monitor_filter_update + systemd + + + + udev_monitor_filter_update + 3 + + + + udev_monitor_filter_update + udev_monitor_filter_remove + udev_monitor_filter_add_match_subsystem_devtype + udev_monitor_filter_add_match_tag + + Modify filters + + + + + #include <libudev.h> + + + int udev_monitor_filter_update + struct udev_monitor *udev_monitor + + + + int udev_monitor_filter_remove + struct udev_monitor *udev_monitor + + + + int udev_monitor_filter_add_match_subsystem_devtype + struct udev_monitor *udev_monitor + const char *subsystem + const char *devtype + + + + int udev_monitor_filter_add_match_tag + struct udev_monitor *udev_monitor + const char *tag + + + + + + + + + Return Value + + On success, + udev_monitor_filter_update(), + udev_monitor_filter_remove(), + udev_monitor_filter_add_match_subsystem_devtype() + and + udev_monitor_filter_add_match_tag() + return an integer greater than, or equal to, + 0. On failure, a negative error code is + returned. + + + + See Also + + + udev_new3, + udev_device_new_from_syspath3, + udev_enumerate_new3, + udev_monitor_new_from_netlink3, + udev_monitor_receive_device3, + udev_list_entry3, + systemd1, + + + + diff --git a/man/udev_monitor_new_from_netlink.xml b/man/udev_monitor_new_from_netlink.xml new file mode 100644 index 0000000..538a27e --- /dev/null +++ b/man/udev_monitor_new_from_netlink.xml @@ -0,0 +1,86 @@ + + +%entities; +]> + + + + + + udev_monitor_new_from_netlink + systemd + + + + udev_monitor_new_from_netlink + 3 + + + + udev_monitor_new_from_netlink + udev_monitor_ref + udev_monitor_unref + + Create, acquire and release a udev monitor object + + + + + #include <libudev.h> + + + struct udev_monitor *udev_monitor_new_from_netlink + struct udev *udev + const char *name + + + + struct udev_monitor *udev_monitor_ref + struct udev_monitor *udev_monitor + + + + struct udev_monitor *udev_monitor_unref + struct udev_monitor *udev_monitor + + + + + + + + + Return Value + + On success, + udev_monitor_new_from_netlink() returns a + pointer to the allocated udev monitor. On failure, + NULL is returned. + udev_monitor_ref() returns the argument + that it was passed, unmodified. + udev_monitor_unref() always returns + NULL. + + + + See Also + + + udev_new3, + udev_device_new_from_syspath3, + udev_enumerate_new3, + udev_monitor_filter_update3, + udev_monitor_receive_device3, + udev_list_entry3, + systemd1, + + + + diff --git a/man/udev_monitor_receive_device.xml b/man/udev_monitor_receive_device.xml new file mode 100644 index 0000000..bbdce3c --- /dev/null +++ b/man/udev_monitor_receive_device.xml @@ -0,0 +1,110 @@ + + +%entities; +]> + + + + + + udev_monitor_receive_device + systemd + + + + udev_monitor_receive_device + 3 + + + + udev_monitor_receive_device + udev_monitor_enable_receiving + udev_monitor_set_receive_buffer_size + udev_monitor_get_fd + udev_monitor_get_udev + + Query and modify device monitor + + + + + #include <libudev.h> + + + struct udev_device *udev_monitor_receive_device + struct udev_monitor *udev_monitor + + + + int udev_monitor_enable_receiving + struct udev_monitor *udev_monitor + + + + int udev_monitor_set_receive_buffer_size + struct udev_monitor *udev_monitor + int size + + + + int udev_monitor_get_fd + struct udev_monitor *udev_monitor + + + + struct udev *udev_monitor_get_udev + struct udev_monitor *udev_monitor + + + + + + + + + Return Value + + On success, + udev_monitor_receive_device() returns a + pointer to a newly referenced device that was received via the + monitor. The caller is responsible to drop this reference when + done. On failure, NULL is returned. + + On success, + udev_monitor_enable_receiving() and + udev_monitor_set_receive_buffer_size() + return an integer greater than, or equal to, + 0. On failure, a negative error code is + returned. + + On success, udev_monitor_get_fd() + returns the file descriptor used by this monitor. On failure, + a negative error code is returned. + + udev_monitor_get_udev() always returns + a pointer to the udev context that this monitor is associated + with. + + + + See Also + + + udev_new3, + udev_device_new_from_syspath3, + udev_enumerate_new3, + udev_monitor_new_from_netlink3, + udev_monitor_filter_update3, + udev_list_entry3, + systemd1, + + + + diff --git a/man/udev_new.xml b/man/udev_new.xml new file mode 100644 index 0000000..34e249d --- /dev/null +++ b/man/udev_new.xml @@ -0,0 +1,83 @@ + + +%entities; +]> + + + + + + udev_new + systemd + + + + udev_new + 3 + + + + udev_new + udev_ref + udev_unref + + Create, acquire and release a udev context object + + + + + #include <libudev.h> + + + struct udev *udev_new + void + + + + struct udev *udev_ref + struct udev *udev + + + + struct udev *udev_unref + struct udev *udev + + + + + + + Description + + udev_new() allocates a new udev context + object and returns a pointer to it. This object is opaque and must + not be accessed by the caller via different means than functions + provided by libudev. Initially, the reference count of the context + is 1. You can acquire further references, and drop gained references + via udev_ref() and + udev_unref(). Once the reference count hits 0, + the context object is destroyed and freed. + + + + Return Value + + On success, udev_new() returns a pointer + to the allocated udev context. On failure, NULL + is returned. udev_ref() returns the argument + that it was passed, unmodified. udev_unref() + always returns NULL. + + + + See Also + + + systemd1, + + + + diff --git a/man/udevadm.xml b/man/udevadm.xml new file mode 100644 index 0000000..ee0658d --- /dev/null +++ b/man/udevadm.xml @@ -0,0 +1,931 @@ + + + + + + + + udevadm + systemd + + + + udevadm + 8 + + + + udevadmudev management tool + + + + + udevadm + + + + + + udevadm info options devpath + + + udevadm trigger options devpath + + + udevadm settle options + + + udevadm control option + + + udevadm monitor options + + + udevadm test options devpath + + + udevadm test-builtin options command devpath + + + udevadm wait options device|syspath + + + udevadm lock options command + + + + Description + udevadm expects a command and command + specific options. It controls the runtime behavior of + systemd-udevd, requests kernel events, manages + the event queue, and provides simple debugging mechanisms. + + + Options + + + + + + Print debug messages to standard error. This option is implied in udevadm test and + udevadm test-builtin commands. + + + + + + + udevadm info + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg choice="opt" rep="repeat"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg> + + + Query the udev database for device information. + + Positional arguments should be used to specify one or more devices. Each one may be a device name + (in which case it must start with /dev/), a sys path (in which case it must start + with /sys/), or a systemd device unit name (in which case it must end with + .device, see + systemd.device5). + + + + + + + + Query the database for the specified type of device data. + Valid TYPEs are: + name, symlink, + path, property, + all. + + + + + + + When showing device properties using the + option, limit display to properties specified in the argument. The argument should + be a comma-separated list of property names. If not specified, all known properties + are shown. + + + + + + When showing device properties using the + option, print only their values, and skip the property name and =. + Cannot be used together with or + . + + + + + + + The /sys/ path of the device to query, e.g. + /sys//class/block/sda. This option is an alternative to + the positional argument with a /sys/ prefix. udevadm info + --path=/class/block/sda is equivalent to udevadm info + /sys/class/block/sda. + + + + + + + The name of the device node or a symlink to query, + e.g. /dev//sda. This option is an alternative to the + positional argument with a /dev/ prefix. udevadm info + --name=sda is equivalent to udevadm info /dev/sda. + + + + + + + Print absolute paths in name or symlink + query. + + + + + + + Print all sysfs properties of the specified device that can be used + in udev rules to match the specified device. It prints all devices + along the chain, up to the root of sysfs that can be used in udev rules. + + + + + + + Display a sysfs tree. This recursively iterates through the sysfs hierarchy and displays it + in a tree structure. If a path is specified only the subtree below and its parent directories are + shown. This will show both device and subsystem items. + + + + + + + Print output as key/value pairs. Values are enclosed in single quotes. + This takes effects only when or + is specified. + + + + + + + Add a prefix to the key name of exported values. + This implies . + + + + + + + Print major/minor numbers of the underlying device, where the file lives on. + If this is specified, all positional arguments are ignored. + + + + + + + Export the content of the udev database. + + + + + + + Cleanup the udev database. + + + + + + + Wait for device to be initialized. If argument SECONDS + is not specified, the default is to wait forever. + + + + + + + + The generated output shows the current device database entry in a terse format. Each line shown + is prefixed with one of the following characters: + + + <command>udevadm info</command> output prefixes + + + + + + Prefix + Meaning + + + + + P: + Device path in /sys/ + + + M: + Device name in /sys/ (i.e. the last component of P:) + + + R: + Device number in /sys/ (i.e. the numeric suffix of the last component of P:) + + + U: + Kernel subsystem + + + T: + Kernel device type within subsystem + + + D: + Kernel device node major/minor + + + I: + Network interface index + + + N: + Kernel device node name + + + L: + Device node symlink priority + + + S: + Device node symlink + + + Q: + Block device sequence number (DISKSEQ) + + + V: + Attached driver + + + E: + Device property + + + +
+ + + udevadm trigger + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg choice="opt"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg> + + Request device events from the kernel. Primarily used to replay events at system coldplug time. + + Takes device specifications as positional arguments. See the description of info + above. + + + + + + + Print the list of devices which will be triggered. + + + + + + + Do not actually trigger the event. + + + + + + + Suppress error logging in triggering events. + + + + + + + Trigger a specific type of devices. Valid types are all, + devices, and subsystems. The default value is + devices. + + + + + + + Type of event to be triggered. Possible actions are add, + remove, change, move, + online, offline, bind, + and unbind. Also, the special value help can be used + to list the possible actions. The default value is change. + + + + + + + Takes a comma separated list of subsystems. When triggering events for devices, the + devices from the specified subsystems and their parents are triggered first. For example, + if , then firstly all block devices and + their parents are triggered, in the next all network devices and their parents are + triggered, and lastly the other devices are triggered. This option can be specified + multiple times, and in that case the lists of the subsystems will be merged. That is, + is equivalent to + . + + + + + + + Trigger events for devices which belong to a + matching subsystem. This option supports shell style pattern matching. + When this option is specified more than once, then each matching result is ORed, that is, + all the devices in each subsystem are triggered. + + + + + + + Do not trigger events for devices which belong to a matching subsystem. This option + supports shell style pattern matching. When this option is specified more than once, + then each matching result is ANDed, that is, devices which do not match all specified + subsystems are triggered. + + + + + + + Trigger events for devices with a matching sysfs attribute. If a value is specified along + with the attribute name, the content of the attribute is matched against the given value using + shell style pattern matching. If no value is specified, the existence of the sysfs attribute is + checked. When this option is specified multiple times, then each matching result is ANDed, + that is, only devices which have all specified attributes are triggered. + + + + + + + Do not trigger events for devices with a matching sysfs attribute. If a value is specified + along with the attribute name, the content of the attribute is matched against the given value + using shell style pattern matching. If no value is specified, the existence of the sysfs attribute + is checked. When this option is specified multiple times, then each matching result is ANDed, + that is, only devices which have none of the specified attributes are triggered. + + + + + + + Trigger events for devices with a matching property value. This option supports shell style + pattern matching. When this option is specified more than once, then each matching result is ORed, + that is, devices which have one of the specified properties are triggered. + + + + + + + Trigger events for devices with a matching tag. When this option is specified multiple times, + then each matching result is ANDed, that is, devices which have all specified tags are triggered. + + + + + + + Trigger events for devices for which the last component (i.e. the filename) of the + /sys/ path matches the specified PATH. This option + supports shell style pattern matching. When this option is specified more than once, then each + matching result is ORed, that is, all devices which have any of the specified + NAME are triggered. + + + + + + Trigger events for devices with a matching device path. When this option is specified more than once, + then each matching result is ORed, that is, all specified devices are triggered. + + + + + + + Trigger events for all children of a given device. When this option is specified more than once, + then each matching result is ORed, that is, all children of each specified device are triggered. + + + + + + + When is specified, trigger events for devices + that are already initialized by systemd-udevd, and skip devices that + are not initialized yet. + When is specified, trigger events for devices + that are not initialized by systemd-udevd yet, and skip devices that + are already initialized. + Typically, it is essential that applications which intend to use such a match, make + sure a suitable udev rule is installed that sets at least one property on devices that + shall be matched. See also Initialized Devices section below for more details. + WARNING: can potentially save a significant + amount of time compared to re-triggering all devices in the system and e.g. can be used to + optimize boot time. However, this is not safe to be used in a boot sequence in general. + Especially, when udev rules for a device depend on its parent devices (e.g. + ATTRS or IMPORT{parent} keys, see + udev7 + for more details), the final state of the device becomes easily unstable with this option. + + + + + + + + Apart from triggering events, also waits for those events to + finish. Note that this is different from calling udevadm + settle. udevadm settle waits for all + events to finish. This option only waits for events triggered by + the same command to finish. + + + + + + Trigger the synthetic device events, and associate a randomized UUID with each. These UUIDs + are printed to standard output, one line for each event. These UUIDs are included in the uevent + environment block (in the SYNTH_UUID= property) and may be used to track + delivery of the generated events. + + + + + + Before triggering uevents, wait for systemd-udevd daemon to be initialized. + Optionally takes timeout value. Default timeout is 5 seconds. This is equivalent to invoke + invoking udevadm control --ping before udevadm trigger. + + + + + + + In addition, optional positional arguments can be used + to specify device names or sys paths. They must start with + /dev/ or /sys/ + respectively. + + + udevadm settle + <arg choice="opt"><replaceable>options</replaceable></arg> + + Watches the udev event queue, and exits if all current events are handled. + + + + + + Maximum number of seconds to wait for the event + queue to become empty. The default value is 120 seconds. A + value of 0 will check if the queue is empty and always + return immediately. A non-zero value will return an exit + code of 0 if queue became empty before timeout was reached, + non-zero otherwise. + + + + + + + Stop waiting if file exists. + + + + + + + See + systemd-udev-settle.service8 + for more information. + + + udevadm control <replaceable>option</replaceable> + Modify the internal state of the running udev daemon. + + + + + + Signal and wait for systemd-udevd to exit. No option except for + can be specified after this option. + Note that systemd-udevd.service contains + and so as a result, this option restarts systemd-udevd. + If you want to stop systemd-udevd.service, please use the following: + systemctl stop systemd-udevd-control.socket systemd-udevd-kernel.socket systemd-udevd.service + + + + + + + + Set the internal log level of + systemd-udevd. Valid values are the + numerical syslog priorities or their textual + representations: , + , , + , , + , , and + . + + + + + + + Signal systemd-udevd to stop executing new events. Incoming events + will be queued. + + + + + + + Signal systemd-udevd to enable the execution of events. + + + + + + + Signal systemd-udevd to reload the rules files and other databases like the kernel + module index. Reloading rules and databases does not apply any changes to already + existing devices; the new configuration will only be applied to new events. + + + + + + + Set a global property for all events. + + + + + value + + Set the maximum number of events, systemd-udevd will handle at the + same time. + + + + + + Send a ping message to systemd-udevd and wait for the reply. This may be useful to check that + systemd-udevd daemon is running. + + + + + seconds + + The maximum number of seconds to wait for a reply from systemd-udevd. + + + + + + + + udevadm monitor + <arg choice="opt"><replaceable>options</replaceable></arg> + + Listens to the kernel uevents and events sent out by a udev rule + and prints the devpath of the event to the console. It can be used to analyze the + event timing, by comparing the timestamps of the kernel uevent and the udev event. + + + + + + + Print the kernel uevents. + + + + + + + Print the udev event after the rule processing. + + + + + + + Also print the properties of the event. + + + + + + + Filter kernel uevents and udev events by subsystem[/devtype]. Only events with a matching subsystem value will pass. + When this option is specified more than once, then each matching result is ORed, that is, all devices in the specified + subsystems are monitored. + + + + + + + Filter udev events by tag. Only udev events with a given tag attached will pass. + When this option is specified more than once, then each matching result is ORed, that is, devices which have one of the + specified tags are monitored. + + + + + + + + udevadm test + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg choice="opt"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg> + + Simulate a udev event run for the given device, and print debug output. + + + + + + Type of event to be simulated. Possible actions are add, + remove, change, move, + online, offline, bind, + and unbind. Also, the special value help can be used + to list the possible actions. The default value is add. + + + + + + + Specify when udevadm should resolve names of users + and groups. When set to early (the + default), names will be resolved when the rules are + parsed. When set to late, names will + be resolved for every event. When set to + never, names will never be resolved + and all devices will be owned by root. + + + + + + + + udevadm test-builtin + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg><replaceable>command</replaceable></arg> + <arg choice="opt"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg> + + Run a built-in command COMMAND + for device DEVPATH, and print debug + output. + + + + + + Type of event to be simulated. Possible actions are add, + remove, change, move, + online, offline, bind, + and unbind. Also, the special value help can be used + to list the possible actions. The default value is add. + + + + + + + + + udevadm wait + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg choice="opt"><replaceable>device|syspath</replaceable></arg> + … + + + Wait for devices or device symlinks being created and initialized by + systemd-udevd. Each device path must start with + /dev/ or /sys/, e.g. /dev/sda, + /dev/disk/by-path/pci-0000:3c:00.0-nvme-1-part1, + /sys/devices/pci0000:00/0000:00:1f.6/net/eth0, or + /sys/class/net/eth0. This can take multiple devices. This may be useful for + waiting for devices being processed by systemd-udevd after e.g. partitioning + or formatting the devices. + + + + + + + Maximum number of seconds to wait for the specified devices or device symlinks being + created, initialized, or removed. The default value is infinity. + + + + + + + Check if systemd-udevd initialized devices. Defaults to true. When + false, the command only checks if the specified devices exist. Set false to this setting if + there is no udev rules for the specified devices, as the devices will never be considered + as initialized in that case. See Initialized Devices section below for more details. + + + + + + + When specified, the command wait for devices being removed instead of created or + initialized. If this is specified, will be ignored. + + + + + + + When specified, also watches the udev event queue, and wait for all queued events + being processed by systemd-udevd. + + + + + + + + + udevadm lock + <arg choice="opt"><replaceable>options</replaceable></arg> + <arg choice="opt"><replaceable>command</replaceable></arg> + … + + + udevadm lock takes an (advisory) exclusive lock on a block device (or all + specified devices), as per Locking Block Device + Access and invokes a program with the locks taken. When the invoked program exits the locks + are automatically released and its return value is propagated as exit code of udevadm + lock. + + This tool is in particular useful to ensure that + systemd-udevd.service8 + does not probe a block device while changes are made to it, for example partitions created or file + systems formatted. Note that many tools that interface with block devices natively support taking + relevant locks, see for example + sfdisk8's + switch. + + The command expects at least one block device specified via or + , and a command line to execute as arguments. + + + + + + + Takes a path to a device node of the device to lock. This switch may be used + multiple times (and in combination with ) in order to lock multiple + devices. If a partition block device node is specified the containing "whole" block device is + automatically determined and used for the lock, as per the specification. If multiple devices are + specified, they are deduplicated, sorted by the major/minor of their device nodes and then locked + in order. + + This switch must be used at least once, to specify at least one device to + lock. (Alternatively, use , see below.) + + + + + + + If a path to a device node is specified, identical to + . However, this switch alternatively accepts a path to a regular file or + directory, in which case the block device of the file system the file/directory resides on is + automatically determined and used as if it was specified with + . + + + + + + + Specifies how long to wait at most until all locks can be taken. Takes a value in + seconds, or in the usual supported time units, see + systemd.time7. If + specified as zero the lock is attempted and if not successful the invocation will immediately + fail. If passed as infinity (the default) the invocation will wait indefinitely + until the lock can be acquired. If the lock cannot be taken in the specified time the specified + command will not be executed and the invocation will fail. + + + + + + + Instead of locking the specified devices and executing a command, just print the + device paths that would be locked, and execute no command. This command is useful to determine + the "whole" block device in case a partition block device is specified. The devices will be sorted + by their device node major number as primary ordering key and the minor number as secondary + ordering key (i.e. they are shown in the order they'd be locked). Note that the number of lines + printed here can be less than the the number of and + switches specified in case these resolve to the same "whole" + devices. + + + + + + + + + Initialized Devices + + Initialized devices are those for which at least one udev rule already completed execution + – for any action but remove — that set a property or other device setting (and + thus has an entry in the udev device database). Devices are no longer considered initialized if a + remove action is seen for them (which removes their entry in the udev device + database). Note that devices that have no udev rules are never considered initialized, but might + still be announced via the sd-device API (or similar). + + + + Example + + + Format a File System + + Take a lock on the backing block device while creating a file system, to ensure that + systemd-udevd doesn't probe or announce the new superblock before it is + comprehensively written: + + # udevadm lock --device=/dev/sda1 mkfs.ext4 /dev/sda1 + + + + Format a RAID File System + + Similar, but take locks on multiple devices at once: + + # udevadm lock --device=/dev/sda1 --device=/dev/sdb1 mkfs.btrfs /dev/sda1 /dev/sdb1 + + + + Copy in a File System + + Take a lock on the backing block device while copying in a prepared file system image, to ensure + that systemd-udevd doesn't probe or announce the new superblock before it is fully + written: + + # udevadm lock -d /dev/sda1 dd if=fs.raw of=/dev/sda1 + + + + + See Also + + udev7 + , + + systemd-udevd.service8 + + + diff --git a/man/user-system-options.xml b/man/user-system-options.xml new file mode 100644 index 0000000..f3bafae --- /dev/null +++ b/man/user-system-options.xml @@ -0,0 +1,58 @@ + + + + + + + + + + Talk to the service manager of the calling user, + rather than the service manager of the system. + + + + + + + + Talk to the service manager of the system. This is the + implied default. + + + + + + + + + Execute the operation remotely. Specify a hostname, or a + username and hostname separated by @, to + connect to. The hostname may optionally be suffixed by a + port ssh is listening on, separated by :, and then a + container name, separated by /, which + connects directly to a specific container on the specified + host. This will use SSH to talk to the remote machine manager + instance. Container names may be enumerated with + machinectl -H + HOST. Put IPv6 addresses in brackets. + + + + + + + + + Execute operation on a local container. Specify a container name to connect to, optionally + prefixed by a user name to connect as and a separating @ character. If the special + string .host is used in place of the container name, a connection to the local + system is made (which is useful to connect to a specific user's user bus: --user + --machine=lennart@.host). If the @ syntax is not used, the connection is + made as root user. If the @ syntax is used either the left hand side or the right hand + side may be omitted (but not both) in which case the local user name and .host are + implied. + + + diff --git a/man/user@.service.xml b/man/user@.service.xml new file mode 100644 index 0000000..0cf7f02 --- /dev/null +++ b/man/user@.service.xml @@ -0,0 +1,194 @@ + + + + + + + user@.service + systemd + + + + user@.service + 5 + + + + user@.service + user-runtime-dir@.service + systemd-user-runtime-dir + System units to start the user manager + + + + user@UID.service + user-runtime-dir@UID.service + /usr/lib/systemd/systemd-user-runtime-dir + user-UID.slice + + + + Description + + The systemd1 + system manager (PID 1) starts user manager instances as + user@UID.service, with the user's numerical UID used as + the instance identifier. These instances use the same executable as the system manager, but running in a + mode where it starts a different set of units. Each systemd --user instance manages a + hierarchy of units specific to that user. See + systemd1 for a + discussion of units and + systemd.special7 for a + list of units that form the basis of the unit hierarchies of system and user units. + + user@UID.service is accompanied by the + system unit user-runtime-dir@UID.service, which + creates the user's runtime directory + /run/user/UID, and then removes it when this + unit is stopped. user-runtime-dir@UID.service + executes the systemd-user-runtime-dir binary to do the actual work. + + User processes may be started by the user@.service instance, in which + case they will be part of that unit in the system hierarchy. They may also be started elsewhere, + for example by + sshd8 or a + display manager like gdm, in which case they form a .scope unit (see + systemd.scope5). + Both user@UID.service and the scope units are + collected under the user-UID.slice. + + Individual user-UID.slice slices are + collected under user.slice, see + systemd.special7. + + + + + Controlling resources for logged-in users + + Options that control resources available to logged-in users can be configured at a few + different levels. As described in the previous section, user.slice contains + processes of all users, so any resource limits on that slice apply to all users together. The + usual way to configure them would be through drop-ins, e.g. /etc/systemd/system/user.slice.d/resources.conf. + + + The processes of a single user are collected under + user-UID.slice. Resource limits for that user + can be configured through drop-ins for that unit, e.g. /etc/systemd/system/user-1000.slice.d/resources.conf. If the limits + should apply to all users instead, they may be configured through drop-ins for the truncated + unit name, user-.slice. For example, configuration in /etc/systemd/system/user-.slice.d/resources.conf is included in all + user-UID.slice units, see + systemd.unit5 + for a discussion of the drop-in mechanism. + + When a user logs in and a .scope unit is created for the session (see previous section), + the creation of the scope may be managed through + pam_systemd8. + This PAM module communicates with + systemd-logind8 + to create the session scope and provide access to hardware resources. Resource limits for the + scope may be configured through the PAM module configuration, see + pam_systemd8. + Configuring them through the normal unit configuration is also possible, but since + the name of the slice unit is generally unpredictable, this is less useful. + + In general any resources that apply to units may be set for + user@UID.service and the slice + units discussed above, see + systemd.resource-control5 + for an overview. + + + + Examples + + Hierarchy of control groups with two logged in users + + $ systemd-cgls +Control group /: +-.slice +├─user.slice +│ ├─user-1000.slice +│ │ ├─user@1000.service +│ │ │ ├─pulseaudio.service +│ │ │ │ └─2386 /usr/bin/pulseaudio --daemonize=no +│ │ │ └─gnome-terminal-server.service +│ │ │ └─init.scope +│ │ │ ├─ 4127 /usr/libexec/gnome-terminal-server +│ │ │ └─ 4198 zsh +│ │ … +│ │ └─session-4.scope +│ │ ├─ 1264 gdm-session-worker [pam/gdm-password] +│ │ ├─ 2339 /usr/bin/gnome-shell +│ │ … +│ │ ├─session-19.scope +│ │ ├─6497 sshd: zbyszek [priv] +│ │ ├─6502 sshd: zbyszek@pts/6 +│ │ ├─6509 -zsh +│ │ └─6602 systemd-cgls --no-pager +│ … +│ └─user-1001.slice +│ ├─session-20.scope +│ │ ├─6675 sshd: guest [priv] +│ │ ├─6708 sshd: guest@pts/6 +│ │ └─6717 -bash +│ └─user@1001.service +│ ├─init.scope +│ │ ├─6680 /usr/lib/systemd/systemd --user +│ │ └─6688 (sd-pam) +│ └─sleep.service +│ └─6706 /usr/bin/sleep 30 +… + User with UID 1000 is logged in using gdm (session-4.scope) and + ssh1 + (session-19.scope), and also has a user manager instance + running (user@1000.service). User with UID 1001 is logged + in using ssh (session-20.scope) and + also has a user manager instance running (user@1001.service). Those are all (leaf) system units, and form + part of the slice hierarchy, with user-1000.slice and + user-1001.slice below user.slice. User units are visible below the + user@.service instances (pulseaudio.service, gnome-terminal-server.service, init.scope, sleep.service). + + + + + Default user resource limits + + $ systemctl cat user-1000.slice +# /usr/lib/systemd/system/user-.slice.d/10-defaults.conf +# … +[Unit] +Description=User Slice of UID %j +After=systemd-user-sessions.service + +[Slice] +TasksMax=33% + The user-UID.slice units by default don't + have a unit file. The resource limits are set through a drop-in, which can be easily replaced + or extended following standard drop-in mechanisms discussed in the first section. + + + + + See Also + + systemd1, + systemd.service5, + systemd.slice5, + systemd.resource-control5, + systemd.exec5, + systemd.special7, + pam8 + + + diff --git a/man/userdbctl.xml b/man/userdbctl.xml new file mode 100644 index 0000000..fbab810 --- /dev/null +++ b/man/userdbctl.xml @@ -0,0 +1,346 @@ + + + + + + + + userdbctl + systemd + + + + userdbctl + 1 + + + + userdbctl + Inspect users, groups and group memberships + + + + + userdbctl + OPTIONS + COMMAND + NAME + + + + + Description + + userdbctl may be used to inspect user and groups (as well as group memberships) + of the system. This client utility inquires user/group information provided by various system services, + both operating on JSON user/group records (as defined by the JSON User Records and JSON Group Records definitions), and classic UNIX NSS/glibc + user and group records. This tool is primarily a client to the User/Group Record Lookup API via Varlink, and may also + pick up drop-in JSON user and group records from /etc/userdb/, + /run/userdb/, /run/host/userdb/, + /usr/lib/userdb/. + + + + Options + + The following options are understood: + + + + + MODE + + Choose the output mode, takes one of classic, + friendly, table, json. If + classic, an output very close to the format of /etc/passwd or + /etc/group is generated. If friendly a more comprehensive and + user friendly, human readable output is generated; if table a minimal, tabular + output is generated; if json a JSON formatted output is generated. Defaults to + friendly if a user/group is specified on the command line, + table otherwise. + + Note that most output formats do not show all available information. In particular, + classic and table show only the most important fields. Various + modes also do not show password hashes. Use json to view all fields, including + any authentication fields. + + + + + FORMAT + + Selects JSON output mode (like ) and selects the + precise display mode. Takes one of pretty or short. If + pretty, human-friendly whitespace and newlines are inserted in the output to make + the JSON data more readable. If short, all superfluous whitespace is + suppressed. + + + + SERVICE:SERVICE… + SERVICE:SERVICE… + + Controls which services to query for users/groups. Takes a list of one or more + service names, separated by :. See below for a list of well-known service + names. If not specified all available services are queried at once. + + + + BOOL + + Controls whether to include classic glibc/NSS user/group lookups in the output. If + is used any attempts to resolve or enumerate users/groups provided + only via glibc NSS is suppressed. If is specified such users/groups + are included in the output (which is the default). + + + + BOOL + + Controls whether to include Varlink user/group lookups in the output, i.e. those done + via the User/Group Record Lookup API via + Varlink. If is used any attempts to resolve or enumerate + users/groups provided only via Varlink are suppressed. If is + specified such users/groups are included in the output (which is the default). + + + + BOOL + + Controls whether to include user/group lookups in the output that are defined using + drop-in files in /etc/userdb/, /run/userdb/, + /run/host/userdb/, /usr/lib/userdb/. If + is used these records are suppressed. If + is specified such users/groups are included in the output (which + is the default). + + + + BOOL + + Controls whether to synthesize records for the root and nobody users/groups if they + aren't defined otherwise. By default (or yes) such records are implicitly + synthesized if otherwise missing since they have special significance to the OS. When + no this synthesizing is turned off. + + + + + + This option is short for + . Use this option to show only records that are natively defined as + JSON user or group records, with all NSS/glibc compatibility and all implicit synthesis turned + off. + + + + BOOL + + Controls whether to do lookups via the multiplexer service (if specified as true, the + default) or do lookups in the client (if specified as false). Using the multiplexer service is + typically preferable, since it runs in a locked down sandbox. + + + + + + When used with the ssh-authorized-keys command, this will allow + passing an additional command line after the user name that is chain executed after the lookup + completed. This allows chaining multiple tools that show SSH authorized keys. + + + + + + + + + + + Commands + + The following commands are understood: + + + + + user USER… + + List all known users records or show details of one or more specified user + records. Use to tweak output mode. + + + + group GROUP… + + List all known group records or show details of one or more specified group + records. Use to tweak output mode. + + + + users-in-group GROUP… + + List users that are members of the specified groups. If no groups are specified list + all user/group memberships defined. Use to tweak output + mode. + + + + groups-of-user USER… + + List groups that the specified users are members of. If no users are specified list + all user/group memberships defined (in this case groups-of-user and + users-in-group are equivalent). Use to tweak output + mode. + + + + services + + List all services currently providing user/group definitions to the system. See below + for a list of well-known services providing user information. + + + + ssh-authorized-keys + + Show SSH authorized keys for this account. This command is intended to be used to + allow the SSH daemon to pick up authorized keys from user records, see below. + + + + + + Well-Known Services + + The userdbctl services command will list all currently running services that + provide user or group definitions to the system. The following well-known services are shown among + this list: + + + + io.systemd.DynamicUser + + This service is provided by the system service manager itself (i.e. PID 1) and + makes all users (and their groups) synthesized through the DynamicUser= setting in + service unit files available to the system (see + systemd.exec5 for + details about this setting). + + + + io.systemd.Home + + This service is provided by + systemd-homed.service8 + and makes all users (and their groups) belonging to home directories managed by that service + available to the system. + + + + io.systemd.Machine + + This service is provided by + systemd-machined.service8 + and synthesizes records for all users/groups used by a container that employs user + namespacing. + + + + io.systemd.Multiplexer + + This service is provided by + systemd-userdbd.service8 + and multiplexes user/group look-ups to all other running lookup services. This is the primary entry point + for user/group record clients, as it simplifies client side implementation substantially since they + can ask a single service for lookups instead of asking all running services in parallel. + userdbctl uses this service preferably, too, unless + or are used, in which case finer control over the services to talk to is + required. + + + + io.systemd.NameServiceSwitch + + This service is (also) provided by + systemd-userdbd.service8 + and converts classic NSS/glibc user and group records to JSON user/group records, providing full + backwards compatibility. Use to disable this compatibility, see + above. Note that compatibility is actually provided in both directions: + nss-systemd8 will + automatically synthesize classic NSS/glibc user/group records from all JSON user/group records + provided to the system, thus using both APIs is mostly equivalent and provides access to the same + data, however the NSS/glibc APIs necessarily expose a more reduced set of fields + only. + + + + io.systemd.DropIn + + This service is (also) provided by + systemd-userdbd.service8 + and picks up JSON user/group records from /etc/userdb/, + /run/userdb/, /run/host/userdb/, + /usr/lib/userdb/. + + + + + Note that userdbctl has internal support for NSS-based lookups too. This means + that if neither io.systemd.Multiplexer nor + io.systemd.NameServiceSwitch are running look-ups into the basic user/group + databases will still work. + + + + Integration with SSH + + The userdbctl tool may be used to make the list of SSH authorized keys possibly + contained in a user record available to the SSH daemon for authentication. For that configure the + following in sshd_config5: + + … +AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u +AuthorizedKeysCommandUser root +… + + Sometimes it's useful to allow chain invocation of another program to list SSH authorized keys. By + using the such a tool may be chain executed by userdbctl + ssh-authorized-keys once a lookup completes (regardless if an SSH key was found or + not). Example: + + … +AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u --chain /usr/bin/othertool %u +AuthorizedKeysCommandUser root +… + + The above will first query the userdb database for SSH keys, and then chain execute + /usr/bin/othertool to also be queried. + + + + Exit status + + On success, 0 is returned, a non-zero failure code otherwise. + + + + + + See Also + + systemd1, + systemd-userdbd.service8, + systemd-homed.service8, + nss-systemd8, + getent1 + + + + diff --git a/man/vconsole.conf.xml b/man/vconsole.conf.xml new file mode 100644 index 0000000..e4e2864 --- /dev/null +++ b/man/vconsole.conf.xml @@ -0,0 +1,144 @@ + + + + + + + vconsole.conf + systemd + + + + vconsole.conf + 5 + + + + vconsole.conf + Configuration file for the virtual console + + + + /etc/vconsole.conf + + + + Description + + The /etc/vconsole.conf file configures + the virtual console, i.e. keyboard mapping and console font. It is + applied at boot by udev using 90-vconsole.rules file. + You can safely mask this file if you want to avoid this kind of initialization. + + + The format of vconsole.conf is a newline-separated list of environment-like + shell-compatible variable assignments, ignoring comments and empty lines. It is possible to source the + configuration from shell scripts, however, beyond mere variable assignments no shell features are + supported, allowing applications to read the file without implementing a shell compatible execution + engine. See + os-release5 for a + detailed description of the format. + + Note that the kernel command line options + vconsole.keymap=, + vconsole.keymap_toggle=, + vconsole.font=, + vconsole.font_map=, + vconsole.font_unimap= may be used + to override the console settings at boot. + + Depending on the operating system other configuration files + might be checked for configuration of the virtual console as well, + however only as fallback. + + /etc/vconsole.conf is usually created and updated + using + systemd-localed.service8. + localectl1 + may be used to instruct systemd-localed.service to + query or update configuration. + + + + Options + + The following options are understood: + + + + + KEYMAP= + KEYMAP_TOGGLE= + + Configures the key mapping table for the keyboard. + KEYMAP= defaults to us if not set. The + KEYMAP_TOGGLE= can be used to configure a second toggle keymap and is by + default unset. + + + + FONT= + FONT_MAP= + FONT_UNIMAP= + + Configures the console font, the console map + and the unicode font map. + + + + + + + Kernel Command Line + + A few configuration parameters from vconsole.conf may be overridden + on the kernel command line: + + + + vconsole.keymap= + vconsole.keymap_toggle= + + Overrides KEYMAP= and KEYMAP_TOGGLE=. + + + + + vconsole.font= + vconsole.font_map= + vconsole.font_unimap= + + Overrides FONT=, FONT_MAP=, and + FONT_UNIMAP=. + + + + + + Example + + + German keyboard and console + + /etc/vconsole.conf: + + KEYMAP=de-latin1 +FONT=eurlatgr + + + + + + See Also + + systemd1, + systemd-vconsole-setup.service8, + loadkeys1, + setfont8, + locale.conf5, + systemd-localed.service8 + + + + diff --git a/man/veritytab.xml b/man/veritytab.xml new file mode 100644 index 0000000..dc2f11c --- /dev/null +++ b/man/veritytab.xml @@ -0,0 +1,198 @@ + + + + + + + + veritytab + systemd + + + + veritytab + 5 + + + + veritytab + Configuration for verity block devices + + + + /etc/veritytab + + + + Description + + The /etc/veritytab file describes + verity protected block devices that are set up during + system boot. + + Empty lines and lines starting with the # + character are ignored. Each of the remaining lines describes one + verity protected block device. Fields are delimited by + white space. + + Each line is in the formvolume-name data-device hash-device roothash options + The first four fields are mandatory, the remaining one is optional. + + The first field contains the name of the resulting verity volume; its block device is set up + below /dev/mapper/. + + The second field contains a path to the underlying block data device, or a specification of a block device via + UUID= followed by the UUID. + + The third field contains a path to the underlying block hash device, or a specification of a block device via + UUID= followed by the UUID. + + The fourth field is the roothash in hexadecimal. + + The fifth field, if present, is a comma-delimited list of options. The following options are + recognized: + + + + + + + + + Defines what to do if a data verity problem is detected (data corruption). Without these + options kernel fails the IO operation with I/O error. With --ignore-corruption option the + corruption is only logged. With --restart-on-corruption or + --panic-on-corruption the kernel is restarted (panicked) immediately. + + (You have to provide way how to avoid restart loops.) + + + + + + Instruct kernel to not verify blocks that are expected to contain zeroes and always directly + return zeroes instead. + + WARNING: Use this option only in very specific cases. This option is available since Linux kernel version 4.5. + + + + + + + Instruct kernel to verify blocks only the first time they are read from the data device, rather + than every time. + + WARNING: It provides a reduced level of security because only offline tampering of the data device's content + will be detected, not online tampering. This option is available since Linux kernel version 4.17. + + + + + + + A base64 string encoding the root hash signature prefixed by base64: or a + path to roothash signature file used to verify the root hash (in kernel). This feature requires Linux kernel + version 5.4 or more recent. + + + + + + Marks this veritysetup device as requiring network. It will be + started after the network is available, similarly to + systemd.mount5 + units marked with . The service unit to set up this device + will be ordered between remote-fs-pre.target and + remote-veritysetup.target, instead of + veritysetup-pre.target and + veritysetup.target. + + Hint: if this device is used for a mount point that is specified in + fstab5, + the option should also be used for the mount + point. Otherwise, a dependency loop might be created where the mount point + will be pulled in by local-fs.target, while the + service to configure the network is usually only started after + the local file system has been mounted. + + + + + + + This device will not be added to veritysetup.target. + This means that it will not be automatically enabled on boot, unless something else pulls + it in. In particular, if the device is used for a mount point, it'll be enabled + automatically during boot, unless the mount point itself is also disabled with + . + + + + + + This device will not be a hard dependency of + veritysetup.target. It'll still be pulled in and started, but the system + will not wait for the device to show up and be enabled, and boot will not fail if this is + unsuccessful. Note that other units that depend on the enabled device may still fail. In + particular, if the device is used for a mount point, the mount point itself also needs to + have the option, or the boot will fail if the device is not enabled + successfully. + + + + + + Setup this verity protected block device in the initrd, similarly to + systemd.mount5 + units marked with . + + Although it's not necessary to mark the mount entry for the root file system with + , is still recommended with + the verity protected block device containing the root file system as otherwise systemd + will attempt to detach the device during the regular system shutdown while it's still in + use. With this option the device will still be detached but later after the root file + system is unmounted. + + All other verity protected block devices that contain file systems mounted in the initrd should + use this option. + + + + + + At early boot and when the system manager configuration is + reloaded, this file is translated into native systemd units by + systemd-veritysetup-generator8. + + + + Examples + + /etc/veritytab example + Set up two verity protected block devices. One using device blocks, another using files. + + usr PARTUUID=783e45ae-7aa3-484a-beef-a80ff9c19cbb PARTUUID=21dc1dfe-4c33-8b48-98a9-918a22eb3e37 36e3f740ad502e2c25e2a23d9c7c17bf0fdad2300b7580842d4b7ec1fb0fa263 auto +data /etc/data /etc/hash a5ee4b42f70ae1f46a08a7c92c2e0a20672ad2f514792730f5d49d7606ab8fdf auto + + + + + + See Also + + systemd1, + systemd-veritysetup@.service8, + systemd-veritysetup-generator8, + fstab5, + veritysetup8, + + + + diff --git a/man/vtable-example.c b/man/vtable-example.c new file mode 100644 index 0000000..e3346a8 --- /dev/null +++ b/man/vtable-example.c @@ -0,0 +1,112 @@ +/* SPDX-License-Identifier: MIT-0 */ + +#include +#include +#include +#include +#include +#include + +#define _cleanup_(f) __attribute__((cleanup(f))) + +#define check(x) ({ \ + int r = (x); \ + errno = r < 0 ? -r : 0; \ + printf(#x ": %m\n"); \ + if (r < 0) \ + return EXIT_FAILURE; \ + }) + +typedef struct object { + char *name; + uint32_t number; +} object; + +static int method(sd_bus_message *m, void *userdata, sd_bus_error *error) { + printf("Got called with userdata=%p\n", userdata); + + if (sd_bus_message_is_method_call(m, + "org.freedesktop.systemd.VtableExample", + "Method4")) + return 1; + + const char *string; + check(sd_bus_message_read(m, "s", &string)); + check(sd_bus_reply_method_return(m, "s", string)); + + return 1; +} + +static const sd_bus_vtable vtable[] = { + SD_BUS_VTABLE_START(0), + SD_BUS_METHOD( + "Method1", "s", "s", method, 0), + SD_BUS_METHOD_WITH_NAMES_OFFSET( + "Method2", + "so", SD_BUS_PARAM(string) SD_BUS_PARAM(path), + "s", SD_BUS_PARAM(returnstring), + method, offsetof(object, number), + SD_BUS_VTABLE_DEPRECATED), + SD_BUS_METHOD_WITH_ARGS_OFFSET( + "Method3", + SD_BUS_ARGS("s", string, "o", path), + SD_BUS_RESULT("s", returnstring), + method, offsetof(object, number), + SD_BUS_VTABLE_UNPRIVILEGED), + SD_BUS_METHOD_WITH_ARGS( + "Method4", + SD_BUS_NO_ARGS, + SD_BUS_NO_RESULT, + method, + SD_BUS_VTABLE_UNPRIVILEGED), + SD_BUS_SIGNAL( + "Signal1", + "so", + 0), + SD_BUS_SIGNAL_WITH_NAMES( + "Signal2", + "so", SD_BUS_PARAM(string) SD_BUS_PARAM(path), + 0), + SD_BUS_SIGNAL_WITH_ARGS( + "Signal3", + SD_BUS_ARGS("s", string, "o", path), + 0), + SD_BUS_WRITABLE_PROPERTY( + "AutomaticStringProperty", "s", NULL, NULL, + offsetof(object, name), + SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE), + SD_BUS_WRITABLE_PROPERTY( + "AutomaticIntegerProperty", "u", NULL, NULL, + offsetof(object, number), + SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION), + SD_BUS_VTABLE_END +}; + +int main(int argc, char **argv) { + _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL; + + sd_bus_default(&bus); + + object object = { .number = 666 }; + check((object.name = strdup("name")) != NULL); + + check(sd_bus_add_object_vtable(bus, NULL, + "/org/freedesktop/systemd/VtableExample", + "org.freedesktop.systemd.VtableExample", + vtable, + &object)); + + check(sd_bus_request_name(bus, + "org.freedesktop.systemd.VtableExample", + 0)); + + for (;;) { + check(sd_bus_wait(bus, UINT64_MAX)); + check(sd_bus_process(bus, NULL)); + } + + check(sd_bus_release_name(bus, "org.freedesktop.systemd.VtableExample")); + free(object.name); + + return 0; +} diff --git a/man/vtable-example.xml b/man/vtable-example.xml new file mode 100644 index 0000000..a195777 --- /dev/null +++ b/man/vtable-example.xml @@ -0,0 +1,55 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/man/yubikey-crypttab.sh b/man/yubikey-crypttab.sh new file mode 100644 index 0000000..ce9c291 --- /dev/null +++ b/man/yubikey-crypttab.sh @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: MIT-0 + +# Destroy any old key on the Yubikey (careful!) +ykman piv reset + +# Generate a new private/public key pair on the device, store the public key in +# 'pubkey.pem'. +ykman piv generate-key -a RSA2048 9d pubkey.pem + +# Create a self-signed certificate from this public key, and store it on the +# device. The "subject" should be an arbitrary user-chosen string to identify +# the token with. +ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem + +# We don't need the public key anymore, let's remove it. Since it is not +# security sensitive we just do a regular "rm" here. +rm pubkey.pem + +# Enroll the freshly initialized security token in the LUKS2 volume. Replace +# /dev/sdXn by the partition to use (e.g. /dev/sda1). +sudo systemd-cryptenroll --pkcs11-token-uri=auto /dev/sdXn + +# Test: Let's run systemd-cryptsetup to test if this all worked. +sudo /usr/lib/systemd/systemd-cryptsetup attach mytest /dev/sdXn - pkcs11-uri=auto + +# If that worked, let's now add the same line persistently to /etc/crypttab, +# for the future. +sudo bash -c 'echo "mytest /dev/sdXn - pkcs11-uri=auto" >> /etc/crypttab' -- cgit v1.2.3