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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
The systemd-oomd.service unit contains
[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.oom1.service
which means the symlink is supposed to be created dynamically when the
service is enabled.
No need to invoke ls when we are just interested in file names.
Also, the cd to source root makes the output identical to
"git ls-files" (relative instead of absolute paths).
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.
* sd-bus/man: document EBUSY error in bus_message_read
The EBUSY error can be returned from sd_bus_exit_container(), and, if
that happens, it will be propogated upwards towards bus_message_read. In
terms of documentation, this means that bus_message_read's man page
can't just include the error text for sd_bus_message_read_basic, as
reading basic types exclusively doesn't have the potential for this
error.
sd_bus_message_read_basic's error documentation isn't incorrect when
applied to sd_bus_message_read, it's just incomplete. While EBUSY is
documented in sd_bus_message_open_container.xml,
it's explanation is unique to the sd_bus_message_exit_container function
and makes for poor documentation of the general read API.
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.
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 299d9417238e0727a48ebaabb5a9de0c908ec5c8.
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
