| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rpms can be installed in two different modes: into a chroot, where the system
is not running, and onto a live system. In the first mode, where should create
all changes that are "permanent", and in the second mode, all changes which are
"permanent" but also those which only affect the running system. Thus, changes
like new modprobe rules, tmpfiles rules, binfmt rules, udev rules, etc., are
guarded by 'test -d "/run/systemd/system"' which is the official way to check
if systemd is running, so that they are *not* executed when installed into a
chroot. But the same logic does not apply to sysusers, hwdb, and the journal
catalog: all those files can and should result in changes being performed
immediately to the system. This makes the creation of immutable images possible
(because there are no permanent changes to executed after a reboot), and allows
other packages to depend on the the effect of those changes.
Thus, the guard to check if we're not in a chroot is dropped from triggers for
sysusers, hwdb, and the journal catalog. This means that those triggers will
execute, and no subsequent work is needed. systemd-sysusers.service,
systemd-journal-catalog-update.service, and systemd-hwdb-update.service.in all
have ConditionNeedsUpdate= so they they generally won't be invoked after a
reboot. (systemd.rpm does not touch /usr to trigger the condition, because the
%transfiletriggers make that unnecessary.)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2085481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This closes an important gap: so far we would reexecute the system manager and
restart system services that were configured to do so, but we wouldn't do the
same for user managers or user services.
The scheme used for user managers is very similar to the system one, except
that there can be multiple user managers running, so we query the system
manager to get a list of them, and then tell each one to do the equivalent
operations: daemon-reload, disable --now, set-property Markers=+needs-restart,
reload-or-restart --marked.
The total time that can be spend on this is bounded: we execute the commands in
parallel over user managers and units, and additionally set SYSTEMD_BUS_TIMEOUT
to a lower value (15 s by default). User managers should not have too many
units running, and they should be able to do all those operations very
quickly (<< 1s). The final restart operation may take longer, but it's done
asynchronously, so we only wait for the queuing to happen.
The advantage of doing this synchronously is that we can wait for each step to
happen, and for example daemon-reloads can finish before we execute the service
restarts, etc. We can also order various steps wrt. to the phases in the rpm
transaction.
When this was initially proposed, we discussed a more relaxed scheme with bus
property notifications. Such an approach would be more complex because a bunch
of infrastructure would have to be added to system manager to propagate
appropriate notifications to the user managers, and then the user managers
would have to wait for them. Instead, now there is no new code in the managers,
all new functionality is contained in src/rpm/. The ability to call 'systemctl
--user user@' makes this approach very easy. Also, it would be very hard to
order the user manager steps and the rpm transaction steps.
Note: 'systemctl --user disable' is only called for a user managers that are
running. I don't see a nice way around this, and it shouldn't matter too much:
we'll just leave a dangling symlink in the case where the user enabled the
service manually.
A follow-up for https://bugzilla.redhat.com/show_bug.cgi?id=1792468 and
fa97d2fcf64e0558054bee673f734f523373b146.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of embedding the commands to invoke directly in the macros,
let's use a helper script as indirection. This has a couple of advantages:
- the macro language is awkward, we need to suffix most commands by "|| :"
and "\", which is easy to get wrong. In the new scheme, the macro becomes
a single simple command.
- in the script we can use normal syntax highlighting, shellcheck, etc.
- it's also easier to test the invoked commands by invoking the helper
manually.
- most importantly, the logic is contained in the helper, i.e. we can
update systemd rpm and everything uses the new helper. Before, we would
have to rebuild all packages to update the macro definition.
This raises the question whether it makes sense to use the lua scriptlets when
the real work is done in a bash script. I think it's OK: we still have the
efficient lua scripts that do the short scripts, and we use a single shared
implementation in bash to do the more complex stuff.
The meson version is raised to 0.47 because that's needed for install_mode.
We were planning to raise the required version anyway…
|
|
|
|
|
|
|
|
|
| |
We can make things a bit simpler and more readable by not specifying the path.
Since we didn't specify the full path for all commands (including those invoked
recursively by anythign we invoke), this didn't really privide any security or
robustness benefits. I guess that full paths were used because this style of
rpm packagnig was popular in the past, with macros used for everything
possible, with special macros for common commands like %{__ln} and %{__mkdir}.
|
|
|
|
|
|
|
| |
The naming of variables is very inconsistent. I tried to use more
modern style naming (UNDERSCORED_TITLE_CASE), but I didn't change existing
names too much. Only SYSTEM_DATA_UNIT_PATH is renamed to SYSTEM_DATA_UNIT_DIR
to match SYSTEM_CONFIG_UNIT_DIR.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a long-standing issue in packaging scriptlets: daemon-reload
was moved to the end of the transaction, but restarting services was still
straightaway after package installation.
https://bugzilla.redhat.com/show_bug.cgi?id=1614751
Note that daemon-reload is called twice. This wouldn't be hardly noticable,
except that now a bunch of units (at least in Fedora) generate very verbose
warnings about deprecated features. So we get those warnings twice…
reload-or-restart --needing-restart is also called twice, but the second call
is usually a noop, because the first clears the flag for restarted units. The
second call is necessary for the case where we only uninstall packages, and the
%transfiletriggerpostun trigger fires, but not the %transfiletriggerin
scriptlet.
Also note that this assumes that units are marked only for restart if paths
under @systemunitdir@ or /etc/systemd/system have been touched. I would prefer
make the trigger that does 'restart --needing-restart' fire always, but it
seems rpm doesn't have such functionality. (Except as a %transfiletrigger that
would trigger on "/*" to catch all transactions, but that seems ineffiecient
and ugly.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
P>1000000 is *before* "normal" scriptlets, P<1000000 is *after*. I think it
makes sense to do stuff like execution of sysctl/sysusers/tmpfiles configuration
before package scriptlets. I think that was the intent, but a single digit got
dropped ;(
Also, let's reorder the scriptlets in the file to match execution order, to
make it easier to see what is going on.
Most of those may happen in any order, but there are some exceptions:
tmpfiles should be after sysusers,
udevadm --reload should be after hwdb.
|
|
|
|
|
|
|
|
| |
The trigger was initially written to use %transfiletriggerun instead
of %transfiletriggerpostun because the latter would not fire. It turned
out to a buffer overread in rpm that since has been long fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1284645
https://github.com/rpm-software-management/rpm/commit/f6521c50f6836374a0f7995f8f393aaf36e178ea
|
|
|
|
|
|
|
|
| |
Note that this goes both ways: in particular the lua version had udev
scriptlets in the wrong package, fixed in
https://src.fedoraproject.org/rpms/systemd/c/3c9433d7cf4afc8d76660402f6c3d9d991596b83.
Add missing "|| :" so the scriptlets never fail.
|
|
It is only of interest to rpm-based distros, we can move it out of src/core/
which is pretty busy.
|