Skrypty startowe mldonkey

[Tomasz Pala]

On Fri, Dec 11, 2015 at 12:17:34 +0100, Paweł Gołaszewski wrote:

> Nie bądź taki hop-do-przodu.
> 
> systemd jest fajne, ale ma swoje wady. Dla przykładu w systemie gościa lxc 
> działa tragicznie i pierwsza rzecz, którą robię to wymiana na 
> stary-dobry-sysvinit
> 
> Trochę minie zanim lepsze wyprze gorsze, a w międzyczasie trzeba funkcjonować.

Wiem, sam wczoraj wracałem z networkd na naszą konfigurację interfejsów,
a od dłuższego czasu kombinuję, czy journald w ogóle jest używalny na
serwerach[*]. Dlatego tak stanowczo sprzeciwiam się psuciu rc-scripts -
to, co mieliśmy, było w wystarczającym stopniu działające, aby nie ruszać.
Zachować kompatybilność, nie robić żadnych mass-commitów (bo żaden nie
naprawi skryptów, które ludzie mają z innych źródeł), a robić nowe
rzeczy, to właśnie już tylko pod systemd.

* problemy do tej pory:
- zmiana nazw interfejsów przez udeva psuje tworzenie VLAN-ów, od tej
  pory zamiast ethX.V, co powinno przełożyć się na nowanazwa.V, tworzy
  renameY w nowanazwa, gdzie Y to kolejny numer z sekwencji, tj. kompletnie
  nieprzewidywalny - nawet nie wiem, jak sprawdzić tag takiego VLAN-u,
- VLAN-u tworzone przez networkd nie dziedziczą adresu MAC interfejsu,
- ...a gdy VLAN stworzony z ręki ma taki sam MAC, to networkd od razu
  ustawia mu taki sam adres IP - trzeba pilnować nazwy w sekcji Match...
- jak do jasnej ciasnej wyłączyć wybrany interfejs?! networkd od razu go
  podnosi, networkctl nie ma komend stop, jedynie można wyłączyć razem
  wszystko... WTF?! Chyba nie ma opcji 'nie wpieprzaj się gdy się położy',
- opcje, których systemd nie przewiduje, trzeba dodawać skryptem, np.
  link nie obsługuje parametru allmulticast.
Rzeczy bardziej złożonych (bridge, bonding) to już nawet nie testuję.

Z journald nie lepiej:
- nie da się stworzyć osobnych reguł przechowywania wg różnych kryteriów
  (level, facility) - gdy część logów chcę trzymać rok, a reszta jest mi
  zbędna na następny dzień, to tutaj nic nie wskóram (a przecież takie
  fajne filtrowanie jest!),
- gdy brakuje miejsca na logi, kasuje najstarsze - nie widziałem opcji
  'ignoruj nowe',
- efektem dwóch powyższych ograniczeń jest to, że jakiś byle użytkownik
  albo proces z włączonym debugowaniem może tak zaspamować logi, że
  wywali nam wszystko co istotne,
- po crashu logi pojawiają się w dosyć losowej kolejności - z czasów nie
  umiałem dość do sekwencji zdarzeń... a po crashu systemu nie zostają
  nawet szczątki logów, tylko przemianowany plik journala (akurat to
  drugie nie było lepiej ze zwykłym syslogiem).

Zatem mimo potencjału, jaki tkwi w tych rozwiązaniach, póki co
eksperyment zakończyłem z wynikiem 'nieużywalne poza desktopem'.

-- 
Tomasz Pala <gotar w pld-linux.org>