Что необходимо, чтобы минимальная начальная загрузка systemd запустила getty на виртуальной консоли?
Поскольку jordanm сказал, logrotate является лучшим. Но если Вы действительно хотите к самокрутке,
tail -n 50 logfile.txt > logfile.new
mv logfile.new logfile.txt
сохранил бы только последние 50 строк.
Во-первых, системаd не является традиционным униксом init. Systemd намного больше, поэтому сравнивать их немного несправедливо.
Для ответа на вопрос, кажется, что необходимы некоторые двоичные файлы и следующие конфигурационные файлы:
/usr/lib/systemd/system/default.target /usr/lib/systemd/system/basic.target /usr/lib/systemd/system/sysinit.target /usr/lib/systemd/system/getty.target /usr/lib/systemd/system/getty@.service /usr/lib/systemd/system/console-getty.service
выдача systemctl для включения консольного getty.service getty@tty2.service, затем создание этих симлинков:
/etc/systemd/system/default.target.wants/getty@tty2.service -> /lib/systemd/system/getty@service /etc/systemd/system/getty.target.wants/console-getty.service -> /lib/systemd/system/console-getty.service
ПРИМЕЧАНИЕ: Чтобы использовать специальные возможности systemd для динамического запуска agetty, при нажатии Alt+F3 и т.д., кажется, что вы также должны иметь как минимум эти два файла:
/etc/systemd/logind.conf /lib/systemd/system/autovt@.service
где autovt@. service является сим-ссылкой на getty@.service.
Содержимое файлов конфигурации:
Файлы default.target, getty.target, sysinit.target могут быть пустыми, за исключением тега [Unit] и (возможно) Description=xxx.
basic.target также содержит информацию о зависимостях:
[Unit] Description=Basic System Requires=sysinit.target Wants=sockets.target timers.target paths.target slices.target After=sysinit.target sockets.target timers.target paths.target slices.target
Я не уверен, нужны ли ссылки на цели, которые не существуют в виде файлов или нет. Они описаны на странице man systemd.special(7) man page.
console-getty.service: (Особый случай для agetty на консоли)
[Unit] Description=Console Getty After=systemd-user-sessions.service plymouth-quit-wait.service Before=getty.target [Service] ExecStart=-/sbin/agetty --noclear --keep-baud console 115200,38400,9600 $TERM Type=idle Restart=always RestartSec=0 UtmpIdentifier=cons TTYPath=/dev/console TTYReset=yes TTYVHangup=yes KillMode=process IgnoreSIGPIPE=no SendSIGHUP=yes [Install] WantedBy=getty.target
getty@.service: (общая конфигурация для всех сервисов getty, кроме console)
[Unit] Description=Getty on %I After=systemd-user-sessions.service plymouth-quit-wait.service Before=getty.target IgnoreOnIsolate=yes ConditionPathExists=/dev/tty0 [Service] ExecStart=-/sbin/agetty --noclear %I $TERM Type=idle Restart=always RestartSec=0 UtmpIdentifier=%I TTYPath=/dev/%I TTYReset=yes TTYVHangup=yes TTYVTDisallocate=no KillMode=process IgnoreSIGPIPE=no SendSIGHUP=yes [Install] WantedBy=getty.target DefaultInstance=tty1
Наконец, вам, вероятно, понадобится несколько этих специальных двоичных файлов (я не пробовал, какие из них решающие):
/lib/systemd/systemd (/sbin/init usually points to this) /lib/systemd/systemd-logind /lib/systemd/systemd-cgroups-agent /lib/systemd/systemd-user-sessions /lib/systemd/systemd-vconsole-setup /lib/systemd/systemd-update-utmp /lib/systemd/systemd-sleep /lib/systemd/systemd-sysctl /lib/systemd/systemd-initctl /lib/systemd/systemd-reply-password /lib/systemd/systemd-ac-power /lib/systemd/systemd-activate /lib/systemd/systemd-backlight /lib/systemd/systemd-binfmt /lib/systemd/systemd-bootchart /lib/systemd/systemd-bus-proxyd /lib/systemd/systemd-coredump /lib/systemd/systemd-cryptsetup /lib/systemd/systemd-fsck /lib/systemd/systemd-hostnamed /lib/systemd/systemd-journald /lib/systemd/systemd-journal-gatewayd /lib/systemd/systemd-journal-remote /lib/systemd/systemd-localed /lib/systemd/systemd-machined /lib/systemd/systemd-modules-load /lib/systemd/systemd-multi-seat-x /lib/systemd/systemd-networkd /lib/systemd/systemd-networkd-wait-online /lib/systemd/systemd-quotacheck /lib/systemd/systemd-random-seed /lib/systemd/systemd-readahead /lib/systemd/systemd-remount-fs /lib/systemd/systemd-resolved /lib/systemd/systemd-rfkill /lib/systemd/systemd-shutdown /lib/systemd/systemd-shutdownd /lib/systemd/systemd-socket-proxyd /lib/systemd/systemd-timedated /lib/systemd/systemd-timesyncd /lib/systemd/systemd-udevd /lib/systemd/systemd-update-done
Чтобы подвести итог процессу запуска systemd, я думаю, что он работает примерно так:
- systemd находит
basic.target(или все*. целевыефайлы?) - зависимости разрешаются на основе
WantedBy=,Wants=,Before=,After=... директив в разделе[Install]конфигурационных файлов*.serviceи*.target. В *.service, которые должны запускаться (не являются "специальными" службами), имеется раздел[Service]с директивойExecStart=, в котором указан исполняемый файл, который нужно запустить.
systemd автоматически создает getty при переключении на терминалы. , до определенного максимального числа. По умолчанию - 6 (так что вы автоматически получаете getty от alt + f1 до alt + f6). Если вы хотите изменить этот параметр, вы можете отредактировать /etc/systemd/logind.conf , чтобы изменить параметр NAutoVTs на другое число (максимум 12)
Если вам нужен getty для создания, даже если вы не переключаете вручную, вы можете добавить символическую ссылку на /usr/lib/systemd/system/getty@.service на /etc/systemd/system/getty.target Каталог .wants / :
ln -sf /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
в результате getty.target потребует еще одну службу getty @ .
Цель - это набор сервисов, которые необходимо создать, замена уровней выполнения, которые поддерживают зависимости. Цель по умолчанию зависит от getty.target
edit: Я изучил немного больше в документации .
При загрузке демон systemd загружает все системы в цели по умолчанию и их зависимости. Цель определяется файлами
/etc/systemd/system/default.target
/usr/lib/systemd/system/default.target
У цели есть список подключенных служб, указанных символическими ссылками в каталогах
/etc/systemd/system/default.target.wants
/usr/lib/systemd/system/default.target.wants
Версия / etc переопределяет значения по умолчанию для распространения в / usr / lib . Требуется только один из файлов .target , в то время как ни один из каталогов не требуется.
getty - это лишь одна из служб среди других, которые могут запускаться с помощью сценариев инициализации. В проверенном мной дистрибутиве (fedora, arch) getty запускается двумя разными способами:
- Запускается определенными сценариями для каждого терминала (ссылки на
/ usr / lib / systemd / system / getty @ .service, в котором имя tty заменено наsystemdиз имени файла ссылки ) - Автоматически вызывается при необходимости
logind, когда пользователь переключается на виртуальный терминал (аналогично тому, как старыйinetdзапускал службы только при поступлении запроса).logind- это другой демон, распространяемый сsystemd, и считывает его конфигурацию из файла/etc/systemd/logind.conf.
Надеюсь, это удовлетворительно.
После некоторых экспериментов я обнаружил, что одной целевой -сервисной пары достаточно для загрузки. Скопировано изemergency.service:
[Unit]
DefaultDependencies=no
Description=shell.service: Console and Login
[Service]
Environment=HOME=/root
WorkingDirectory=-/root
ExecStart=-/usr/lib/systemd/systemd-sulogin-shell
ExecStartPost=/usr/bin/openvt -f -c 16 agetty tty16
ExecStartPost=/usr/bin/openvt -f -c 17 -- agetty -p tty17
ExecStartPost=/usr/bin/openvt -f -c 18 -- agetty -p -a USER tty18
Type=idle
StandardInput=tty-force
StandardOutput=inherit
StandardError=inherit
#KillMode=process
KillMode=control-group
IgnoreSIGPIPE=no
SendSIGHUP=yes
Для тестирования :переименование каталога юнитов дистрибутива в /lib/systemd/systemDEACT— это простой, но радикальный способ уменьшить количество юнитов/юнит -файлов с 200 до 10; есть еще ложные:
UNIT LOAD ACTIVE SUB DESCRIPTION
dev-sda3.device loaded activating tentative /dev/sda3
-.mount loaded active mounted Root Mount
tmp.mount loaded active mounted /tmp
init.scope loaded active running System and Service Manager
io.service loaded inactive dead io: usbhid kmod for keyboard
remount.service loaded inactive dead remount: rw for / and tmpfs for /tmp
shell.service loaded active running shell.service: Console and Login
-.slice loaded active active Root Slice
system.slice loaded active active System Slice
* systemd-journald.socket not-found inactive dead systemd-journald.socket
* local-fs-pre.target not-found inactive dead local-fs-pre.target
* local-fs.target not-found inactive dead local-fs.target
mini.target loaded active active "mini": Minimal Boot and Shell
* swap.target not-found inactive dead swap.target
* umount.target not-found inactive dead umount.target
Рядом сshell.service(см. вверху )я сделал remount.serviceи io.service; modprobe usbhidимеет решающее значение для моего (любого? )USB-клавиатура. Службе перемонтирования требуется синхронизация с fsck в сценарии initrd в Arch для перемонтирования и с tmp.mount для /tmp. Я также должен выяснить, где правильно разместить этот rwна KCL... тем временем я получаю пару зеленых [OK]при загрузке от двух oneshot и одного бездействующего услуги.
Дерево зависимостей::
mini.target
* |-io.service
* |-remount.service
* `-shell.service
С моим remountизбыточным/конфликтующим с KCL и ioпросто выполнением modprobe usbhid(, что можно сделать с ExecStart...в shell.serviceтакже ), это всего лишь одна пара цель/служба. Плюс ссылка default.target, если вы не добавите systemd.unit=mini.targetв CL ядра.
Я часами гонялся за предварительнымdev-sdaX.device(единственным корневым разделом ); теперь я думаю, что это наполовину нормально.
-.mount, -.sliceи init.scopeявляются внутренними и имеют смысл.
tmp.mountДумаю, сгенерировано в /run.
Единицы not-foundjournald, local -fs, swap и umount, похоже, не вредят systemd; с --state loadedони не показаны. Вероятно, их следует создавать в качестве первых дополнительных единиц. Но как определить local-fs, если корневой раздел уже проверен из initrd? Может ли загрузка с initrd быть минимальной ?
systemctl statusтакже минимальна. Слайс есть, но только один (нет пользователя -X слайсов):
* archlinux
State: running
Jobs: 0 queued
Failed: 0 units
Since: Fri 2021-10-01 15:24:16 UTC; 3min 2s ago
CGroup: /
|-init.scope
| `-1 /sbin/init arch\x5cvmlinuz-linux
`-system.slice
`-shell.service
|-215 /usr/lib/systemd/systemd-sulogin-shell
|-219 bash
|-220 agetty tty16
|-222 agetty -p tty17
|-225 agetty -p -a USER tty18
`-238 systemctl status
С помощью KillModeвы можете контролировать, что происходит с процессами внутри shell.service. Соответствующий ps axfравен:
1 ? Ss 0:00 /sbin/init arch\vmlinuz-linux
215 tty1 Ss 0:00 /usr/lib/systemd/systemd-sulogin-shell
219 tty1 S 0:00 \_ bash
245 tty1 R+ 0:00 \_ ps axf
246 tty1 S+ 0:00 \_ tail -8
220 tty16 Ss+ 0:00 agetty tty16
222 tty17 Ss+ 0:00 agetty -p tty17
225 tty18 Ss+ 0:00 agetty -p -a USER tty18
У agettyнет родителя -благодаря openvt? -но PID1/init/systemd по-прежнему отслеживает pid. Мне удалось перезапустить shell.serviceс разными KillModeс.
Не рекомендуется использовать ctrl-Dили exitна этой оболочке sulogin -...
И как мне все это прекратить?
После этого радикального каталога -переименуйте команду reboot«не могу разговаривать с демоном инициализации» или около того. (копия)reboot.serviceс действиемreboot-force(без перезагрузки, без перезагрузки -немедленно )является наиболее прямым выходом и достаточна для этой тестовой загрузки (без запуска журнала и т. д. ). Выключение Sysvinit не очень элегантное и быстрое. Затем systemctl start rebootвыполняет сигнализацию и отключение PID, а также sync(, я полагаю, ), но никакое иное упорядоченное отключение. Это было бы с "конечной" или "закрытой" целью,откуда вы можете перейти к CPU reboot, poweroffили halt. С выключением или без него -initramfs.
Итак, systemdможет запускаться и работать (и останавливаться! )без journald, udevd и dbus и всех этих юнит-файлов и --userэкземпляров. Но трудно "супермаскировать" (, т.е. заставить уйти )200 дистрибутивных -юнитов, и тогда еще остаются какие-то следы встроенных -в юниты и встроенных -в логику.
TL;DR :emergency.target, DefaultDependencies=no,openvt