IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add the '=' action modifier that instructs tmpfiles.d to check the file
type of a path and remove objects that do not match before trying to
open or create the path.
BUG=chromium:1186405
TEST=./test/test-systemd-tmpfiles.py "$(which systemd-tmpfiles)"
Change-Id: If807dc0db427393e9e0047aba640d0d114897c26
When using top level drop-ins it isn't immediately obvious that one can
make use of symlinking to disable a top-level drop in for a specific
unit.
Signed-off-by: Peter Morrow <pemorrow@linux.microsoft.com>
When e.g. tmp.mount is present in the initrd, and we serialize it, switch root,
and deserialize, the new systemd is confused because it thinks /tmp is mounted.
In general, it doesn't make sense to serialize anything that refers to paths in
the old root file system.
This fixes two errors for me:
1. tmp.mount was not mounted properly before local-fs.target. It would be
mounted as some point (I guess when we re-read /proc/self/mountinfo for some
other reason). In effect systemd-tmpfiles-setup.service would see one fs, and
some other units started later a different one. In particular gdm.service would
fail because the pre-created /tmp/.X11-unix with proper permissions would not
exist at time it was started.
2. # systemd[1]: proc-sys-fs-binfmt_misc.automount: Got hangup/error on autofs pipe from kernel. Likely our automount point has been unmounted by someone or something else?
# systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed with result 'unmounted'.
# systemd[1]: Mounting proc-sys-fs-binfmt_misc.mount...
# systemd[1]: Mounted proc-sys-fs-binfmt_misc.mount.
# systemd[1]: Starting systemd-binfmt.service...
# systemd[1]: Finished systemd-binfmt.service.
# systemd[1]: proc-sys-fs-binfmt_misc.automount: Path /proc/sys/fs/binfmt_misc is already a mount point, refusing start.
# systemd[1]: Failed to set up automount proc-sys-fs-binfmt_misc.automount.
# systemd[1]: proc-sys-fs-binfmt_misc.automount: Path /proc/sys/fs/binfmt_misc is already a mount point, refusing start.
# systemd[1]: Failed to set up automount proc-sys-fs-binfmt_misc.automount.
# systemd[1]: proc-sys-fs-binfmt_misc.automount: Path /proc/sys/fs/binfmt_misc is already a mount point, refusing start.
# systemd[1]: Failed to set up automount proc-sys-fs-binfmt_misc.automount.
# systemd[1]: Stopping systemd-binfmt.service...
# systemd[1]: systemd-binfmt.service: Deactivated successfully.
# systemd[1]: Stopped systemd-binfmt.service.
I couldn't understand the error here, but in retrospect the first line is entirely
correct: "someone or something else" was the old systemd unmounting the old root.
When /var/lib/systemd/coredump/ is backed by a tmpfs, all disk usage
will be accounted under the systemd-coredump process cgroup memory
limit.
If MemoryMax is set, this might cause systemd-coredump to be terminated
by the kernel oom handler when writing large uncompressed core files,
even if the compressed core would fit within the limits.
Detect if a tmpfs is used, and if so check MemoryMax from the process
and slice cgroups, and do not write uncompressed core files that are
greater than half the available memory. If the limit is breached,
stop writing and compress the written chunk immediately, then delete
the uncompressed chunk to free more memory, and resume compressing
directly from STDIN.
Example debug log when this situation happens:
systemd-coredump[737455]: Setting max_size to limit writes to 51344896 bytes.
systemd-coredump[737455]: ZSTD compression finished (51344896 -> 3260 bytes, 0.0%)
systemd-coredump[737455]: ZSTD compression finished (1022786048 -> 47245 bytes, 0.0%)
systemd-coredump[737455]: Process 737445 (a.out) of user 1000 dumped core.
Try to infer the unused memory that a unit can claim before the
memory.max limit is reached, including any limit set on any parent
slice above the unit itself.
We were effectively doing all post-upgrade scripts twice in Fedora. We got this
wrong, so it's likely other people will get it wrong too. So let's explain
what is actually needed to make this work, but also when it's not useful.
It is not necessary to stop whole configuration process until MTU and
IPv6LL address generation mode are set. But it is enough just setting
IPv6 MTU again after MTU is set, and dropping IPv6LL address after
setting the address generation mode.
The condition does not fix infinite loop of interface reset, as the
interface is reset after netlink reply is received, thus setting_mtu is
false.
See also #18738.
Previously, several failures in link_carrier_gained() make link enter
failed state, and other errors are ignored. Now, all failures in
link_carrier_gained(), moreover, link_update() are critical.
