Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#1  2024-05-23 21:47:45

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

Lepiej uważajcie na nowe wydania systemd — ktoś tam się z pewnym organem na łby pozamieniał i postanowił dodać 30s opóźnienie podczas startu systemu jeśli się używa cgroups v1, którego systemd nie chce wspierać. xD

Założyłem wątek na GH systemd, zobaczymy co popiszą. xD

Offline

 

#2  2024-05-24 21:58:00

  mati75 - Psuj

mati75
Psuj
Skąd: masz ten towar?
Zarejestrowany: 2010-03-14

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

O nawet sam wielki pan autor odpisał. Jak wiele osób też nie trawie jego podejścia do projektów.


https://l0calh0st.pl/obrazki/userbar.png

Offline

 

#3  2024-05-25 02:32:06

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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

Offline

 

#4  2024-05-26 03:30:02

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

Problem to będzie wtedy, jak cgroupv1 zostanie porzucony przez libcgroup.
Na razie się na to nie zanosi.
Co do "strasznych problemów z Systemd" to tenże systemd w ogóle nie musi się cgroup zajmować, póki jest cgrulesengd.
Ciekawe tylko, czy da się w Systemd całkowicie wyłączyć zarządzanie cgroup, że się od cgroup odczepił.

OpenRC też teoretycznie używa cgroupv2, ale to w niczym nie przeszkadza w działaniu cgroupv1 przez cgrulesengd, np:

Kod:

# G1 Gentuś11 ### screen  ###   nie maj 26 03:33:18  Domek : ~ 

# root ~> cat /proc/self/cgroup
15:misc:/
14:rdma:/
13:pids:/system/shell
12:hugetlb:/
11:net_prio:/
10:perf_event:/
9:net_cls:/
8:freezer:/
7:devices:/
6:memory:/system/shell
5:blkio:/system/shell
4:cpuacct:/system/shell
3:cpu:/system/shell
2:cpuset:/
1:name=openrc:/11
0::/openrc.agetty.tty5

Z reszta jajo potrafi obsługiwać oba tryby cgroup równocześnie, więc nie ma obowiązku polegać na Systemd czy OpenRC.

Kod:

grep cgroup /proc/filesystems 
nodev    cgroup
nodev    cgroup2

Tutaj widać, jak OpenRC montuje cgroup:
https://raw.githubusercontent.com/OpenRC/openrc/mas … .d/cgroups.in
Ciekawe, czy SystemD wymyślił jakiś nowy, rewolucyjny system montowania cgroup...

Pozdro

Ostatnio edytowany przez Jacekalex (2024-05-26 04:44:51)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#5  2024-05-30 11:19:12

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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:

Kod:

#  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:

Kod:

# 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

Offline

 

#6  2024-06-19 10:00:54

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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ć?

Offline

 

#7  2024-06-19 12:32:02

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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

Kod:

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ł?

Kod:

 cat /service/cgroup/run

Kod:

#!/bin/sh

exec 2>&1

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

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

Kod:

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

procesy:

Kod:

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)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#8  2024-06-19 14:01:09

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

Jacekalex napisał(-a):

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

To nic nie da, bo problem tkwi w tym kto zarządza katalogiem /sys/fs/cgroups/ i w systemd zawsze to będzie systemd. I jak inny demon będzie próbował przemieszczać procesy z cokolwiek co się znajduje w /sys/fs/cgroups/ i podkatalogach, to będą problemy, które właśnie ja obserwuje, gdzie ścieżka widziana przez nftables często nie jest taka jak być powinna (jest ustawiona na wartość katalogu, z którego pid procesu został przemieszczony, a tak mamy /sys/fs/cgroup/user.slice/... , który należy do systemd...)

Jacekalex napisał(-a):

U mnie przy OpenRC udeva dostarcza ostatnio

Kod:

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 zasadzie po co Ci konto root jak jest systemd?
Który w dodatku wszystko robi lepiej i jest mądrzejszy od użyszkodnika?

W debianie są podobne rzeczy:

Kod:

p  systemd-standalone-sysusers => standalone sysusers binary for use in non-systemd systems [testing,unstable]
p  systemd-standalone-tmpfiles => standalone tmpfiles binary for use in non-systemd systems [testing,unstable]

ale od udev'a nic nie widzę.

Niby:

Kod:

$  aptitude show udev
Package: udev
Version: 256-1
State: installed
Automatically installed: no
Multi-Arch: foreign
Priority: important
Section: admin
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Architecture: amd64
Uncompressed Size: 11.6 M
Compressed Size: 1,887 k
Filename: pool/main/s/systemd/udev_256-1_amd64.deb
Checksum-FileSize: 1886512
MD5Sum: 66266a21153135e979094739ff82a922
SHA256: 8c362f3bc510f01fababb6486a426a8618f00189aafad96b3fdec771f34eecbd
Archive: testing, unstable, now
Depends: libacl1 (>= 2.2.23), libblkid1 (>= 2.37.2), libc6 (>= 2.38), libcap2 (>= 1:2.10), libselinux1 (>= 3.1~), systemd | systemd-standalone-sysusers | systemd-sysusers,
         libkmod2, libudev1 (= 256-1)
Suggests: libcryptsetup12, libidn2-0, libtss2-rc0t64
Conflicts: systemd (< 255~rc1-4~)
Replaces: systemd (< 255~rc1-4~)
Description: /dev/ and hotplug management daemon
 udev is a daemon which dynamically creates and removes device nodes from /dev/, handles hotplug events and loads drivers at boot time.
Homepage: https://systemd.io
Tags: admin::boot, admin::filesystem, admin::hardware, admin::kernel, devel::lang:c, devel::library, hardware::detection, implemented-in::c, implemented-in::shell,
      interface::daemon, role::devel-lib, role::program

Więc teoretycznie powinien działać i bez systemd choć nie wiem jak ze stabilnością. xD

Ostatnio edytowany przez morfik (2024-06-19 14:02:51)

Offline

 

#9  2024-06-19 19:12:42

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#10  2024-06-22 16:14:55

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

Być może sobie popatrzę jak będę miał wolną maszynę. xD

Co do tematu, to są dwa rozwiązania. 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, które mają problemy. Drugie to wyrzucenie systemd. Może tymczasowo skorzystam z tego pierwszego rozwiązania ale docelowo to nie będzie wyjścia by wywalić systemd jeśli chce się mieć FW per user appka.

Z tego co widzę, to w debianie powoli rozbijają systemd na czynniki pierwsze, np. pojawiła się kolejna paczka  systemd-standalone-shutdown i  w sumie są już 3:

Kod:

p  systemd-standalone-shutdown => standalone shutdown binary for use in exitrds [unstable]
p  systemd-standalone-sysusers => standalone sysusers binary for use in non-systemd systems [unstable]
p  systemd-standalone-tmpfiles => standalone tmpfiles binary for use in non-systemd systems [unstable]

Offline

 

#11  2024-06-22 18:03:11

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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.

Kod:

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:

Kod:

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

Kod:

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

Jak widać u mnie, wykonalne:

Kod:

 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:

Kod:

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

Kod:

###  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)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#12  2024-06-23 23:20:27

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

W debianie nie ma:

Kod:

 # ls -l `which cgexec`
-rwxr-xr-x 1 root root 22880 2024-06-23 19:28:44 /usr/bin/cgexec*

BTW, w jakiej wersji masz cgroup-tools? 3.1.x czy 2.0.x? Bo chyba tę starszą. xD

Próbuję skonfigurować ścieżkę w /sys/fs/cgroup/ posługując się samymi narzędziami z cgroup-tools ale coś mi nie wychodzi.

Ostatnio edytowany przez morfik (2024-07-01 20:27:26)

Offline

 

#13  2024-07-01 20:33:32

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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

Offline

 

#14  2024-07-02 20:28:21

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

morfik napisał(-a):

...
BTW, w jakiej wersji masz cgroup-tools? 3.1.x czy 2.0.x? Bo chyba tę starszą. xD

Próbuję skonfigurować ścieżkę w /sys/fs/cgroup/ posługując się samymi narzędziami z cgroup-tools ale coś mi nie wychodzi.

U mnie?

Kod:

dev-libs/libcgroup-3.1.0 daemon pam static-libs -systemd -test tools

Cieszę się, że się Tobie udało.
https://github.com/libcgroup/libcgroup/issues/432#i … nt-2200828308

Tego gościa też pozdrów...

xD

PS
Późno odpisuję, bo FF dostał dziwacznego kataru:

Kod:

[23938.849726] traps: WRScene~ilder#1[3521] trap stack segment ip:60c835efc5c4 sp:705be11b3b80 error:0 in firefox[60c835ef1000+84000]

a w Chrome nie mam zapisanego hasła do DUGa.
Także trzeba było poczekać, aż się nowy FF zbuduje.

Pozdro


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#15  2024-07-03 14:52:11

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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.

Offline

 

#16  2024-07-04 22:56:51

  mati75 - Psuj

mati75
Psuj
Skąd: masz ten towar?
Zarejestrowany: 2010-03-14

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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.


https://l0calh0st.pl/obrazki/userbar.png

Offline

 

#17  2024-07-05 15:22:39

  Pavlo950 - człowiek pasjonat :D

Pavlo950
człowiek pasjonat :D
Zarejestrowany: 2012-02-20
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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

Offline

 

#18  2024-07-06 09:59:14

  mati75 - Psuj

mati75
Psuj
Skąd: masz ten towar?
Zarejestrowany: 2010-03-14

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

W 24.04 network-manager jest powiązany z netplan przez netplan-generator który działa tam bardzo dobrze:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2069495
https://bugs.launchpad.net/netplan/+bug/1999178


https://l0calh0st.pl/obrazki/userbar.png

Offline

 

#19  2024-07-06 15:16:43

  Pavlo950 - człowiek pasjonat :D

Pavlo950
człowiek pasjonat :D
Zarejestrowany: 2012-02-20
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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

Offline

 

#20  2024-07-07 12:14:27

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

Ja mam takie efekty ze spowolnieniem np. aktualizacji systemu, gdy zapomnę odmontować zasoby SAMBA  (montowane przez fstab), gdy zdalna maszyna poszła offline. Wtedy to faktycznie instalacja pakietów która normalnie powinna zając paredziesiąt sekund, potrafi się wlec i 15minut. xD

Np. w przeszłości były takie kwiatki też:
https://github.com/systemd/systemd/issues/16156#issuecomment-800922842

Ostatnio edytowany przez morfik (2024-07-07 12:25:39)

Offline

 

#21  2024-07-07 15:21:35

  Pavlo950 - człowiek pasjonat :D

Pavlo950
człowiek pasjonat :D
Zarejestrowany: 2012-02-20
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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

Kod:

#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.

Offline

 

#22  2024-07-07 22:10:59

  mati75 - Psuj

mati75
Psuj
Skąd: masz ten towar?
Zarejestrowany: 2010-03-14

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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?


https://l0calh0st.pl/obrazki/userbar.png

Offline

 

#23  2024-07-07 22:14:33

  Pavlo950 - człowiek pasjonat :D

Pavlo950
człowiek pasjonat :D
Zarejestrowany: 2012-02-20
Serwis

Re: Systemd i 30s opóźnienie boot dla osób korzystających z cgroups v1

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)

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Możesz wyłączyć AdBlock — tu nie ma reklam ;-)