enhance cgroup support

[maciejsszmigiero]

Add a possibility to:

• Set a cgroup name for a service,

• Set a cgroup name prefix for services that don't have an explicit cgroup
  name set by the previous feature.
  This allows defining, for example, a root "services" cgroup, under which
  children cgroups for particular services are kept,

• Add a service to a controller without needing to set any of its settings,

• Keep a service cgroup when it becomes empty (for example to keep between
  service restarts some cgroup settings that were set outside OpenRC).

These functionalities allow configuration of a service cgroup name for v1
controllers and v2 (unified) hierarchy; the service name in the "openrc"
hierarchy is not affected by these settings.

The default values are set in a way so not to result in any change of
services cgroup behavior unless specifically configured in a different way
by an user.

[williamh]

I'm open to having a prefix, but I don't think we should allow the cgroup name to be configurable. It would bee very easy for users to end up with collisions.

Also, I'm curious why you want to add a service to a controller without changing any of its settings?

[maciejsszmigiero]

I'm open to having a prefix, but I don't think we should allow the cgroup name to be configurable.
It would bee very easy for users to end up with collisions.

It is not a problem if two services end with the same cgroup name, since this setting is only used
for particular controllers like "cpu" or "pids" - the service name in the "openrc" hierarchy is not affected by this setting.
In fact, placing two services in an one cgroup will allow them to share things like io limits without needing to place them both in an intermediate cgroup.

Also, I'm curious why you want to add a service to a controller without changing any of its settings?

I have a centralized script where all the cgroups settings are configured (not only for services).
Truth is, I could ask OpenRC to set a some random setting in each controller and then override it anyway but this way looks neater (we also have something similar already for a "cpuacct" controller).

[maciejsszmigiero]

Rebased this pull request onto current master.

Just as it is in the case of #182 I have OpenRC with this change deployed for few months already on
few machines without any issues and also this is a backward-compatible change: nothing changes for
existing OpenRC setups, unless a user specifically starts to make use of new functionalities added by
it.

[maciejsszmigiero]

Rebased this pull request onto current master.

[maciejsszmigiero]

Rebased this pull request onto current master.

[robbat2]

@maciejsszmigiero question on this PR.
Does this clean up properly if the user modifies the cgroup name while the service is running?
E.g. these steps
0. Service is not yet started.

1. modify /etc/conf.d/bar set the cgroup_name to a specific value, e.g. bar
2. start service bar
3. modify /etc/conf.d/bar set the cgroup_name to a different specific value, e.g. baz
4. stop or restart the service

Does it correctly use the bar cgroup for stopping, then baz for starting up again? Does the old cgroup get cleaned up?

[maciejsszmigiero]

@robbat2 I guess by "clean up properly" you mean whether all tasks in the old cgroup will get killed in your scenario (rather than just the pid monitored by start-stop-daemon, which is a separate thing from cgroups).

Currently, this isn't the case.
Since likely this isn't the answer you were expecting I will modify this PR to store the current cgroup name using service_set_value to maintain its consistency between start and stop operations.