Долго грузится gnome shell

samson4747	# 10 лет назад
Темы: 33 Сообщения: 534 Участник с: 23 февраля 2012	red, это оно, почти, как у меня даже) $ systemctl status updatedb.timer ● updatedb.timer - Daily locate database update Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static) Active: active (waiting) since Сб 2014-04-26 09:17:06 MSK; 7min ago $ но, думаю о полном отключении сервиса, изменение времени, думаю не поможет... опробую сейчас... завтра глянем... Прошу прощение за то что долго отвечаю... Спасибо, за помощь! В итоге: Создал: /etc/systemd/system/updatedb.timer.d/updatedb.timer.conf `[Timer] OnCalendar=12:00` Имеем: $ systemd-analyze Startup finished in 2.414s (kernel) + 14.613s (userspace) = 17.028s $ systemd-analyze blame 3.044s lvm-monitoring.service 2.811s accounts-daemon.service 2.801s systemd-modules-load.service 2.473s lm_sensors.service 2.323s systemd-vconsole-setup.service 2.158s alsa-restore.service 1.981s systemd-logind.service 1.972s dcron.service 1.237s polkit.service 1.016s systemd-binfmt.service 972ms gdm.service 819ms dev-hugepages.mount 813ms systemd-tmpfiles-setup-dev.service 805ms tmp.mount 727ms colord.service 482ms systemd-remount-fs.service 401ms kmod-static-nodes.service 396ms media-bcb536f2\x2def06\x2d4838\x2dad5e\x2db48bb6960be0.mount 367ms systemd-random-seed.service 338ms systemd-journal-flush.service 268ms dev-mqueue.mount 245ms systemd-user-sessions.service 241ms dev-sda5.swap 230ms systemd-udev-trigger.service 221ms systemd-tmpfiles-setup.service 203ms [email protected] 182ms lvmetad.service 151ms udisks2.service 148ms sys-kernel-debug.mount 113ms systemd-localed.service 112ms systemd-udevd.service 82ms upower.service 80ms systemd-update-utmp.service 75ms systemd-sysctl.service 64ms [email protected] 47ms proc-sys-fs-binfmt_misc.mount 41ms rtkit-daemon.service 28ms sys-fs-fuse-connections.mount 28ms sys-kernel-config.mount lines 17-39/39 (END) $ Уже приемлимей, НО думаю, это дело времени, так как например после полудня, он опять при загрузке начнёт тормозить загрузку. Аль ошибаюсь? Хотя в итоге, накосячил: $ systemctl status updatedb.timer ● updatedb.timer - Daily locate database update Loaded: error (Reason: Bad message) Drop-In: /etc/systemd/system/updatedb.timer.d └─updatedb.timer.conf Active: inactive (dead) $ Исправим сейчас, но всё же мне кажется это будет делом времени. После исправления: `$ systemctl status updatedb.timer ● updatedb.timer - Daily locate database update Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static) Drop-In: /etc/systemd/system/updatedb.timer.d └─updatedb.timer.conf Active: active (waiting) since Сб 2014-04-26 09:51:01 MSK; 51s ago $ systemd-analyze Startup finished in 2.370s (kernel) + 15.808s (userspace) = 18.178s $` "If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding. —Aaron Griffin

# 10 лет назад

Сообщения: 534

Участник с: 23 февраля 2012

red, это оно, почти, как у меня даже)

$ systemctl status updatedb.timer
● updatedb.timer - Daily locate database update
   Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static)
   Active: active (waiting) since Сб 2014-04-26 09:17:06 MSK; 7min ago
$

но, думаю о полном отключении сервиса, изменение времени, думаю не поможет... опробую сейчас... завтра глянем...
Прошу прощение за то что долго отвечаю...
Спасибо, за помощь!

В итоге:
Создал: /etc/systemd/system/updatedb.timer.d/updatedb.timer.conf

[Timer]
OnCalendar=12:00

Имеем:

$ systemd-analyze
Startup finished in 2.414s (kernel) + 14.613s (userspace) = 17.028s
$ systemd-analyze blame
          3.044s lvm-monitoring.service
          2.811s accounts-daemon.service
          2.801s systemd-modules-load.service
          2.473s lm_sensors.service
          2.323s systemd-vconsole-setup.service
          2.158s alsa-restore.service
          1.981s systemd-logind.service
          1.972s dcron.service
          1.237s polkit.service
          1.016s systemd-binfmt.service
           972ms gdm.service
           819ms dev-hugepages.mount
           813ms systemd-tmpfiles-setup-dev.service
           805ms tmp.mount
           727ms colord.service
           482ms systemd-remount-fs.service
           401ms kmod-static-nodes.service
           396ms media-bcb536f2\x2def06\x2d4838\x2dad5e\x2db48bb6960be0.mount
           367ms systemd-random-seed.service
           338ms systemd-journal-flush.service
           268ms dev-mqueue.mount
           245ms systemd-user-sessions.service
           241ms dev-sda5.swap
           230ms systemd-udev-trigger.service
           221ms systemd-tmpfiles-setup.service
           203ms [email protected]
           182ms lvmetad.service
           151ms udisks2.service
           148ms sys-kernel-debug.mount
           113ms systemd-localed.service
           112ms systemd-udevd.service
            82ms upower.service
            80ms systemd-update-utmp.service
            75ms systemd-sysctl.service
            64ms [email protected]
            47ms proc-sys-fs-binfmt_misc.mount
            41ms rtkit-daemon.service
            28ms sys-fs-fuse-connections.mount
            28ms sys-kernel-config.mount
lines 17-39/39 (END)
$

Уже приемлимей, НО думаю, это дело времени, так как например после полудня, он опять при загрузке начнёт тормозить загрузку. Аль ошибаюсь?
Хотя в итоге, накосячил:

$ systemctl status updatedb.timer
● updatedb.timer - Daily locate database update
   Loaded: error (Reason: Bad message)
  Drop-In: /etc/systemd/system/updatedb.timer.d
           └─updatedb.timer.conf
   Active: inactive (dead)
$

Исправим сейчас, но всё же мне кажется это будет делом времени.
После исправления:

$ systemctl status updatedb.timer
● updatedb.timer - Daily locate database update
   Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static)
  Drop-In: /etc/systemd/system/updatedb.timer.d
           └─updatedb.timer.conf
   Active: active (waiting) since Сб 2014-04-26 09:51:01 MSK; 51s ago
$ systemd-analyze
Startup finished in 2.370s (kernel) + 15.808s (userspace) = 18.178s
$

"If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding. —Aaron Griffin

cucullus	# 10 лет назад
Темы: 266 Сообщения: 3541 Участник с: 06 июня 2007	проверьте файловую систему! у меня однажды updatedb работал вечно из-за какого-то косяка со ссылками. такие дела.

samson4747	# 10 лет назад
Темы: 33 Сообщения: 534 Участник с: 23 февраля 2012	у меня проверка fsck, выполняется каждые 3 загрузки, ошибок не наблюдал P.S.: под LiveCD (тоже всё хорошо) $ sudo fsck.ext4 -n /dev/sda1 e2fsck 1.41.11 (14-Mar-2010) Superblock last mount time is in the future. (by less than a day, probably due to the hardware clock being incorrectly set) Fix? no Superblock last write time is in the future. (by less than a day, probably due to the hardware clock being incorrectly set). Fix? no /dev/sda1: clean, 403802/2383872 files, 6648881/9520512 blocks $ "If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding. —Aaron Griffin

samson4747

# 10 лет назад

Темы: 33

Сообщения: 534

Участник с: 23 февраля 2012

у меня проверка fsck, выполняется каждые 3 загрузки, ошибок не наблюдал
P.S.: под LiveCD (тоже всё хорошо)

$ sudo fsck.ext4 -n /dev/sda1
e2fsck 1.41.11 (14-Mar-2010)
Superblock last mount time is in the future.
	(by less than a day, probably due to the hardware clock being incorrectly set)  Fix? no

Superblock last write time is in the future.
	(by less than a day, probably due to the hardware clock being incorrectly set).  Fix? no

/dev/sda1: clean, 403802/2383872 files, 6648881/9520512 blocks
$

samson4747	# 9 лет, 12 месяцев назад
Темы: 33 Сообщения: 534 Участник с: 23 февраля 2012	Как и ожидал, говоря об этом выше, Timer не помог, имеем вновь: `$ systemd-analyze Startup finished in 2.415s (kernel) + 1min 49.252s (userspace) = 1min 51.667s` `$ systemd-analyze blame 1min 38.897s updatedb.service ... lines 19-41/41 (END)` $ systemctl status updatedb.timer ● updatedb.timer - Daily locate database update Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static) Drop-In: /etc/systemd/system/updatedb.timer.d └─updatedb.timer.conf Active: active (waiting) since Пн 2014-04-28 18:18:34 MSK; 2min 27s ago $ Есть например мысль прописать в в /etc/updatedb.conf "DAILY_UPDATE=no", но думаю не повредит ли данное отключение индексированние посредством updatedb... На крайний случай можно конечно Timer подобрать где-то на 21-00, но тогда это только снизит количество тормозных загрузок. Через день: `$ systemd-analyze Startup finished in 2.242s (kernel) + 2min 2.000s (userspace) = 2min 4.243s $ systemd-analyze blame 1min 51.937s updatedb.service 1min 42.573s man-db.service ...` Это совсем не дело. "If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding. —Aaron Griffin

samson4747

# 9 лет, 12 месяцев назад

Темы: 33

Сообщения: 534

Участник с: 23 февраля 2012

Как и ожидал, говоря об этом выше, Timer не помог, имеем вновь:

$ systemd-analyze
Startup finished in 2.415s (kernel) + 1min 49.252s (userspace) = 1min 51.667s


$ systemd-analyze blame
    1min 38.897s updatedb.service
...
lines 19-41/41 (END)


$ systemctl status updatedb.timer
● updatedb.timer - Daily locate database update
   Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static)
  Drop-In: /etc/systemd/system/updatedb.timer.d
           └─updatedb.timer.conf
   Active: active (waiting) since Пн 2014-04-28 18:18:34 MSK; 2min 27s ago
$

Есть например мысль прописать в в /etc/updatedb.conf "DAILY_UPDATE=no", но думаю не повредит ли данное отключение индексированние посредством updatedb...
На крайний случай можно конечно Timer подобрать где-то на 21-00, но тогда это только снизит количество тормозных загрузок.

Через день:

$ systemd-analyze
Startup finished in 2.242s (kernel) + 2min 2.000s (userspace) = 2min 4.243s
$ systemd-analyze blame
    1min 51.937s updatedb.service
    1min 42.573s man-db.service
...

Это совсем не дело.