The same as parent commit, but users. This is the third and last
foo_object_find() function in logind, so I think that this particular
family of bugs is finally squashed.
The story is the same as in 471cffcfb0e005b7c4044b3b52cc4f25d217efac:
device_attach() → seat_send_changed() → sd_bus_emit_properties_changed_strv()
→ emit_properties_changed_on_interface() → node_vtable_get_userdata()
→ seat_object_find(), which returns 0 because message == NULL.
But when we are emitting a signal, message is always NULL. Removing the
overeager check and assert in the called function allow the signal to be
emitted.
Fixes#13769.
TEST-41 verifies that the StartLimitBurst property will correctly
limit the number of unit restarts, but the test currently doesn't
adjust the StartLimitIntervalSec which defaults to 10 seconds.
On Ubuntu CI, running under un-accelerated qemu, it can take more than
10 seconds to perform all 3 restarts, which avoids the burst limit,
and fails the test.
Instead, specify a long StartLimitIntervalSec in the test, so we can
be sure to correctly test StartLimitBurst even on slow testbeds.
Fixes#13794.
Currently, when console is disabled but progress is tracked, pipe opened
for communication between systemd-fsck and fsck may be closed
inadvertently (when opening of /dev/console return in error). That lead
to finish fsck prematurely (because it receives a SIGPIPE) and so fsck
may not check correctly filesystems and do not have time to fix memory
corruptions.
This commit changes the opening of /dev/console to be done previously to
pipe creation and so fix the bug described just above.
This makes it easy to tell that the function only uses the Unit* for
reporting, and only makes changes to the other argument (which most likely
also points at the same Unit structure) for modifications.
Currently, there is no way to match against system-wide constants, such
as architecture or virtualization type, without forking helper binaries.
That potentially results in a huge number of spawned processes which
output always the same answer.
This patch introduces a special CONST keyword which takes a hard-coded
string as its key and returns a value assigned to that key. Currently
implemented are CONST{arch} and CONST{virt}, which can be used to match
against the system's architecture and virtualization type.
No functional change, just adjusting code to follow the same pattern
everywhere. In particular, never call _verify() on an already loaded unit,
but return early from the caller instead. This makes the code a bit easier
to follow.
Now all unit types define .load. But even if it wasn't defined, we'd need
to call unit_load_fragment_and_dropin() anyway, so this code would not have
worked correctly.
Also, unit_load_fragment_and_dropin() either returns -ENOENT or changes
UNIT_STUB to UNIT_LOADED, so we don't need to repeat this here.
There is a slight functional change when load_state == UNIT_MERGED. Before,
we would not call unit_load_dropin(), but now we do. I'm not sure if this
causes an actual difference in behaviour, but since all other unit types do
this, I think it's better to do the same thing here too.
unit_load_fragment_and_dropin() and unit_load_fragment_and_dropin_optional()
are really the same, with one minor difference in behaviour. Let's drop
the second function.
"_optional" in the name suggests that it's the "dropin" part that is optional.
(Which it is, but in this case, we mean the fragment to be optional.)
I think the new version with a flag is easier to understand.
pyparsing 2.3.1/2.4.0 had some changes to grouping of And matches, and as a
result we'd report 0 properties and 0 matches, and not really do any checks.
With this change we get identical behaviour for pyparsing 2.3.1, 2.4.0, 2.4.2:
$ hwdb/parse_hwdb.py
hwdb/60-evdev.hwdb: 72 match groups, 94 matches, 262 properties
hwdb/60-input-id.hwdb: 3 match groups, 3 matches, 4 properties
hwdb/60-keyboard.hwdb: 173 match groups, 256 matches, 872 properties
Keycode KBD_LCD_MENU1 unknown
Keycode KBD_LCD_MENU4 unknown
Keycode KBD_LCD_MENU2 unknown
Keycode KBD_LCD_MENU3 unknown
hwdb/60-sensor.hwdb: 101 match groups, 120 matches, 105 properties
hwdb/70-joystick.hwdb: 2 match groups, 3 matches, 2 properties
hwdb/70-mouse.hwdb: 104 match groups, 119 matches, 123 properties
hwdb/70-pointingstick.hwdb: 8 match groups, 30 matches, 11 properties
hwdb/70-touchpad.hwdb: 6 match groups, 9 matches, 6 properties
