61097 2026-10-16 12:00:23 +0300 proftpd: systemctl stop/restart не останавливает демон в standalone-режиме (несогласованное расположение pidfile, отсутствует systemd-юнит) 2026-10-16 15:15:37 +0300 1 1 1 Unclassified Branch p10 proftpd не указана x86_64 Linux RESOLVED WONTFIX https://bugzilla.altlinux.org/show_bug.cgi?id=51209 P5 normal --- 1 varaksaaa qa-p10 amakeenk qa-p10 oldest_to_newest 302600 0 varaksaaa 2026-10-16 12:00:23 +0300 Проблема, решённая в #51209, актуальна, но проявляется по-другому (сервис запускается, но впоследствии не перезапускается), поэтому отдельная ошибка. ### Описание проблемы На системе с пакетом proftpd из p10 (1.3.6-alt0.4.ga73dbfe3b), работающем в standalone-режиме, `systemctl stop proftpd` и `systemctl restart proftpd` фактически не останавливают процесс демона: - `systemctl stop proftpd` возвращает успех (rc=0), однако процесс proftpd продолжает работать. В журнале systemd при этом: «Unit process NNNN (proftpd) remains running after unit stopped», «Found left-over process NNNN (proftpd). Ignoring». - После `systemctl restart proftpd` новое приложение сразу завершается, а в журнале появляется: ``` proftpd[3409]: <HOST_IP> - Failed binding to 0.0.0.0, port 7777: Address already in use proftpd[3409]: <HOST_IP> - Check the ServerType directive to ensure you are configured correctly proftpd[3409]: <HOST_IP> - Check to see if inetd/xinetd, or another proftpd instance, is already using 0.0.0.0, port 7777 proftpd[3409]: <HOST_IP> - Unable to start proftpd; check logs for more details ``` Старый же инстанс (PID до рестарта) продолжает слушать порт и обслуживает старые настройки; `systemctl status proftpd` при этом сообщает, что сервис активен (active). - Единственные способы остановить демон — перезагрузка системы либо ручное завершение процесса. В результате любые изменения конфигурации молча не применяются: сервер продолжает работать со старой конфигурацией. ### Воспроизведение 1. Чистая система с пакетом proftpd из p10 (1.3.6-alt0.4.ga73dbfe3b). 2. В /etc/proftpd.conf установить standalone-режим: `ServerType standalone` (порт — 21 по умолчанию или иной; штатно поставляемый файл конфигурации содержит `ServerType inetd`, для реального использования сервера директива меняется на standalone). 3. `# systemctl start proftpd` 4. Убедиться, что демон работает, и запомнить его PID: `# ss -tulpn | grep :21` 5. Изменить конфигурацию (например, сменить порт либо добавить любую директиву). 6. `# systemctl restart proftpd` 7. `# ss -tulpn | grep :21`, `# systemctl status proftpd`, `journalctl -u proftpd` Ожидаемый результат: старый процесс остановлен, демон перезапущен с новыми настройками (новый PID). Фактический результат: в списке портов по-прежнему старый процесс (PID из п. 4), например: ``` tcp 0 0 0.0.0.0:7777 0.0.0.0:* LISTEN 3164/proftpd: (acce ``` новый инстанс в списке процессов отсутствует, в журнале — «Failed binding to 0.0.0.0, port …: Address already in use», а `systemctl status proftpd` сообщает, что сервис активен. ### Причина Три взаимодействующих дефекта пакета (проверено на уровне исходников): 1. Расхождение между фактическим расположением pidfile демона и тем, которое использует init-скрипт: - /etc/init.d/proftpd: `PIDFILE=/run/proftpd/proftpd.pid`; остановка/статус выполняются через `stop_daemon --pidfile "$PIDFILE" --lockfile "$LOCKFILE" --expect-user nobody proftpd`; - поставляемый /etc/proftpd.conf не содержит директивы `PidFile`; - демон при этом использует значение по умолчанию, скомпилированное при сборке: в исходниках proftpd `configure.in` определяет `PR_PID_FILE_PATH = "${localstatedir}/proftpd.pid"`, а `src/pidfile.c` использует его как путь по умолчанию (`static const char *pidfile_path = PR_PID_FILE_PATH;`); - spec-файл собирается с `--localstatedir=/var/lib/proftpd`, то есть pidfile фактически пишется в /var/lib/proftpd/proftpd.pid; - правило tmpfiles пакета лишь создаёт пустой каталог /run/proftpd (`d /run/proftpd 0750 root root -`). В итоге stop()/status() не находят pidfile, сообщают «not running» (rc=0) и не завершают никого, а start() всегда запускает новый инстанс. 2. В пакете отсутствует systemd-юнит, поэтому systemd использует сгенерированный из init-скрипта юнит (systemd-sysv-generator): Type=forking, KillMode=process, GuessMainPID=no, PIDFile не задан. MainPID не определяется (0), и `systemctl stop` не завершает ни одного процесса. 3. Init-скрипт печатает «[ DONE ]» сразу после fork и не проверяет, что новый инстанс действительно стартовал; гибель нового инстанса («Failed binding … Address already in use») видна только в журнале. Итог: после stop/restart старый процесс со старой конфигурацией продолжает обслуживать подключения, сервис при этом отчитывается о штатном состоянии, а о проблеме можно узнать только по журналу. ### История дефекта - proftpd 1.3.6-alt0.2.ga73dbfe3b (2019-12-25, closes #37187): «change localstatedir=/var/lib/proftpd instead /var/run/proftpd» — место pidfile по умолчанию было перенесено из /var/run/proftpd в /var/lib/proftpd, при этом PIDFILE в init-скрипте (/run/proftpd/proftpd.pid) с новым местом согласован не был. Расхождение сохраняется во всех последующих сборках. - 1.3.8-alt0.3.ga3489a6c8 (2023-09-27, sisyphus и p11): добавлен systemd-юнит proftpd.service (PIDFile=/run/proftpd/proftpd.pid) — всё равно не совпадающий с фактическим расположением pidfile в сборках с `--localstatedir=/var/lib/proftpd`; в p11 расхождение присутствовало вплоть до 1.3.8-alt0.3.ga3489a6c8. - Исправление: sisyphus 1.3.9-alt0.3.rc2 (2024-08-20) и p11 1.3.8-alt0.3.ga3489a6c8.p11 (2025-11-24): «Fix runstatedir (closes #51209)» — `--localstatedir=%_runstatedir/%name` (т. е. /run/proftpd), в результате чего расположение pidfile демона совпало с init-скриптом и systemd-юнитом. ### Проверка по версиям - p10, proftpd 1.3.6-alt0.4.ga73dbfe3b: дефект присутствует (проверено на уровне исходников: proftpd.init, proftpd.conf, proftpd.spec, а также исходники proftpd-1.3.6 — configure.in и src/pidfile.c). - p11, proftpd 1.3.8-alt0.3.ga3489a6c8.p11: дефект отсутствует (проверено на системе: pidfile создаётся в /run/proftpd/proftpd.pid, MainPID юнита совпадает с PID из pidfile, `systemctl stop`/`restart` корректно останавливают и запускают демон). - sisyphus, proftpd 1.3.9-alt4.c: дефект отсутствует (на уровне исходников: `--localstatedir=%_runstatedir/%name` в spec и systemd-юнит с PIDFile=/run/proftpd/proftpd.pid). ### Предлагаемое исправление для p10 Бэкпорт изменений, внесённых в p11/sisyphus: 1. В %configure заменить `--localstatedir=/var/lib/proftpd` на `--localstatedir=%_runstatedir/%name`; 2. Поставить в пакет systemd-юнит proftpd.service: ``` [Unit] Description=ProFTPD FTP Server After=network.target [Service] Type=forking PIDFile=/run/proftpd/proftpd.pid ExecStart=/usr/sbin/proftpd ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy = multi-user.target ``` 3. В %files добавить `%_unitdir/%name.service` и заменить `%dir /var/lib/%name` на `%dir %_runstatedir/%name` (правило tmpfiles для /run/proftpd уже присутствует в spec). Альтернативный минимальный вариант: добавить директиву `PidFile /run/proftpd/proftpd.pid` в поставляемый /etc/proftpd.conf — init-скрипт и сгенерированный юнит начнут корректно работать, однако отсутствие собственного systemd-юнита при этом сохранится. 302620 1 lakostis 2026-10-16 14:06:55 +0300 я не занимаюсь бэкпортами, обратитесь с этой проблемой в ООО 302632 2 amakeenk 2026-10-16 15:15:37 +0300 В р10, скорее всего, это исправляться уже не будет.