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@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 <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
