-
Notifications
You must be signed in to change notification settings - Fork 28
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
drop systemd service #551
Comments
Hello! I've opened a pull request here: #586 Please let me know if there's anything that looks like it needs to be changed :) |
I think this still makes sense, yes. |
Thanks @cgwalters for the confirmation, will look at this. |
Hi @cgwalters, to drop |
I typed this out, only compile tested but hopefully illustrates the idea
|
Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like |
Fixes coreos#551 Get hints by coreos#551 (comment) Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment) Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment) Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment) Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Fixes coreos#551 Get hints by coreos#551 (comment), and copy the comment here: Basically we detect if we're running in systemd; if we're not, we re-exec ourselves via systemd-run. Then we can just directly run code in what is now the daemon. I think an important aspect of this is that we retain something like `--unit bootupd` which acts as a lock - only one unit with that name can run at a time to avoid two concurrent invocations breaking things.
Bootupd is no longer using a systemd service and socket unit. It is now called either directly from the command line by an administrator or in the furture as part of the boot process in a oneshot unit. See: coreos/bootupd#551
Bootupd is no longer using a systemd service and socket unit. It is now called either directly from the command line by an administrator or in the furture as part of the boot process in a oneshot unit. See: coreos/bootupd#551
With the following issues now fixed: - coreos/bootupd#630 - coreos/bootupd#658 - coreos/bootupd#551 And corresponding support in Anaconda: - rhinstaller/anaconda#5508 We can now (re-)enable bootupd for the bootable containers. After a bit of testing, we will enable it for the classic ostree ones. See: https://gitlab.com/fedora/ostree/sig/-/issues/1
In Fedora and derivatives there's a policy I think of writing SELinux policies for things that are systemd
.service
s.We happen to have a
.socket
and.service
units but we aren't really a service today. The socket actually denies non-root from connecting.I think we should just delete those units and where we want to run things under systemd, we do it dynamically via
systemd-run
e.g.The primary goal of this is to get this project off the list of things that need a SELinux policy.
But I think it'd be a good cleanup anyways.
The text was updated successfully, but these errors were encountered: