Re: systemd: Exklusives Starten eines Service beim Booten
Christoph Pleger - 23.11.17, 11:19:
> > Aber, ich habe ein leichten Verdacht das dass hier ein XY Problem ist.
> > Wenn du alles in eine CGroup packen willst nur um allen Prozessen eine
> > gewisse Ressource-Limitation aufzudrücken, verwende doch einfach
> > /etc/systemd/system.conf (oder /etc/systemd/system.conf.d/*.conf
> > respektive)
>
> Es geht darum, beim Booten erstens alle Systemprozesse in eine eigene
> cgroup zu verschieben und zweitens jeweils eine neue cgroup für lokale
> und Remote-User einzurichten. Später werden dann per pam_exec beim Login
> die Prozesse des neu angemeldeten Nutzers in die entsprechende cgroup
> eingeordnet, so dass letzlich der lokale Nutzer nicht durch SSH-Logins
> anderer Nutzer zu stark blockiert werden kann und außerdem
> Systemprozesse auch genügend CPU-Ressourcen abbekommen.
Systemd packt doch die Benutzer bereits in Slices. Das dürfte also bereits via
/etc/systemd/user.conf bzw. angepassten Slice-Konfigurationen gehen. (siehe
Manpages systemd.slice, systemd-logind )
> Jetzt stelle ich aber gerade ein neues Problem fest: Logins mit $USERID
> < 100 sollen in die System-Gruppe eingeordnet werden. Nach einem
> SSH-Login von root steht die PID des Login-Prozesses aber nicht in
> /sys/fs/cgroup/cpu,cpuacct/system/tasks, sondern in
> /sys/fs/cgroup/cpu,cpuacct/tasks - obwohl die Parent-PID, nämlich der
> SSH-Daemon, in der Systemgruppe ist. Wurden nicht sonst Kindprozesse
> immer automatisch in die cgroup eingeordnet, zu der auch der
> Elter-Prozess gehört?
Ich hab den Eindruck, dass Du teilweise Systemd nachbauen möchtest. Systemd
packt Dienste bereits in eigenes Slices und Dienste lassen sich auch mit
eigenen Limits belegen.
Daher lässt sich für SSH auch pauschal nochmal ein Anteil an CPU-Zeit
reservieren.
Siehe auch die Manpage systemd.resource-control.
Falls ihr kein Problem damit habt, Systemd zu Hilfe zu nehmen, empfehle ich,
die umfangreiche Systemd-Dokumentation erst mal nach Ansätzen durch zu
stöbern.
Alternativ gibt es auch noch cgmanager, falls doch Sysvinit zum Einsatz kommen
soll.
In Bezug auf Control Groups gibt es die Idee, dass nur *ein* Prozess dort drin
rum bastelt. Ich weiß noch nicht so ganz, ob ich das so gut finde…
Danke,
--
Martin
Reply to: