2020-11-09 04:23:58 +00:00
|
|
|
|
# SPDX-License-Identifier: LGPL-2.1-or-later
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
# Message catalog for systemd's own messages
|
|
|
|
|
|
|
|
|
|
# The catalog format is documented on
|
2017-02-21 17:21:13 +00:00
|
|
|
|
# https://www.freedesktop.org/wiki/Software/systemd/catalog
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
2012-11-20 01:18:47 +00:00
|
|
|
|
# For an explanation why we do all this, see https://xkcd.com/1024/
|
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
-- f77379a8490b408bbe5f6940505a777b
|
2015-01-13 15:06:25 +00:00
|
|
|
|
Subject: The journal has been started
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
2015-01-13 15:06:25 +00:00
|
|
|
|
The system journal process has started up, opened the journal
|
2012-11-16 02:03:22 +00:00
|
|
|
|
files for writing and is now ready to process requests.
|
|
|
|
|
|
|
|
|
|
-- d93fb3c9c24d451a97cea615ce59c00b
|
2015-01-13 15:06:25 +00:00
|
|
|
|
Subject: The journal has been stopped
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
The system journal process has shut down and closed all currently
|
|
|
|
|
active journal files.
|
|
|
|
|
|
journald: use structured message + catalog entry for disk usage
The format of the journald disk usage log entry was changed back and
forth a few times. It is annoying to have a very verbose message, but
if it is short it is hard to understand. But we have a tool for this,
the catalogue.
$ journalctl -x -u systemd-journald
Jan 23 18:48:50 rawhide systemd-journald[891]: Runtime journal (/run/log/journal/) is 8.0M, max 196.2M, 188.2M free.
-- Subject: Disk space used by the journal
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Runtime journal (/run/log/journal/) is currently using 8.0M.
-- Maximum allowed usage is set to 196.2M.
-- Leaving at least 294.3M free (of currently available 1.9G of disk space).
-- Enforced usage limit is thus 196.2M, of which 188.2M are still available.
--
-- The limits controlling how much disk space is used by the journal may
-- be configured with SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=,
-- RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize= settings in
-- /etc/systemd/journald.conf. See journald.conf(5) for details.
Jan 23 18:48:50 rawhide systemd-journald[891]: System journal (/var/log/journal/) is 480.1M, max 1.6G, 1.2G free.
-- Subject: Disk space used by the journal
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- System journal (/var/log/journal/) is currently using 480.1M.
-- Maximum allowed usage is set to 1.6G.
-- Leaving at least 2.5G free (of currently available 5.8G of disk space).
-- Enforced usage limit is thus 1.6G, of which 1.2G are still available.
--
-- The limits controlling how much disk space is used by the journal may
-- be configured with SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=,
-- RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize= settings in
-- /etc/systemd/journald.conf. See journald.conf(5) for details.
2015-11-10 12:44:19 +00:00
|
|
|
|
-- ec387f577b844b8fa948f33cad9a75e6
|
|
|
|
|
Subject: Disk space used by the journal
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
journald: use structured message + catalog entry for disk usage
The format of the journald disk usage log entry was changed back and
forth a few times. It is annoying to have a very verbose message, but
if it is short it is hard to understand. But we have a tool for this,
the catalogue.
$ journalctl -x -u systemd-journald
Jan 23 18:48:50 rawhide systemd-journald[891]: Runtime journal (/run/log/journal/) is 8.0M, max 196.2M, 188.2M free.
-- Subject: Disk space used by the journal
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Runtime journal (/run/log/journal/) is currently using 8.0M.
-- Maximum allowed usage is set to 196.2M.
-- Leaving at least 294.3M free (of currently available 1.9G of disk space).
-- Enforced usage limit is thus 196.2M, of which 188.2M are still available.
--
-- The limits controlling how much disk space is used by the journal may
-- be configured with SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=,
-- RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize= settings in
-- /etc/systemd/journald.conf. See journald.conf(5) for details.
Jan 23 18:48:50 rawhide systemd-journald[891]: System journal (/var/log/journal/) is 480.1M, max 1.6G, 1.2G free.
-- Subject: Disk space used by the journal
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- System journal (/var/log/journal/) is currently using 480.1M.
-- Maximum allowed usage is set to 1.6G.
-- Leaving at least 2.5G free (of currently available 5.8G of disk space).
-- Enforced usage limit is thus 1.6G, of which 1.2G are still available.
--
-- The limits controlling how much disk space is used by the journal may
-- be configured with SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=,
-- RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize= settings in
-- /etc/systemd/journald.conf. See journald.conf(5) for details.
2015-11-10 12:44:19 +00:00
|
|
|
|
|
|
|
|
|
@JOURNAL_NAME@ (@JOURNAL_PATH@) is currently using @CURRENT_USE_PRETTY@.
|
|
|
|
|
Maximum allowed usage is set to @MAX_USE_PRETTY@.
|
|
|
|
|
Leaving at least @DISK_KEEP_FREE_PRETTY@ free (of currently available @DISK_AVAILABLE_PRETTY@ of disk space).
|
|
|
|
|
Enforced usage limit is thus @LIMIT_PRETTY@, of which @AVAILABLE_PRETTY@ are still available.
|
|
|
|
|
|
|
|
|
|
The limits controlling how much disk space is used by the journal may
|
|
|
|
|
be configured with SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=,
|
|
|
|
|
RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize= settings in
|
|
|
|
|
/etc/systemd/journald.conf. See journald.conf(5) for details.
|
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
-- a596d6fe7bfa4994828e72309e95d61e
|
|
|
|
|
Subject: Messages from a service have been suppressed
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Documentation: man:journald.conf(5)
|
|
|
|
|
|
|
|
|
|
A service has logged too many messages within a time period. Messages
|
|
|
|
|
from the service have been dropped.
|
|
|
|
|
|
|
|
|
|
Note that only messages from the service in question have been
|
|
|
|
|
dropped, other services' messages are unaffected.
|
|
|
|
|
|
2015-01-13 15:06:25 +00:00
|
|
|
|
The limits controlling when messages are dropped may be configured
|
2016-04-26 18:46:20 +00:00
|
|
|
|
with RateLimitIntervalSec= and RateLimitBurst= in
|
2018-10-08 03:28:36 +00:00
|
|
|
|
/etc/systemd/journald.conf or LogRateLimitIntervalSec= and LogRateLimitBurst=
|
|
|
|
|
in the unit file. See journald.conf(5) and systemd.exec(5) for details.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
-- e9bf28e6e834481bb6f48f548ad13606
|
|
|
|
|
Subject: Journal messages have been missed
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
Kernel messages have been lost as the journal system has been unable
|
|
|
|
|
to process them quickly enough.
|
|
|
|
|
|
2012-11-15 22:03:31 +00:00
|
|
|
|
-- fc2e22bc6ee647b6b90729ab34a250b1
|
|
|
|
|
Subject: Process @COREDUMP_PID@ (@COREDUMP_COMM@) dumped core
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Documentation: man:core(5)
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
|
|
|
|
Process @COREDUMP_PID@ (@COREDUMP_COMM@) crashed and dumped core.
|
|
|
|
|
|
|
|
|
|
This usually indicates a programming error in the crashing program and
|
2012-11-16 02:03:22 +00:00
|
|
|
|
should be reported to its vendor as a bug.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2016-09-27 10:40:54 +00:00
|
|
|
|
-- 5aadd8e954dc4b1a8c954d63fd9e1137
|
|
|
|
|
Subject: Core file was truncated to @SIZE_LIMIT@ bytes.
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
Documentation: man:coredump.conf(5)
|
|
|
|
|
|
|
|
|
|
The process had more memory mapped than the configured maximum for processing
|
|
|
|
|
and storage by systemd-coredump(8). Only the first @SIZE_LIMIT@ bytes were
|
|
|
|
|
saved. This core might still be usable, but various tools like gdb(1) will warn
|
|
|
|
|
about the file being truncated.
|
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
-- 8d45620c1a4348dbb17410da57c60c66
|
|
|
|
|
Subject: A new session @SESSION_ID@ has been created for user @USER_ID@
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2020-10-15 18:49:18 +00:00
|
|
|
|
Documentation: sd-login(3)
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
A new session with the ID @SESSION_ID@ has been created for the user @USER_ID@.
|
|
|
|
|
|
|
|
|
|
The leading process of the session is @LEADER@.
|
|
|
|
|
|
|
|
|
|
-- 3354939424b4456d9802ca8333ed424a
|
2015-01-13 15:06:25 +00:00
|
|
|
|
Subject: Session @SESSION_ID@ has been terminated
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2020-10-15 18:49:18 +00:00
|
|
|
|
Documentation: sd-login(3)
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
A session with the ID @SESSION_ID@ has been terminated.
|
|
|
|
|
|
|
|
|
|
-- fcbefc5da23d428093f97c82a9290f7b
|
|
|
|
|
Subject: A new seat @SEAT_ID@ is now available
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2020-10-15 18:49:18 +00:00
|
|
|
|
Documentation: sd-login(3)
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
A new seat @SEAT_ID@ has been configured and is now available.
|
|
|
|
|
|
|
|
|
|
-- e7852bfe46784ed0accde04bc864c2d5
|
2015-01-13 15:06:25 +00:00
|
|
|
|
Subject: Seat @SEAT_ID@ has now been removed
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2020-10-15 18:49:18 +00:00
|
|
|
|
Documentation: sd-login(3)
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
2012-11-17 00:31:47 +00:00
|
|
|
|
A seat @SEAT_ID@ has been removed and is no longer available.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
|
|
|
|
-- c7a787079b354eaaa9e77b371893cd27
|
|
|
|
|
Subject: Time change
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2012-11-17 13:40:05 +00:00
|
|
|
|
The system clock has been changed to @REALTIME@ microseconds after January 1st, 1970.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
|
|
|
|
-- 45f82f4aef7a4bbf942ce861d1f20990
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Subject: Time zone change to @TIMEZONE@
|
2012-11-15 22:03:31 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2013-06-27 19:51:44 +00:00
|
|
|
|
The system timezone has been changed to @TIMEZONE@.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
-- b07a249cd024414a82dd00cd181378ff
|
|
|
|
|
Subject: System start-up is now complete
|
2012-11-15 22:03:31 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
All system services necessary queued for starting at boot have been
|
2016-12-11 16:32:28 +00:00
|
|
|
|
started. Note that this does not mean that the machine is now idle as services
|
|
|
|
|
might still be busy with completing start-up.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2012-11-17 13:40:05 +00:00
|
|
|
|
Kernel start-up required @KERNEL_USEC@ microseconds.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
2022-10-13 20:30:48 +00:00
|
|
|
|
Initrd start-up required @INITRD_USEC@ microseconds.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
2012-11-21 17:54:46 +00:00
|
|
|
|
Userspace start-up required @USERSPACE_USEC@ microseconds.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
2016-12-11 16:32:28 +00:00
|
|
|
|
-- eed00a68ffd84e31882105fd973abdd1
|
|
|
|
|
Subject: User manager start-up is now complete
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
The user manager instance for user @_UID@ has been started. All services queued
|
|
|
|
|
for starting have been started. Note that other services might still be starting
|
|
|
|
|
up or be started at any later time.
|
|
|
|
|
|
|
|
|
|
Startup of the manager took @USERSPACE_USEC@ microseconds.
|
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
-- 6bbd95ee977941e497c48be27c254128
|
|
|
|
|
Subject: System sleep state @SLEEP@ entered
|
2012-11-15 22:03:31 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
The system has now entered the @SLEEP@ sleep state.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
-- 8811e6df2a8e40f58a94cea26f8ebf14
|
|
|
|
|
Subject: System sleep state @SLEEP@ left
|
2012-11-15 22:03:31 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
The system has now left the @SLEEP@ sleep state.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
-- 98268866d1d54a499c4e98921d93bc40
|
|
|
|
|
Subject: System shutdown initiated
|
2012-11-15 22:03:31 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2017-12-13 16:43:03 +00:00
|
|
|
|
System shutdown has been initiated. The shutdown has now begun and
|
2012-11-16 02:03:22 +00:00
|
|
|
|
all system services are terminated and all file systems unmounted.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
2021-07-25 02:20:27 +00:00
|
|
|
|
-- c14aaf76ec284a5fa1f105f88dfb061c
|
|
|
|
|
Subject: System factory reset initiated
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
System factory reset has been initiated. The precise operation this
|
|
|
|
|
executes is implementation-defined, but typically has the effect of
|
|
|
|
|
reverting the system's state and configuration to vendor defaults.
|
|
|
|
|
|
2023-09-04 13:31:47 +00:00
|
|
|
|
-- d9ec5e95e4b646aaaea2fd05214edbda
|
|
|
|
|
Subject: Container init crashed
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Container init has crashed and exited.
|
2023-08-30 09:30:42 +00:00
|
|
|
|
The details of the crash can be obtained from the container manager.
|
|
|
|
|
|
|
|
|
|
-- 3ed0163e868a4417ab8b9e210407a96c
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: System reboot failed after crash
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
Reboot has failed when systemd attempted to reboot after a crash.
|
|
|
|
|
|
|
|
|
|
-- 645c735537634ae0a32b15a7c6cba7d4
|
2023-09-05 04:57:28 +00:00
|
|
|
|
Subject: Init execution froze
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-09-05 04:57:28 +00:00
|
|
|
|
Systemd froze execution after fatal error.
|
2023-08-30 09:30:42 +00:00
|
|
|
|
|
|
|
|
|
-- 5addb3a06a734d3396b794bf98fb2d01
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init received fatal signal while coredump is disabled
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Systemd received fatal signal, but core dumping is disabled.
|
2023-08-30 09:30:42 +00:00
|
|
|
|
|
|
|
|
|
-- 5c9e98de4ab94c6a9d04d0ad793bd903
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init received fatal signal but fork failed
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Systemd received fatal signal, but failed to fork to dump the core.
|
|
|
|
|
|
2023-08-30 09:30:42 +00:00
|
|
|
|
-- 5e6f1f5e4db64a0eaee3368249d20b94
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init received fatal signal from unknown sender process
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 83f84b35ee264f74a3896a9717af34cb
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init received fatal signal from our own process
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 3a73a98baf5b4b199929e3226c0be783
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init received fatal signal from other process
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 2ed18d4f78ca47f0a9bc25271c26adb4
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init received fatal signal but waitpid() failed
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Systemd received fatal signal, but waitpid() failed when
|
|
|
|
|
trying to dump the core.
|
|
|
|
|
|
2023-08-30 09:30:42 +00:00
|
|
|
|
-- 56b1cd96f24246c5b607666fda952356
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init received fatal signal but coredump failed
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 4ac7566d4d7548f4981f629a28f0f829
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init received fatal signal and dumped core
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 38e8b1e039ad469291b18b44c553a5b7
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init failed to fork crash shell
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Systemd crashed and failed to fork off crash shell.
|
|
|
|
|
|
2023-08-30 09:30:42 +00:00
|
|
|
|
-- 872729b47dbe473eb768ccecd477beda
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Crash shell failed to execute
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Systemd crashed and failed to spawn crash shell.
|
|
|
|
|
|
2023-08-30 09:30:42 +00:00
|
|
|
|
-- 658a67adc1c940b3b3316e7e8628834a
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Manager failed to load SELinux policy
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- e6f456bd92004d9580160b2207555186
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Battery level critically low, waiting for charger
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Battery level is critically low. Please connect your charger
|
|
|
|
|
or the system will power off in 10 seconds.
|
|
|
|
|
|
2023-08-30 09:30:42 +00:00
|
|
|
|
-- 267437d33fdd41099ad76221cc24a335
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Battery level critically low, powering off
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 79e05b67bc4545d1922fe47107ee60c5
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Manager failed to run main loop
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- dbb136b10ef4457ba47a795d62f108c9
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: User manager failed to determine $XDG_RUNTIME_DIR path
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- ed158c2df8884fa584eead2d902c1032
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init failed to drop capability bounding set of usermode helpers
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 42695b500df048298bee37159caa9f2e
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init failed to drop capability bounding set
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- bfc2430724ab44499735b4f94cca9295
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: User manager failed to disable new privileges
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 59288af523be43a28d494e41e26e4510
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Manager failed to start default target
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 689b4fcc97b4486ea5da92db69c9e314
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Manager failed to isolate default target
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 5ed836f1766f4a8a9fc5da45aae23b29
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Manager failed to collect passed file descriptors
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 6a40fbfbd2ba4b8db02fb40c9cd090d7
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init failed to fix up environment variables
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- 0e54470984ac419689743d957a119e2e
|
|
|
|
|
Subject: Failed to allocate manager object
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- d67fa9f847aa4b048a2ae33535331adb
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Manager failed to write Smack onlycap list
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- af55a6f75b544431b72649f36ff6d62c
|
|
|
|
|
Subject: Critical error while doing system shutdown
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
-- d18e0339efb24a068d9c1060221048c2
|
2023-09-04 13:31:47 +00:00
|
|
|
|
Subject: Init failed to fork off valgrind helper
|
2023-08-30 09:30:42 +00:00
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2012-11-16 02:03:22 +00:00
|
|
|
|
-- 7d4958e842da4a758f6c1cdc7b36dcc5
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
Subject: A start job for unit @UNIT@ has begun execution
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
A start job for unit @UNIT@ has begun execution.
|
|
|
|
|
|
|
|
|
|
The job identifier is @JOB_ID@.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
-- 39f53479d3a045ac8e11786248231fbf
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
Subject: A start job for unit @UNIT@ has finished successfully
|
2012-11-15 22:03:31 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
A start job for unit @UNIT@ has finished successfully.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
The job identifier is @JOB_ID@.
|
2012-11-15 22:03:31 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
-- be02cf6855d2428ba40df7e9d022f03d
|
|
|
|
|
Subject: A start job for unit @UNIT@ has failed
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
A start job for unit @UNIT@ has finished with a failure.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
The job identifier is @JOB_ID@ and the job result is @JOB_RESULT@.
|
|
|
|
|
|
|
|
|
|
-- de5b426a63be47a7b6ac3eaac82e2f6f
|
|
|
|
|
Subject: A stop job for unit @UNIT@ has begun execution
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
A stop job for unit @UNIT@ has begun execution.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
The job identifier is @JOB_ID@.
|
|
|
|
|
|
|
|
|
|
-- 9d1aaa27d60140bd96365438aad20286
|
|
|
|
|
Subject: A stop job for unit @UNIT@ has finished
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
A stop job for unit @UNIT@ has finished.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
The job identifier is @JOB_ID@ and the job result is @JOB_RESULT@.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
-- d34d037fff1847e6ae669a370e694725
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
Subject: A reload job for unit @UNIT@ has begun execution
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
A reload job for unit @UNIT@ has begun execution.
|
|
|
|
|
|
|
|
|
|
The job identifier is @JOB_ID@.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
-- 7b05ebc668384222baa8881179cfda54
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
Subject: A reload job for unit @UNIT@ has finished
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
A reload job for unit @UNIT@ has finished.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
catalog: update job begin/done messages
These texts have been slightly misleading previously, as they talked
about units, not jobs, but are actually generated for jobs, not units.
This difference matters as units can change state without a job
requesting that.
Also, the message be02cf6855d2428ba40df7e9d022f03d was particularly
wrong, as it claimed the unit failed, while it actually is the start job
that failed, which is a major difference, as jobs can fail without the
unit actually being placed in a failed state. Let's move this message a
bit up, closed to 39f53479d3a045ac8e11786248231fbf (i.e. the message
seen when a start job finished successfully).
2018-11-13 19:36:51 +00:00
|
|
|
|
The job identifier is @JOB_ID@ and the job result is @JOB_RESULT@.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
-- 641257651c1b4ec9a8624d7a40a9e1e7
|
|
|
|
|
Subject: Process @EXECUTABLE@ could not be executed
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
The process @EXECUTABLE@ could not be executed and failed.
|
|
|
|
|
|
2015-01-13 15:06:25 +00:00
|
|
|
|
The error number returned by this process is @ERRNO@.
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
-- 0027229ca0644181a76c4e92458afa2e
|
2012-11-17 00:31:47 +00:00
|
|
|
|
Subject: One or more messages could not be forwarded to syslog
|
2012-11-16 02:03:22 +00:00
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-11-16 02:03:22 +00:00
|
|
|
|
|
|
|
|
|
One or more messages could not be forwarded to the syslog service
|
|
|
|
|
running side-by-side with journald. This usually indicates that the
|
|
|
|
|
syslog implementation has not been able to keep up with the speed of
|
|
|
|
|
messages queued.
|
2012-12-05 10:59:05 +00:00
|
|
|
|
|
|
|
|
|
-- 1dee0369c7fc4736b7099b38ecb46ee7
|
|
|
|
|
Subject: Mount point is not empty
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2012-12-05 10:59:05 +00:00
|
|
|
|
|
|
|
|
|
The directory @WHERE@ is specified as the mount point (second field in
|
|
|
|
|
/etc/fstab or Where= field in systemd unit file) and is not empty.
|
|
|
|
|
This does not interfere with mounting, but the pre-exisiting files in
|
|
|
|
|
this directory become inaccessible. To see those over-mounted files,
|
|
|
|
|
please manually mount the underlying file system to a secondary
|
|
|
|
|
location.
|
2013-06-20 01:45:08 +00:00
|
|
|
|
|
|
|
|
|
-- 24d8d4452573402496068381a6312df2
|
|
|
|
|
Subject: A virtual machine or container has been started
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2013-06-20 01:45:08 +00:00
|
|
|
|
|
|
|
|
|
The virtual machine @NAME@ with its leader PID @LEADER@ has been
|
|
|
|
|
started is now ready to use.
|
|
|
|
|
|
|
|
|
|
-- 58432bd3bace477cb514b56381b8a758
|
|
|
|
|
Subject: A virtual machine or container has been terminated
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2013-06-20 01:45:08 +00:00
|
|
|
|
|
|
|
|
|
The virtual machine @NAME@ with its leader PID @LEADER@ has been
|
|
|
|
|
shut down.
|
2016-01-22 15:20:25 +00:00
|
|
|
|
|
|
|
|
|
-- 36db2dfa5a9045e1bd4af5f93e1cf057
|
|
|
|
|
Subject: DNSSEC mode has been turned off, as server doesn't support it
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2020-05-25 17:32:33 +00:00
|
|
|
|
Documentation: man:systemd-resolved.service(8)
|
|
|
|
|
Documentation: man:resolved.conf(5)
|
2016-01-22 15:20:25 +00:00
|
|
|
|
|
|
|
|
|
The resolver service (systemd-resolved.service) has detected that the
|
|
|
|
|
configured DNS server does not support DNSSEC, and DNSSEC validation has been
|
|
|
|
|
turned off as result.
|
|
|
|
|
|
|
|
|
|
This event will take place if DNSSEC=allow-downgrade is configured in
|
|
|
|
|
resolved.conf and the configured DNS server is incompatible with DNSSEC. Note
|
|
|
|
|
that using this mode permits DNSSEC downgrade attacks, as an attacker might be
|
|
|
|
|
able turn off DNSSEC validation on the system by inserting DNS replies in the
|
|
|
|
|
communication channel that result in a downgrade like this.
|
|
|
|
|
|
|
|
|
|
This event might be indication that the DNS server is indeed incompatible with
|
|
|
|
|
DNSSEC or that an attacker has successfully managed to stage such a downgrade
|
|
|
|
|
attack.
|
|
|
|
|
|
|
|
|
|
-- 1675d7f172174098b1108bf8c7dc8f5d
|
|
|
|
|
Subject: DNSSEC validation failed
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2016-01-22 15:20:25 +00:00
|
|
|
|
Documentation: man:systemd-resolved.service(8)
|
|
|
|
|
|
|
|
|
|
A DNS query or resource record set failed DNSSEC validation. This is usually
|
|
|
|
|
indication that the communication channel used was tampered with.
|
|
|
|
|
|
|
|
|
|
-- 4d4408cfd0d144859184d1e65d7c8a65
|
|
|
|
|
Subject: A DNSSEC trust anchor has been revoked
|
|
|
|
|
Defined-By: systemd
|
2016-06-26 15:43:37 +00:00
|
|
|
|
Support: %SUPPORT_URL%
|
2016-01-22 15:20:25 +00:00
|
|
|
|
Documentation: man:systemd-resolved.service(8)
|
|
|
|
|
|
|
|
|
|
A DNSSEC trust anchor has been revoked. A new trust anchor has to be
|
|
|
|
|
configured, or the operating system needs to be updated, to provide an updated
|
|
|
|
|
DNSSEC trust anchor.
|
2017-09-26 14:42:02 +00:00
|
|
|
|
|
|
|
|
|
-- 5eb03494b6584870a536b337290809b3
|
|
|
|
|
Subject: Automatic restarting of a unit has been scheduled
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
Automatic restarting of the unit @UNIT@ has been scheduled, as the result for
|
|
|
|
|
the configured Restart= setting for the unit.
|
|
|
|
|
|
|
|
|
|
-- ae8f7b866b0347b9af31fe1c80b127c0
|
|
|
|
|
Subject: Resources consumed by unit runtime
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
The unit @UNIT@ completed and consumed the indicated resources.
|
2017-12-14 09:15:41 +00:00
|
|
|
|
|
2018-11-13 22:28:09 +00:00
|
|
|
|
-- 7ad2d189f7e94e70a38c781354912448
|
|
|
|
|
Subject: Unit succeeded
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
The unit @UNIT@ has successfully entered the 'dead' state.
|
|
|
|
|
|
2019-06-29 00:02:30 +00:00
|
|
|
|
-- 0e4284a0caca4bfc81c0bb6786972673
|
|
|
|
|
Subject: Unit skipped
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2019-07-18 05:39:55 +00:00
|
|
|
|
The unit @UNIT@ was skipped due to an ExecCondition= command failure, and has
|
|
|
|
|
entered the 'dead' state with result '@UNIT_RESULT@'.
|
2019-06-29 00:02:30 +00:00
|
|
|
|
|
2018-11-13 20:25:22 +00:00
|
|
|
|
-- d9b373ed55a64feb8242e02dbe79a49c
|
|
|
|
|
Subject: Unit failed
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
The unit @UNIT@ has entered the 'failed' state with result '@UNIT_RESULT@'.
|
|
|
|
|
|
2018-11-13 21:10:38 +00:00
|
|
|
|
-- 98e322203f7a4ed290d09fe03c09fe15
|
|
|
|
|
Subject: Unit process exited
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
An @COMMAND@= process belonging to unit @UNIT@ has exited.
|
|
|
|
|
|
|
|
|
|
The process' exit code is '@EXIT_CODE@' and its exit status is @EXIT_STATUS@.
|
|
|
|
|
|
2017-12-14 09:15:41 +00:00
|
|
|
|
-- 50876a9db00f4c40bde1a2ad381c3a1b
|
|
|
|
|
Subject: The system is configured in a way that might cause problems
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
The following "tags" are possible:
|
|
|
|
|
- "var-run-bad" — /var/run is not a symlink to /run
|
|
|
|
|
- "overflowuid-not-65534" — the kernel user ID used for "unknown" users (with
|
|
|
|
|
NFS or user namespaces) is not 65534
|
|
|
|
|
- "overflowgid-not-65534" — the kernel group ID used for "unknown" users (with
|
|
|
|
|
NFS or user namespaces) is not 65534
|
|
|
|
|
Current system is tagged as @TAINT@.
|
2019-03-19 18:14:53 +00:00
|
|
|
|
|
|
|
|
|
-- fe6faa94e7774663a0da52717891d8ef
|
|
|
|
|
Subject: A process of @UNIT@ unit has been killed by the OOM killer.
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
A process of unit @UNIT has been killed by the Linux kernel out-of-memory (OOM)
|
|
|
|
|
killer logic. This usually indicates that the system is low on memory and that
|
|
|
|
|
memory needed to be freed. A process associated with @UNIT@ has been determined
|
|
|
|
|
as the best process to terminate and has been forcibly terminated by the
|
|
|
|
|
kernel.
|
|
|
|
|
|
|
|
|
|
Note that the memory pressure might or might not have been caused by @UNIT@.
|
2020-04-07 09:15:49 +00:00
|
|
|
|
|
|
|
|
|
-- b61fdac612e94b9182285b998843061f
|
|
|
|
|
Subject: Accepting user/group name @USER_GROUP_NAME@, which does not match strict user/group name rules.
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
2020-05-25 17:32:33 +00:00
|
|
|
|
Documentation: https://systemd.io/USER_NAMES
|
2020-04-07 09:15:49 +00:00
|
|
|
|
|
|
|
|
|
The user/group name @USER_GROUP_NAME@ has been specified, which is accepted
|
|
|
|
|
according the relaxed user/group name rules, but does not qualify under the
|
|
|
|
|
strict rules.
|
|
|
|
|
|
|
|
|
|
The strict user/group name rules written as regular expression are:
|
|
|
|
|
|
|
|
|
|
^[a-zA-Z_][a-zA-Z0-9_-]{0,30}$
|
|
|
|
|
|
|
|
|
|
The relaxed user/group name rules accept all names, except for the empty
|
|
|
|
|
string; names containing NUL bytes, control characters, colon or slash
|
|
|
|
|
characters; names not valid UTF-8; names with leading or trailing whitespace;
|
|
|
|
|
the strings "." or ".."; fully numeric strings, or strings beginning in a
|
|
|
|
|
hyphen and otherwise fully numeric.
|
|
|
|
|
|
2020-05-24 22:37:26 +00:00
|
|
|
|
-- 1b3bb94037f04bbf81028e135a12d293
|
|
|
|
|
Subject: Failed to generate valid unit name from path '@MOUNT_POINT@'.
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
The following mount point path could not be converted into a valid .mount
|
|
|
|
|
unit name:
|
|
|
|
|
|
|
|
|
|
@MOUNT_POINT@
|
|
|
|
|
|
|
|
|
|
Typically this means that the path to the mount point is longer than allowed
|
|
|
|
|
for valid unit names.
|
|
|
|
|
|
|
|
|
|
systemd dynamically synthesizes .mount units for all mount points appearing on
|
|
|
|
|
the system. For that a simple escaping algorithm is applied: the absolute path
|
|
|
|
|
name is used, with all "/" characters replaced by "-" (the leading one is
|
|
|
|
|
removed). Moreover, any non-alphanumeric characters (as well as any of ":",
|
|
|
|
|
"-", "_", ".", "\") are replaced by "\xNN" where "NN" is the hexadecimal code
|
|
|
|
|
of the character. Finally, ".mount" is suffixed. The resulting string must be
|
|
|
|
|
under 256 characters in length to be a valid unit name. This restriction is
|
|
|
|
|
made in order for all unit names to also be suitable as file names. If a mount
|
|
|
|
|
point appears that — after escaping — is longer than this limit it cannot be
|
|
|
|
|
mapped to a unit. In this case systemd will refrain from synthesizing a unit
|
|
|
|
|
and cannot be used to manage the mount point. It will not appear in the service
|
|
|
|
|
manager's unit table and thus also not be torn down safely and automatically at
|
|
|
|
|
system shutdown.
|
|
|
|
|
|
|
|
|
|
It is generally recommended to avoid such overly long mount point paths, or —
|
|
|
|
|
if used anyway – manage them independently of systemd, i.e. establish them as
|
|
|
|
|
well as tear them down automatically at system shutdown by other software.
|
2020-06-26 20:36:39 +00:00
|
|
|
|
|
|
|
|
|
-- b480325f9c394a7b802c231e51a2752c
|
|
|
|
|
Subject: Special user @OFFENDING_USER@ configured, this is not safe!
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
Documentation: https://systemd.io/UIDS-GIDS
|
|
|
|
|
|
|
|
|
|
The unit @UNIT@ is configured to use User=@OFFENDING_USER@.
|
|
|
|
|
|
|
|
|
|
This is not safe. The @OFFENDING_USER@ user's main purpose on Linux-based
|
|
|
|
|
operating systems is to be the owner of files that otherwise cannot be mapped
|
|
|
|
|
to any local user. It's used by the NFS client and Linux user namespacing,
|
|
|
|
|
among others. By running a unit's processes under the identity of this user
|
|
|
|
|
they might possibly get read and even write access to such files that cannot
|
|
|
|
|
otherwise be mapped.
|
|
|
|
|
|
|
|
|
|
It is strongly recommended to avoid running services under this user identity,
|
|
|
|
|
in particular on systems using NFS or running containers. Allocate a user ID
|
|
|
|
|
specific to this service, either statically via systemd-sysusers or dynamically
|
|
|
|
|
via the DynamicUser= service setting.
|
2020-07-08 15:51:55 +00:00
|
|
|
|
|
|
|
|
|
-- 1c0454c1bd2241e0ac6fefb4bc631433
|
|
|
|
|
Subject: systemd-udev-settle.service is deprecated.
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
Usage of the systemd service unit systemd-udev-settle.service is deprecated. It
|
|
|
|
|
inserts artificial delays into the boot process without providing the
|
|
|
|
|
guarantees other subsystems traditionally assumed it provides. Relying on this
|
|
|
|
|
service is racy, and it is generally a bug to make use of it and depend on it.
|
|
|
|
|
|
|
|
|
|
Traditionally, this service's job was to wait until all devices a system
|
|
|
|
|
possesses have been fully probed and initialized, delaying boot until this
|
|
|
|
|
phase is completed. However, today's systems and hardware generally don't work
|
|
|
|
|
this way anymore, hardware today may show up any time and take any time to be
|
|
|
|
|
probed and initialized. Thus, in the general case, it's no longer possible to
|
|
|
|
|
correctly delay boot until "all devices" have been processed, as it is not
|
|
|
|
|
clear what "all devices" means and when they have been found. This is in
|
|
|
|
|
particular the case if USB hardware or network-attached hardware is used.
|
|
|
|
|
|
|
|
|
|
Modern software that requires some specific hardware (such as a network device
|
|
|
|
|
or block device) to operate should only wait for the specific devices it needs
|
|
|
|
|
to show up, and otherwise operate asynchronously initializing devices as they
|
|
|
|
|
appear during boot and during runtime without delaying the boot process.
|
|
|
|
|
|
|
|
|
|
It is a defect of the software in question if it doesn't work this way, and
|
|
|
|
|
still pulls systemd-udev-settle.service into the boot process.
|
|
|
|
|
|
|
|
|
|
Please file a bug report against the following units, with a request for it to
|
|
|
|
|
be updated to operate in a hotplug fashion without depending on
|
|
|
|
|
systemd-udev-settle.service:
|
|
|
|
|
|
|
|
|
|
@OFFENDING_UNITS@
|
2022-03-18 15:52:06 +00:00
|
|
|
|
|
|
|
|
|
-- 7c8a41f37b764941a0e1780b1be2f037
|
|
|
|
|
Subject: Initial clock synchronization
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
For the first time during the current boot an NTP synchronization has been
|
|
|
|
|
acquired and the local system clock adjustment has been initiated.
|
2022-09-16 21:57:26 +00:00
|
|
|
|
|
2023-01-19 19:23:11 +00:00
|
|
|
|
-- 7db73c8af0d94eeb822ae04323fe6ab6
|
|
|
|
|
Subject: Initial clock bump
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
The system clock has been advanced based on a timestamp file on disk, in order
|
|
|
|
|
to ensure it remains roughly monotonic – even across reboots – if an RTC is not
|
|
|
|
|
available or is unreliable.
|
|
|
|
|
|
2022-09-16 21:57:26 +00:00
|
|
|
|
-- 3f7d5ef3e54f4302b4f0b143bb270cab
|
|
|
|
|
Subject: TPM PCR Extended
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
2023-01-11 16:03:48 +00:00
|
|
|
|
The Trusted Platform Module's (TPM) Platform Configuration Register (PCR)
|
|
|
|
|
@PCR@, on banks @BANKS@, has been extended with the string '@MEASURING@'.
|
2022-09-16 21:57:26 +00:00
|
|
|
|
|
2023-01-11 16:03:48 +00:00
|
|
|
|
Whenever the system transitions to a new runtime phase, the specified PCR is
|
|
|
|
|
extended with a different string, to ensure that security policies for
|
|
|
|
|
TPM-bound secrets and other resources are limited to specific phases of the
|
|
|
|
|
runtime.
|
2023-02-10 15:44:24 +00:00
|
|
|
|
|
|
|
|
|
-- f9b0be465ad540d0850ad32172d57c21
|
|
|
|
|
Subject: Memory Trimmed
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
Memory of process @_PID@ (@_COMM@) has been trimmed.
|
|
|
|
|
|
|
|
|
|
Either on user request or as result of a memory pressure event, memory of the
|
2023-02-23 23:52:39 +00:00
|
|
|
|
process has been trimmed, returning unneeded allocation caches and other
|
2023-02-10 15:44:24 +00:00
|
|
|
|
resources back to the OS kernel, making them available for other components of
|
|
|
|
|
the OS.
|
|
|
|
|
|
|
|
|
|
@TRIMMED_BYTES@ of memory were returned to the OS, which took @TRIMMED_USEC@
|
2023-06-14 08:13:08 +00:00
|
|
|
|
micro-seconds (μs).
|
2023-06-27 16:46:28 +00:00
|
|
|
|
|
|
|
|
|
-- a8fa8dacdb1d443e9503b8be367a6adb
|
|
|
|
|
Subject: SysV Service Found
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
|
|
|
|
|
A System V service script @SYSVSCRIPT@ has been found on the system that lacks
|
|
|
|
|
a native systemd unit. An automatic unit file @UNIT@ has been generated for
|
|
|
|
|
compatibility.
|
|
|
|
|
|
|
|
|
|
Note that these automatically generated compatibility unit files cannot replace
|
|
|
|
|
native unit files as they generally slow down the system (by creating
|
|
|
|
|
unnecessary, additional synchronization points), are less robust (as SysV services
|
2023-11-06 13:52:01 +00:00
|
|
|
|
cannot properly be lifecycle tracked or automatically restarted) and less
|
2023-06-27 16:46:28 +00:00
|
|
|
|
secure (as no sandboxing restrictions can be enforced).
|
|
|
|
|
|
|
|
|
|
Compatibility support for System V services in systemd is deprecated. Please
|
|
|
|
|
make sure to update the package in question to provide proper, native systemd
|
2023-10-31 05:35:33 +00:00
|
|
|
|
unit files. Contact vendor if necessary. Compatibility support for System V
|
2023-06-27 16:46:28 +00:00
|
|
|
|
services is deprecated and will be removed soon.
|
2024-01-18 19:32:47 +00:00
|
|
|
|
|
|
|
|
|
-- 187c62eb1e7f463bb530394f52cb090f
|
|
|
|
|
Subject: A Portable Service has been attached
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
Documentation: https://systemd.io/PORTABLE_SERVICES/
|
|
|
|
|
|
|
|
|
|
A new Portable Service @PORTABLE_ROOT@ (with extensions: @PORTABLE_EXTENSION@) has
|
|
|
|
|
been attached to the system and is now available for use. The list of attached
|
|
|
|
|
Portable Services can be queried with 'portablectl list'.
|
|
|
|
|
|
|
|
|
|
-- 76c5c754d628490d8ecba4c9d042112b
|
|
|
|
|
Subject: A Portable Service has been detached
|
|
|
|
|
Defined-By: systemd
|
|
|
|
|
Support: %SUPPORT_URL%
|
|
|
|
|
Documentation: https://systemd.io/PORTABLE_SERVICES/
|
|
|
|
|
|
|
|
|
|
A Portable Service @PORTABLE_ROOT@ (with extensions: @PORTABLE_EXTENSION@) has been
|
|
|
|
|
detached from the system and is no longer available for use. The list of attached
|
|
|
|
|
Portable Services can be queried with 'portablectl list'.
|