Forum Debian Users Gang

No trochę aroganckie zachowanie z ich strony, że taki syf wprowadzają by zmusić kogoś do czegoś. Przynajmniej wymieniłem sobie cgroupsv1 na cgroupsv2. Ale nie zmienia to faktu, że gdyby ktoś z nich stał obok mnie to bym mu albo kazał zrobić to chłopakom za ten 30s delay. xD

Według tego co pisali, to z systemd wywalą całkowicie obsługę cgroupsv1 (mieli zrobić to już w zeszłym roku) i wtedy tylko v2 zostanie. Gdzieś też mi się o oczy obiło, że z kernela też mają wywalić cgroupsv1 ale kiedy to zrobią to nie wiem ale raczej nie w najbliższym czasie. Niemniej jednak, wszystko powoli albo przechodzi albo już przeszło na cgroupsv2 domyślnie. W dokumentacji kernela też mi się rzuciło w oczy, że cgroups v2 został właśnie po to zaprojektowany by usunąć ograniczenia i niezbyt przemyślane rozwiązania, które są obecne w v1, także usunięcie cgroupsv1 z kernela to kwestia czasu.

Mi system działa póki co na cgroups v2. Jedyny problem jaki miałem to serwer Xorga nie chciał się odpalić z niewiadomego powodu, gdy jego procesy miałem określone w /etc/cgrules.conf . Jak je wykomentowałem to te procesy poleciały do:

#  cat /sys/fs/cgroup/user.slice/user-1000.slice/session-30.scope/cgroup.procs
165334
165406
165466
165467
165549

├─login(165334)───startx(165406)───xinit(165466)─┬─Xorg(165467)─┬─{Xorg}(165476)
│                                                │              ├─{Xorg}(165477)
│                                                │              ├─{Xorg}(165483)
│                                                │              └─{Xorg}(165492)
│                                                └─openbox(165493)─┬─ssh-agent(165549)
│                                                                  └─{openbox}(165551)

To oczywiście w niczym nie przeszkadza, bo jakby to był jakiś inny proces, np. wymagający dostępu do sieci, to w nftables wystarczyło by podmienić ścieżkę z morfikownia/user/xorg/ na user.slice/user-1000.slice/. No tylko inne procesy też mogą do user.slice/user-1000.slice/ być dodawane, więc trzeba by pisać jakieś pliki usług systemd dla nich i wtedy będzie można zmienić ich położenie w /sys/fs/cgroup/. Inne aplikacje zdają się działać dobrze, nawet te, które mają usługi pod systemd i swoje miejsce w /sys/fs/cgroup/ po przeniesieniu do  morfikownia/system/, przykład:

# cat /sys/fs/cgroup/system.slice/dnscrypt-proxy.service/cgroup.procs

# cat /sys/fs/cgroup/system.slice/dnscrypt-proxy.service/cgroup.threads

# cat /sys/fs/cgroup/morfikownia/system/dnscrypt-proxy/cgroup.procs
292015

# cat /sys/fs/cgroup/morfikownia/system/dnscrypt-proxy/cgroup.threads
292015
292042
292043
292044
292045
292046
292047
292049
292050
296141

Także nie wiem o co dokładnie chodzi z tym Xorg'iem, trzeba będzie się zagłębić. Tak czy inaczej, to czy systemd (czy cokolwiek innego) umieszcza procesy w /sys/fs/cgroup/ jest w zasadzie już chyba bez znaczenia, bo to co się liczy to jedynie ścieżka cgroups, więc co najwyżej trzeba będzie uaktualnić skrypty. xD

Z tego co widziałęm to cgroup-tools:amd64 ma w debianie dwie wersje 2.0.2-2+b1 i w exp 3.0.0-1. Ta wersja 2.x już nie jest wspierana. A w 3.x jest ciekawe info odnośnie modyfikacji procesów i grup zarządzanych przez systemd. U mnie niby działa ale chyba nie powinno się tego robić. xD

morfik napisał(-a):

Chyba będzie mnie czekał powrót z systemd do sysvinit/openrc. xD Wygląda na to, że są pewne rzeczy, których najwyraźniej się nie da przeskoczyć jeśli chodzi o cgroupsv2, gdy systemd nim zarządza i w zasadzie nie toleruje on żadnych innych demonów, które by chciały działać na jakimś wycinku drzewa cgroups. Niby tutaj jeszcze trochę gadamy o tej przypadłości ale nie wygląda to ciekawe i wychodzi na to, że albo systemd i brak filtrowania OUTPUT per aplikacja użytkownika albo trzeba wywalić systemd i wgrać sobie taki init, który nie zarządza cgroups.

@mati75, jak to do końca z tym sysvinit/openrc wygląda w debianie, tj. chodzi mi o zastąpienie np. udev'a? Bo o ile powrót na sysvinit/openrc to raczej nie będzie stanowił problemu ale udev jest częścią systemd i jak go zastąpić?

U mnie przy OpenRC udeva dostarcza ostatnio

qlist -UqC  sys-apps/systemd-utils
sys-apps/systemd-utils abi_x86_64 acl kmod python_single_target_python3_11 split-usr tmpfiles udev

Czyli kawałek  wycięty z ogólnego kolektywnego potwora, jakim jest systemd.

Systemd nie toleruje niczego, bo zasadniczo po co Ci konto root jak jest systemd?
Który w dodatku wszystko robi lepiej i jest mądrzejszy od użyszkodnika?

PS.
Spróbuj cgrulesengd odpalić poza systemd przez daemontoolsa, może wtedy nie będzie utrudniał?

 cat /service/cgroup/run

#!/bin/sh

exec 2>&1

/usr/local/sbin/cgstart ;
##/usr/local/sbin/cgclass;

/usr/sbin/cgrulesengd --nodaemon --nolog

# root ~> svstat /service/cgroup/
/service/cgroup/: up (pid 1582) 441558 seconds

procesy:

root      848  0.0  0.0    964   568 ?        S    cze14   0:00 supervise cgroup
root     2267  0.0  0.0   6148  5592 ?        S    cze14   0:59 /usr/sbin/cgrulesengd --nodaemon --nolog

Ostatnio edytowany przez Jacekalex (2024-06-19 19:09:04)

No to SystemD do wyętolenia...

Mam dobrą nowinę, Gentuś też wdraża binarne paczusie do szybkiej instalacji.
Sznurek: https://wiki.gentoo.org/wiki/Binary_package_guide
Więc może u Morfika też kiedyś zagości...
xD

Ostatnio edytowany przez Jacekalex (2024-06-19 19:20:52)

Pierwsze, to przekonfigurowanie cgexec tak by user mógł dodawać pid'y, bo standardowo tylko root może to robić i w ten sposób porobić aliasy na appki,

Hmm
W Gentusiu cgexec ma SUID na roota.

ls -l `which cgexec`
-rws--x--x 1 root root 14408 2023-12-12  /usr/bin/cgexec

Jeśli z resztą nie chcesz cgexec puszczać z  SUID
to możesz zrobić tak:

groupadd -r cgroup
chown root:cgroup /usr/bin/cgexec
chmod 2750 /usr/bin/cgexec

find /sys/fs/cgroup -iname tasks | while read task; 
do
chown root:cgroup $task; chmod 660 $task;
done;

Jak widać u mnie, wykonalne:

 ls -l /sys/fs/cgroup/memory/users/pidgin/tasks 
-rw-rw---- 1 root cgroup 0 06-14 09:51 /sys/fs/cgroup/memory/users/pidgin/tasks

Potem każdy użyszkodnik dodany do grupy cgroup ma prawo do skutecznego użycia cgexec.

Oczywiście jak zwykle SystemD może mieć wonty do uprawnień tasks.

I nawet aliansów, możesz sobie porobić skryty z poleceniami, np:

ls -l `which mpv`
-rwxr-xr-x 1 root root 109 2023-09-18  /usr/local/bin/mpv

###  cat  `which mpv`
#!/bin/bash
export ALSAOUT="vlc"
/bin/elogind-inhibit  --why="Filma Gramy \;\)" /usr/bin/mpv --pause   "$@"

Ostatnio edytowany przez Jacekalex (2024-07-02 20:29:37)

Trochę się wyjaśniło w kwestii konfiguracji cgroups i ogarnianie cgroups dla zwykłego user'a jest trochę problematyczne w przypadku v2, w skrócie, to nie jest już takie proste jak zmiana uprawnień do plików. xD

This is a little tricky in comparison to the cgroup v1, where just changing the permission of the tasks file of the cgroup or group ownership is sufficient but cgroup v2 has an enforced rule, that says the user writing pid into destination cgroup should have permission to write on the nearest common ancestor of both source and destination cgroup. It is to avoid moving the tasks from the delegated subtree to the non-delegated subtree. It suggested moving the parent or the first task of the user to the delegated subtree by the root user, so all the tasks forked by the first task will be under the delegated subtree and freely moved between the children cgroups under the delegated subtree.

-- https://github.com/libcgroup/libcgroup/issues/432#i … nt-2199869257

No wygląda, że się w końcu udało w miarę sensownie ogarnąć tego cgroups v2 w połączeniu z systemd, więc może nie będzie potrzeby wywalania i powrotu do sysvinit/openrc. Choć jeszcze nad tym pomyślę ale narazie jest lato, więc może w zimę. xD Jeszcze trochę potestuję i zobaczę czy nie będzie żadnych problemów, bo póki co zdaje się to działać bez zarzutu.

mati75 napisał(-a):

morfik napisał(-a):

@mati75, jak to do końca z tym sysvinit/openrc wygląda w debianie, tj. chodzi mi o zastąpienie np. udev'a? Bo o ile powrót na sysvinit/openrc to raczej nie będzie stanowił problemu ale udev jest częścią systemd i jak go zastąpić?

Nie wiem, mam dość systemd i powiązanych twórczości. Osobiście przeszedłem wszędzie na systemd. Czekam aż debian wrzuci jakiś pseudo moduły jak zrobiło to ubuntu z netplan, gdzie rzeźbi on konfiguracje z network-manager i przez to systemd się wywala.

netplan można wywalić, ja u siebie tego nie mam XD za to network-manager działa poprawnie w przeciwieństwie do networkd i innych wynalazków

mati75 napisał(-a):

W 24.04 network-manager jest powiązany z netplan przez netplan-generator który działa tam bardzo dobrze:

No tak, ale sam network-manager do działania nie wymaga netplan. Z drugiej strony netplan-generator sugeruje nm, ale nie wymaga go. Patrz zależności.

mati75 napisał(-a):

https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2069495
https://bugs.launchpad.net/netplan/+bug/1999178

Dziwne XD

W ogóle, w /etc/systemd/system.conf, jest coś takiego:

#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s
#DefaultDeviceTimeoutSec=90s

Pamiętam że jak mi chyba dyzio padał kiedyś i pozmieniałem te opcje na 10s (bo coś się za długo odpalało / wyłączało) to mi problem ze zbyt długim startem / stopem zniknął. To chyba były te opcje ale już teraz nie jestem pewien czy aby na pewno.

mati75 napisał(-a):

Pavlo950 napisał(-a):

No tak, ale sam network-manager do działania nie wymaga netplan. Z drugiej strony netplan-generator sugeruje nm, ale nie wymaga go. Patrz zależności.

https://packages.ubuntu.com/noble/network-manager
Widzę tu coś innego. Występuje o tego momentu https://git.launchpad.net/network-manager/commit/?i … 88e1ff0bf4449
Myślisz że tego nie sprawdzałem?

A bo Ty na repo Ubuntu patrzysz. W Debianie jeszcze jest inaczej network-manager

Ostatnio edytowany przez Pavlo950 (2024-07-07 22:16:04)