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

```
/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.

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

```
 ~> 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   :Evil or Very Mad:  ) mile widziane.   :Question: 

Edit:

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

```
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

 :Cool: Last edited by Jacekalex on Mon Nov 25, 2013 2:04 pm; edited 1 time in total

----------

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

```
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

 :Cool: 

----------

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

```
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,   :Smile: 

i 2/3 systemu zamiaruję wywalić na daemon-toolsa, ten jest "gniotsa nie łamiotsa".   :Very Happy: 

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

```
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.  :Very Happy: 

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.  :Wink: 

Pozdro

 :Cool: 

----------

## 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.  :Very Happy: 

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.    :Twisted Evil: 

Pozdro

 :Cool: 

----------

## Jacekalex

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

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.   :Smile: 

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".  :Wink: 

Pozdro

 :Cool: 

----------

