We want to check if the magic we got from statfs() is one of the magics listed
for one of the file systems in the given group. To do this, we'd iteratate over
the file system names, convert each name to an array of magics, and compare
those to the one we got. We were using gperf-generated lookup table for this,
so the string lookups were quick, but still this seems unnecessarily complex.
Let's just generate a simple lookup function, because we can:
$ src/basic/filesystem-sets.py fs-in-group
bool fs_in_group(const struct statfs *st, FilesystemGroups fs_group) {
switch (fs_group) {
case FILESYSTEM_SET_BASIC_API:
return F_TYPE_EQUAL(st->f_type, CGROUP2_SUPER_MAGIC)
|| F_TYPE_EQUAL(st->f_type, CGROUP_SUPER_MAGIC)
|| F_TYPE_EQUAL(st->f_type, DEVPTS_SUPER_MAGIC)
|| F_TYPE_EQUAL(st->f_type, MQUEUE_MAGIC)
|| F_TYPE_EQUAL(st->f_type, PROC_SUPER_MAGIC)
|| F_TYPE_EQUAL(st->f_type, SYSFS_MAGIC)
|| F_TYPE_EQUAL(st->f_type, TMPFS_MAGIC);
case FILESYSTEM_SET_ANONYMOUS:
return F_TYPE_EQUAL(st->f_type, ANON_INODE_FS_MAGIC)
|| F_TYPE_EQUAL(st->f_type, PIPEFS_MAGIC)
|| F_TYPE_EQUAL(st->f_type, SOCKFS_MAGIC);
...
We flatten the nested lookup of group=>fs=>magic into a single level.
The compiler can work its magic here to make the lookup quick.
Previously, the gperf table was the main "source of truth", and additional
information (e.g. which file system names are obsolete) was scattered in
various files. We would then parse the gperf file, using python, awk, grep, and
bash, and use the results in various ways. This is hard to understand and
maintain. Let's replace all of this with a single python script that generates
the requested outputs as appropriate.
$ diff -u <(git show @{u}:src/basic/filesystems-gperf.gperf) \
<(src/basic/filesystem-sets.py gperf)
shows that the outputs are the same except for comments.
Similarly, 'src/basic/filesystem-sets.py fs-type-to-string' and
'src/basic/filesystem-sets.py filesystem-sets' can be used to view
the generated code.
The check that the kernel doesn't define any new file system magics is
converted into a normal test. It doesn't seem necessary to fail the build
when that happens.
I was looking at strace for systemd-getty-generator and noticed the call to
faccessat2(3</sys>, "", W_OK, AT_EMPTY_PATH), even though we already did
fstatfs(3</sys>), which should give us all the necessary information. Let's
only do this additional check when it's likely to yield something useful, i.e.
for network fses and otherwise skip the syscall.
The call to statvfs is replaced by statfs because that gives us the .f_type
field and allows is_network_fs() to be called.
I'm a bit worried that the is_network_fs() is somewhat costly. This will be
improved in later commits.
Currently translated at 100.0% (264 of 264 strings)
po: Translated using Weblate (Chinese (Simplified) (zh_CN))
Currently translated at 100.0% (264 of 264 strings)
po: Translated using Weblate (Chinese (Simplified) (zh_CN))
Currently translated at 100.0% (264 of 264 strings)
Co-authored-by: Jesse Guo <jesseguotech@outlook.com>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/main/zh_CN/
Translation: systemd/main
nftables is available since kernel 3.13 (released on 19 January 2014).
Major distributions have already provided nftables, and marked/called
iptables as deprecated or legacy.
Moreover, currently, iptables/libiptc backend does not support IPv6.
Hence, it is not necessary to keep iptables/libiptc backend anymore.
Let's drop it in the next release.
Note, fedora/centos have already disabled iptables/libiptc support since v249.
Follow-up for 89e83aada8.
`is-supported` expects to return a positive exit status.
To achieve that, verb_make_policy() needs to return 0 on success.
Finishes the fix for #38019.
Co-authored-by: Yu Watanabe <watanabe.yu+github@gmail.com>
- wait after kill,
- try --now only once,
- ignore error in reading /proc/$PID/comm when --now is set,
as the process may be already died.
Follow-up for 9e0d0c3fdf.
Hopefully fixes#38352.
For some reasons, kernel or sfdisk once remove the created partitions
and recreated them. And if 'udevadm trigger' triggers devices currently
being removed, the udevd does not receive the triggered events, and the
command stuck.
```
[ 33.150452] TEST-64-UDEV-STORAGE.sh[546]: + sfdisk --wipe=always /dev/md/mdmirpar
[ 33.478336] systemd-udevd[442]: md127: Device is queued (SEQNUM=2163, ACTION=change)
[ 33.480153] kernel: md127: p1 p2 p3
[ 33.483772] systemd-udevd[442]: md127p1: Device is queued (SEQNUM=2164, ACTION=add)
[ 33.483914] systemd-udevd[442]: md127p2: Device is queued (SEQNUM=2165, ACTION=add)
[ 33.484999] systemd-udevd[442]: md127p3: Device is queued (SEQNUM=2166, ACTION=add)
[ 33.485564] systemd-udevd[442]: md127: Received inotify event of watch handle 164.
[ 33.503016] TEST-64-UDEV-STORAGE.sh[546]: + SYSTEMD_LOG_LEVEL=debug
[ 33.503016] TEST-64-UDEV-STORAGE.sh[546]: + timeout 30 udevadm trigger --settle --parent-match /dev/md/mdmirpar
[ 33.485905] systemd-udevd[442]: Successfully forked off '(udev-synth)' as PID 3208.
[ 33.486067] systemd-udevd[442]: md127: Removing watch handle 164.
[ 33.489035] systemd-udevd[442]: md127p1: Device is queued (SEQNUM=2167, ACTION=remove)
[ 33.489048] systemd-udevd[442]: Received inotify event about removal of watch handle 164.
[ 33.489507] systemd-udevd[442]: md127p2: Device is queued (SEQNUM=2168, ACTION=remove)
[ 33.496298] systemd-udevd[442]: md127p3: Device is queued (SEQNUM=2169, ACTION=remove)
[ 33.500628] systemd-udevd[442]: md127: Device is queued (SEQNUM=2170, ACTION=change)
[ 33.502355] systemd-udevd[442]: md127p1: Device is queued (SEQNUM=2171, ACTION=add)
[ 33.509371] TEST-64-UDEV-STORAGE.sh[3211]: md127: Triggered device with action 'change'.
[ 33.509371] TEST-64-UDEV-STORAGE.sh[3211]: md127p1: Triggered device with action 'change'.
[ 33.509371] TEST-64-UDEV-STORAGE.sh[3211]: md127p2: Triggered device with action 'change'.
[ 33.512532] systemd-udevd[442]: md127: Device is queued (SEQNUM=2172, ACTION=change, UUID=a0b75692-08ad-428a-859b-9ef8772874d7)
[ 33.512666] systemd-udevd[442]: md127p1: Device is queued (SEQNUM=2173, ACTION=change, UUID=4cd75a91-aa5b-4678-878c-0420b6c2e1e9)
[ 33.512796] systemd-udevd[442]: md127p2: Device is queued (SEQNUM=2174, ACTION=add)
[ 33.512910] systemd-udevd[442]: md127p3: Device is queued (SEQNUM=2175, ACTION=add)
[ 33.531834] TEST-64-UDEV-STORAGE.sh[3211]: md127: Got uevent without UUID, ignoring: No such file or directory
[ 33.553563] TEST-64-UDEV-STORAGE.sh[3211]: md127p1: Got uevent without UUID, ignoring: No such file or directory
[ 33.561262] TEST-64-UDEV-STORAGE.sh[3211]: md127p2: Got uevent without UUID, ignoring: No such file or directory
[ 33.562468] TEST-64-UDEV-STORAGE.sh[3211]: md127p2: Got uevent without UUID, ignoring: No such file or directory
[ 33.563143] TEST-64-UDEV-STORAGE.sh[3211]: md127p3: Got uevent without UUID, ignoring: No such file or directory
[ 33.564174] TEST-64-UDEV-STORAGE.sh[3211]: md127p1: Got uevent without UUID, ignoring: No such file or directory
[ 33.567614] TEST-64-UDEV-STORAGE.sh[3211]: md127p3: Got uevent without UUID, ignoring: No such file or directory
[ 33.597750] TEST-64-UDEV-STORAGE.sh[3211]: md127: Got uevent without UUID, ignoring: No such file or directory
[ 33.623522] TEST-64-UDEV-STORAGE.sh[3211]: md127p1: Got uevent without UUID, ignoring: No such file or directory
[ 33.676268] TEST-64-UDEV-STORAGE.sh[3211]: md127p3: Got uevent without UUID, ignoring: No such file or directory
[ 33.686088] TEST-64-UDEV-STORAGE.sh[3211]: md127p2: Got uevent without UUID, ignoring: No such file or directory
```
Let's wait for partition devices being actually created, and wait for
all queued events being processed. Then, call 'udevadm trigger'.
Previously, ordered_set_put_strdupv() and friends returns the number of
pushed entries, but that is potentially larger than INT_MAX (of course,
realistically, OOM is triggered in that case).
No caller uses the number of the new entries. Let's return 1 when at
least one element is added.
Fixes CID#1611523.
cpu_set_add_range() is used in parse_cpu_set(), hence already tested.
But it is better to test these functions explicitly.
For CID#1611787 and CID#1611788, that should be false-positive.
Installing stuff in a chroot should not fail because efivars are
not available. When running in a container touching efivars is
completely disabled, but there are some cases (recovery) where
it is needed to touch them in a chroot, so don't disable them but
avoid failing the run instead.
The change in 4d2e61211d
broke armv7 where uintptr_t is 4 bytes:
/* test_id */
Assertion '((uintptr_t) _p) % alignof(uint64_t) == 0' failed at src/basic/cgroup-util.c:108, function cg_get_cgroupid_at(). Aborting.
(gdb) p (uintptr_t)fh.file_handle.f_handle % _Alignof(uint64_t)
$9 = 4
Enforce that the structure is aligned as expected
Follow-up for 4d2e61211d
We generally log what happens, but we didn't log anything about checking credentials,
so add that.
The error message when we cannot acces /proc/1/environ was confusing.
We went back and forth between 'prog.sh', files('prog.sh'), and
find_program('prog.sh'). We want to use files() or find_program() so that we
get a good error message if the file is missing. Behaviour of meson changed
over time, and in the past not all forms could be used in all places. For
example 0f4c4f3824 added find_program() in many
places to avoid repeated messages. But it seems that all recent meson versions
work fine with files().
find_program prints silly messages:
Program tools/make-man-index.py found: YES
(/home/zbyszek/src/systemd/tools/make-man-index.py)
Program tools/meson-render-jinja2.py found: YES
(/home/zbyszek/src/systemd/tools/meson-render-jinja2.py)
...
We know that those files will be found, they are part of the git checkout.
With files() this is gone and the meson output is easier to read.
All those files are standalone programs that can be executed directly.
Some .py files were marked executable, others weren't, probably accidentally.
Mark them all as executable in preparation for subsequent changes.
Some files were using that, others weren't. Since those are user-facing
docs, we should use the nice clean form, not the workaround for strange
systems that we use in other places.
Before 7d247d3cb8, we needed the file name
twice. But now we only need it once, so no need to overcomplicate things
by defining a variable with a single use.
When a variable is used, it's also easier to make a mistake and e.g.
accidentally reuse the variable later.
