[SOLVED?][OpenRC]Zdychające usługi, bug czy feature?

[Jacekalex]

Miałem podobny cyrk w starym systemie, ale myślałem, ze ja coś popieprzyłem w skryptach startowych.
Teraz mam świeżutki system, postawiony w sobotę, skryptów startowych w /etc/init.d nie dotknąłem nawet palcem, wszystko domyślne.

Bezpośrednio po starcie wszystkie usługi mają prawidłowy status started.
Tymczasem po jakimś czasie ( godzina?), potrzebuję zrestartować np Mysql, i zaczyna się piekło durnowatych komunikatów w typie

Code: Select all

/etc/init.d/mysql restart
udev-mount      | * You are attempting to run an openrc service on a
udev-mount      | * system which openrc did not boot.
sysfs           | * You are attempting to run an openrc service on audev-mount      | * You may be inside a chroot or you may have used

udev-mount      | * another initialization system to boot this system.
sysfs           | * system which openrc did not boot.
udev-mount      | * In this situation, you will get unpredictable results!
sysfs           | * You may be inside a chroot or you may have used
udev-mount      | * If you really want to do this, issue the following command:sysfs           | * another initialization system to boot this system.

sysfs           | * In this situation, you will get unpredictable results!
udev-mount      | * flock() failed: Interrupted system call
udev-mount      | * touch /run/openrc/softlevel
udev-mount      | * ERROR: udev-mount failed to start
sysfs           | * If you really want to do this, issue the following command:
sysfs           | * touch /run/openrc/softlevel
sysfs           | * ERROR: sysfs failed to start
udev            | * ERROR: cannot start udev as sysfs would not start
fsck            | * You are attempting to run an openrc service on a
fsck            | * system which openrc did not boot.
fsck            | * You may be inside a chroot or you may have used
fsck            | * another initialization system to boot this system.
fsck            | * In this situation, you will get unpredictable results!
fsck            | * If you really want to do this, issue the following command:
fsck            | * touch /run/openrc/softlevel
fsck            | * ERROR: fsck failed to start
mysql           | * ERROR: cannot start mysql as fsck would not start
localmount      | * ERROR: cannot start localmount as fsck would not start

Patrzę, a OpenRC twierdzi, że wszystkie usługi są zastopowane pomimo, że działają, i wstały prawidłowo.

Code: Select all

rc-status default
Runlevel: default
 dbus                                                              [  stopped  ]
 apparmor                                                          [  stopped  ]
 mysql                                                             [  stopped  ]
 dovecot                                                           [  stopped  ]
 bluetooth                                                         [  stopped  ]
 named                                                             [  stopped  ]
 netmount                                                          [  stopped  ]
 clamd                                                             [  stopped  ]
 cupsd                                                             [  stopped  ]
 gpm                                                               [  stopped  ]
 postfix                                                           [  stopped  ]
 vixie-cron                                                        [  stopped  ]
 vnstatd                                                           [  stopped  ]
 xdm                                                               [  stopped  ]
 local                                                             [  stopped  ]

Dotyczy to wszystkich poziomów: sysinit, boot i default.
Dość to wkurzające, jak wtedy trzeba podnieść jakąś wyłączoną usługę, bądź coś zrestartować.
jak to naprawić?

Wersje:

Code: Select all

 ~> qlist -UqCv openrc udev
sys-apps/openrc-0.11.8 elibc_glibc kernel_linux ncurses pam unicode
sys-fs/eudev-1.1 gudev hwdb keymap kmod modutils openrc
sys-fs/udev-init-scripts-26
virtual/udev-200 gudev hwdb keymap kmod

W logach ani słowa o jakiejś katastrofie, która nagle zmienia pamięć OpenRC, albo ja nie wiem, czego szukać.
Wszelkie pomysły (z wyjątkiem zmiany na systemd ) mile widziane.

Edit:
Okazało się, że stabilna wersja OpenRC-11.8 ma chyba jakiś błąd.

Code: Select all

qlist openrc -UqCv
sys-apps/openrc-0.12.4 elibc_glibc kernel_linux ncurses netifrc pam tools unicode

EDIT 2:
OpenRC-12.4 wywala się tak samo, 4 godziny wszystko ok, i nagle boooom.
Pozdro

[SlashBeast]

Wyglada tak, jakby tracil /run/openrc, spawdz co masz w /run/openrc/softlevel

To wlasnie tam trzymane sa statusy uslug itp.

[Jacekalex]

Cała zawartość /run/openrc/ z momentu, kiedy działa:
http://wklej.dug.net.pl/4681

Obecnie:

Code: Select all

cat  /run/openrc/softlevel 
default

Jak zdechnie, to zrobię porównanie, tylko kłopot polega na tym że pojęcia nie mam, kiedy zdechnie.

Jest jakaś opcja debugowania, żeby w rc.log lądowały wszystkie wydarzenia, a nie tylko start i stop systemu?

Bo największy problem polega na tym że w logu o żadnych podobnych kłopotach ani śladu, albo po prostu nie wiem, czego szukać.
Ten cyrk się zaczął mniej więcej w czasie, kiedy w OpenRC pojawił się support do cgroup.
Wtedy się tym nie zająłem, bo miałem kilka własnych skryptów startowych, i myślałem, ze coś mieszają.
Ale teraz mam czysty system, jedynie apparmor jest z overlaya hardened-development, ale przed jego zainstalowaniem problem też występował.
Poza tym skryptów startowych nie tknąłem choćby palcem.

Pozdro

[Jacekalex]

Ciekawostka.....
To nie OpeRC jest winne, praktycznie przed moim nosem zresetował się cały katalog /run. w taki sposób, że był pusty, po czym po chwili udev założył tam folder mount.

Zniknęły wszystkie pidy i sockety z /run.
Na poprzednim systemie tego nie zauważyłem, bo trzymałem osobny /var/run (też tmpfs), i tam siedziała większość usług.
W nowym /var/run jest dowiązaniem do /run, i nagle ni z gruszki, niz pietruszki, zniknął dostęp do mysqld.sock, clamd.sock, praktycznie wszystko, co tam się komunikowało.


Co ciekawe, to raczej nie jest wina kernela, który kasuje tmpfsy, bo mam w tmpfs /tmp i /var/tmp, tam wszystko jest na swoim miejscu, testowy postfix ma na tmpfs w /var/spool/postfix, i nie zgubił ani jednego pliku.
Także z pośród kilku folderów tmpfs problem jest tylko w /run, i jest to jedyny folder tmpfs, który jest tworzony przez /lib64/rc/sh/init.sh.
Foldery ustawione w /etc/fstab zachowują się normalnie, nic z nich nie znika bez powodu.

Problem na starym systemie wynikł w okolicach dodania do OpeRC obsługi cgroup, i w portage udeva-200, wiem, ze na nim po raz pierwszy zauważyłem ten problem.

Miałem kilka innych cyrków z udevem, dlatego wyprowadziłem się na eudev, ten działa bez żadnych widocznych problemów.

[SlashBeast]

Wrzuc na kernel grsecurity i wlacz audit mountow, to bedzie wiadomo kiedy i jaki proces zamontowal /run

Code: Select all

Nov 02 14:15:07 [kernel] [   11.497061] grsec: mount of tmpfs to /run by /bin/mount[mount:213] uid/euid:0/0 gid/egid:0/0, parent /lib64/rc/sh/init.sh[init.sh:201] uid/euid:0/0 gid/egid:0/0

Jak juz to bedziesz mial i jezeli powod nie bedzie jasny, wtedy z tymi informacjami zrob bug report na openrc

[Jacekalex]

Grseca mam cały czas, ale Audyt montowania wyłączony.
Myślę, że to nie OpenRC, tylko udev coś szaleje, i chyba ma to coś wspólnego być może ze sprzętem.

Dzisiaj cały czas z nosem przy kompie, ale dałem udeadm monitor na terminalu, jak OpeRC działało.
Po godzinie patrzę, OpenRC zdechło, na monitorze udeva czysto.

A teraz patrzę, udev melduje, ze ster do dekodera mpeg w tunerze zawołał kilka razy o firmware, przez tyle godzin nic ważnego, wyłączyłem, i z ciekawości rc-status.
I co? usługi na swoim miejscu?
Zastanawiam się, jakim cudem, ale muszę przyznać, ze już sobie obejrzałem, jak się podnosi i restartuje różne usługi,
i 2/3 systemu zamiaruję wywalić na daemon-toolsa, ten jest "gniotsa nie łamiotsa".

Zrobione, zobaczymy, czy się czegoś ciekawego dowiem:

Code: Select all

sysctl -w kernel.grsecurity.audit_mount=1
kernel.grsecurity.audit_mount = 1

Myślę, że po zamieszaniu z łączeniem udeva z systemd tyle się namieszało, że jeszcze nie jeden cyrk zobaczymy.

Zupełnie np nie czaję, po jaki ch w OpeRC i Systemd cgroup, który można równie dobrze załatwić takim skryptem.
U mnie powstał, jak cgconfig nie chciał własnego konfigu czytać, i nie zamienię go na nic innego.
Bash, echo, mkdir, chown i chmod przynajmniej zawsze działają jednakowo.

Pozdro

[SlashBeast]

Juz kiedys z Williamem ktory wrzucil w openrc cgroups rozmawialem o tym i wyszlo, ze to glownie by trackowac childy ktore sie detachuja od parenta i to troche ma sens.

co do udeva, dawno temu przeszedlem na mdev(-like-a-boss) i nie mam zadnego, absolutnie najmniejszego problemu, ale moje DE to openbox+tint + gazylion terminali.

[Jacekalex]

Ja natomiast wiem z autopsji, że dobrymi chęciami piekło jest wybrukowane, i nawet,
jak coś jest zrobione dla mojego dobra, to mnie mocno wkurza, jeśli komplikuje sprawę.

Właśnie dlatego developerzy *buntu "zdecydowali" za mnie, że jednak lepsze i łatwiejsze jest Gentoo.

Mam od zawsze Gnome-2 i pierdylion rożnych usług sieciowych i programów do testowania.
Przy okazji emigracji Xorg => Wayland chyba będę się musiał przeprosić z KDE albo RazorQT,
ale to bezpośrednio wina Devów Gnome, i tego czegoś, co zrobili z biblioteki Gtk.

Pozdro

[Jacekalex]

Nie wiem, czy się OpenRC przestraszyło, że jakby co, to naskrobię własnego inita odpalającego supervice (daemon-tools).

Tak z ciekawości zacząłem się zastanawiać, jak mogłoby to wyglądać, i najwyraźniej do OpenRC dotarło, że nie żartuję, bo od dwóch dni jest ok.
Co ciekawe, problem zniknął na OpeRC-0.12.4 po włączeniu rc_paralell="YES",
co jest tym dziwniejsze, że często to ustawienie wcześniej powodowało różne kłopoty.

Logowanie z Grsec nie pokazało żadnej podejrzanej akcji wobec folderu /run.

Kolejna sytuacja, która pokazuje, że "bywają takie rzeczy na niebie i ziemi, o których nie śniło się największym filozofom".

Pozdro