Rulez un gitlab runner și vreau ca fiecare job să se pună în propriul său cgroup.
Pot seta subprocesul gitlab bash la cgroup-ul potrivit, dar copiii săi nu moștenesc cgroup-ul.
Asa fac eu:
$ /usr/bin/ps -opid,cgroup $PPID $$
PID CGROUP
43547 11:blkio:/user.slice,9:dispozitive:/user.slice,7:pids:/user.slice,6:memory:/user.slice,2:cpuacct,cpu:/user.slice,1: name=systemd:/user.slice/user-988.slice/session-c2500.scope
43548 11:blkio:/user.slice,9:dispozitive:/user.slice,7:pids:/user.slice,6:memory:/user.slice,2:cpuacct,cpu:/user.slice,1: name=systemd:/user.slice/user-988.slice/session-c2500.scope
$ /usr/bin/sudo /usr/bin/env CGROUP_LOGLEVEL=DEBUG /usr/bin/cgclassify -g cpu,cpuacct:/gitlab-runner/$CI_CONCURRENT_PROJECT_ID --sticky $PPID $$
CPU găsit în rw,nosuid,nodev,noexec,relatime,cpuacct,cpu
S-a găsit opțiunea cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu, count 0
... tuns...
Se va muta pid 43547 în cgroup „/gitlab-runner/0”
Adăugarea procesorului controlerului
Adăugarea controlerului cpuacct
Se va muta pid-ul 43548 în cgroup „/gitlab-runner/0”
Adăugarea procesorului controlerului
Adăugarea controlerului cpuacct
$ /usr/bin/ps -opid,cgroup $PPID $$
PID CGROUP
43547 11:blkio:/user.slice,9:dispozitive:/user.slice,7:pids:/user.slice,6:memory:/user.slice,2:cpuacct,cpu:/gitlab-runner/0, 1:name=systemd:/user.slice/user-988.slice/session-c2500.scope
43548 11:blkio:/user.slice,9:dispozitive:/user.slice,7:pids:/user.slice,6:memory:/user.slice,2:cpuacct,cpu:/gitlab-runner/0, 1:name=systemd:/user.slice/user-988.slice/session-c2500.scope
Interogarea unei alte rulări, găsirea proceselor în cgroup:
$ ps -e -opid,comm,cgroup | grep gitlab-runner/3
77554 la 11:blkio:/user.slice,9:devices:/user.slice,7:pids:/user.slice,6:memory:/user.slice,2:cpuacct,cpu:/gitlab-runner/3 ,1:name=systemd:/user.slice/user-988.slice/session-c2604.scope
77555 bash 11:blkio:/user.slice,9:devices:/user.slice,7:pids:/user.slice,6:memory:/user.slice,2:cpuacct,cpu:/gitlab-runner/3 ,1:name=systemd:/user.slice/user-988.slice/session-c2604.scope
Privindu-și copiii...
$ pstree -p 77554
su(77554)–bash(77555)–bash(77575)–python3.6(78199)– ârun-cypress-spl(78206)âââacoperire(80245)ââ¬ânode(91561)ââ¬âCypress(91796 )ââ¬âChiparos (91799)âââChiparos (91990)ââ¬â{Chiparos}(91992)
â â â ââ{Chiparos}(91993)
Copiii săi nu sunt în cgroup:
$ ps -opid,comm,cgroup 78206 | pisică
COMANDĂ PID CGROUP
78206 run-cypress-spl 78206 run-cypress-spl 11:blkio:/user.slice,9:devices:/user.slice,7:pids:/user.slice,6:memory:/user.slice,2: cpuacct,cpu:/user.slice,1:name=systemd:/user.slice/user-988.slice/session-c2604.scope
am gasit si eu https://stackoverflow.com/questions/50749408/how-systemd-tracks-fork-process-with-type-fork ceea ce implică faptul că systemd ar putea preveni moștenirea cgroup la fork.
Există o cale de a ocoli asta?
CentOS7, systemd-219-78.el7_9.5.x86_64.
Update: Dacă am înțeles acest răspuns, răspunsul poate fi Delegate=true. Nu cred că acest lucru este acceptat pe acest sistem... Îl încerc în continuare.
Actualizare: am încercat asta și nu a fost găsită nicio diferență:
$ cat /etc/systemd/system/gitlab-runner.service.d/override.conf
[Serviciu]
Delegat=da
Actualizare: aceasta poate fi o modalitate alternativă pe care o voi încerca în continuare: https://unix.stackexchange.com/questions/490978/limit-cpu-and-memory-consumption-of-all-x-applications
