@AkihiroSuda @kolyshkin Does cgroupv2 still require systemd, or is systemd support only required if you're using cgroupv2 on a systemd system? (From memory the early design required it, but I haven't closely followed how it's evolved since. Since we have fs2 I guess you can technically run cgroupv2 without systemd -- as long as you're not running with systemd, because of the obvious conflicts.)

@metux This needs new CI jobs to make sure that no_systemd builds actually work and pass the unit/integration tests.

Does cgroupv2 still require systemd, or is systemd support only required if you're using cgroupv2 on a systemd system?

Never required on non-systemd hosts.

Even on systemd hosts, the systemd driver was never strictly required in practice, but future version of systemd may strictly require it, in theory.

This needs new CI jobs to make sure that no_systemd builds actually work and pass the unit/integration tests.

Yes, and README (the build tags section) needs to be updated too.

Even on systemd hosts, the systemd driver was never strictly required in practice, but future version of systemd may strictly require it, in theory.

"Required" may have been too strong of a word to use. Though you can't set Delegate=yes if you don't have systemd support I guess? (And given the history of systemd futzing around with our cgroups, I'm a bit skeptical that it's not at the very least a recommended setup?) In any case this doesn't really block the PR then.

Though you can't set Delegate=yes if you don't have systemd support I guess?

I think we can implement "minimal" systemd support, adding something like

if IsRunningSystemd() {
    err := os.Exec("systemctl", "set-property", unit, "Delegate=yes").Run()
    ...
}

This code won't add any new dependencies or impact the binary size much. In fact, ideally this should be done with

Thinking about this, an "alternative" systemd driver can be added to runc, which will call systemctl upon container start/stop/update. This has its own pros and cons, of course.

Though you can't set Delegate=yes if you don't have systemd support I guess?

I think we can implement "minimal" systemd support, adding something like

if IsRunningSystemd() {
    err := os.Exec("systemctl", "set-property", unit, "Delegate=yes").Run()
    ...
}

This code won't add any new dependencies or impact the binary size much. In fact, ideally this should be done with

Where does IsRunningSystemd() come from when speaking to systemd and thats dependencies are off ?
I wonder what the purpose if that shall be when systemd support is switched off anyways.

OTOH, I feel very unhappy with such arbitrary command calls, especially in case when systemd stuff had been disabled explicitly. Could end up calling a completely different program. Actually, I once used to write one with that name, long before systemd even existed.

I think we should have it in 1.1. Set the milestone accordingly.

Though you can't set Delegate=yes if you don't have systemd support I guess?

I think we can implement "minimal" systemd support, adding something like

if IsRunningSystemd() {
    err := os.Exec("systemctl", "set-property", unit, "Delegate=yes").Run()
    ...
}

This code won't add any new dependencies or impact the binary size much. In fact, ideally this should be done with

Where does IsRunningSystemd() come from when speaking to systemd and thats dependencies are off ?
I wonder what the purpose if that shall be when systemd support is switched off anyways.

OTOH, I feel very unhappy with such arbitrary command calls, especially in case when systemd stuff had been disabled explicitly. Could end up calling a completely different program. Actually, I once used to write one with that name, long before systemd even existed.

The idea is to make it possible to use runc compiled without systemd support on a systemd-enabled system.

The IsRunningSystemd function does a simple stat(2), and keeping it even when building with no_systemd won't affect the binary size much, nor will it bring any new dependencies.

But I don't think that calling systemctl will work as I thought it would -- first of all, we don't have a unit to set properties for.

So we can just assume that system won't screw up whatever we create in /sys/fs/cgroup.

Can we somehow limit the number of jobs? 60 is too much :)

Say, only test with non-default tags on 1 go version. Or something similar.

@metux can you please address #2987 (comment), and also do a rebase?

@metux please let us know if you want to keep working on this. This needs a rebase, and #2987 (comment) also needs to be addressed.

obsoleted by rewrite: #3959