All those pages contain a redirect at the top of the page, so it doesn't
make much sense to tell people to take the detour. Linking directly will
also increase the search rankings of the new pages.
The file has instructions how to "enable" it by symlinking into the
appropriate place. If we create a different mechanism to do enablement
later on, we can always adjust the instructions.
Closes#3998.
Same justification as the previous commit.
$ for i in network/*-*; do git blame $i;done | less
shows that those files were written by Tom Gundersen, Lennart Poettering, Yu
Watanabe, me, and Marc-André Lureau.
This matches what we have for example programs under man/, and is nice
because it allows people to copy the files as they wish without worrying
about copyright. The files are too trivial to copyright anyway.
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 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.
to make it easier to fuzz code that uses external libraries like libelf/libdw.
The dependencies are skipped on OSS-Fuzz because they aren't available
at runtime if they aren't linked statically. This restriction can safely
be lifted when the fuzzers are built locally with all the dependencies
installed. As far as I know there is at least one fuzz target in the systemd
repository that can benefit from this: https://github.com/systemd/systemd/issues/11018
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.
In the olden days systemd-resolved used dbus and it didn't make sense to start
it before dbus which is started fairly late. But we have mostly ported resolved
over to varlink. The queries from nss-resolve are done using varlink, so name
resolution can work without dbus. resolvectl still uses dbus, so e.g. 'resolvectl
query' will not work, but by starting systemd-resolved earlier we're not making this
any worse.
If systemd-resolved is started after dbus, it registers the name and everything
is fine. If it is started before dbus, it'll watch for the dbus socket and
connect later. So it should be fine to start systemd-resolved earlier. (If dbus
is stopped and restarted, unfortunately systemd-resolved does not reconnect.
This seems to be a small bug: since our daemons know how to watch for
dbus.socket, they could restart the watch if they ever lose the connection. But
this scenario shouldn't happen in normal boot, and restarting dbus is not
supported anyway.)
Moving the start earlier the following advantages:
- name resolution becomes availabe earlier, in particular for synthesized
hostnames even before the network is up.
- basic.target is part of initrd.target, so systemd-resolved will get started
in the initrd if installed. This is required for nfs-root when the server is
specified using a name (https://bugzilla.redhat.com/show_bug.cgi?id=2037311).
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.
Dangling symlinks get pruned when packaging up the installation
directory. Just store empty files instead, and compare the names
rather than the content for .requires/.wants - the filename is
what is important anyway, the content is ignored.
Fixes#22059
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>
Otherwise, systemd-homed-active.service will fail to deactivate all
homes because homectl can no longer talk to homed if dbus stops first.
As a result, /home cannot be umounted.
Doing this on systemd-homed-active.service instead works as well, but
systemd-homed will exit 1 if dbus is already shut down.
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
