standard-conf.xml is currently included by:
man/binfmt.d.xml
man/environment.d.xml
man/modules-load.d.xml
man/sysctl.d.xml
man/coredump.conf.xml
man/journal-remote.conf.xml
man/journal-upload.conf.xml
man/journald.conf.xml
man/logind.conf.xml
man/networkd.conf.xml
man/resolved.conf.xml
man/systemd-sleep.conf.xml
man/systemd-system.conf.xml
All those programs actually use CONF_PATHS_NULSTR or CONF_PATHS_STRV,
so this changes the documentation to match code.
CID #139583: plen + 1 is evaluated as int, and could in principle overflow.
So cast to ssize_t and add an additional check that our overflow calculation
doesn't overflow itself.
Follow-up for a3ce813697 and
5ce41697bd.
Before a3ce813697, all properties in
src->properties and src->properties_db are mixed and copied to
dst->properties_db by device_copy_properties().
So, it is not necessary to store data from udev database file to
sd_device::properties_db before copying properties.
But now, properties are not mixed. So, the read data need to be
stored to also ::properties_db.
Fixes#11721.
This also set lower log level for the messages.
6e2efb6c73 introduces the log messages.
But udevd may be started with --resolve-names=never, and the behavior
is expected.
Fixes#11720.
Fix section header for stable branches and backports. All the other
headings end in a colon and have no blank lines between them and the
body of the section, so fix this one accordingly.
Some tests will create a subtree of /sys under build/test/sys and
depending on the local system that tree might end up having an infinite
chain of symlinks. For example:
$ ls build/test/sys/devices/pnp0/00:00/subsystem/devices/00:00/subsystem/devices/00:00/subsystem/devices/00:00/subsystem/devices/00:00/subsystem/devices/00:00/subsystem/
devices drivers drivers_autoprobe
Exuberant ctags will by default follow symlinks, so configure it not to
do so through a local .ctags file setting --links=no.
Tested that `ctags -R` doesn't get stuck with the dotfile present.
Linux can be run on a device meant to act as a USB peripheral. In order
for a machine to act as such a USB device it has to be equipped with
a UDC - USB Device Controller.
This patch adds a target reached when UDC becomes available. It can be used
for activating e.g. a service unit which composes a USB gadget with
configfs and activates it.
We potentially might descent into quite deep directory trees. Let's
hence make sure we can allocate a lot of fds.
(This reflects the fact that glibc nftw() and friends have some logic in
place to reduce fd usage while descending into directory trees. Doing so
is a bit nasty I think, and given that fds are basically free now, if we
ask for them, lte's just protect ourselves and make use of that)
(No, I am not aware of a real-world case where this was necessary, but
let's better be safe than sorry)
Let's add a fully safe way to exclude certain directories from aging, by
taking a BSD file lock on them before aging them. This is useful for
clients that untar tarballs into /tmp or /var/tmp, which might have
really old timestamps, and to which the aging logic would be very harsh:
they can simply take a BSD file lock on any directory they like and thus
exclude it from automatic aging, and thus need not to be afraid of
untarring stuff below it.
Previously, similar functionality was already available through the
sticky bit on non-directories, but it's problematic, since as soon as
the bit is set no clean-up is done for it at all anymore, forever. Also,
it is not suitable for untarring stuff, since the sticky bit after all
is a concept denoted in the tarball itself. BSD file locking semantics
are much much nicer there, as they are automatically released when the
application that has them dies, and they are entirely orthogonal to data
encoded in tarballs.
This patch takes BSD file locks only on *directories* while descending
down the tree, not on regular files. Moreover, it will do so in
non-blocking mode only, i.e. if anyone else has a lock the aging for a
dir and everything below it is immediately skipped for the current
clean-up iteration.
Of course applications might take BSD file locks for other reasons than
just prevent aging (i.e for their own reasons), but that should be
entirely OK, as in that case tmpfiles should step away from those files
anyway too: it's a good idea to stay away from any such locked file
anyway since it's apparently curretnly being manipulated.
This allows us to fix bugs like this:
https://github.com/systemd/mkosi/issues/252
In all other cases (i.e. classic DNS connection towards an upstream
server, or incoming stub connection, or incoming LMMNR connection) we
want long-running connections, hence keep the connection open for good.
Only in the LLMNR client case let's close the stream as soon as we are
done.
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Filipe Brandenburger
Andrzej Pietrasiewicz
Lennart Poettering