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 turns out to be more complicated than it looked initially...
%transfiletriggerun is called early, while %transfiletriggerin is
called late, and neither satifisfies the requirement to call
daemon-reload after new unit files have been installed, but before
%postun scripts in packages get to fire.
It seems that the only solution is to use %filetriggerun (which
is called once per package) to do the reload, and keep state in
/var/lib/rpm-state/systemd/ to avoid calling the reload multiple
times.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Saving_state_between_scriptlets
says that /var/lib/rpm-state/systemd/ is the right dir.
This uses new functionality added in rpm 4.13. Instead of doing
one daemon-reload per packages, we do just one or two
(When both installing and uninstalling packages, we do
two. Unfortunately this also includes the common case of upgrades.
When only installing or when only installing, we do just one.)
New file triggers.systemd can be built, but the contents have
to be copied into the rpm spec file by hand. Using %{load} does
not seem to work. It can serve as documentation.
* remove journal flushing (systemd-journal-flush.service runs journalctl --flush on boot)
* use sh -c and PATH instead of @SYSTEMCTL@ expansion
* remove unnecessary semicolons etc
strtoull() doesn't make it particularly easy to detect passed-in
negative numbers, as it silently converts them to positive ones without
generating any error. Since we are not interested in negative values we
should hence explicitly filter them out by looking at the string
directly and returning ERANGE if we see a leading "-".
Fixes: #1829
Let's make sure "LimitCPU=30min" can be parsed properly, following the
usual logic how we parse time values. Similar for LimitRTTIME=.
While we are at it, extend a bit on the man page section about resource
limits.
Fixes: #1772
Let's not convert RLIM_INFINITY to "unsigned long long" and then back to
rlim_t, but let's leave it in the right type right-away.
Parse resource limits as 64 bit in all cases, as according to the man
page that's what libc does anyway.
Make sure setting a resource limit to (uint64_t) -1 results in a parsing
error, and isn't implicitly converted to RLIM_INFINITY.
Let's generate a simple error, and that's it. Let's not try to be smart
and record the last word that failed.
Also, let's make sure we don't compare numeric values with 0 by relying
on C's downgrade-to-bool feature, as suggested in CODING_STYLE.
This is useful if we want to parse RLIMIT_RTTIME values where the common
UNIX syntax is without any units but refers to a non-second unit (µs in
this case), but where we want to allow specification of units.
The macro is generically useful for putting together search paths, hence
let's make it truly generic, by dropping the implicit ".d" appending it
does, and leave that to the caller. Also rename it from
CONF_DIRS_NULSTR() to CONF_PATHS_NULSTR(), since it's not strictly about
dirs that way, but any kind of file system path.
Also, mark CONF_DIR_SPLIT_USR() as internal macro by renaming it to
_CONF_PATHS_SPLIT_USR() so that the leading underscore indicates that
it's internal.
If we don't know a container manager, we should consider it as "other"
rather than as no container manager at all, to provide a somwhat useful
upgrade path.
In most cases, systemd requires escaping $ (for systemd variable
substitution) and % (for specifiers) by doubling them. This was somewhat
of an issue in tests like exec-environment*.service where systemd was
doing the substitutions and we were not really checking that those were
available in the actual environment of the command. Fix that.
Expressions such as `exit $(test ...)` are incorrect. They only work
because $(test ...) will produce no output, so the command will become a
bare "exit" which will exit with the status of the latest executed
command which turns out to be the test... The direct approach is simply
calling "test" as the last command, for which the shell will propagate
the exit status.
One situation where this was breaking tests was on `exit $(test ...) &&
$(test ...) && $(test ...)` where the second and third tests were not
really executing, since the first command is actually `exit` so && was
doing nothing there. Fixed it by just using `test ... && test ... &&
test ...` as it was initially intended.
Pass -x to all shell executions for them to produce useful debugging
output to stderr. Consequently, removed most of the explicit `echo`s
that are no longer needed.
Mark all units as Type=oneshot explicitly.
Also made sure all shell variables are properly quoted.
v2: Added an explicit LC_ALL=C to ionice invocations since some locales
(such as French) will add a space before the colon in the output.
Tested by running `sudo ./test-execute` and confirming all tests enabled
on my system (essentially all of them except for the s390 one) passed.
Tweaked the variables or options or expected values and confirmed the
tests do indeed fail when the values are not exactly the expected ones.
v2: Also tested with `LANG=fr_FR.UTF-8 sudo ./test-execute` to confirm
it still works in a different locale.
Put it at the top of the file, where it's hard to miss.
Also add the mapping of runlevel → target because since it is now
static.
I'm not adding runlevel(7), because we do not want to make obsolete
stuff even more prominent.
