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 attribute is x86-only, so when building on non-intel archs it
generates a compiler warning. When building with -Werror this turns
into an error, so only include the attribute on intel archs.
Add a comment line explaining that the syscall defines might be
defined to invalid negative numbers, as libseccomp redefines them
to negative numbers if not defined by the kernel headers, which is
not obvious just from reading the code checking for defined && > 0
Since bug reports, backtraces, coverage reports and build logs are scattered
across at least four different places and there is no publicly available dashboards
the badge can point to, let's just point it to the build logs, which hopefully are going to be
a little bit more usable once https://github.com/google/oss-fuzz/issues/2690 is
addressed.
If rescue.target, multi-user.target and graphical.target are all
inactive, get_current_runlevel() is not able to determine current
runlevel, and returns with zero. This zero runlevel value results to
assertion failure in utmp_put_runlevel().
# systemctl stop rescue.target multi-user.target graphical.target
# systemctl start systemd-update-utmp-runlevel.service
systemd[1]: Stopped target Graphical Interface.
systemd[1]: Stopped target Multi-User System.
systemd[1]: Starting Update UTMP about System Runlevel Changes...
systemd-update-utmp[67]: Assertion 'runlevel > 0' failed at src/shared/utmp-wtmp.c:275, function utmp_put_runlevel(). Aborting.
systemd[1]: systemd-update-utmp-runlevel.service: Main process exited, code=dumped, status=6/ABRT
systemd[1]: systemd-update-utmp-runlevel.service: Failed with result 'core-dump'.
systemd[1]: Failed to start Update UTMP about System Runlevel Changes.
Let's just print a warning in this case and skip the utmp update, to
avoid systemd-update-utmp-runlevel.service failures.
Previously, we'd only set the shell to /usr/bin/nologin and lock the
password for system users. Let's go one step further and also lock the
whole account.
This is a paranoid safety precaution, since neither disabling the shell
like this nor disabling the password is sufficient to lock an account,
since remote shell tools generally allow passing different shells, and
logins into ftp or similar protocols don't know the shell concept anyway.
Moreover, in times of ssh authentication by password is just one
option of authentication among many.
Takes inspiration from the recommendations in usermod(8)'s -L switch:
"Note: if you wish to lock the account (not only access with a
password), you should also set the EXPIRE_DATE to 1."
The #ifndef check used to work for missing __NR_* syscall defines, but
unfortunately libseccomp now redefines missing syscall number to negative
numbers, in their public header file, e.g.:
https://github.com/seccomp/libseccomp/blob/master/include/seccomp.h.in#L801
When systemd is built, since it includes <seccomp.h>, it pulls in the
incorrect negative value for any __NR_* syscall define that's included in
the seccomp.h header (for those syscalls that the kernel headers don't
yet define, e.g. when built with older/stable-distro kernels). This leads
to bugs like:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1821625
This changes the check so that it can override the negative number that
libseccomp defines, instead of trying to use the negative syscall number.
To avoid gcc warnings (which are failures with meson --werror), this checks
without generating a redefinition gcc warning.
I have no idea why libseccomp decided to define missing syscalls
to negative numbers inside their *public* header file, causing
problems like this.
I assumed that unit_name_to_instnace() returns NULL if there is no instance.
In fact it returns "", so the check for instance was wrong.
Also avoid unnecessary call to unit_name_is_valid().
In high load scenarios it is possible for services to be started
before the NameOwnerChanged signal is properly installed.
Emulate a callback by also queuing a GetNameOwner when the match is
installed.
Fixes: #12956
To make debugging much easier, especially for crashes in tests under
QEMU, let's store the entire coredump bundle in the systemd journal,
which is usually kept around by various CIs. Right now, we usually end
up with a journal, but without the coredump itself, which is pretty
useless.
Since ask_password() (and related calls) already append one char, we
ended up appending two. That's not pretty. Let's fix this, and do it
like in all other cases ask_password() (or an equivalent function) is
called.
Otherwise, changing the default gateway doesn't purge old gateway routes
left on the system during daemon restart. This also fixes removing other
foreign gateway routes that don't match the expected configuration.
Tested:
Changed gateway addresses prior to the patch and they lingered on
the system during each reconfiguration. Applied this patch and
reconfigured gateways and other routes multiple times and it removed
the foreign routes that had gateways that didn't match.
Signed-off-by: William A. Kennington III <william@wkennington.com>
This removes a special case that was implemented before: if some service
was already enabled, we'd treat it as having higher priority.
From https://bugzilla.redhat.com/show_bug.cgi?id=1735584#c4:
> Setting ntp off and on should give the same result as just setting it
> on. There should be no stickiness (hidden state). It should behave like
> running an ansible role.
>
> The other service might have been enabled because no other was installed at
> the time. If I install a new NTP service with a higher priority, setting ntp
> on should enable and start the new service, and disable all other. Also, if
> for some reason multiple services are enabled, after setting ntp on there
> should be only one enabled to avoid systemd selecting between them randomly
> on the next boot.
The general idea is that for things which can occur repeatedly, like SetNTP
being called with the same argument, we only log at debug level. For things
which change state, like when we realize that a unit that wasn't enabled
before needs to be enabled, we log at info level.
Also, don't return success if there are no units loaded.
Follow-up for 26ded55709.
The commit says,
> Note that with this change sysinit.target (and thus early boot) is NOT
systematically delayed until the entropy pool is initialized,
But the dependency was not dropped.
This was found by David Seifert (@SoapGentoo).
