Forum Debian Users Gang

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.

No i jest możliwość zmiany parametrów cgroups bez resetowania unitów:

# systemctl set-property httpd.service CPUShares=500 MemoryLimit=500M

Ostatnio edytowany przez morfik (2015-02-10 08:17:27)

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- … -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.

OOMScoreAdjust=

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:

root:/etc/systemd/system# cat dnscrypt-proxy.service.d/oom.conf
[Service]
OOMScoreAdjust=-500

Poniżej są wartości jakie zostały ustawione w /proc/`pidof dnscrypt-proxy`/oom_* po zresetowaniu usługi:

/proc/55232/oom_adj        -8
/proc/55232/oom_score            0
/proc/55232/oom_score_adj        -500

Niedługo te moje unity będą przypominać długością skrypty sysvinit. xD

Dobrze jest też rzucić okiem na te poniższe opcje kernela:

vm.overcommit_memory = 0
vm.oom_kill_allocating_task = 0
vm.oom_dump_tasks = 1
vm.panic_on_oom = 0

Ostatnio edytowany przez morfik (2015-02-12 07:15:44)

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:



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)

@up

Czyli można by mieć na jednej karcie serwer dhcp oraz żeby ta karta brała z niego ip?

1682

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:12:15)

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)

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

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?

A co ma być? Podnieś interfejs, załaduj konfigurację wifi, a przy wyłączaniu wyczyść i wyłącz interfejs. xD

Ostatnio edytowany przez morfik (2015-02-27 22:35:17)

2 sekundy to żaden wyczyn. Nie ma się czym chwalić.

A ile to jest wyczyn?

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:



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:



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.

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)

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

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

I faktycznie to podziałało i teraz systemd już sobie tworzy interfejs bond0 i konfiguruje go bez większego problemu.

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.

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

Także, będzie dobrze. xD