systemctl,verbs: Introduce SYSTEMD_OFFLINE environment variable

A lot of code references the `running_in_chroot()` function; while
I didn't dig I'm pretty certain this arose to deal with situations
like RPM package builds in `mock` - there we don't want the `%post`s
to `systemctl start` for example.

And actually this exact same use case arises for
[rpm-ostree](https://github.com/projectatomic/rpm-ostree/)
where we implement offline upgrades by default; the `%post`s are
always run in a new chroot using [bwrap](https://github.com/projectatomic/bubblewrap).

And here's the problem: bwrap creates proper mount roots, so it
passes `running_in_chroot()`, and then if a script tries to do
`systemctl start` we get:
`System has not been booted with systemd as init system (PID 1)`
but that's an *error*, unlike the `running_in_chroot()` case where we ignore.

Further complicating things is there are real world RPM packages
like `glusterfs` which end up invoking `systemctl start`.

A while ago, the `SYSTEMD_IGNORE_CHROOT` environment variable was
added for the inverse case of running in a chroot, but still wanting
to use systemd as PID 1 (presumably some broken initramfs setups?).

Let's introduce a `SYSTEMD_OFFLINE` environment variable for cases like
mock/rpm-ostree so we can force on the "ignore everything except preset" logic.
This way we'll still not start services even if mock switches to use nspawn or
bwrap or something else that isn't a chroot.

We also cleanly supercede the `SYSTEMD_IGNORE_CHROOT=1` which is now spelled
`SYSTEMD_OFFLINE=0`.  (Suggested by @poettering)

Also I made things slightly nicer here and we now print the ignored operation.
This commit is contained in:
Colin Walters 2017-12-13 16:04:41 -05:00
parent 2de2abad62
commit f38951a628
4 changed files with 64 additions and 6 deletions

View File

@ -13,10 +13,21 @@ documented in the proper man pages.
All tools:
* `$SYSTEMD_OFFLINE=[0|1]` — if set to `1`, then `systemctl` will
refrain from talking to PID 1; this has the same effect as the historical
detection of `chroot()`. Setting this variable to `0` instead has a similar
effect as `SYSTEMD_IGNORE_CHROOT=1`; i.e. tools will try to
communicate with PID 1 even if a `chroot()` environment is detected.
You almost certainly want to set this to `1` if you maintain a package build system
or similar and are trying to use a modern container system and not plain
`chroot()`.
* `$SYSTEMD_IGNORE_CHROOT=1` — if set, don't check whether being invoked in a
chroot() environment. This is particularly relevant for systemctl, as it will
not alter its behaviour for chroot() environments if set. (Normally it
refrains from talking to PID 1 in such a case.)
`chroot()` environment. This is particularly relevant for systemctl, as it
will not alter its behaviour for `chroot()` environments if set. Normally it
refrains from talking to PID 1 in such a case; turning most operations such
as `start` into no-ops. If that's what's explicitly desired, you might
consider setting `SYSTEMD_OFFLINE=1`.
* `$SD_EVENT_PROFILE_DELAYS=1` — if set, the sd-event event loop implementation
will print latency information at runtime.

View File

@ -23,12 +23,54 @@
#include <stdbool.h>
#include <stddef.h>
#include "env-util.h"
#include "log.h"
#include "macro.h"
#include "string-util.h"
#include "verbs.h"
#include "virt.h"
/* Wraps running_in_chroot() which is used in various places,
* but also adds an environment variable check so external processes
* can reliably force this on.
*/
bool running_in_chroot_or_offline(void) {
int r;
/* Added to support use cases like rpm-ostree, where from %post
* scripts we only want to execute "preset", but not "start"/"restart"
* for example.
*
* See ENVIRONMENT.md for docs.
*/
r = getenv_bool("SYSTEMD_OFFLINE");
if (r < 0)
log_debug_errno(r, "Parsing SYSTEMD_OFFLINE: %m");
else if (r == 0)
return false;
else
return true;
/* We've had this condition check for a long time which basically
* checks for legacy chroot case like Fedora's
* "mock", which is used for package builds. We don't want
* to try to start systemd services there, since without --new-chroot
* we don't even have systemd running, and even if we did, adding
* a concept of background daemons to builds would be an enormous change,
* requiring considering things like how the journal output is handled, etc.
* And there's really not a use case today for a build talking to a service.
*
* Note this call itself also looks for a different variable SYSTEMD_IGNORE_CHROOT=1.
*/
r = running_in_chroot();
if (r < 0)
log_debug_errno(r, "running_in_chroot(): %m");
else if (r > 0)
return true;
return false;
}
int dispatch_verb(int argc, char *argv[], const Verb verbs[], void *userdata) {
const Verb *verb;
const char *name;
@ -84,8 +126,11 @@ int dispatch_verb(int argc, char *argv[], const Verb verbs[], void *userdata) {
return -EINVAL;
}
if ((verb->flags & VERB_NOCHROOT) && running_in_chroot() > 0) {
log_info("Running in chroot, ignoring request.");
if ((verb->flags & VERB_NOCHROOT) && running_in_chroot_or_offline()) {
if (name)
log_info("Running in chroot, ignoring request: %s", name);
else
log_info("Running in chroot, ignoring request.");
return 0;
}

View File

@ -35,4 +35,6 @@ typedef struct {
int (* const dispatch)(int argc, char *argv[], void *userdata);
} Verb;
bool running_in_chroot_or_offline(void);
int dispatch_verb(int argc, char *argv[], const Verb verbs[], void *userdata);

View File

@ -332,7 +332,7 @@ static bool install_client_side(void) {
/* Decides when to execute enable/disable/... operations
* client-side rather than server-side. */
if (running_in_chroot() > 0)
if (running_in_chroot_or_offline())
return true;
if (sd_booted() <= 0)