Re: unable to attach pid to service delegated directory in unified mode after restart

[Lennart Poettering <mzerqung@xxxxxxxxxxx>]

On Mo, 21.02.22 18:07, Felip Moll (lipixx@xxxxxxxxx) wrote:

> > That's a bad idea typically, and a generally a hack: the unit should
> > probably be split up differently, i.e. the processes that shall stick
> > around on restart should probably be in their own unit, i.e. another
> > service or scope unit.
>
> So, if I understand it correctly you are suggesting that every forked
> process must be started through a new systemd unit?

systemd has two different unit types: services and scopes. Both group
processes in a cgroup. But only services are where systemd actually
forks+execs (i.e. "starts a process"). If you want to fork yourself, that's
fine, then a scope unit is your thing. If you use scope units you do
everything yourself, but as part of your setup you then tell systemd
to move your process into its own scope unit.

> If that's the case it seems inconvenient because we're talking about a job
> scheduler where sometimes may have thousands of forked processes executed
> quickly, and where performance is key.
> Having to manage a unit per each process will probably not work in this
> situation in terms of performance.

You don't really have to "manage" it. You can register a scope unit
asynchronously, it's firing off one dbus message basically at the same
time you fork things off, telling systemd to put it in a new scope unit.

> The other option I can imagine is to start a new unit from my daemon of
> Type=forking, which remains forever until I decide to clean it up even if
> it doesn't have any process inside.
> Then I could put my processes in the associated cgroup instead of inside
> the main daemon cgroup. Would that make sense?

Migrating processes wildly between cgroups is messy, because it fucks
up accounting and is restricted permission-wise. Typically you want to
create a cgroup and populate it, and then stick to that.

> The issue here is that for creating the new unit I'd need my daemon to
> depend on systemd libraries, or to do some fork-exec using systemd commands
> and parsing output.

To allocate a scope unit you'd have to fire off a D-Bus method
call. No need for any systemd libraries.

> I am trying to keep the dependencies at a minimum and I'd love to have an
> alternative.

Sorry, but if you want to rearrange processes in cgroups, or want
systemd to manage your processes orthogonal to the service concept you
have to talk to systemd.

> Yeah, I know and understand it is not supported, but I am more interested
> in the technical part of how things would break.
> I see in systemd/src/core/cgroup.c that it often differentiates a cgroup
> with delegation with one without it (!unit_cgroup_delegate(u)), but it's
> hard for me to find out how or where this exactly will mess up with any
> cgroup created outside of systemd. I'd appreciate it if you can give me
> some light on why/when/where things will break in practice, or just an
> example?

THis depends highly on what precisely you do. At best systemd will
complain or just override the changes you did outside of the tree you
got delegated. You might break systemd as a whole though (for example,
add a process directly to a slice's cgroup and systemd will be very
sad).

Lennart

--
Lennart Poettering, Berlin