Автор Тема: [решено] Замена systemd на sysvinit - последствия. Как починить?  (Прочитано 11645 раз)

Онлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
В теории он должен это делать через post_service скрипт
Я знаю. И в спеке это обязано быть. То есть, оно должно работать именно так, а если не работает, надо чинить. И я, как раз, собрался syslog-ng обновлять.

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259

reboot накрылся медным тазом. :-)


печально, потому что надо ребутить по крону, а не по клавиатуре ((

Это только в момент замены systemd на sysvinit. После перезагрузки через SysRq всё будет как обычно на sysv.

Вообще же, стартеркит xfce с systemd на p8, переводится на sysv однострочником.

В p8, благодаря Антону, появился новый пакет:
# rpm -q --qf '%{DESCRIPTION}\n' apt-conf-ignore-systemd
This is the apt configuration file for systems on sysvinit,
to ignore the installation of systemd packages,
see http://apt-rpm.org/tricks.shtml for details.

Пакет блокирует установку всех пакетов требующих установку и работающий systemd.
Предотвращает разлом или замусоривание системы на sysvinit.
Пакет совсем новый и например в последнем релизе стартеркита sysv-xfce его ещё нет. Ожидается его появление в следующем релизе.
Моё ИМХО:
Рекомендуется в поставку по-умолчанию во все образы систем на sysv.


Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Посему мысль была - раз в месяц перезагружать с проверкой ночью, пока никого это не напрягает. ... Наверняка есть болеедругие способы, но я о них не знаю ))

Посмотрите man fstab и man tune2fs на предмет check.

Онлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Посмотрите man fstab и man tune2fs на предмет check.
Откладывание, либо отключение проверки вообще - это не сильно хороший выход.

Оффлайн marsden

  • Давно тут
  • **
  • Сообщений: 42
Наверняка есть болеедругие способы, но я о них не знаю
Это было головной болью с ext2/3, с ext4 это происходит быстро, в основном (но если конвертировать в ext4 из 3, надо помнить, что реально конвертация заканчивается псле перезаписи всех старых файлов и каталогов). Плюс есть ФС, для которых такая проверка не выполняется, например btrfs. И, в конце концов, по крону можно отмонтировать, прочекать и примонтировать вместо ребута.

скорее всего, так и сделаю. Но это для отдельных разделов, которые и монтируются-то не через fstab, а чисто скриптом. А вот как с корневым разделом быть? Раньше у меня так не получалось, правда, пробовал последний раз лет 7-8 назад.

Оффлайн marsden

  • Давно тут
  • **
  • Сообщений: 42
Посмотрите man fstab и man tune2fs на предмет check.
Откладывание, либо отключение проверки вообще - это не сильно хороший выход.

ну это понятно... это совсем нехороший и даже не выход. Поэтому матерюсь на звонки с вопросами "ну когда уже?" и жду )) слава Богу редко такое ))

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Посмотрите man fstab и man tune2fs на предмет check.
Откладывание, либо отключение проверки вообще - это не сильно хороший выход.

Почему откладывание? :-)
Поле в fstab только разрешает проверку, но без счётчика для файловой, проверка
# cat /etc/fstab | col -bfx | grep ' / '
UUID=634f74e2-a465-4617-85d8-1fefa673c207       /       ext4    relatime        1       1

не отработает:
В стартеркитах на p8 счётчики вообще не включены:
# tune2fs -l /dev/sda8 | grep -i 'Maximum mount count\|check'
Maximum mount count:      -1
Last checked:             Mon Apr 30 07:28:44 2018
Check interval:           0 (<none>)


Но в системах на p6, которые были ещё на sysvinit, они установлены по-умолчанию:
# cat /etc/fstab | col -bfx | grep ' / '
UUID=e9f90d7c-a413-4fd4-9f05-84e31f93f065       /       ext4    relatime        1       1

Если корневая будет монтироваться 24-ый раз на загрузке, корневая будет проверена в принудительном порядке.
Если корневая будет смонтирована менее 23-ёх раз, но наступит/пройдёт Sat Mar 23 11:50:01 2019, корневая на загрузке будет проверена в принудительном порядке, т.е. через полгода если компьютер не включался вообще:
# tune2fs -l /dev/sda3 | grep -i 'Maximum mount count\|check'
Maximum mount count:      23
Last checked:             Mon Sep 24 11:50:01 2018
Check interval:           15552000 (6 months)
Next check after:         Sat Mar 23 11:50:01 2019

В стартеркитах на p8, где-то шо-то поломали дефолт проверки.
« Последнее редактирование: 24.09.2018 12:52:07 от Speccyfighter »

Онлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Почему откладывание? :-)
Потому, что "либо отключение". :-)

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Почему откладывание? :-)
Потому, что "либо отключение". :-)

:-) Вообще-то я ему
Посему мысль была - раз в месяц перезагружать с проверкой ночью,

не предлагал отложить или выключить, я предлагал включить и настроить

поскольку
ни в sysv-tde
# tune2fs -l /dev/sda8 | grep -i 'Maximum mount count\|check'
Maximum mount count:      -1
Last checked:             Mon Apr 30 07:28:44 2018
Check interval:           0 (<none>)

ни в sysv-xfce
# tune2fs -l /dev/sda11 | grep -i 'Maximum mount count\|check'
Maximum mount count:      -1
Last checked:             Fri Sep  7 10:44:12 2018
Check interval:           0 (<none>)

счётчики по-умолчанию не включены и никакой проверки не будет, независимо от того что стоит в fstab.

Онлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
А вот как с корневым разделом быть?
Ну он же маленький? Плюс, всё равно, когда-нибудь все файлы будут модифицированы. Плюс есть хак в виде "chattr +e" после конвертации в ext4. В общем, конвертировать в ext4, и всё. Только вот вопрос: если установка с systemd, значит это новая установка, и там уже ext4 должна быть. И, кстати, можно в fstab уже написать ext4 везде - модуля для ext2/3 в отдельном виде в ядрах больше не существует, а ext4.ko сам разберётся, что ему подсунули что-то меньшей версии.  А вот наоборт разбираться не будет: система не загрузится, если в fstab будет ext3, а реально ext4. То есть, последовательность такая:

1. написать в fstab для корня ext4 (в общем-то, для остальных разделов с ext2/3 тоже)
2. сделать скриптик
#!/bin/sh

/sbin/fsck.ext3 -pf /dev/$1
/sbin/tune2fs -j /dev/$1
/sbin/tune2fs -O extents,uninit_bg,dir_index /dev/$1
/sbin/fsck.ext4 -yfD /dev/$1
2. перевести корнень в r/o
3. запустить скриптик на нужном разделе
4. перевсти корень в r/w, или перегрузиться
5. Сделать "chattr +e" для всех файлов и каталогов. Или не делать, а ждать, пока перезапись сделается посредством dist-upgrade и т.п.

Если что-то пойдёт не так, я не виноват. :-)

Онлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Ну или e4defrag поиспользовать: http://rus-linux.net/MyLDP/admin/defragment-ext4.html

Оффлайн marsden

  • Давно тут
  • **
  • Сообщений: 42
Если что-то пойдёт не так, я не виноват. :-)

вот так всегда  :-D 
спасибо за скриптик, попробую

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Если что-то пойдёт не так, я не виноват. :-)

вот так всегда  :-D 

Всё гораздо проще.
В системе на sysvinit:

Шо имеем в счётчиках корневой?
# tune2fs -l /dev/sda8 | grep -i 'mount count\|check'
Mount count:              220
Maximum mount count:      -1
Last checked:             Mon Apr 30 07:28:44 2018
Check interval:           0 (<none>)

Устанавливаем:
-i 1m - проверять каждый месяц
-c 30 - допустимое количество монтирований без проверки
-C 30 - принудительно устанавливаем счётчик монтирований корневой, заставляя на перезагрузке выполнить проверку
# tune2fs -c 30 -C 30 -i 1m /dev/sda8
tune2fs 1.42.13 (17-May-2015)
Setting maximal mount count to 30
Setting current mount count to 30
Setting interval between checks to 2592000 seconds

Соответственно установили
# tune2fs -l /dev/sda8 | grep -i 'mount count\|check'
Mount count:              30
Maximum mount count:      30
Last checked:             Mon Apr 30 07:28:44 2018
Check interval:           2592000 (1 month)
Next check after:         Wed May 30 07:28:44 2018

Перегружаемся и получаем
# grep -rHi 'check force\|sda9: clean,' /var/log | grep 'Sep 24'
/var/log/daemons/info:Sep 24 13:32:16 core-i3-5005u fsck: /dev/sda8 has been mounted 30 times without being checked, check forced.
/var/log/daemons/info:Sep 24 13:32:16 core-i3-5005u fsck: /dev/sda9: clean, 83844/11124736 files, 31696812/44497408 blocks
/var/log/syslog/messages:Sep 24 13:32:16 core-i3-5005u fsck: /dev/sda8 has been mounted 30 times without being checked, check forced.
/var/log/syslog/messages:Sep 24 13:32:16 core-i3-5005u fsck: /dev/sda9: clean, 83844/11124736 files, 31696812/44497408 blocks

Счётчик Mount count после перезагрузки с проверкой сбросился и начал новый отсчёт количества монтирований корневой:
# tune2fs -l /dev/sda8 | grep -i 'mount count\|check'
Mount count:              1
Maximum mount count:      30
Last checked:             Mon Sep 24 16:32:02 2018
Check interval:           2592000 (1 month)
Next check after:         Wed Oct 24 16:32:02 2018

Если компьютер включится позднее чем Wed Oct 24 16:32:02 2018, то проверка будет выполнена на первой же загрузке.

Может это в Советы отправить? Что-то под названием:
Настройка проверки файловой системы на загрузке
« Последнее редактирование: 24.09.2018 14:02:30 от Speccyfighter »

Онлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Всё гораздо проще.
В системе на sysvinit:
Это вообще не имеет отношения к решению проблемы внезапной долгой проверки при перезагрузке в случайный момент времени. Это всего лишь меняет правила возникновения события, не удаляя случайности его самого. Переход же на ext4 минимизирует время на провеку в момент возникновения этого случайного события, переход на btrfs (и какие-то другие ФС) вообще устраняет событие.

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Всё гораздо проще.
В системе на sysvinit:
Это вообще не имеет отношения к решению проблемы внезапной долгой проверки при перезагрузке в случайный момент времени.

Если файловая была например не чисто размонтирована, почему проверка не должна выполняться?

Переход же на ext4 минимизирует время на провеку

Если он устанавливает(вил) систему на базе p8, ему незачем переходить на ext4, она и так там по-умолчанию.