Add runc_nosd build tag to opt out of systemd support

[kolyshkin]

This is a carry of #3959, please see details in there.

The changes from #3959 are:

• all merge conflicts resolved
• build tag renamed from no_systemd to runc_nosd

Using this makes runc binary size ~10% smaller (of which half is github.com/godbus/dbus/v5).

For the unstripped binary:

│ -9.91%  │ runc                                        │ 15 MB    │ 14 MB    │ -1.5 MB │
│         │ runc-nosd                                   │          │          │         │

For stripped binary:

│ -10.32% │ runc-stripped                               │ 11 MB    │ 9.5 MB   │ -1.1 MB │
│         │ runc-nosd-stripped                          │          │          │         │

[cyphar]

This is missing runc_nosd.

[akhilerm]

A quick question. Isnt systemd required if you are using runc with cgroups v2? Or is it only a recommendation to use the systemd manager for cgroupv2?

[cyphar]

@akhilerm You can in principle use runc without systemd on cgroupv2 systems, but it is very fragile because systemd can rewrite or change your cgroups if you don't register your cgroups with it and ask it to delegate them to you. I wouldn't recommend it, the kinds of bugs you run into are really frustrating to debug and can lead to containers having their cgroup limits entirely removed by systemd. But it's not (yet) strictly required.

[akhilerm]

@akhilerm You can in principle use runc without systemd on cgroupv2 systems, but it is very fragile because systemd can rewrite or change your cgroups if you don't register your cgroups with it and ask it to delegate them to you. I wouldn't recommend it, the kinds of bugs you run into are really frustrating to debug and can lead to containers having their cgroup limits entirely removed by systemd. But it's not (yet) strictly required.

If thats the case, will this change have an impact on the users. As most of them will be on cgroupsv2 or are in the process of migrating to cgroupv2. Which means, they will need the systemd support.

[cyphar]

@akhilerm We aren't going to ship binaries with this flag set, and it won't be the default build option. I'm not even sure if @kolyshkin intends for this to be merged or is still expeirmenting.

At best it'll be an option for users that really want to disable this feature, for whatever reason. Personally I think the dislike of systemd that motivated the original PR ("Lennartix") kind of sullies the patch set somewhat, as it's not really clear to me why removing some DBus calls (that are no-ops on the vanishingly small number of non-systemd systems anyway) is that important.

[cyphar]

@kolyshkin Can you reword the original commit messages to not use the term "lennartix"?

[thaJeztah]

Yeah, I'm not sure if we should take this change. I know the original contributor opened pull requests in various projects, but my fear is that it'll add the risk of considerable complexity; from experience, I know that such build-tags can start as "easy", but with more tags, the matrix can expand rapidly, which may result in more and more code having to be differentiated. For some packages that could be "ok" (e.g. I'm much more comfortable with the no_criu tag).

For this case specifically, we know running without systemd isn't "ideal", and I'm not sure how much test-coverage we get, more so if none of the active maintainers will be running in such a configuration. So I'd rather not take on that complexity unless there's a code-owner that can commit to maintaining.