log_parse_environment() uses should_parse_proc_cmdline() to determine whether
it should parse settings from the kernel command line. But the checks that
should_parse_proc_cmdline() apply to the whole process, and we could get a positive
answer also when log_parse_environment() was called from one of the nss modules.
In case of nss-modules, we don't want to look at the kernel command line.
log_parse_environment_variables() that only looks at the environment variables
is split out and used in the nss modules.
Fixes#22020.
There are a few undesirable properties to how boot entries are
currently sorted.
First, it sorts by entry file name only, which may not correspond
to the title that is shown (for exmaple because it is prefixed by
machine-id). The file ending will also create unexpected ordering
("arch-lts.conf" would come before "arch.conf").
While the list is sorted alphabetically ascending, it is also
lower version/priority first, which is unintuitive. In particular,
a boot-counted entry that is bad (0 tries left) will be at the very
top.
Additionally, the Windows and Mac loaders should be sorted with
the rest of the loaders.
The BFQ weights are not passed verbatim to the kernel, provide that
information in a form of debug message so that users are not
surprised/confused when IOWeight != io.bfq.weight.
The logs used the service name as the primary log key. But the service name
often needs to contain escape symbols, and the logs are rather hard to read
because of this. Thus the logs are changed to use the path to the source
desktop file. I think this is much more useful because the user will want to
look at the source file too and maybe change it if something goes wrong.
A bit more logging to show which directories we are looking at and why we
skip certain units is added too.
$ rm -rf /tmp/out && mkdir /tmp/out && SYSTEMD_LOG_LEVEL=debug SYSTEMD_LOG_TARGET=console build/systemd-xdg-autostart-generator /tmp/{out,out,out}
Scanning autostart directory "/home/zbyszek/.config/autostart"…
Scanning autostart directory "/etc/xdg/autostart"…
/etc/xdg/autostart/tracker-miner-rss-3.desktop: not generating unit, marked as skipped by generator.
/etc/xdg/autostart/gnome-initial-setup-first-login.desktop: ExecCondition executable gnome-systemd-autostart-condition not found, unit will not be started automatically: No such file or directory
/etc/xdg/autostart/geoclue-demo-agent.desktop: symlinking app-geoclue\x2ddemo\x2dagent@autostart.service in xdg-desktop-autostart.target/.wants…
SELinux enabled state cached to: disabled
Directory "/tmp" already exists, but has mode 0777 that is too permissive (0755 was requested), refusing.
/etc/xdg/autostart/polkit-mate-authentication-agent-1.desktop: symlinking app-polkit\x2dmate\x2dauthentication\x2dagent\x2d1@autostart.service in xdg-desktop-autostart.target/.wants…
/etc/xdg/autostart/mate-settings-daemon.desktop: symlinking app-mate\x2dsettings\x2ddaemon@autostart.service in xdg-desktop-autostart.target/.wants…
/etc/xdg/autostart/user-dirs-update-gtk.desktop: symlinking app-user\x2ddirs\x2dupdate\x2dgtk@autostart.service in xdg-desktop-autostart.target/.wants…
/etc/xdg/autostart/org.freedesktop.problems.applet.desktop: symlinking app-org.freedesktop.problems.applet@autostart.service in xdg-desktop-autostart.target/.wants…
/etc/xdg/autostart/org.gnome.SettingsDaemon.Datetime.desktop: not generating unit, startup phases are not supported.
/etc/xdg/autostart/org.gnome.SettingsDaemon.XSettings.desktop: not generating unit, startup phases are not supported.
/etc/xdg/autostart/org.gnome.SettingsDaemon.DiskUtilityNotify.desktop: symlinking app-org.gnome.SettingsDaemon.DiskUtilityNotify@autostart.service in xdg-desktop-autostart.target/.wants…
/etc/xdg/autostart/gnome-initial-setup-copy-worker.desktop: not generating unit, startup phases are not supported.
/etc/xdg/autostart/org.gnome.Evolution-alarm-notify.desktop: symlinking app-org.gnome.Evolution\x2dalarm\x2dnotify@autostart.service in xdg-desktop-autostart.target/.wants…
/etc/xdg/autostart/tracker-miner-fs-3.desktop: not generating unit, marked as skipped by generator.
/etc/xdg/autostart/orca-autostart.desktop: ExecCondition executable gnome-systemd-autostart-condition not found, unit will not be started automatically: No such file or directory
...
Inspired by https://bugzilla.redhat.com/show_bug.cgi?id=2038750.
The return value from xdg_autostart_service_generate_unit() is ignored by the
caller, so we can do a shortcut return without functional change. This is nicer
because we're now consistently always returning an error if something failed.
BPF_RAW_TRACEPOINT_OPEN is expected to work only on x86 and x86_64,
since BPF trampoline is implemented only on these architectures.
Attach probing by bpf_program__attach_lsm already happens in
`bpf_lsm_supported`. The resulting pointer can store libbpf error and
that is the case for unsupported architectures.
Add libbpf error check to `bpf_lsm_supported` so execution does not
reach the point where unit startup fails.
Units would fail to start, incl. systemd-journald.service and systemd-udevd.service.
Since unit->manager->restrict_fs will be set if and only if we can use it,
we can just check for that and remove the other checks.
Follow-up for 299d941723.
It was reported as used by the linker:
> [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start.
> My local call stack (with LTO):
>
> #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2)
> #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2)
> #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2)
> #3 _start (/usr/lib64/ld-linux-x86-64.so.2)
>
> Looking through the source, I think it's this (links for glibc 2.34):
> - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features.
> - Then init_cpu_features calls get_cet_status.
> - At last, get_cet_status invokes arch_prctl.
Fixes#22033.
This restores the preference order from before 9e82a74. The code
previous to that change 'preferred' /boot over /boot/efi; that
commit changed it to check /boot/efi before checking /boot.
Changing this precedence could (and did, for me) have unexpected
effects - it seems safer to leave it how it was.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
BPF LSM is cgroup unaware and it's set up is happening in core manager.
It occures that the current implementation is too restrictive and causes
pid 1 to freeze.
Instead:
* in bpf_lsm_setup set manager->restrict_fs pointer last,
so it is an indicator that the set up was successful
* check for manager->restrict_fs before applying unit options
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Lidong Zhong
Luca Boccassi
yangmingtai
Jan Janssen
Michal Koutný
Ludwig Nussel
Julia Kartseva
Albert Brox
Adam Williamson
Franck Bui
Mike Gilbert
Pigmy-penguin