Skip calling start and stop methods on unit objects, as doing that is
not only time consuming, but it also starts/stops units that interfere
with the machine state. The actual code paths should be covered (to some
degree) by the respective method counterparts on the manager object.
As described in systemd/systemd#27204 reexecuting the daemon while
running in a systemd-run "session" causes the session end prematurely.
Let's skip the Reexecute() method in dfuzzer and trigger it manually
until the issue is resolved.
Replace the call to the `end.service` with `systemctl poweroff`, since
it seems to cause issues no matter what `--job-mode=` is used:
```
[ 129.070993] testsuite-21.sh[380]: ++ systemctl start --job-mode=flush end.service
[ 129.154985] testsuite-21.sh[912]: Failed to start end.service: Transaction for end.service/start is destructive (sysinit.target has 'stop' job queued, but 'start' is included in transaction).
[ 129.159636] testsuite-21.sh[912]: See system logs and 'systemctl status end.service' for details.
```
Also, add a "safety net" which bypasses the manager and does the
poweroff directly, since sometimes the D-Bus call performed by
`systemctl` might timeout (as the manager might be still processing data
from the fuzzing):
```
[ 115.776778] sh[894]: + systemctl poweroff --no-block
[ 166.164242] testsuite-21.sh[893]: Failed to start transient service unit: Connection timed out
[ 166.269289] sh[894]: Call to PowerOff failed: Connection timed out
```
Otherwise it oversaturates the journal, which in some cases can't keep
up with the load of messages (due to the performance penalty caused by
sanitizers), and gets killed by a watchdog.
Frantisek Sumsal
Mike Yuan
Lennart Poettering