sysexits.h has:
#define EX_CANTCREAT 73 /* can't create (user) output file */
EX_DATAERR is a copy-paste error from the previous sentence, which is
correct.
It is not const, because a) systemd can bump it on its own if
errors occur, and b) the user can change it using signals.
Also it's not boolean.
$ busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager ShowStatus
b true
$ sudo kill -SIGRTMIN+21 1
$ busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager ShowStatus
b false
Fixes#4503.
This makes most header files easier to look at. Also Emacs gets really
slow when browsing through large sections of overly long prototypes,
which is much improved by this macro.
We should probably not do something similar with too many other cases,
as macros like this might help readability for some, but make it worse
for others. But I think given the complexity of this specific prototype
and how often we use it, it's worth doing.
This builds on the previous GENERIC_PARSER_ARGS macro work. I think in
general it is a better idea to declare macros that generate full C
statements instead of just parts of them, hence, let's introduce
CONFIG_PARSER_PROTOTYPE() which defines a full C function prototype,
instead of the pre-existing way of defining the C function prototype
manually, but then using GENERIC_PARSER_ARGS to define its arguments.
This doesn't drop GENERIC_PARSER_ARGS though, but renames it to
CONFIG_PARSER_ARGUMENTS, and changes the ConfigParserCallback function
type to use it. The new name follows more closely how the other symbols
in the header are named.
The macro is inspired by the other string table macros, and takes the
same arguments in the same order and dumps a string table to stdout.
Since it's typesafe it's nice to implement this as macro rather than
regular function.
This new macro is useful for implementing commands such as "systemctl -t
help" and similar, i.e. wherever we want to dump all values of an enum
to stdout.
The use of UINT64_C() in the SettingsMask enum definition is misleading:
it does not mean that individual fields have this width. E.g., with
enum {
FOO = UINT64_C(1)
}
sizeof(FOO) gives 4. It only means that the shift is done properly. So
1 << 35 is undefined, but UINT64_C(1) << 35 is the expected 64 bit
constant. Thus, the use UINT64_C() is useful, because we know that the shifts
are done properly, no matter what the value of _RLIMIT_MAX is, but when those
fields are used in expressions, we don't know what size they will be
(probably 4). Let's add a define which "hides" the enum definition behind a
define which gives the same value but is actually 64 bit. I think this is a
nicer solution than requiring all users to cast SETTING_RLIMIT_FIRST before
use.
Fixes#9035.
On both 32 and 64 bits, the result is:
enum Enum → 32 bits, unsigned
enum BigEnum → 32 bits, unsigned
enum BigEnum2 → 64 bits, unsigned
big_enum2_pos → 4
big_enum2_neg → 8
The last two lines show that even if the enum is 64 bit, and the field of an
enum is defined with UINT64_C(), the field can still be smaller.
Functions whose only purpose is to be used with _cleanup_() should not
touch errno, so that failing removals do not alter errno at unexpected
places.
This is already done in unlink_and_freep(), rmdir_and_freep(),
rm_rf_physical_and_freep(), hence do so for unlink_tempfilep(), too.
Follow-up for #9013
In https://github.com/systemd/systemd/pull/6561, `run_target`
was changed to `custom_target`, which inadvertently caused
relative paths to be passed to ctags due to
https://github.com/mesonbuild/meson/issues/3589.
The switch to `run_target` causes absolute paths to be
passed again and makes it easier to jump from file to
file, hopefully delaying the need to exit Vim :-)
Let's tweak the assignment of errors a bit, and automatically abs()
errnos, similar to how log_error_errno() and friends does it.
Macros are fine to use, but regular functions usually preferable if
there's no reason to use macros, because they avoid multiple evaluation
and suchlike. Hence, let's just use a regular funciton for assigning
errors, instead of macros.
Follow-up for #8993
When "systemctl daemon-reload" is run at the same time as "systemctl
start foo", the latter might hang. That's because commands like start
wait for JobRemoved signal to know when the job is finished. But if the
job is finished during reloading, the signal is never sent.
The hang can be easily reproduced by running
# for ((N=1; N>0; N++)) ; do echo $N ; systemctl daemon-reload ; done
# for ((N=1; N>0; N++)) ; do echo $N ; systemctl start systemd-coredump.socket ; done
in two different terminals. The start command will hang after 1-2
iterations.
This keeps track of jobs that were started before reload and finished
during it and sends JobRemoved after the reload has finished.
This simplifies the use of tempfiles in tests and fixes "leaked"
temporary files in test-fileio, test-catalog, test-conf-parser.
Not the whole tree is converted.
tmpfiles.d relies on merging lines for the same file paths, as well as
detecting conflicts between lines for the same file paths. /var/run is a
prominent case that is an alias for /run, any many tmpfiles snippets
refer to paths in /var/run rather than /run currently, which breaks the
conflict detection and merging.
We can't really fix this comprehensively, as doing so would require us
to resolve symlinks early on, but that's precisely not what we want to
do, as tmpfiles is usually run very early on where the paths might not
be fully available yet (in particular as we might likely create them
ourselves).
Hence, let's at least detect and fix this case for the most prominent
case of this ambiguity, and also log explicitly about this, asking users
to fix the snippets in question so that the merging and conflict
detection works properly again.
