Проблема, решённая в #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-юнита при этом сохранится.