Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graceful recover after a failure #707

Closed
travier opened this issue Aug 22, 2024 · 2 comments
Closed

Graceful recover after a failure #707

travier opened this issue Aug 22, 2024 · 2 comments
Labels
bug Something isn't working jira For syncing with Jira

Comments

@travier
Copy link
Member

travier commented Aug 22, 2024

From #694 (comment):

If for whatever reason the previous command fails, then I need to systemctl reset-failed before calling bootupd again.

root@fedora:~# systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pipe bootupctl status
Running as unit: bootupd.service
root@fedora:~# systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pty bootupctl status
Running as unit: bootupd.service; invocation ID: c111d0e1cebe4401bb89af4cfa5358f1
Press ^] three times within 1s to disconnect TTY.

root@fedora:~# systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pty bootupctl status
Failed to start transient service unit: Unit bootupd.service was already loaded or has a fragment file.
root@fedora:~# systemctl status bootupd.service
× bootupd.service - /usr/bin/bootupctl status
     Loaded: loaded (/run/systemd/transient/bootupd.service; transient)
  Transient: yes
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: signal) since Mon 2024-07-29 16:46:17 CEST; 14s ago
 Invocation: c111d0e1cebe4401bb89af4cfa5358f1
    Process: 4624 ExecStart=/usr/bin/bootupctl status (code=killed, signal=HUP)
   Main PID: 4624 (code=killed, signal=HUP)
   Mem peak: 3M
        CPU: 32ms

Jul 29 16:46:17 fedora systemd[1]: Starting bootupd.service - /usr/bin/bootupctl status...
Jul 29 16:46:17 fedora systemd[1]: bootupd.service: Main process exited, code=killed, status=1/HUP
Jul 29 16:46:17 fedora systemd[1]: bootupd.service: Failed with result 'signal'.
Jul 29 16:46:17 fedora systemd[1]: Failed to start bootupd.service - /usr/bin/bootupctl status.
root@fedora:~# systemd-run --unit bootupd --property=MountFlags=slave --service-type=oneshot --pty bootupctl status
Failed to start transient service unit: Unit bootupd.service was already loaded or has a fragment file.
@travier
Copy link
Member Author

travier commented Aug 22, 2024

A quick & dirty way to avoid that is issue is to always call systemctl reset-failed bootupd.service before trying to run another command.

@travier travier added the bug Something isn't working label Aug 22, 2024
travier added a commit to travier/bootupd that referenced this issue Sep 2, 2024
If for whatever reason a bootupd command fails, it will leave the
systemd service unit in a failed state and systemd will then refuse to
run a unit under the same name with `systemd-run` again until the
failure is cleared.

Thus systematically call `systemctl reset-failed` before calling
`systemd-run` to clear any potential failures from previous calls.

See: coreos#707
travier added a commit to travier/bootupd that referenced this issue Sep 2, 2024
If for whatever reason a bootupd command fails, it will leave the
systemd service unit in a failed state and systemd will then refuse to
run a unit under the same name with `systemd-run` again until the
failure is cleared.

Thus systematically call `systemctl reset-failed` before calling
`systemd-run` to clear any potential failures from previous calls.

See: coreos#707
See: coreos#663
travier added a commit to travier/bootupd that referenced this issue Sep 2, 2024
If for whatever reason a bootupd command fails, it will leave the
systemd service unit in a failed state and systemd will then refuse to
run a unit under the same name with `systemd-run` again until the
failure is cleared.

Thus systematically call `systemctl reset-failed` before calling
`systemd-run` to clear any potential failures from previous calls.

See: coreos#707
See: coreos#663
travier added a commit to travier/bootupd that referenced this issue Sep 2, 2024
If for whatever reason a bootupd command fails, it will leave the
systemd service unit in a failed state and systemd will then refuse to
run a unit under the same name with `systemd-run` again until the
failure is cleared.

Thus systematically call `systemctl reset-failed` before calling
`systemd-run` to clear any potential failures from previous calls.

Do not check the return code of the systemctl command on purpose as it
may fail if the unit does not exists yet, i.e. if no bootupctl command
has been run yet.

Also ignore stdout/stderr to avoid showing unexpected errors messages to
users.

See: coreos#707
See: coreos#663
@HuijingHei
Copy link
Member

Close as fixed by #715

@travier travier added the jira For syncing with Jira label Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working jira For syncing with Jira
Projects
None yet
Development

No branches or pull requests

2 participants