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!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Wziąłem się właśnie za analizę cgroups. Wywaliłem wszystko co było związane z cgroups z systemu:
cgroupfs-mount purge libcgroup1 purge cgmanager purge libcgmanager0 purge cgroup-tools purge
I aktualnie nie mam w nim żadnych pakietów od cgroups. Do tego też poczyściłem skrypty startowe z sysvinit i po resecie cgroups wygląda tak:
# cat /proc/`pidof qbittorrent-nox`/cgroup 9:cpuset:/ 8:devices:/system.slice/qbittorrent-nox.service 7:blkio:/ 6:memory:/ 5:perf_event:/ 4:cpu,cpuacct:/ 3:net_cls,net_prio:/ 2:freezer:/ 1:name=systemd:/system.slice/qbittorrent-nox.service # cat /proc/cgroups #subsys_name hierarchy num_cgroups enabled cpuset 9 1 1 cpu 4 1 1 cpuacct 4 1 1 memory 6 1 1 devices 8 81 1 freezer 2 1 1 net_cls 3 1 1 blkio 7 1 1 perf_event 5 1 1 net_prio 3 1 1 # ls -al /sys/fs/cgroup/ total 0 drwxr-xr-x 11 root root 300 2015-02-10 04:16:14 ./ drwxr-xr-x 8 root root 0 2015-02-10 04:15:58 ../ dr-xr-xr-x 2 root root 0 2015-02-10 04:16:14 blkio/ dr-xr-xr-x 2 root root 0 2015-02-10 04:16:14 cpu,cpuacct/ dr-xr-xr-x 2 root root 0 2015-02-10 04:16:14 cpuset/ dr-xr-xr-x 4 root root 0 2015-02-10 04:16:14 devices/ dr-xr-xr-x 2 root root 0 2015-02-10 04:16:14 freezer/ dr-xr-xr-x 2 root root 0 2015-02-10 04:16:14 memory/ dr-xr-xr-x 2 root root 0 2015-02-10 04:16:14 net_cls,net_prio/ dr-xr-xr-x 2 root root 0 2015-02-10 04:16:14 perf_event/ dr-xr-xr-x 4 root root 0 2015-02-10 04:16:14 systemd/ lrwxrwxrwx 1 root root 11 2015-02-10 04:16:14 cpu -> cpu,cpuacct/ lrwxrwxrwx 1 root root 11 2015-02-10 04:16:14 cpuacct -> cpu,cpuacct/ lrwxrwxrwx 1 root root 16 2015-02-10 04:16:14 net_cls -> net_cls,net_prio/ lrwxrwxrwx 1 root root 16 2015-02-10 04:16:14 net_prio -> net_cls,net_prio/
To jakie kontrolery są widoczne można dostosować via plik /etc/systemd/system.conf :
[Manager] ... DefaultControllers= JoinControllers=cpu,cpuacct net_cls,net_prio ...
Z tego co wyczytałem to: DefaultControllers= staje się powoli przestarzały i lepiej go już nie używać. Jeśli potrzebujemy współdzielonych kontrolerów, łączymy je w JoinControllers= i tu można połączyć sobie dosłownie wszystko. Domyślnie są połączone te 4 powyżej.
Systemd daje kilka narzędzi do wyciągania info o procesach pod kontrolą cgroups. Pierwsze z nich to ps z obsługą cgroups (dobrze jest sobie zrobić alias):
alias psc='ps xawf -eo pid,user,cgroup,args'
Dalej mamy natywne narzędzie systemd-cgls , które to listuje drzewo procesów w cgroups. I ostatnie narzędzie, na które się natknąłem to systemd-cgtop — to taki top tyle, że pokazuje wykorzystanie zasobów przez procesy w cgroups:
# systemd-cgtop Path Tasks %CPU Memory Input/s Output/s / 181 22.8 1.4G 126.9K 0B /system.slice/accounts-daemon.service 1 - - - - /system.slice/atd.service 1 - - - - /system.slice/cron.service 1 - - - - /system.slice/dbus.service 1 - - - - /system.slice/dnscrypt-proxy.service 1 - - - - /system.slice/exim4.service 1 - - - - /system.slice/hddtemp.service 1 - - - - /system.slice/ifplugd.service 1 - - - - /system.slice/lightdm.service 2 - - - - /system.slice/monitorix.service 2 - - - - /system.slice/networking.service 2 - - - - /system.slice/nfs-common.service 2 - - - - /system.slice/polkitd.service 1 - - - - /system.slice/qbittorrent-nox.service 1 - - - - /system.slice/rpcbind.service 1 - - - - /system.slice/rsyslog.service 1 - - - - /system.slice/rtkit-daemon.service 1 - - - - /system.slice/smartd.service 1 - - - - /system.slice/system-getty.slice/getty@tty1.service 1 - - - - /system.slice/systemd-journald.service 1 - - - - /system.slice/systemd-logind.service 1 - - - - /system.slice/systemd-timesyncd.service 1 - - - - /system.slice/systemd-udevd.service 1 - - - - /system.slice/upower.service 1 - - - - /system.slice/vnstat.service 1 - - - - /user.slice/user-1000.slice/session-1.scope 62 - - - - ^C
Aktualnie tam nic nie ma jeszcze — brak cyferek.
By przypisać procesy do grup, trzeba dopisać kilka parametrów do plików unitów. I tu jest drobny problem, bo był jakiś zgrzyt — http://lwn.net/Articles/555923/ i szereg opcji i przełączników szlag trafił — http://lwn.net/Articles/557486/ . W każdym razie czytając dokumentację i różne wiki, wychodzi na to, że standardowo w plikach unitów, można dodawać póki co poniższe kontrolery cgroups: CPUShares= , MemoryLimit= , BlockIOWeight= , BlockIODeviceWeight= , BlockIOReadBandwidth= , czyli zarządzać limitami cpu, pamięci i transferem dysku. Są to wysokopoziomowe opcje konfiguracyjne dla cgroups. Są też i niskopoziomowe, z tym, że zgodnie z tymi linkami, już się ich nie stosuje, a jeśli chodzi o te wysokopoziomowe, to będą rozbudowywane tak by móc precyzować więcej opcji w unitach, bo póki co to dostępnych jest tylko 5.
Inna istotna uwaga jeszcze — jeśli włączamy kontrolery dla jakiejś usługi i ta usługa jest w jakimś .slice i dodatkowo w tym slice są inne usług, część z tych kontrolerów zostanie włączona automatycznie dla pozostałych usług w tym slice. Co jest logiczne, no bo jak inaczej wydzielić np. pamięć jeśli nie przez podział w danym .slice? Dzięki czemu ta usługa dostanie tyle zasobów,a pozostałe będą traktowane na równi.
Przeprowadzę zatem mały test i za królika będzie robić nam qbittorrent — ustawimy mu 3 z powyższych 5 kontrolerów (dokładnie są one opisane tutaj: http://www.freedesktop.org/software/systemd/man/systemd.cgroup.html), tak by mu ograniczyć zasoby.
Do pliku unitu dopisujemy zatem poniższe linijki:
[Service] ... CPUShares=256 MemoryLimit=50M BlockIOWeight=128 ...
Jeśli teraz zrestartujemy qbittorrenta i zajrzymy w systemd-cgtop to ujrzymy coś takiego:
Path Tasks %CPU Memory Input/s Output/s / 153 24.2 1.6G 124.5K 0B /system.slice - 5.2 78.3M - - /system.slice/qbittorrent-nox.service 1 2.9 49.9M 498.4K 0B /system.slice/lightdm.service 2 2.3 27.0M - - /system.slice/hddtemp.service 1 0.0 - - - /system.slice/monitorix.service 2 0.0 1.2M - - /system.slice/ifplugd.service 1 0.0 - - - /system.slice/accounts-daemon.service 1 - - - - ...
...
Jak widać, pojawiły się cyferki (mogli by też jakieś bardziej cywilizowane narzędzie wymyśleć xD).
Zmienił się także opis procesu:
# cat /proc/`pidof qbittorrent-nox`/cgroup 9:cpuset:/ 8:memory:/system.slice/qbittorrent-nox.service 7:perf_event:/ 6:blkio:/system.slice/qbittorrent-nox.service 5:cpu,cpuacct:/system.slice/qbittorrent-nox.service 4:net_cls,net_prio:/ 3:devices:/system.slice/qbittorrent-nox.service 2:freezer:/ 1:name=systemd:/system.slice/qbittorrent-nox.service
Usługa qbittorrenta została dopisana do memory, blkio oraz do cpu. Możemy także podejrzeć pliki cgroups by sprawdzić czy wartości są takie jak mają być. Dla powyższych 3 kontrolerów to będzie:
# cat /sys/fs/cgroup/cpu/system.slice/qbittorrent-nox.service/cpu.shares 256 # cat /sys/fs/cgroup/memory/system.slice/qbittorrent-nox.service/memory.limit_in_bytes 52428800 # cat /sys/fs/cgroup/blkio/system.slice/qbittorrent-nox.service/blkio.weight 128
Zatem wszystko zostało ładnie ustawione.
Domyślnie jest tylko kilka slice'ów (system.slice, machine.slice, user.slice) w których są grupowane usługi. Chodzi o to, że każdemu slice'owi można przyporządkować konkretne zasoby i np. jeśli wziąć pod uwagę tylko te trzy powyższe, można rozdzielić zasoby na system, maszyny wirtualne oraz użytkowników (wszystkich).
Co w przypadku gdy chce bardziej wymyślnie pokroić sobie system? Ja wiem, zamiast wrzucać qbittorrenta (i inne usługi p2p) do system.slice, to można by dla nich stworzyć osobny slice p2p (może być i podgrupą system.slice), po czym określić dla tego slice odpowiednie zasoby i wrzucić do niego usługi p2p.
By coś takiego zrobić, musimy stworzyć nowy plik p2p.slice i dodać do niego poniższą zawartość:
[Unit] Description=P2P Slice Documentation=http://www.freedesktop.org/software/systemd/man/systemd.cgroup.html DefaultDependencies=no Before=slices.target [Slice] CPUShares=1024 MemoryLimit=256M BlockIOWeight=512
Został w ten sposób wydzielony kawałek zasobów pod usługi p2p:
# cat /sys/fs/cgroup/memory/p2p.slice/memory.limit_in_bytes 268435456 # cat /sys/fs/cgroup/cpu/p2p.slice/cpu.shares 1024 # cat /sys/fs/cgroup/blkio/p2p.slice/blkio.weight 512
Do tego trzeba odpowiednio zmienić plik unitu qbittorrenta:
[Service] ... CPUShares=256 MemoryLimit=50M BlockIOWeight=128 Slice=p2p.slice
Generalnie to różni się tylko opcją slice= , która przeniesie qbitorrenta z system.slice do p2p.slice i od tej chwili qbittorrent będzie widoczny w drzewie cgroups pod ścieżką: /sys/fs/cgroup/memory/p2p.slice/qbittorrent-nox.service/ i podobnie dla pozostałych zasobów.
Jak człowiek sobie porówna te dwa wycinki z określaniem zasobów, to wie, że wewnątrz p2p.slice, qbittorrent ma do wykorzystania 1/4 procka przydzielonego do p2p.slice, 50M z 256M ramu i 1/4 przepustowości dysku z przydzielonej połowy dla tego p2p.slice. Mam nadzieję, że to tak działa. xD
To działa wyśmienicie jeśli chodzi o daemony systemowe, problem jest z procesami użytkownika, bo te są pakowane wszystkie do jednego user.slice, choć są podzielone w zależności od userów. Niemniej jednak, nie mam pojęcia jak zarządzać tymi procesami i dać np. 300M ramu na firefoxa, być może się nie da tego zrobić w taki sposób i te cgroups systemd są jedynie dla daemonów systemowych/użytkownika, a same procesy użytkownika trzeba ogarnąć w inny sposób, np przez zwykły skrypt sh, który będzie odpowiednio tworzył i uzupełniał konkretne pliki w drzewie cgroups.
Nasuwa się też pytanie co z pozostałymi parametrami, no bo w końcu można ustawić jedynie 5, a plików w cgroups jest o wiele więcej. Wcześniej przed tym zgrzytem można to było zrobić via ControlGroupAttribute= ale z tego już nie ma. Póki co jeszcze nie doszukałem się jak to teraz się robi bo co by nie mówić, dokumentacja trochę jest out of date jesli chodzi o te cgroups ale może to wkrótce wyjaśnię,
EDIT:
Tu jeszcze takie coś znalazłem:
Note that the number of cgroup attributes currently exposed as unit properties is limited. This will be extended later on, as their kernel interfaces are cleaned up. For example cpuset or freezer are currently not exposed at all due to the broken inheritance semantics of the kernel logic. Also, migrating units to a different slice at runtime is not supported (i.e. altering the Slice= property for running units) as the kernel currently lacks atomic cgroup subtree moves.[/quote]
No i jest możliwość zmiany parametrów cgroups bez resetowania unitów:Kod:
# systemctl set-property httpd.service CPUShares=500 MemoryLimit=500MOstatnio edytowany przez morfik (2015-02-10 08:17:27)
Offline
Wcześniej pisałem o różnych sposobach na edycję plików unitów i w końcu ustaliłem jak to powinno się robić poprawnie.
Są dwa narzędzia:
# systemctl edit # systemctl cat
Pierwsze z nich edytuje plik usługi i to bez potrzeby jakiegokolwiek kopiowania i wpisywania ścieżek typu /lib/systemd/system/ albo etc/systemd/system/ . Jeśli mamy do zmiany jakiś unit systemowy to dajemy tylko systemctl edit , poniżej przykład z życia:
# systemctl edit plymouth-quit.service
Otworzy to pustą kartkę w edytorze zdefiniowanym w zmiennej $EDITOR .
Wrzucamy tam to co chcemy zmienić, w tym przypadku jest to linijka z exec, a ta siedzi w sekcji Service — sekcję trzeba przepisać:
[Service] ExecStart= ExecStart=-/bin/plymouth quit --retain-splash
Generalnie zachowuje się to tak jak zmienne — pierwsza linijka z exec czyści, druga ustawia. Jeśli ten drugi exec nie zostałby poprzedzony tym pierwszym, wtedy zostałby dodany do unitu, a tego nie zawsze chcemy. Jako, że tutaj chcemy nadpisać exec, trzeba go wyczyścić i jeśli w pliku unita by było więcej linijek z exec, to wszystkie zostaną wyczyszczone.
Po dokonaniu edycji, zapisaniu i wyjściu z edytora, systemd automatycznie przeładuje wszystko i usługę będzie można zresetować bez dodatkowych ingerencji ze strony użytkownika.
Zanim jednak się zresetuje usługę dobrze jest podejrzeć co się w niej zmieniło — do tego celu służy drugie z poleceń:
# systemctl cat plymouth-quit.service # /lib/systemd/system/plymouth-quit.service [Unit] Description=Terminate Plymouth Boot Screen After=rc-local.service plymouth-start.service systemd-user-sessions.service [Service] ExecStart=-/bin/plymouth quit Type=oneshot TimeoutSec=20 # /etc/systemd/system/plymouth-quit.service.d/override.conf [Service] ExecStart= ExecStart=-/bin/plymouth quit --retain-splash
I jak widać, zostały wypisane oba pliki — ten systemowy oraz nasze zmiany. To ma tę zaletę, że w przypadku gdy aktualizujemy jakiś pakiet i plik unitu ulegnie zmianie, nowe linijki zostaną automatycznie uwzględnione i nie trzeba będzie robić delty i patrzyć czy coś w jakichś unitach uległo zmianie — przykład:
# systemd-delta [EXTENDED] /lib/systemd/system/plymouth-quit.service → /etc/systemd/system/plymouth-quit.service.d/override.conf
Żadne zmiany nie zostały wyszczególnione.
Inna sprawa to sprawdzenie usługi po jej restarcie:
root:~# systemctl status plymouth-quit.service
● plymouth-quit.service - Terminate Plymouth Boot Screen
Loaded: loaded (/lib/systemd/system/plymouth-quit.service; static; vendor preset: enabled)
[b]Drop-In:[/b] /etc/systemd/system/[b]plymouth-quit.service.d[/b]
└─[b]override.conf[/b]
Active: inactive (dead) since Tue 2015-02-10 12:02:27 CET; 1min 58s ago
Process: 1914 ExecStart=/bin/plymouth quit --retain-splash (code=exited, status=0/SUCCESS)
Main PID: 1914 (code=exited, status=0/SUCCESS)[/quote]
Jak widać, został utworzony plik override.conf w katalogu /etc/systemd/system/plymouth-quit.service.d/ i to on nadpisuje konfigurację.
Jeśli zmian faktycznie by było dużo i zdecydowalibyśmy się na skopiowanie unitu, wtedy również korzystamy z systemctl edit ale z opcją full, przykładowo:Kod:
# systemctl edit --full plymouth-quit.serviceSpowoduje to skopiowanie zawartości unitu i przy zapisie, plik powędruje do katalogu /etc/systemd/system/
Offline
Pamiętacie OOM-killera? To taki bezpiecznik, który ma czuwać nad procesami i ubijać te, które doprowadzają do wyczerpania się pamięci w przypadku gdy nie używa się SWAPa — przynajmniej takie jest domyślne działanie tego mechanizmu. Pod tymi linkami jest trochę info na temat tego jak ręcznie i przy pomocy cgroups sterować takim OMM-killerem — http://lwn.net/Articles/317814/ , http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html .
W systemd, w opcjach unitów, jest jednak taki parametr:
Sets the adjustment level for the Out-Of-Memory killer for executed processes. Takes an integer between -1000 (to disable OOM killing for this process) and 1000 (to make killing of this process under memory pressure very likely). See proc.txt for details.
[b]OOMScoreAdjust=[/b][/quote]
W skrócie, jeśli nie chcemy aby jakiś demon systemowy był ubijany z racji zjadania zbyt dużej ilości pamięci, można mu obniżyć wartość tego parametru do -1000, choć ja tam nie radzę, lepiej zostawić na poziomie -800, wtedy wszystko inne będzie ubijane, a jak i to nie pomoże odciążyć pamięci, to wtedy i ten proces zostanie zabity.
Dla przykładu wziąłem sobie dnscrypt-proxy i dopisałem do niego:Kod:
root:/etc/systemd/system# cat dnscrypt-proxy.service.d/oom.conf [Service] OOMScoreAdjust=-500Poniżej są wartości jakie zostały ustawione w /proc/`pidof dnscrypt-proxy`/oom_* po zresetowaniu usługi:
Kod:
/proc/55232/oom_adj -8 /proc/55232/oom_score 0 /proc/55232/oom_score_adj -500Niedługo te moje unity będą przypominać długością skrypty sysvinit. xD
Dobrze jest też rzucić okiem na te poniższe opcje kernela:Kod:
vm.overcommit_memory = 0 vm.oom_kill_allocating_task = 0 vm.oom_dump_tasks = 1 vm.panic_on_oom = 0Ostatnio edytowany przez morfik (2015-02-12 07:15:44)
Offline
Wcześniej wspominałem coś o tworzeniu plików tymczasowych przez systemd przy pomocy mechanizmu tmpfiles . Okazuje się, że jest jeszcze jedna ciekawa rzecz, o której warto wspomnieć -- chodzi o automatyczne czyszczenie określonych katalogów/plików tymczasowych.
Ja u siebie mam poniższą konfigurację plików tymczasowych:
# Type | Path | Mode | UID | GID | Age | Argument D /tmp/morfik_cache/ 0700 morfik morfik - - D /tmp/morfik_cache/.kde/ 0700 morfik morfik - - D /tmp/morfik_cache/.kde/share/apps/amarok/albumcovers/cache/ 0700 morfik morfik 6h - D /tmp/morfik_cache/.cache/ 0700 morfik morfik - - D /tmp/morfik_cache/.cache/mozilla/firefox/ 0700 morfik morfik 6h - D /tmp/morfik_cache/.macromedia/ 0700 morfik morfik 6h - D /tmp/morfik_cache/build 0700 morfik morfik 6h - L+ /home/morfik/.kde/share/apps/amarok/albumcovers/cache/ - morfik morfik - /tmp/morfik_cache/.kde/share/apps/amarok/albumcovers/cache/ L+ /home/morfik/.cache/ - morfik morfik - /tmp/morfik_cache/.cache/ L+ /home/morfik/.macromedia/ - morfik morfik - /tmp/morfik_cache/.macromedia/
W skrócie, na starcie systemu jest tworzonych szereg plików w katalogu /tmp/ i do nich są robione dowiązania z katalogu /home/morfik/ -- chodzi o podlinkowanie cache, który czasem się rozrasta w nieskończoność.
Jeśli się przyjrzeć, niektóre pozycje mają podany argument Age -- w tym przypadku 6h. W chwili wywoływania systemd-tmpfiles-clean.timer , sprawdzane są daty plików w tych katalogach i jeśli są starsze niż 6h, pliki są usuwane.
Problem w tym, że domyślnie oczyszczenie jest przeprowadzane co 24h i po 15min od startu systemu:
# systemctl cat systemd-tmpfiles-clean.timer # /lib/systemd/system/systemd-tmpfiles-clean.timer # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Daily Cleanup of Temporary Directories Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) [Timer] OnBootSec=15min OnUnitActiveSec=1d
Jeśli to oczyszczenie ma się dokonywać po 6h, trzeba przestawić zegar na np. 1h:
OnUnitActiveSec=1h
I teraz czyszczenie powinno przebiegać o wiele sprawniej.
Ostatnio edytowany przez morfik (2015-02-18 09:50:24)
Offline
Wziąłem się w końcu za przeniesienie sieci z /etc/init.d/networking na natywne rozwiązania systemd. Pierwsza sprawa to taka, że te wszystkie ifup/down odchodzą w niepamięć. Dodatkowo pozbyłem się z systemu ifenslave i ifplugd — to już realizuje sam systemd. Kolejna rzecz, to używanie iproute2 zamiast tych wszystkich innych przestarzałych narzędzi, jak np. ifconfig.
Ja mam dość skomplikowane rozwiązanie sieciowe, w skład którego wchodzi łącze przewodowe, wifi, bonding między tymi dwoma, kilka interfejsów bezprzewodowych, kontenery lxc + bridge. Na dobrą sprawę, w /etc/network/interfaces miałem szereg bloków konfiguracyjnych do oganiania tego wszystkiego i się tak zastanawiałem czy da radę przenieść to wszystko do systemd, bo póki co ciągle jechałem na tym skrypcie sysvinit.
Poszukałem trochę info i co nieco pokombinowałem — wszystko odbywa się w sumie w oparciu o 3 pliki i na dobrą sprawę tylko z dwóch z nich przyszło mi skorzystać póki co. Są to .netdev oraz .network . Ten pierwszy odpowiada za tworzenie wirtualnych urządzeń, np. bridge, bond, veth, czy tun/tap i tam jeszcze całą masę innych — dokładna lista jest tutaj: http://www.freedesktop.org/software/systemd/man/systemd.netdev.html . Każde z takich urządzeń przyjmuje określone parametry ale o tym później. Ten drugi typ pliku określa konfigurację dla samych urządzeń, tych które wykryje udev albo te, które sami stworzymy.
Przejście ze starego skryptu init rozpoczynamy od:
# systemctl disable networking.service # systemctl enable systemd-networkd.socket # systemctl enable systemd-networkd.service
Na sam początek coś prostego — konfiguracja interfejsu lo. Tworzymy najpierw plik w /etc/systemd/network , np. 10-lo.network — sam interfejs lo już istnieje w systemie, więc nie ma po co go tworzyć:
[Match] Name=lo [Network] Description=Loopback DHCP=no LinkLocalAddressing=no Address=127.0.0.1/8 Address=::1/128
Tam gdzie jest sekcja Match definiujemy dopasowania dla interfejsu, a tu generalnie można sprecyzować wiele rzeczy ale to też zależy od konkretnego interfejsu. Opcje można wyciągnąć przez:
udevadm info /sys/class/net/interfejs
Najprościej jest dopasowywać po nazwie, sterowniku czy adresie mac urządzenia. W tym przypadku starczy sam lo.
W sekcji Network określa się opcje dla tego dopasowania. Jako, że jest to pętla zwrotna, to nie potrzebny nam tutaj DHCP ani żadna zaawansowana konfiguracja, jedynie co to przydzielamy klasę adresów 127.0.0.1/8 (dla ipv4) oraz ::1/128 (dla ipv6).
U mnie w wyposażeniu jest jeszcze interfejs eth1 i tu już trochę więcej jest do zrobienia. Podobnie jak w przypadku lo, nie trzeba go tworzyć, zatem potrzebny jest nam plik, np. 50-eth1-dhcp.network i jak można się domyśleć, będzie to konfiguracja dhcp dla tego interfejsu:
[Match] # See: udevadm info /sys/class/net/eth1 MACAddress=3c:4a:92:00:4c:5b Driver=r8169 Name=eth1 [Network] Description=Home network # Accepts "yes", "no", "ipv4", or "ipv6". DHCP=ipv4 # Enables link-local address autoconfiguration. Accepts "yes", "no", "ipv4", or "ipv6". Defaults # to "ipv6". LinkLocalAddressing=no # A static IPv4 or IPv6 address and its prefix length, separated by a "/" character. Specify this # key more than once to configure several addresses. #Address=192.168.1.150/24 #Gateway=192.168.1.1 DNS=127.0.2.1 #Domains= #NTP= # Takes either a boolean argument, or the values "ipv4" or "ipv6", which only enables IP forwarding # for the specified address family. IPForward=true #Bridge= #Bond= [DHCP] UseDNS=false UseMTU=false SendHostname=true UseHostname=false UseDomains=true UseRoutes=true CriticalConnection=true RequestBroadcast=true #RouteMetric= #[Address] #Address=192.168.1.150 #Broadcast=192.168.1.255 #Label= #[Route] #Gateway=192.168.1.1 #Destination=192.168.1.0/24 #Metric= #Scope=
Wynotowałem sobie trochę więcej rzeczy niż zwykle ludzie tam wrzucają — bo tutaj wystarczy tylko podać w sekcji Network parametr DHCP=ipv4 i wszystko się samo skonfiguruje.
Jedziemy zatem od góry. Mamy tam dopasowanie na podstawie adresu mac + nazwy interfejsu + rodzaju sterownika i tylko do takiego urządzenia zostanie zaaplikowana ta konfiguracja. Sekcje Address i Route są na wypadek definiowania bardziej szczegółowych informacji dotyczących konfiguracji adresów. Jeśli mamy zamiar zdefiniować szereg adresów dla danego interfejsu, dodajemy kolejne pola Address w sekcji Network.
Samo DHCP można ustawić na tylko ipv4 lub ipv6 lub oba z nich, ewentualnie można wyłączyć je całkowicie i korzystać z konfiguracji statycznej, a do tego potrzebny jest adres i brama. Można tam także określić statyczny DNS, Jeśli chcemy korzystać z mostu, trzeba na tym interfejsie oraz interfejsie bridge ustawić IPForward — to zmienia opcję kernela dla tego interfejsu net.ipv4.conf.eth1.forwarding z 0 na 1. Jest też inna opcja — IPMasquerade ale kompletnie nie wiem jak to działa i musiałem na zaporze ustawić wszystko by pakiety przeszły z kontenerów.
Dalej jest Bridge i Bond, które to określają urządzenia, do których jest podpięty ten interfejs.
W sekcji DHCP można określić kilka parametrów co do pozyskiwania lease z serwera dhcp. Raczej powinny być zrozumiałe.
To może teraz dodajmy jakiś mostek i tu trzeba stworzyć pierw plik .netdev, np. 20-br_lxc.netdev :
[NetDev] Description=Bridge for LXC containers Name=br_lxc Kind=bridge #MACAddress=
Na dobrą sprawę, określamy jedynie nazwę urządzenia oraz jego rodzaj. Można także określić mu adres MAC.
No i konfigurujemy to urządzenie (plik .network) tak jak te wyżej:
[Match] Name=br_lxc [Network] Description=LXC bridge configuration DHCP=no LinkLocalAddressing=no Address=192.168.10.100/24 #Gateway=192.168.1.1 DNS=192.168.1.1 IPForward=true
Podobnie postępujemy w przypadku z pozostałymi rodzajami urządzeń, np. bond może wyglądać tak:
[NetDev] Description=Bonding interface Name=bond0 Kind=bond #MACAddress= [Bond] # Possible values are "balance-rr", "active-backup", "balance-xor", "broadcast", "802.3ad", # "balance-tlb", and "balance-alb". Mode=active-backup MIIMonitorSec=200 UpDelaySec=1000 DownDelaySec=1000
Z tym, że tutaj jest osobna sekcja Bond — różne interfejsy mają różne opcje.
No i konfiguracja (plik .network):
[Match] Name=bond0 [Network] Description=Bonded network DHCP=ipv4 LinkLocalAddressing=no DNS=127.0.2.1 IPForward=true [DHCP] UseDNS=false UseMTU=false SendHostname=true UseHostname=false UseDomains=true UseRoutes=true CriticalConnection=true RequestBroadcast=true #RouteMetric=
i jeszcze konfiguracja dla slave:
[Match] MACAddress=3c:4a:92:00:4c:5b Driver=r8169 Name=eth1 [Network] Description=Bonded eth1 Bond=bond0
Z tym, że tutaj coś mało opcji jest w tym bondingu.
Jeśli chodzi o same interfejsy kontenerów, to raczej nie trzeba nic robić. Ja jednak dorobiłem im taki wpis:
[Match] Driver=veth Name=veth* [Network] Description=Virtual interfaces Configuration Bridge=br_lxc
Czyli, wszystkie interfejsy zaczynające się od veth zostaną przypisane do mostka br_lxc .
Nazwy plików są dowolne, z tym, że trzeba wziąć pod uwagę, że czytane są w odpowiedniej kolejności I dobrze jest sobie tam dodać numerki by nie było żadnych problemów.
Jest też dedykowane narzędzie do podglądania konfiguracji — networkctl . U mnie po skonfigurowaniu interfejsów wygląda to tak:
[img]http://i.imgur.com/h9USXQB.png[/img]
Teraz już tylko zostało do ogarnięcia szereg poleceń z iproute tak by czyścić i resetować interfejsy, no i trzeba jeszcze skonfigurować wifi ale to później. xD
Ostatnio edytowany przez morfik (2015-02-27 14:24:40)
Offline
Ostatnio na forum przewinęło się kilka wątków dotyczących definiowania wielu adresów IP na jednym interfejsie. Poniżej znajduje się krótkie info na temat tego jak skonfigurować taki interfejs w systemd.
Zakładając, że mamy już wstępnie skonfigurowany (działający) interfejs sieciowy, dodajemy mu kolejną linijkę w sekcji Network, która zawiera adres IP, który chcemy dodać, przykładowo:
[Match] Name=bond0 [Network] Description=Bonded network DHCP=ipv4 LinkLocalAddressing=no DNS=127.0.2.1 IPForward=true Address=192.168.1.200 Address=192.168.1.201 Address=192.168.1.202 Address=192.168.1.203 Address=192.168.1.204 [DHCP] UseDNS=false UseMTU=false SendHostname=true UseHostname=false UseDomains=true UseRoutes=true CriticalConnection=true RequestBroadcast=true #RouteMetric=
Jak widać wyżej, zostało podanych 5 statycznych adresów, do tego dochodzi jeszcze jeden -- ten z konfiguracji DHCP, zatem sam interfejs posiada w tej chwili 6 adresów IP:
root:/etc/systemd/network# ip route show default via 192.168.1.1 dev bond0 proto dhcp src 192.168.1.150 metric 1024 192.168.1.0/24 dev bond0 proto kernel scope link src 192.168.1.200 192.168.1.1 dev bond0 proto dhcp scope link src 192.168.1.150 metric 1024 192.168.10.0/24 dev br_lxc proto kernel scope link src 192.168.10.100 root:/etc/systemd/network# ip addr show bond0 7: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 3c:4a:92:00:4c:5b brd ff:ff:ff:ff:ff:ff inet 192.168.1.200/24 brd 192.168.1.255 scope global bond0 valid_lft forever preferred_lft forever inet 192.168.1.201/24 brd 192.168.1.255 scope global secondary bond0 valid_lft forever preferred_lft forever inet 192.168.1.202/24 brd 192.168.1.255 scope global secondary bond0 valid_lft forever preferred_lft forever inet 192.168.1.203/24 brd 192.168.1.255 scope global secondary bond0 valid_lft forever preferred_lft forever inet 192.168.1.204/24 brd 192.168.1.255 scope global secondary bond0 valid_lft forever preferred_lft forever inet 192.168.1.150/24 brd 192.168.1.255 scope global secondary bond0 valid_lft forever preferred_lft forever root:/etc/systemd/network# networkctl status bond0 ● 7: bond0 Link File: n/a Network File: /etc/systemd/network/50-bond0-dhcp.network Type: ether State: routable (configured) Driver: bonding HW Address: 3c:4a:92:00:4c:5b (Hewlett-Packard Company) MTU: 1500 Address: 192.168.1.150 192.168.1.200 192.168.1.201 192.168.1.202 192.168.1.203 192.168.1.204 Gateway: 192.168.1.1 (TP-LINK TECHNOLOGIES CO.,LTD) DNS: 127.0.2.1 Domain: mhouse.lh
A poniżej ping z innej maszyny:
root@the-mountain:~# ping 192.168.1.200 PING 192.168.1.200 (192.168.1.200): 56 data bytes 64 bytes from 192.168.1.200: seq=0 ttl=64 time=0.679 ms 64 bytes from 192.168.1.200: seq=1 ttl=64 time=0.352 ms 64 bytes from 192.168.1.200: seq=2 ttl=64 time=0.349 ms ^C --- 192.168.1.200 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.349/0.460/0.679 ms root@the-mountain:~# ping 192.168.1.150 PING 192.168.1.150 (192.168.1.150): 56 data bytes 64 bytes from 192.168.1.150: seq=0 ttl=64 time=0.443 ms 64 bytes from 192.168.1.150: seq=1 ttl=64 time=0.420 ms 64 bytes from 192.168.1.150: seq=2 ttl=64 time=0.309 ms ^C --- 192.168.1.150 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.309/0.390/0.443 ms root@the-mountain:~# ping 192.168.1.204 PING 192.168.1.204 (192.168.1.204): 56 data bytes 64 bytes from 192.168.1.204: seq=0 ttl=64 time=0.505 ms 64 bytes from 192.168.1.204: seq=1 ttl=64 time=0.328 ms 64 bytes from 192.168.1.204: seq=2 ttl=64 time=0.341 ms ^C --- 192.168.1.204 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.328/0.391/0.505 ms
Jak widać, wszystko chyba działa jak trzeba.
Offline
@up
Czyli można by mieć na jednej karcie serwer dhcp oraz żeby ta karta brała z niego ip?
Offline
W manie są dwa parametry dotyczące DHCP:
DHCP=
Enables DHCPv4 and/or DHCPv6 support. Accepts "yes", "no", "ipv4", or "ipv6".
DHCPServer=
A boolean. Enables a basic DHCPv4 server on the device. Mostly useful for handing out leases to container instances.[/quote]
Czy ten DHCPServer można zastosować do normalnych maszyn to nie wiem, trzeba by sprawdzić. xD
Offline
1682
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:12:15)
Offline
Z tego co tutaj zauważyłem, to systemd jedynie ma małego demona, który w oparciu o te polecenia z iproute2 ustawia te interfejsy -- na dobrą sprawę, to nie wiem jak zresetować ustawienia interfejsu przy pomocy tych narzędzi od systemd. xD Póki co robię to ręcznie przez:
ip addr flush bond0 systemctl restart systemd-networkd
Jeśli bym nie wydał tego pierwszego polecenia, nowe adresy zostaną dopisane do tego interfejsu. Także ten demon jedynie czyta pliki w /etc/systemd/network i ustawia konfigurację, zwykle przydatne na starcie systemu.
Zatem sama konfiguracja dla tego demona raczej nie powinna bruździć zbytnio i jeśli robi się coś bardziej zaawansowanego, trzeba by pewnie zrobić parę plików *.service i tam wykorzystać te polecenia z "ip *" i uzyskać już wtedy dowolną konfigurację dla sieci. Jakby nie patrzeć, ten demon nie jest jakiś wypasiony, póki co. xD
Offline
Pamiętacie te śmieszne numerki interfejsów, coś na wzór enp2s0 ? By te interfejsy miały postać eth0, eth1 i temu podobne, w debianie udev przepisuje je przy pomocy pliku /etc/udev/rules.d/70-persistent-net.rules , który wygląda mniej więcej tak:
# cat 70-persistent-net.rules # PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1e.0/0000:03:02.0 (8139too) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:75:03:09", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x10ec:0x8136 (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="3c:4a:92:00:4c:5b", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" # PCI device 0x14e4:0x4727 (brcmsmac) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c0:cb:38:01:f0:f5", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
Za każdym razem gdy w systemie pojawia się nowa karta sieciowa, jest tam dodawany nowy wpis i nazwa karty jest przpeisywana. Nie wiem czy to jest standardowe zachowanie debiana, czy ktoś obmyślił taki mechanizm w upstreamie, w każdym razie na wiki archa można wyczytać, że u nich te nazwy nie są automatycznie przepisywane i trzeba dopisywać parametr:
net.ifnames=0
do linijki kernela, by włączyć ten standardowy system nazw oparty o eth, wlan, itp.
W debianie ten parametr również działa, z tym, że trzeba go ustawić na net.ifnames=1 by przywrócić te śmieszne nazwy typu enp2s0 . Nie mam pojęcia jak będą te nazwy wyglądać w przyszłości ale dobrze jest wiedzieć, że systemd umożliwia zmianę tych nazw przy pomocy plików *.link .
Załóżmy zatem, że mamy w systemie interfejs enp2s0 i chcemy przepisać go do postaci eth1 -- inaczej niż przez manipulowanie powyższym parametrem kernela. Sprawdzamy więc jak wyglądają staty tego interfejsu:
# udevadm info /sys/class/net/enp2s0 P: /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0 E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0 E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=RTL8101E/RTL8102E PCI Express Fast Ethernet controller E: ID_MODEL_ID=0x8136 E: ID_NET_DRIVER=r8169 E: ID_NET_NAME_MAC=enx3c4a92004c5b E: ID_NET_NAME_PATH=enp2s0 E: ID_OUI_FROM_DATABASE=Hewlett-Packard Company E: ID_PATH=pci-0000:02:00.0 E: ID_PATH_TAG=pci-0000_02_00_0 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd. E: ID_VENDOR_ID=0x10ec E: IFINDEX=2 E: INTERFACE=enp2s0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/enp2s0 E: TAGS=:systemd: E: USEC_INITIALIZED=670463
I na podstawie tego logu, tworzymy sekcję MATCH w pliku, np. 05-eth1.link :
[Match] MACAddress=3c:4a:92:00:4c:5b Driver=r8169 OriginalName=enp2s0 Path=pci-0000:02:00.0
Adres MAC jest zapisany w ID_NET_NAME_MAC=enx3c4a92004c5b -- enx 3c 4a 92 00 4c 5b
Teraz konfigurujemy ten interfejs:
Description=New name for enp2s0 interface MACAddressPolicy=persistent #MACAddress= #MTUBytes= Name=eth1 BitsPerSecond=100M Duplex=full WakeOnLan=off
Jeśli się nad tym zastanowić, to otwiera to szereg możliwości przepisywania interfejsów w zależności od pewnych czynników i aplikowania różnych konfiguracji określonych w plikach *.network. Dokładnie jeszcze nie wiem co z tym zrobić ale mam kilka pomysłów, choć pewnie większość z nich jeszcze wykracza poza sferę systemd. xD
Ostatnio edytowany przez morfik (2015-02-27 16:54:20)
Offline
Właśnie udało mi się przenieść całą konfigurację sieci na systemd -- nawet nie było to takie skomplikowane, myślałem, że zajmie to dłużej. xD Generalnie rzecz biorąc, w tym poście skupię się tylko na samej konfiguracji wifi. bo to mi chyba tylko zostało do omówienia.
Jeśli chodzi o wifi, to troszeczkę inaczej się konfiguruje ten system (zwłaszcza mając zaprzęgnięty do roboty bonding). O większości w sumie już mówiłem -- standardowa konfiguracja dla interfejsu wifi wygląda tak (50-wlan0-dhcp.network):
[Match] # See: udevadm info /sys/class/net/wlan0 MACAddress=c0:cb:38:01:f0:f5 Type=wlan Driver=brcmsmac Name=wlan0 [Network] Description=Home wifi network DHCP=ipv4 LinkLocalAddressing=no DNS=127.0.2.1 #IPForward=true [DHCP] UseDNS=false UseMTU=false SendHostname=true UseHostname=false UseDomains=true UseRoutes=true CriticalConnection=true RequestBroadcast=true #RouteMetric=
Jedynie co, to dopasowanie uległo zmianie ale przy pomocy tylko tego pliku nie uda się nam zestawić połączenia z routerem -- potrzebna jest konfiguracja uwierzytelniania, a to, przynajmniej w tym przypadku, trzeba robić via wpa_supplicant. Samej konfiguracji wpa_supplicanta nie będę opisywał i zakładam, że konfiguracje sieci wifi są trzymane w /etc/wpa_supplicant/wpa_supplicant.conf .
Potrzebny jest nam plik unitu, z tym, że standardowo jest jeden dołączony do pakietu wpasupplicant ale nie działa, przynajmniej u mnie, xD Tak czy inaczej napisałem własny plik .service ( /etc/systemd/system/wpa_supplicant@.service) :
[Unit] Description=WPA supplicant (%i) After=systemd-networkd.service Requires=systemd-networkd.service Before=network-online.target ConditionPathIsSymbolicLink=/sys/class/net/%i [Service] Type=forking ExecStartPre=/sbin/ip link set %i up ExecStart=/sbin/wpa_supplicant -s -i %i -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplicant.conf -B -P /run/wpa_supplicant.%i.pid ExecStopPost=/sbin/ip addr flush %i ExecStopPost=/sbin/ip link set %i down Pidfile=/run/wpa_supplicant.%i.pid [Install] WantedBy=multi-user.target
W zależności od interfejsu można tę usługę włączyć via:
systemctl start /etc/systemd/system/wpa_supplicant@wlan0.service
Dodatkowo jest ona sprzęgnięta z systemd-networkd, dzięki czemu przy przeładowaniu samego systemd-networkd zresetuje się także połączenie wifi -- nie będzie trzeba tego robić osobno. No i oczywiście usługa odpala się przed podniesieniem sieci, dzięki czemu wszystko co wymaga do działania internetu nie zwróci błędu z powodu zbyt wolnego logowania się do sieci wifi. Jest także warunek obecności danego urządzenia w systemie -- w przeciwnym wypadku, usługa nie wystartuje.
Jeśli chodzi o sam bonding jeszcze, to trzeba określić mac urządzenia bond0 -- bo, w przypadku posiadania 2+ podpiętych do niego interfejsów, występuje problem z adresem MAC (to przezte brakujące parametry dla bondingu). By sobie z tym poradzić, trzeba skonfigurować sam interfejs bond i wdrukować mu na sztywno adres MAC (05-bond0.link):
[Match] Driver=bonding Name=bond0 [Link] Description=Fixed MAC address for bond0 MACAddress=3c:4a:92:00:4c:5b
I po resecie już wszystko powinno grać:
╭─[morfik@morfikownia] - [~] - [2015-02-27 21:18:49] ╰─[0] < > $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier configured 2 eth1 ether carrier configured 3 ifb0 ether degraded unmanaged 4 ifb1 ether degraded unmanaged 5 wlan0 wlan carrier configured 6 br_lxc ether routable configured 7 bond0 ether routable configured 9 veth10-sid ether degraded configured 8 links listed.
Co ciekawe, po tych wszystkich zabiegach, odzyskałem około 4-5s z czasu startu systemu. xD Obecnie jest to:
root:~# systemd-analyze Startup finished in 15.794s (kernel) + 20.563s (userspace) = 36.358s
Jak zejdę poniżej 20s w userspace, to będzie święto. xD
Ostatnio edytowany przez morfik (2015-02-28 20:09:19)
Offline
Startup finished in 15.794s (kernel) + 20.563s (userspace) = 36.358s
Współczuję w dalszym ciągu. :)
A co to jest?
Type=simple ExecStartPre=/sbin/ip link set %i up ExecStart=/sbin/wpa_supplicant -s -i %i -D nl80211,wext -q -c /etc/wpa_supplicant/wpa_supplicant.conf -O /run/wpa_supplicant ExecStopPost=/sbin/ip addr flush %i ExecStopPost=/sbin/ip link set %i down
To jest mega-pro-systemd, czy jakieś stolarskie narzędzia?
W ogóle nie rozumiem, czym się ludzie tak jarają z tym Systemd.
To chyba jakiś syndrom sztokholmski. xD
Offline
Startup finished in 1.521s (kernel) + 1.219s (userspace) = 2.740s
https://dl.dropboxusercontent.com/u/4118086/plot.svg
Jak zejdę poniżej 1s w userspace to będzie święto ;)
ps
sorki Morfik, ale musiałem xd
Offline
Już pisałem ale powtórzę ostatni raz — gdybym rozebrał swój system i wymienił przy tym szereg podzespołów, odpaliłby się on w 0,5s. xD Ja nie porównuje swojej maszyny z innymi, bo to jest śmieszne trochę — każdy system jest inny i ma co innego wgrane — czy tylko ja na to zwracam uwagę? Takiego systemu jak ja mam, to raczej nigdzie się nie spotka, w końcu większości z was wystarczą dwie linijki w plikach unitów, a jak widać po moich unitach, to jest troszeczkę bardziej rozbudowana konfiguracja i na dobrą sprawę nie interesują mnie wyniki systemów, które nic w sobie, poza samym initem, nie mają. xD
Te numerki co wrzucam co jakiś czas, to są staty mojej maszyny (i tylko mojej, mojej własnej xD) — jest tu z grubsza cały czas to samo oprogramowanie, no chyba, że coś wywalam jak w przypadku tego przejścia ze skryptu networking ale w dużej mierze system zostaje cały czas taki sam (+ takie same podzespoły) i dlatego porównując szereg wyników na przestrzeni konfiguracji tego samego systemu po przejściu z sysvinit na systemd można mieć obraz co tak naprawdę ssało w sysvinit, bo póki co to wywaliłem szereg rzeczy, które natywnie obsługuje systemd, funkcjonalność nie ucierpiała, a nawet się znacznie rozbudowała i system startuje o wiele szybciej i tu czytać uważnie — na początku było około 2:30 (sysvinit) na start systemu, teraz jest 36s , także prosiłbym o czytanie co się w tym wątku pisze, bo ręce opadają, jak znów Jacekalex pisze o tym, że żal mu mnie. xD Jeśli ktoś jest ciekaw, czemu tak długo trwa ten start, niech sobie obejrzy to http://i.imgur.com/ZIkD4B6.png .
A co to jest?[/quote]
A co ma być? Podnieś interfejs, załaduj konfigurację wifi, a przy wyłączaniu wyczyść i wyłącz interfejs. xDOstatnio edytowany przez morfik (2015-02-27 22:35:17)
Offline
[quote=raven18]
Startup finished in 1.521s (kernel) + 1.219s (userspace) = 2.740s
https://dl.dropboxusercontent.com/u/4118086/plot.svg
Jak zejdę poniżej 1s w userspace to będzie święto ;)
ps
sorki Morfik, ale musiałem xd[/quote]
2 sekundy to żaden wyczyn. Nie ma się czym chwalić.
Offline
2 sekundy to żaden wyczyn. Nie ma się czym chwalić.[/quote]
A ile to jest wyczyn?
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
[quote=Jacekalex]
2 sekundy to żaden wyczyn. Nie ma się czym chwalić.[/quote]
A ile to jest wyczyn?[/quote]
Tyle czasu potrzebuje standardowy Debian z jądrem aptosida/siduction/liquorix na start z dysku ssd.
Wyczyn to zauważalnie mniej niż standardowy system. Ale to nie wątek na takie dyskusje.
Tu bardziej odpowiednie miejsce:
https://forum.dug.net.pl/viewtopic.php?id=12976
Offline
Od wersji 219, systemd pokazuje informacje o zużywanej przez proces pamięci przy wywoływaniu statusu unitu via "systemctl status unit". Domyślnie jest to dla usług, które mają ustawione parametr MemoryLimit= w sekcji Service w pliku unitu. Jeśli jesteśmy ciekawi ile zjadają poszczególne usługi systemu, możemy przestawić kila opcji w pliku /etc/systemd/system.conf :
DefaultCPUAccounting=yes DefaultBlockIOAccounting=yes DefaultMemoryAccounting=yes
We wspomnianym pliku mamy też możliwość zdefiniowania domyślnych przydziałów ale można ten krok pominąć, w efekcie "systemctl status unit" wydrukuje jedynie status zjadanej pamięci bez określania przydziału, co wygląda mniej więcej tak:
[img]http://i.imgur.com/2BHrZxo.png[/img]
Pierwsza usługa nie ma ustawionego limitu, druga zaś ma, co można łatwo odczytać.
Po przestawieniu tych powyższych opcji, możemy sobie obejrzeć status wszystkich usług w systemd-cgtop , co wygląda mniej więcej tak:
[img]http://i.imgur.com/5glHry1.png[/img]
Mogliby tylko dopracować tego cgtopa. xD
Inne ciekawe opcje, które znalazłem przy okazji w pliku /etc/systemd/system.conf , to
DefaultTimeoutStartSec=30s DefaultTimeoutStopSec=30s DefaultRestartSec=1s DefaultStartLimitInterval=5s DefaultStartLimitBurst=3
Pierwsze dwie z nich ustawiają czas oczekiwania na załadowanie/zatrzymanie usługi i domyślnie to wynosiło 90s, co w moim odczuciu było za wolno. Ostatnia opcja zaś określa czas między kolejnymi automatycznymi restartami, np. w przypadku gdy jakaś usługa nawali. Dwie ostatnie opcje określają czas oraz ilość dozwolonych prób automatycznego restartu usługi — jeśli nastąpią 3 próby uruchomienia usługi w ciągu 5s, taka usługa już nie zostanie odpalona po raz czwarty. Każdy z tych parametrów można przepisać w plikach usług.
Offline
Otrzymałem ciekawą odpowiedź na jedno z moich pytań:
> 4. How to disable/enable an interface? When I was using the sysvinit
> networking script, I also had tools like ifup and ifdown . Do I have
> to create some service files that include several ip* commands, or is
> there a better way?
At the moment we only do static configuration, so we don't natively
support run-time configuration. We'll soon get the equivalent of
ifup/ifdown as part of networkctl, but for now we only support
applying your configuration files as specified at boot-time.
You can of course use ip(8) to manually bring links up/down: "ip link
set down wlan0" and networkd will cope with that just fine.
HTH,
Tom[/quote]
Także póki co jeszcze nie da rady wyłączyć/włączyć interfejsu via networkctl i póki co odbywa się to tylko podczas startu systemu. Na szczęście niedługo może zaimplementują ten ficzer. xD
Offline
A ja się mocno zdziwiłem.
Odpalam Jessie na Systemd (coś go wciągneło i sobie sam zmienił dowiązanie /sbin/init), wstaje jak zwykle, z 5 błędów po 30 sekund, ale w czasie wstawania podniósł konsole od 2 do 6 i można się było zalogować
Jak wyczaję, jak na Aptosidowym Jaju 3.19 Nvidię zainstalować, to może się dowiem coś więcej.
Chociaż, może to się po prostu wqoorwili Developerzy różnych dystrybucji,
i sami zaczęli łatać tego Frankensteina? xD
Swoją drogą, ifup i ifdown do networkctl?
Ciekawe, kiedy kernel nie będzie już potrzebny, bo zastąpi go systemd-linuxctl...
xD
Ostatnio edytowany przez Jacekalex (2015-03-05 02:24:57)
Offline
Udało mi się załatać dwa problemy dotyczące konfiguracji sieci, a konkretnie chodzi o interfejsy bond. Jeden z nich dotyczył ustawiania nieprawidłowego adresu MAC na interfejsie bond0, a drugi pokazywał dość nieprecyzyjne informacje pod /proc/net/bonding/bond0 .
Z wiadomości jakie ludzie słali na liście mailingowej wychodzi na to, że:
The kernel creates bond0 itself. This is confusing and we should
probably request the kernel to stop doing that (patch needed).
When the first bond interface is created (no matter its name), the
bond module is loaded and bond0 created. So if you try to create
bond0, the kernel will jump in and create its own instance with that
name first (with the default settings). If you try to create bond1
instead, the kernel will still first create bond0, but this we can
just ignore and bond1 will be created with the correct settings.
Cheers,
Tom[/quote]
I po zmianie konfiguracji na bond1, wszystko było już tak jak powinno. Niemniej jednak trochę takie rozwiązanie ssie — niby jest tylko jeden interfejs a kernel sobie dodatkowo zajmuje bond0 ale udało się również i ten problem rozwiązać:You can use "options bonding max_bonds=0" to disable the creation of bond0.
--
Michał Bartoszkiewicz[/quote]
I faktycznie to podziałało i teraz systemd już sobie tworzy interfejs bond0 i konfiguruje go bez większego problemu.Offline
Jest jakiś śmieszny błąd na linii systemd <> nfs w debianie od dłuższego czasu i chyba nikt nie ma zamiaru z tym nic zrobić, mimo, że mi się udało gdzieś nawet wyśledzić odpowiednie rozwiązanie na jednej z list mailingowanych. W każdym razie, problem objawia się w poniższy sposób:
systemd[1]: Job network.target/stop deleted to break ordering cycle starting with network-online.target/stop systemd[1]: Found ordering cycle on wpa_supplicant@wlan0.service/stop systemd[1]: Found dependency on systemd-networkd.service/stop systemd[1]: Found ordering cycle on network-online.target/stop systemd[1]: Found dependency on network.target/stop systemd[1]: Found dependency on systemd-networkd.service/stop systemd[1]: Found dependency on dbus.service/stop systemd[1]: Found dependency on dbus.socket/stop systemd[1]: Found dependency on sysinit.target/stop systemd[1]: Found dependency on nfs-common.service/stop systemd[1]: Found dependency on rpcbind.target/stop systemd[1]: Found dependency on rpcbind.service/stop systemd[1]: Found dependency on network-online.target/stop systemd[1]: Breaking ordering cycle by deleting job network.target/stop
Generalnie rzecz biorąc jest on nieco inny w zaleznośći od konfiguracji systemu ale łączy go usługa rpcbind, która jest generowana automatycznie przez systemd z powodu braku pliku .service .Podobnie sprawa ma się z nfs-common i by rozwiązać ten powyższy problem, czyli zapętlenie się, trzeba stworzyć 3 pliki:
/etc/systemd/system/rpcbind.service
[Unit] Description=RPC bind portmap service After=systemd-tmpfiles-setup.service Wants=remote-fs-pre.target Before=remote-fs-pre.target DefaultDependencies=no [Service] Environment="OPTIONS=-w" ExecStart=/sbin/rpcbind $OPTIONS EnvironmentFile=-/etc/rpcbind.conf EnvironmentFile=-/etc/default/rpcbind Type=forking KillMode=process Restart=on-failure [Install] WantedBy=sysinit.target Alias=portmap
/etc/systemd/system/nfs-common.service
[Unit] Description=NFS Common daemons Wants=remote-fs-pre.target After=rpcbind.service time-sync.target DefaultDependencies=no [Service] Type=oneshot RemainAfterExit=yes ExecStart=/etc/init.d/nfs-common start ExecStop=/etc/init.d/nfs-common stop [Install] WantedBy=sysinit.target
/etc/tmpfiles.d/rpcbind.conf
#Type Path Mode UID GID Age Arguments d /run/rpcbind 0755 root root - - f /run/rpcbind/rpcbind.xdr 0600 root root - - f /run/rpcbind/portmap.xdr 0600 root root - -
I teraz już tylko dodać to do autostartu i po resecie problem z zapętleniem się usług powinien zniknąć.
Offline
W końcu się doczekałem odpowiedzi na kilka maili, które wysłałem dość dawno. I jest taka informacja na temat dostępności cgroups dla zwykłych użytkowników:
> What is the best way to set cgroup limits for user processes? I mean the
> individual processes. I know that you can set limits for user.slice, but
> how to set limits for, let's say, firefox?
We simply do not support this right now. Unprivileged users do not get
access to the cgroup properties of the various controllers right
now, simply because this is unsafe.
We can open this up one day, bit by bit but this requires some kernel
work, and an OK from Tejun that this is safe.[/quote]
oraz trochę info na temat oznaczania pakietów via pliki systemd:> BTW, one more thing. Is there a way to set a mark for network packets
> using unit services? I really need this feature, but I couldn't find
> any useful information on this subject.
Daniel is working on adding native support for this via the net_cls
cgroup controller, but in the process he noticed that the kernel
support for this is actually quite broken, and there's work now going
on to fix the kernel first.
Lennart[/quote]
Także, będzie dobrze. xDOffline
Time (s) | Query |
---|---|
0.00010 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00107 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.188.227.64' WHERE u.id=1 |
0.00062 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.188.227.64', 1732506820) |
0.00038 | SELECT * FROM punbb_online WHERE logged<1732506520 |
0.00061 | DELETE FROM punbb_online WHERE ident='18.224.31.82' |
0.00071 | DELETE FROM punbb_online WHERE ident='52.14.252.16' |
0.00046 | SELECT topic_id FROM punbb_posts WHERE id=283827 |
0.00006 | SELECT id FROM punbb_posts WHERE topic_id=29025 ORDER BY posted |
0.00055 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=29025 AND t.moved_to IS NULL |
0.00005 | SELECT search_for, replace_with FROM punbb_censoring |
0.01036 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=29025 ORDER BY p.id LIMIT 75,25 |
0.00273 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29025 |
Total query time: 0.01774 s |