Forum Debian Users Gang

Kolejny ciekawy ficzer systemd — drukarki. Chodzi to to, że standardowo usługa cupsa w systemd wygląda tak:

root:~# systemctl list-unit-files | grep cups
cups.path                              enabled
cups.service                           enabled
cups.socket                            enabled

ale standardowo nie działa (po mimo faktu jej włączenia):

root:~# systemctl status cups
● cups.service - CUPS Printing Service
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:cupsd(8)
           man:cupsd.conf(5)

oraz

root:~# lsof -i | grep cups

O co w tym wszystkim chodzi? Ano o aktywację drukarki gdy ta jest potrzebna. Generalnie są 3 różne scenariusze:
1) usługa cupsa działa nonstop, nawet jeśli drukarka nie jest podłączona lub jest wyłączona
2) cups jest odpalany gdy podłącza się drukarkę
3) cups się odpala gdy jakieś dokumenty się chce przesłać do wydruku

W moim przypadku satysfakcjonowałyby mnie te 2 ostatnie punkty, czyli by można było drukować ale bez konieczności posiadania w systemie ciągle odpalonego cupsa. W sysvinit sobie to musiałem przełączać, a tutaj na systemd? Zobaczmy co się stanie gry podłączę/włączę drukarkę:

Jan 28 21:45:12 morfikownia kernel: [  759.173496] usb 2-1.3: new full-speed USB device number 7 using ehci-pci
Jan 28 21:45:12 morfikownia kernel: [  759.267973] usb 2-1.3: New USB device found, idVendor=04b8, idProduct=0005
Jan 28 21:45:12 morfikownia kernel: [  759.267984] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 28 21:45:12 morfikownia kernel: [  759.267990] usb 2-1.3: Product: USB Printer
Jan 28 21:45:12 morfikownia kernel: [  759.267994] usb 2-1.3: Manufacturer: EPSON
Jan 28 21:45:12 morfikownia kernel: [  759.267998] usb 2-1.3: SerialNumber: 990040006261521120
Jan 28 21:45:12 morfikownia kernel: [  759.273747] usblp 2-1.3:1.0: usblp0: USB Bidirectional printer dev 7 if 0 alt 0 proto 2 vid 0x04B8 pid 0x0005
Jan 28 21:45:12 morfikownia mtp-probe: checking bus 2, device 7: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3"
Jan 28 21:45:12 morfikownia mtp-probe: bus: 2, device: 7 was not an MTP device
Jan 28 21:45:12 morfikownia systemd[1]: Starting CUPS Printing Service...
Jan 28 21:45:12 morfikownia systemd[1]: Started CUPS Printing Service.
Jan 28 21:45:12 morfikownia systemd[1]: Starting Printer.
Jan 28 21:45:12 morfikownia systemd[1]: Reached target Printer.
Jan 28 21:45:12 morfikownia colord: Profile added: EPSON_STYLUS_COLOR_760-Gray..
Jan 28 21:45:12 morfikownia colord: Profile added: EPSON_STYLUS_COLOR_760-RGB..
Jan 28 21:45:12 morfikownia colord: Device added: cups-EPSON_STYLUS_COLOR_760

oraz:

root:~# lsof -i | grep cups
cupsd     6802        root   10u  IPv4  65965      0t0  TCP localhost:ipp (LISTEN)
root:~# systemctl status cups
● cups.service - CUPS Printing Service
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2015-01-28 21:45:12 CET; 1min 23s ago
     Docs: man:cupsd(8)
           man:cupsd.conf(5)
 Main PID: 6802 (cupsd)
   CGroup: /system.slice/cups.service
           └─6802 /usr/sbin/cupsd -f

Jan 28 21:45:12 morfikownia systemd[1]: Starting CUPS Printing Service...
Jan 28 21:45:12 morfikownia systemd[1]: Started CUPS Printing Service.

Co w przypadku gdy chcemy coś wydrukować ale usługa cupsa nie jest podniesiona? Wystarczy wejść w plik->drukuj i zaznaczyć odpowiednią drukarkę, a po chwili zostaną odświeżone informacje o niej:



W między czasie zaś zostanie podniesiony daemon cupsa:

Jan 28 21:53:23 morfikownia systemd[1]: Starting CUPS Printing Service...
Jan 28 21:53:23 morfikownia systemd[1]: Started CUPS Printing Service.
Jan 28 21:53:23 morfikownia colord: Profile added: EPSON_STYLUS_COLOR_760-Gray..
Jan 28 21:53:23 morfikownia colord: Profile added: EPSON_STYLUS_COLOR_760-RGB..
Jan 28 21:53:23 morfikownia colord: Device added: cups-EPSON_STYLUS_COLOR_760
Jan 28 21:53:23 morfikownia colord: Profile added: EPSON_Stylus_COLOR_760_laptop-Gray..
Jan 28 21:53:23 morfikownia colord: Profile added: EPSON_Stylus_COLOR_760_laptop-RGB..
Jan 28 21:53:23 morfikownia colord: Device added: cups-EPSON_Stylus_COLOR_760_laptop

Może i to fajnie działa ale ma jedną wadę — przy wyłączaniu drukarki, cups nie zdycha i trzeba go ubić ręcznie. xD

1509

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:08:28)

Testuję sobie właśnie ten wbudowany w systemd mechanizm synchronizacji czasu, chodzi o:

root:~# timedatectl status
      Local time: Fri 2015-01-30 09:02:20 CET
  Universal time: Fri 2015-01-30 08:02:20 UTC
        RTC time: Fri 2015-01-30 08:02:20
       Time zone: Europe/Warsaw (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2014-10-26 02:59:59 CEST
                  Sun 2014-10-26 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2015-03-29 01:59:59 CET
                  Sun 2015-03-29 03:00:00 CEST

Już pominę fakt, że widać, kiedy jest zmiana czasu. xD Chodzi głównie o ten NTP, bo jakby nie patrzeć, nie mam u siebie wgranego żadnego pakietu z ntp. Za wszystko odpowiada usługa systemd-timesyncd.service , którą się konfiguruje via  /etc/systemd/timesyncd.conf :

[Time]
NTP=0.pl.pool.ntp.org 1.pl.pool.ntp.org 2.pl.pool.ntp.org 3.pl.pool.ntp.org
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Po aktywacji, system zaczyna synchronizować czas ale to też w ciekawy sposób:

Jan 30 08:27:43 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 64s/-0.013s/0.020s/0.005s/+397ppm
Jan 30 08:28:47 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 128s/-0.032s/0.021s/0.014s/+274ppm
Jan 30 08:30:55 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 128s/-0.051s/0.018s/0.046s/+74ppm
Jan 30 08:33:04 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 256s/-0.024s/0.020s/0.043s/+27ppm
Jan 30 08:37:20 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 512s/-0.036s/0.021s/0.039s/-7ppm
Jan 30 08:45:52 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 512s/-0.056s/0.023s/0.034s/-62ppm
Jan 30 08:54:24 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 1024s/-0.022s/0.020s/0.030s/-73ppm
Jan 30 09:11:29 morfikownia systemd-timesyncd[34930]: interval/delta/delay/jitter/drift 2048s/-0.023s/0.021s/0.025s/-79ppm

Jak widać, odstępy między kolejnymi synchronizacjami zwiększają się, aż do osiągnięcia maksymalnych 2048sekund (34min). Nie wiem jaki jest cel takiego rozwiązania  ale jeśli się przyjrzeć, to z jakichś powodów czasem czas (xD) nie ulega podwojeniu. Być może mają coś wspólnego z tym te cyferki, tylko co? xD

W każdym razie jeśli chodzi o czas, to chciałem nadać temu procesowi od synchronizacji wyższy priorytet i tu z początku wystąpił problem -- jak niby to zrobić no bo raczej nie przez:

# nice -n -20 ionice -n 0 -c 1

Poszukałem i znalazłem. Oczywiście chodzi o parametry unitów, a  yych dotyczących priorytetów jest z 10 i są tam miedzy innymi te 3, które widać wyżej i działa to dokładnie na takiej samej zasadzie co powyższa linijka, z tym, że procesy nie są wywoływane na zasadzie, że pierw odpala się nice, którego proces przybiera określony priorytet, potem wywołuje proces potomny, który dziedziczy ten priorytet i ustawia priorytet dla IO i wywołuje następny proces potomny, który dziedziczy oba te priorytety. xD Tu jest tylko jeden proces z założonymi już priorytetami.

Poniżej są te 3 parametry:

Nice=-20
IOSchedulingClass=1
IOSchedulingPriority=0

Nice przybiera wartości od -20 do 19, IOSchedulingClass od 0 do 3, a IOSchedulingPriority od 0 do 7 . Wszędzie im niższy numer tym większy priorytet. Cała filozofia. xD

No to teraz sobie wyprofiluje system, bo jakby nie patrzeć to ile razy nadawaliście skryptom init priorytety? A ile razy nadpisała wam to aktualizacja pakietu? xD

Ostatnio edytowany przez morfik (2015-01-30 09:30:01)

W końcu udało mi się odtworzyć konsolę, którą miałem na pulpicie, wykorzystując do tego celu journalctl . Wcześniej wykorzystywałem do tego urządzenie FIFO + rsyslog . W tej chwili już nie potrzebuje ani jednego ani drugiego. xD Całość sprowadza się do wpisania w config tmuxa poniżej linijki:

new -d -s logi -n logi "journalctl -b --no-pager | ccze -m ansi && journalctl -n 0 -f | ccze -m ansi"

Są tam dwa wywołania journalctl, z których jeden czyta logi od startu maszyny, drugi zaś nasłuchuje kolejnych. Oba logi są pokolorowane. Na dobrą sprawę z wierzchu, to niczym się ta konsola nie różni. Jest tylko trochę więcej komunikatów + dodatkowo będą wyświetlane logi z wczesnego startu systemu, bo tego rsyslog nie potrafił. Dodatkowa zaleta tego rozwiązania jest taka, że jeśli mi tmux zdechnie, to po tym jak się odpali, dostaję kompletny log, a nie tak jak w przypadku tego urządzenia FIFO, tracone było wszystko i log zaczynał się w miejscu urwania.

I taka sprawa jeszcze:

Jan 31 22:17:12 morfikownia su[46070]: + /dev/pts/2 morfik:root
Jan 31 22:17:12 morfikownia su[46070]: pam_unix(su:session): session opened for user root by (uid=1000)
Jan 31 22:30:37 morfikownia systemd[1]: Stopping Flush Journal to Persistent Storage...
Jan 31 22:30:37 morfikownia systemd[1]: Stopping Journal Service...
Jan 31 22:30:37 morfikownia systemd-journal[257]: Journal stopped
Jan 31 22:30:37 morfikownia systemd-journal[50572]: Permanent journal is using 116.7M (max allowed 300.0M, trying to leave 1.7G free of 4.6G available → current limit 300.0M).
Jan 31 22:30:37 morfikownia systemd-journald[257]: Received SIGTERM from PID 1 (systemd).
Jan 31 22:30:37 morfikownia systemd[1]: Starting Journal Service...
Jan 31 22:30:37 morfikownia systemd-journal[50572]: Journal started
Jan 31 22:30:37 morfikownia systemd[1]: Started Journal Service.
Jan 31 22:30:37 morfikownia systemd[1]: Starting Flush Journal to Persistent Storage...
Jan 31 22:30:37 morfikownia systemd[1]: Started Flush Journal to Persistent Storage.

Jak widać wyżej, log jest ciągły, nawet pomimo zresetowania journala -- gdybym zresetował rsysloga, konsolę by mi szlag trafił i trzeba by ją odpalać jeszcze raz.

No to już jedną nogą jestem przy pozbyciu się rsysloga. Jeszcze muszę nauczyć ten journalctl łapać logi z sieci oraz filtrować logi usług, bo sporo komunikatów jest zbędnych -- jeśli te dwie rzeczy uda mi się zaimplementować, to wywalam rsysloga razem z logrotate i uprzątnę ten burdel co mi się zrobił przez ostatnie miesiące w /var/log/ . xD

Doszukałem się trochę info na temat tego ficzera z szyfrowaniem dziennika:

One key is the "sealing key" which is kept on the system, and the other is the "verification key" which should be securely stored elsewhere. Using the FSPRG mechanism, a new sealing key is generated periodically using a non-reversible process. The old key is then securely deleted from the system after the change.

The verification key can be used to calculate the sealing key for any given time range. That means that the attacker can only access the current sealing key (which will presumably be used for the next sealing operation), while the administrator can reliably generate any sealing key to verify previous log file seals. Changing log file entries prior to the last seal will result in a verification failure.

http://lwn.net/Articles/512895/

By z skorzystać z tej opcji, trzeba w /etc/systemd/journald.conf mieć ustawione:

...
Storage=persistent
Seal=yes
...

Trzeba także wygenerować sobie dwa klucze, a te z kolei zaś najlepiej tworzyć z mniejszym interwałem niż jest domyślnie czyli 15min:

# journalctl --setup-keys --interval=60s

Po stworzeniu kluczy trzeba zatrzymać dziennik, usunąć wszystkie pliki dziennika i wystartować go jeszcze raz.

I tu jest mały problem, z tym, że nie wiem czy to tylko u mnie, czy to jakiś bug/ficzer, że ten mechanizm nie działa. xD Jeśli popatrzeć na sam klucz:

root:/var/log/journal/159815709bbc46c29ef786cfc497afd4# ls -al
total 8.1M
drwxr-sr-x+ 2 root systemd-journal 4.0K 2015-02-01 07:16:13 ./
drwxr-sr-x+ 3 root systemd-journal 4.0K 2015-01-22 19:22:30 ../
-rw-------+ 1 root systemd-journal  482 2015-02-01 07:18:00 fss
-rw-r-----+ 1 root systemd-journal 8.0M 2015-02-01 07:18:00 system.journa
l
root:/var/log/journal/159815709bbc46c29ef786cfc497afd4# ls -al
total 8.1M
drwxr-sr-x+ 2 root systemd-journal 4.0K 2015-02-01 07:16:13 ./
drwxr-sr-x+ 3 root systemd-journal 4.0K 2015-01-22 19:22:30 ../
-rw-------+ 1 root systemd-journal  482 2015-02-01 07:19:00 fss
-rw-r-----+ 1 root systemd-journal 8.0M 2015-02-01 07:18:00 system.journal

to widać wyraźnie, że się generuje co 1min ale jeśli chodzi o sprawdzanie dziennika, to przed pieczętowaniem jest ok:

# journalctl --verify --verify-key 48738d-de9093-2f6b15-9416f8/181f35-35a4e900
PASS: /var/log/journal/159815709bbc46c29ef786cfc497afd4/system.journal
=> No sealing yet, 14.775ms of entries not sealed.

ale po zapieczętowaniu, już nie jest ok i wyrzuca błędy o nieprawidłowych wiadomościach.

Nie mam pojęcia co z tym zrobić — jest dokładnie to samo na wersji eksperymentalnej i sidowej. Próbowałem na standardowych ustawieniach, jak i na swoich własnych i ciągle to samo. Znalazłby się ktoś, kto by przetestował czy ten mechanizm u niego działa normalnie? xD

Ja po angielsku czytam lepiej niż po polsku, zwłaszcza jeśli chodzi o linuxy, xD

systemctl-cat, systemctl-edit: cat the config file of the unit you specify, so you don't need to know the path on the system (ie: systemctl-cat apache2.service). The systemctl-edit apache2.service immediately opens the unit file to edit. After a save, the service can get reloaded automatically.

A tego nie wiedziałem — ułatwi mi to życie, bo wpisywanie ciągle ścieżek /lib/systemd/system/systemd-... wnerwia człowieka. xD

journald-remoting: the binary logger now has remote support (aka: remoting) via HTTP (instead of the syslog protocol, which isn't standardized (ie: no timezones, single-line logs only, ...)). Journald has a pull and push model. Pull = HTTP GET request for a JSON stream. Push model pushes via the HTTP POST request to a remote journald instance. Allows for "simple" implementations of programs (PHP, Ruby, ...) to send data to a remote journald endpoint, since it's just HTTP POST. Could replace syslogging.

Obadam, może uda się zastąpić rsysloga całkowicie. xD

Can also hide partitions instead of making them just read only. For instance, if /home is "hidden" it will appear as an empty directory.
...
Can also hide /dev/* devices and hide all the physical devices (like /dev/sda, ...) and only keep /dev/zero, /dev/null, ... for particular services.

Podoba mi się to. xD

Ostatnio edytowany przez morfik (2015-02-03 19:39:13)

Właśnie się doszukałem ciekawej opcji dla kernela:

systemd.confirm_spawn=1

Po jej dopisaniu, powinien się odpalić tryb interaktywny systemd, coś jak w openrc -- pyta przed wystartowaniem usługi. No tylko jest jeden problem: https://bugzilla.redhat.com/show_bug.cgi?id=1084401

Jak oni myśleli przy robieniu tego trybu interaktywnego, to ja nie mam zielonego pojęcia. To wygląda mniej więcej tak: odpala się system, wyrzuca pierwszą usługę, wpisuje się "y", po czym czyta komunikat, potem następna usługa i znów komunikat. Ale tu niema tak łatwo -- za wolno ci idzie czytanie i odpowiadanie, to usługa zostanie wystartowana bez potrzeby odpowiadania na pytania (domyślne "y"). Czyli czytasz sobie błęda czy coś próbujesz zrozumieć, a tu usługi ci się w tle odpalają i generują komunikaty i ekran się przewija. Szkoda, że nie wiem, kto jest odpowiedzialny osobiście za ten mechanizm, to bym mu pogratulował. xD

Mam nadzieję, że to poprawią, bo szlag człowieka może trafić przez brak tego trybu interaktywnego.

W OpenRC trym interaktywny się włącza jednym przyciskiem, domyślnie i w czasie uruchamiania runlevelu sysinit.

Opcja w konfigu:

# Set rc_interactive to "YES" and you'll be able to press the I key during
# boot so you can choose to start specific services. Set to "NO" to disable
# this feature. This feature is automatically disabled if rc_parallel is
# set to YES.
rc_interactive="YES"

W SystemD nigdy nic podobnego nie widziałem.

Ostatnio edytowany przez Jacekalex (2015-02-07 14:32:27)

ethanak napisał(-a):

fajny wynalazek! ktoś to już opatentował?

Licencja  BSD, możesz to przepisać jako łatki i do SystemD i do M$ Windows,
nie ma problemu. xD

Gdyby nie te timeouty przy pytaniach, to by też było wypasione. xD

i dlatego w durnym netbooku nie mogę wyczaić gdzie mi się system kaszani? może to równoległe uruchamianie jest zahebiste dopóki coś się nie spartoli.

btw. nie wiem jak wy - ja serwery zwykłem uruchamiać, mają działać, i jeśli muszę zrobić reboot wcześniej niż rok po odpaleniu to znaczy że albo mam problemy sprzętowe, albo coś spieprzyłem.

yossarian napisał(-a):

Jacekalex napisał(-a):

W OpenRC trym interaktywny się włącza jednym przyciskiem, domyślnie i w czasie uruchamiania runlevelu sysinit.

Opcja w konfigu:

# Set rc_interactive to "YES" and you'll be able to press the I key during
# boot so you can choose to start specific services. Set to "NO" to disable
# this feature. This feature is automatically disabled if rc_parallel is
# set to YES.
rc_interactive="YES"

W SystemD nigdy nic podobnego nie widziałem.

Pewnie dlatego, że mamy 21. wiek i usługi startują równocześnie.

Jak ostatnio wrzuciłem SystemD na Gentusia, to faktycznie, usługa, 5 minut postoju, usługa, 5 minut, usługa, 5 minut - w skali tygodnia można to uznać za jednocześnie.:D
W Debku Jessie zainstalowałem SystemD, i uruchamianie Debiana zakończyło się na starcie Udeva.
Może kiedyś będę musiał pogodzić się z Systemd, ale póki taka konieczność nie występuje, to wolę spróbować przeczekać to cudo.

Są duże szanse, że uda mi się z OpenRC doczekać końca SystemD, sporo obiektywnych informacji na to wskazuje.  :D

Pozdro
;)

Czy tylko mi ten systemd działa jak trza? xD

Na początku przy przejściu, to faktycznie wlekł się ten start — miałem ponad 2:20. Teraz?

morfik:~$ systemd-analyze
Startup finished in 15.536s (kernel) + 25.735s (userspace) = 41.272s
morfik:~$ systemd-analyze blame | head
          8.930s morfinetwork.service
          6.664s networking.service
          4.559s systemd-cryptsetup@kabi.service
          3.568s monitorix.service
          3.363s accounts-daemon.service
          3.158s keyboard-setup.service
          2.829s exim4.service
          2.283s upower.service
          2.098s zram_tmp.service
          2.088s systemd-logind.service

Czyli realnie to jest 26s, bo te15s to czas na otworzenie zaszyfrowanego LVM. Z czego połowa tych usług, to są moje niestandardowe rzeczy. xD Jest też jakiś problem z siecią jeszcze, może to po części wina wifi, dhcp albo tych skryptów init, bo jeszcze nie patrzyłem na sieć w wykonaniu systemd, a oni tam też mają jakąś natywną usługę do tego — za jakiś czas też rzucę na to okiem

Tu jeszcze taka ciekawostka — znalazłem na necie linijkę, która pokazuje całkowity czas potrzebny na wystartowanie wszystkich usług, tyle, że w schemacie sysvinit, czyli jedna po drugiej. Tylko trochę lipa, bo jednostki nie są takie same i musiałem to zrobić na dwa razy:

morfik:~/Desktop$  cat 1|awk '{print $0;sum=sum+$1} END {print NR,"services: Total =",sum/1000,"seconds"}'
675ms dev-hugepages.mount
554ms kbd.service
544ms systemd-tmpfiles-setup-dev.service
521ms cpufrequtils.service
431ms systemd-fsck@dev-disk-by\x2duuid-27632431\x2dfa15\x2d49ba\x2d8354\x2d9c193e321aa6.service
427ms systemd-journald.service
425ms kmod-static-nodes.service
397ms nfs-common.service
355ms systemd-rfkill@rfkill0.service
333ms systemd-fsck@dev-mapper-kabi.service
318ms home.mount
276ms systemd-tmpfiles-setup.service
272ms lvm2-activation.service
228ms sudo.service
222ms plymouth-read-write.service
216ms systemd-udev-trigger.service
210ms console-setup.service
209ms systemd-backlight@backlight:acpi_video0.service
207ms systemd-fsck@dev-disk-by\x2duuid-4c67dff5\x2d3d8e\x2d4b3f\x2d9cf1\x2d49b88d5f67a9.service
204ms rpcbind.service
200ms systemd-tmpfiles-clean.service
186ms systemd-remount-fs.service
173ms boot.mount
137ms sysfsutils.service
135ms systemd-backlight@backlight:intel_backlight.service
128ms systemd-udevd.service
113ms media-Kabi.mount
110ms systemd-timesyncd.service
101ms plymouth-start.service
98ms user@108.service
90ms systemd-sysctl.service
88ms systemd-random-seed.service
86ms udev-finish.service
65ms systemd-update-utmp.service
63ms plymouth-quit.service
62ms lvm2-monitor.service
59ms plymouth-quit-wait.service
58ms systemd-cryptsetup@debian_laptop.service
53ms dev-disk-by\x2duuid-c4f58930\x2dbfda\x2d4f4e\x2dbad0\x2d2be8d1b5bc9e.swap
40ms user@1000.service
31ms systemd-rfkill@rfkill1.service
28ms dnscrypt-proxy.service
17ms cloud_storage-mega.encrypted.service
 8ms lvm2-pvscan@254:0.service
 4ms systemd-update-utmp-runlevel.service
 2ms sys-fs-fuse-connections.mount
46 services: Total = 9.159 seconds

morfik:~/Desktop$  cat 2|awk '{print $0;sum=sum+$1} END {print NR,"services: Total =",sum,"seconds"}'
8.930s morfinetwork.service
6.664s networking.service
4.559s systemd-cryptsetup@kabi.service
3.568s monitorix.service
3.363s accounts-daemon.service
3.158s keyboard-setup.service
2.829s exim4.service
2.283s upower.service
2.098s zram_tmp.service
2.088s systemd-logind.service
2.083s rsyslog.service
2.016s systemd-fsck-root.service
1.994s alsa-restore.service
1.965s lm-sensors.service
1.964s cryptmount.service
1.962s ifplugd.service
1.960s loadcpufreq.service
1.959s virtualbox.service
1.958s hddtemp.service
1.958s nfs-kernel-server.service
1.958s systemd-user-sessions.service
1.922s systemd-udev-settle.service
1.788s zram_swap.service
1.753s hdparm.service
1.701s rtkit-daemon.service
1.701s systemd-modules-load.service
1.519s rc-local.service
1.474s systemd-journal-flush.service
1.454s lightdm.service
1.452s resolvconf.service
1.443s lvm2-activation-early.service
1.122s polkitd.service
1.099s dev-mqueue.mount
1.098s sys-kernel-debug.mount
34 services: Total = 80.843 seconds

Łącznie zatem na same usługi to by było:

46 services: Total = 9.159 seconds
34 services: Total = 80.843 seconds

Czyli około 90s, do tego trzeba by doliczyć jeszcze czas na wpisanie hasła: 15.536s i start systemu zajmuje.... 105s — to ja już wolę te moje 41s. xD

A tak wygląda start: http://i.imgur.com/frvfK1K.png

Jeśli ktoś, patrząc na ten wykresik, nie rozumie co tam się dzieje, to powinien poczytać i jestem zdania, że w chwili gdy zrozumie co tam się odbywa, większość (albo i wszystkie) problemy znikną raz dwa. xD

i dlatego w durnym netbooku nie mogę wyczaić gdzie mi się system kaszani? może to równoległe uruchamianie jest zahebiste dopóki coś się nie spartoli.

To może napisz co ci się tam dzieje. Rzuć okiem na wcześniejsze posty w tym temacie, tam masz ciekawą rozpiskę jak przeanalizować start systemu — w skrajnych wypadkach to ci wypluje 10k linijek i nie ma bata byś nie doszedł wtf — ja póki co szereg rzeczy sobie wyjaśniłem i po mimo faktu, że jadę na wersji z experimentala, sam system działa mi bez zarzutu — może najwyższy czas wyzbyć się uprzedzeń, bo póki co, to tylko słyszę, że "omfg nie działa, to wina systemd", a o analizie wtf, to już w przypadku sytemd  nikt nie słyszał, a ten init jest o wiele bardziej rozmowny niż wszystko inne. xD

Jeśli cierpicie na brak informacji, tu macie zajebistą dokumentację: http://www.freedesktop.org/software/systemd/man/systemd.index.html — jest tego naprawdę sporo, i póki co wszystko czego potrzebowałem do zrozumienia tematu znalazłem tam w tej dokumentacji. Choć i tak jeszcze w 70% linków nie było dane mi zajrzeć. xD

Zatem do dzieła, wiem, że ciężko jest zmienić swoje przyzwyczajenia (patrzcie np. ipv6|ipv4 albo ip|ifconfig) ale po tygodniu operowania na systemd, będziecie go sobie chwalić. xD

Ostatnio edytowany przez morfik (2015-02-08 02:14:12)