systemd中文文档

- 启动: http://systemd.cn/docs/Booting/
- 自动启动评估: http://systemd.cn/docs/Booting/AUTOMATIC_BOOT_ASSESSMENT/
- 启动组件和根文件系统探测: http://systemd.cn/docs/Booting/ROOTFS_DISCOVERY/
- 引导加载程序接口: http://systemd.cn/docs/Booting/BOOT_LOADER_INTERFACE/
- 恢复出厂设置: http://systemd.cn/docs/Booting/FACTORY_RESET/
- 挂载点可用性要求: http://systemd.cn/docs/Booting/MOUNT_REQUIREMENTS/
- TPM2 PCR测量: http://systemd.cn/docs/Booting/TPM2_PCR_MEASUREMENTS/
- Boot Loader Specification: http://systemd.cn/docs/BOOT_LOADER_SPECIFICATION/
- Discoverable Partitions: http://systemd.cn/docs/DISCOVERABLE_PARTITIONS/
- Elf Dlopen Metadata: http://systemd.cn/docs/ELF_DLOPEN_METADATA/
- Osc Context: http://systemd.cn/docs/OSC_CONTEXT/
- Package Metadata for Executable Files: http://systemd.cn/docs/PACKAGE_METADATA_FOR_EXECUTABLE_FILES/
- API File Systems: http://systemd.cn/docs/API_FILE_SYSTEMS/
- Appstream Bundle: http://systemd.cn/docs/APPSTREAM_BUNDLE/
- Backports: http://systemd.cn/docs/BACKPORTS/
- Booting Without /usr is Broken: http://systemd.cn/docs/SEPARATE_USR_IS_BROKEN/
- Code Quality Tools: http://systemd.cn/docs/CODE_QUALITY/
- Coding Style: http://systemd.cn/docs/CODING_STYLE/
- Compatibility with SysV: http://systemd.cn/docs/INCOMPATIBILITIES/
- Container Interface: http://systemd.cn/docs/CONTAINER_INTERFACE/
- Contributing: http://systemd.cn/docs/CONTRIBUTING/
- Control Group APIs and Delegation: http://systemd.cn/docs/CGROUP_DELEGATION/
- Converting Existing Users to systemd-homed: http://systemd.cn/docs/CONVERTING_TO_HOMED/
- Credentials: http://systemd.cn/docs/CREDENTIALS/
- Desktop Environment Integration: http://systemd.cn/docs/DESKTOP_ENVIRONMENTS/
- Diagnosing Boot Problems: http://systemd.cn/docs/DEBUGGING/
- File Descriptor Store: http://systemd.cn/docs/FILE_DESCRIPTOR_STORE/
- Frequently Asked Questions: http://systemd.cn/docs/FAQ/
- Governance: http://systemd.cn/docs/GOVERNANCE/
- Hacking on systemd: http://systemd.cn/docs/HACKING/
- Home Directories: http://systemd.cn/docs/HOME_DIRECTORY/
- Inhibitor Locks: http://systemd.cn/docs/INHIBITOR_LOCKS/
- Initrd Interface: http://systemd.cn/docs/INITRD_INTERFACE/
- Journal Export Formats: http://systemd.cn/docs/JOURNAL_EXPORT_FORMATS/
- Journal File Format: http://systemd.cn/docs/JOURNAL_FILE_FORMAT/
- Journal Message Catalogs: http://systemd.cn/docs/CATALOG/
- JSON Group Records: http://systemd.cn/docs/GROUP_RECORD/
- JSON User Records: http://systemd.cn/docs/USER_RECORD/
- Known Environment Variables: http://systemd.cn/docs/ENVIRONMENT/
- Locking Block Device Access: http://systemd.cn/docs/BLOCK_DEVICE_LOCKING/
- Minimal Builds: http://systemd.cn/docs/MINIMAL_BUILDS/
- My Service Can't Get Realtime!: http://systemd.cn/docs/MY_SERVICE_CANT_GET_REALTIME/
- Native Journal Protocol: http://systemd.cn/docs/JOURNAL_NATIVE_PROTOCOL/
- New Control Group Interfaces: http://systemd.cn/docs/CONTROL_GROUP_INTERFACE/
- Notes for Translators: http://systemd.cn/docs/TRANSLATORS/
- Password Agents: http://systemd.cn/docs/PASSWORD_AGENTS/
- Pax Controla Groupiana: http://systemd.cn/docs/PAX_CONTROL_GROUPS/
- Portability and Stability: http://systemd.cn/docs/PORTABILITY_AND_STABILITY/
- Portable Services Introduction: http://systemd.cn/docs/PORTABLE_SERVICES/
- Porting systemd To New Distributions: http://systemd.cn/docs/DISTRO_PORTING/
- Porting to New Architectures: http://systemd.cn/docs/PORTING_TO_NEW_ARCHITECTURES/
- Predictable Network Interface Names: http://systemd.cn/docs/PREDICTABLE_INTERFACE_NAMES/
- Presets: http://systemd.cn/docs/PRESET/
- Project IDs for Disk Quotas on Exec Directories: http://systemd.cn/docs/DISK-QUOTAS-PROJECTIDS/
- Random Seeds: http://systemd.cn/docs/RANDOM_SEEDS/
- Reporting of Security Vulnerabilities: http://systemd.cn/docs/SECURITY/
- Resource Pressure Handling: http://systemd.cn/docs/PRESSURE/
- Running Services After the Network Is Up: http://systemd.cn/docs/NETWORK_ONLINE/
- Safely Building Images: http://systemd.cn/docs/BUILDING_IMAGES/
- Socket Activation with Popular Daemons: http://systemd.cn/docs/DAEMON_SOCKET_ACTIVATION/
- Steps to a Successful Release: http://systemd.cn/docs/RELEASE/
- Storage Daemons for the Root File System: http://systemd.cn/docs/ROOT_STORAGE_DAEMONS/
- systemd Community Conduct Guidelines: http://systemd.cn/docs/CODE_OF_CONDUCT/
- systemd Coredump Handling: http://systemd.cn/docs/COREDUMP/
- systemd File Hierarchy Requirements: http://systemd.cn/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS/
- systemd Optimizations: http://systemd.cn/docs/OPTIMIZATIONS/
- systemd Repository Architecture: http://systemd.cn/docs/ARCHITECTURE/
- systemd-boot UEFI Boot Manager: http://systemd.cn/docs/BOOT/
- systemd-homed and JSON User/Group Record Support in Desktop Environments: http://systemd.cn/docs/USERDB_AND_DESKTOPS/
- systemd-resolved and VPNs: http://systemd.cn/docs/RESOLVED-VPNS/
- Testing systemd Using Sanitizers: http://systemd.cn/docs/TESTING_WITH_SANITIZERS/
- The Case for the /usr Merge: http://systemd.cn/docs/THE_CASE_FOR_THE_USR_MERGE/
- Tips And Tricks: http://systemd.cn/docs/TIPS_AND_TRICKS/
- User Record Blob Directories: http://systemd.cn/docs/USER_RECORD_BLOB_DIRS/
- User/Group Name Syntax: http://systemd.cn/docs/USER_NAMES/
- User/Group Record Lookup API via Varlink: http://systemd.cn/docs/USER_GROUP_API/
- Users, Groups, UIDs and GIDs on systemd Systems: http://systemd.cn/docs/UIDS-GIDS/
- Using /tmp/ and /var/tmp/ Safely: http://systemd.cn/docs/TEMPORARY_DIRECTORIES/
- Varlink API Style: http://systemd.cn/docs/VARLINK/
- VM Interface: http://systemd.cn/docs/VM_INTERFACE/
- What Settings Are Currently Available For Transient Units?: http://systemd.cn/docs/TRANSIENT-SETTINGS/
- Writing Desktop Environments: http://systemd.cn/docs/WRITING_DESKTOP_ENVIRONMENTS/
- Writing Display Managers: http://systemd.cn/docs/WRITING_DISPLAY_MANAGERS/
- Writing Network Configuration Managers: http://systemd.cn/docs/WRITING_NETWORK_CONFIGURATION_MANAGERS/
- Writing Resolver Clients: http://systemd.cn/docs/WRITING_RESOLVER_CLIENTS/
- Writing syslog Daemons Which Cooperate Nicely With systemd: http://systemd.cn/docs/SYSLOG/
- Writing VM and Container Managers: http://systemd.cn/docs/WRITING_VM_AND_CONTAINER_MANAGERS/


# Writing syslog Daemons Which Cooperate Nicely With systemd

Here are a few notes on things to keep in mind when you work on a classic BSD syslog daemon for Linux, to ensure that your syslog daemon works nicely together with systemd.
If your syslog implementation does not follow these rules, then it will not be compatible with systemd v38 and newer.

A few notes in advance: systemd centralizes all log streams in the Journal daemon.
Messages coming in via /dev/log, via the native protocol, via STDOUT/STDERR of all services and via the kernel are received in the journal daemon.

The journal daemon then stores them to disk or in RAM (depending on the configuration of the Storage= option in journald.conf), and optionally forwards them to the console, the kernel log buffer, or to a classic BSD syslog daemon -- and that's where you come in.

Note that it is now the journal that listens on /dev/log, no longer the BSD syslog daemon directly.
If your logging daemon wants to get access to all logging data then it should listen on /run/systemd/journal/syslog instead via the syslog.socket unit file that is shipped along with systemd.
On a systemd system it is no longer OK to listen on /dev/log directly, and your daemon may not bind to the /run/systemd/journal/syslog socket on its own.
If you do that then you will lose logging from STDOUT/STDERR of services (as well as other stuff).

Your BSD compatible logging service should alias `syslog.service` to itself (i.e. symlink) when it is _enabled_.
That way [syslog.socket](https://github.com/systemd/systemd/blob/main/units/syslog.socket) will activate your service when things are logged.
Of course, only one implementation of BSD syslog can own that symlink, and hence only one implementation can be enabled at a time, but that's intended as there can only be one process listening on that socket.
(see below for details how to manage this symlink.)

Note that this means that syslog.socket as shipped with systemd is _shared_ among all implementations, and the implementation that is in control is configured with where syslog.service points to.

Note that journald tries hard to forward to your BSD syslog daemon as much as it can.
That means you will get more than you traditionally got on /dev/log, such as stuff all daemons log on STDOUT/STDERR and the messages that are logged natively to systemd. Also, we will send stuff like the original SCM_CREDENTIALS along if possible.

(BTW, journald is smart enough not to forward the kernel messages it gets to you, you should read that on your own, directly from /proc/kmsg, as you always did.
It's also smart enough never to forward kernel messages back to the kernel, but that probably shouldn't concern you too much...)

And here are the recommendations:

- First of all, make sure your syslog daemon installs a native service unit file (SysV scripts are not sufficient!) and is socket activatable. Newer systemd versions (v35+) do not support non-socket-activated syslog daemons anymore and we do no longer recommend people to order their units after syslog.target.
That means that unless your syslog implementation is socket activatable many services will not be able to log to your syslog implementation and early boot messages are lost entirely to your implementation.
Note that your service should install only one unit file, and nothing else. Do not install socket unit files.

- Make sure that in your unit file you set StandardOutput=null in the [Service] block.
This makes sure that regardless what the global default for StandardOutput= is the output of your syslog implementation goes to /dev/null.
This matters since the default StandardOutput= value for all units can be set to syslog and this should not create a feedback loop with your implementation where the messages your syslog implementation writes out are fed back to it.
In other words: you need to explicitly opt out of the default standard output redirection we do for other services.
(Also note that you do not need to set StandardError= explicitly, since that inherits the setting of StandardOutput= by default)

- /proc/kmsg is your property, flush it to disk as soon as you start up.

- Name your service unit after your daemon (e.g. rsyslog.service or syslog-ng.service) and make sure to include Alias=syslog.service in your [Install] section in the unit file.
This is ensures that the symlink syslog.service is created if your service is enabled and that it points to your service.
Also add WantedBy=multi-user.target so that your service gets started at boot, and add Requires=syslog.socket in [Unit] so that you pull in the socket unit.

Here are a few other recommendations, that are not directly related to systemd:

- Make sure to read the priority prefixes of the kmsg log messages the same way like from normal userspace syslog messages.
When systemd writes to kmsg it will prefix all messages with valid priorities which include standard syslog facility values. OTOH for kernel messages the facility is always 0.
If you need to know whether a message originated in the kernel rely on the facility value, not just on the fact that you read the message from /proc/kmsg! A number of userspace applications write messages to kmsg (systemd, udev, dracut, others), and they'll nowadays all set correct facility values.

- When you read a message from the socket use SCM_CREDENTIALS to get information about the client generating it, and possibly patch the message with this data in order to make it impossible for clients to fake identities.

The unit file you install for your service should look something like this:

```
[Unit]
Description=System Logging Service
Requires=syslog.socket

[Service]
ExecStart=/usr/sbin/syslog-ng -n
StandardOutput=null

[Install]
Alias=syslog.service
WantedBy=multi-user.target
```

And remember: don't ship any socket unit for /dev/log or /run/systemd/journal/syslog (or even make your daemon bind directly to these sockets)! That's already shipped along with systemd for you.