max connections per control group (cgroup)
Alban Crequy
alban.crequy at collabora.co.uk
Fri Aug 8 04:01:58 PDT 2014
On Thu, 07 Aug 2014 19:02:12 -0400
Colin Walters <walters at verbum.org> wrote:
> On Thu, Aug 7, 2014, at 09:32 AM, Alban Crequy wrote:
> >
> > Should it instead consider the following path?
> > /user.slice/user-1000.slice/user at 1000.service
>
> I think one up from that even - user at 1000.service is the systemd
> --user, which is only one process among many of the login slice.
>
> Stated another way, we want to limit per user-<X>.slice.
>
> > /user.slice/user-1000.slice/user at 1000.service
> > belong to the user with -rw-r--r-- so any user process can migrate
> > there.
>
> Right, but not outside beyond that - if they log in multiple times,
> there'll still be only one slice for them - so we really do get a
> maximum number of connections per *user*.
But then, the max_connections_per_cgroup limit would not provide
anything that is not already covered by the existing
max_connections_per_user limit.
It also bothers me that if dbus-daemon cuts the cgroup path with depth=2
to get "/user.slice/user-1000.slice", it would be dependent on the way
systemd organises the cgroups. Systemd's configuration could change and
if dbus-daemon hard-codes depth=2, we will have unforeseen effects.
I asked on systemd mailing list if there is a way to restrict
unprivileged processes to change cgroups:
http://lists.freedesktop.org/archives/systemd-devel/2014-August/021786.html
Best regards,
Alban
More information about the dbus
mailing list