Перецепляю под отдельный bug #28008.
Можно проверять: http://git.altlinux.org/tasks/84795
alterator-fbi-5.28-alt1 -> sisyphus: * Thu Nov 22 2012 Paul Wolneykien <manowar@altlinux> 5.28-alt1 - Do not daemonize in socket-activation mode (closes: 27865). - Add the systemd unit files. - Start the server on the given socket if any (closes: 27987).
В service файле не производится генерация ssl сертификата.
в .socket юните не реализован механизм настройки номера порта через EnvironmentFile.
(В ответ на комментарий №4) > В service файле не производится генерация ssl сертификата. А можно на пальцах, что имеется в виду? Проверка и обновление сертификата скриптом в ExecStartPre? Или что-то более systemd-специфичное?
(В ответ на комментарий №5) > в .socket юните не реализован механизм настройки номера порта через > EnvironmentFile. С этим понятно, делал такое для squidmill. Есть пожелания, куда положить конфигурационный файл? Хотя /etc/ahttpd.conf может подойти…
(В ответ на комментарий №6) > (В ответ на комментарий №4) > > В service файле не производится генерация ssl сертификата. > > А можно на пальцах, что имеется в виду? Проверка и обновление сертификата > скриптом в ExecStartPre? Или что-то более systemd-специфичное? Добавить перед ExecStart, директиву - "ExecPreStart=/usr/bin/cert-sh ahttpd"
(В ответ на комментарий №7) > (В ответ на комментарий №5) > > в .socket юните не реализован механизм настройки номера порта через > > EnvironmentFile. > > С этим понятно, делал такое для squidmill. Есть пожелания, куда положить > конфигурационный файл? Хотя /etc/ahttpd.conf может подойти… Скорее всего да, нужно использовать /etc/ahttpd/ahttpd.conf. Только проверить надо, сможет ли systemd распарсить такой конфиг.
(В ответ на комментарий №9) > (В ответ на комментарий №7) > > (В ответ на комментарий №5) > > > в .socket юните не реализован механизм настройки номера порта через > > > EnvironmentFile. > > > > С этим понятно, делал такое для squidmill. Есть пожелания, куда положить > > конфигурационный файл? Хотя /etc/ahttpd.conf может подойти… > > Скорее всего да, нужно использовать /etc/ahttpd/ahttpd.conf. Только проверить > надо, сможет ли systemd распарсить такой конфиг. Ничего, если что, то мы немного прогнём конфиг в сторону systemd.
(В ответ на комментарий №9) > Скорее всего да, нужно использовать /etc/ahttpd/ahttpd.conf. Только проверить > надо, сможет ли systemd распарсить такой конфиг. Не сможет. В man четко написано какой это должен быть конфиг: The text file should contain new-line separated variable assignments. (В ответ на комментарий №10) > Ничего, если что, то мы немного прогнём конфиг в сторону systemd. Если менять формат конфига, то с сохранением обратной совместимости. При этом стоит учитывать, что переменных окружения с "-" в имени не бывает.
(В ответ на комментарий №11) > (В ответ на комментарий №9) > > Скорее всего да, нужно использовать /etc/ahttpd/ahttpd.conf. Только проверить > > надо, сможет ли systemd распарсить такой конфиг. > > Не сможет. В man четко написано какой это должен быть конфиг: > The text file should contain new-line separated variable assignments. > > (В ответ на комментарий №10) > > Ничего, если что, то мы немного прогнём конфиг в сторону systemd. > > Если менять формат конфига, то с сохранением обратной совместимости. > При этом стоит учитывать, что переменных окружения с "-" в имени не бывает. Я решил, что из-за одной-двух переменных не стоит городить огород. Потому что даже User=$server_user по какой-то причине, не работает.
> Я решил, что из-за одной-двух переменных не стоит городить огород. Потому что > даже User=$server_user по какой-то причине, не работает. sem@ говорит, что systemd не может сорсить файл такого формата.
Да нет, я уже не про формат, а про то, что, видимо, переменные можно использовать только для ограниченного числа директив. И для User переменную подставить нельзя. Как выяснилось, для ListenStream тоже. [Socket] EnvironmentFile=/etc/ahttpd/ahttpd.env ListenStream=$server_port Не работает. И Google ничего не находит по запросу systemd + ListenStream=$. Видимо они там крепко что-то не доработали в этом systemd. Ну или я что-то крепко не понял… :)
(В ответ на комментарий №5) > в .socket юните не реализован механизм настройки номера порта через > EnvironmentFile. Если я, всё таки, всё понял правильно, то выходит, что технических средств использовать EnvironmentFile в *.socket нет. Так что оставляем его как есть. Обновление SSL сейчас соберу.
alterator-fbi-5.28-alt4 -> sisyphus: * Thu Dec 06 2012 Paul Wolneykien <manowar@altlinux> 5.28-alt4 - Check/generate the SSL certificate before starting the service from systemd (closes: 27987).
$ git --git-dir=/gears/a/alterator-fbi.git grep ExecPreStart sisyphus sisyphus:alterator-fbi/systemd/system/ahttpd.service:ExecPreStart=/usr/bin/cert-sh ahttpd ExecPreStart? Пакет с изменением в файле ahttpd.service перед отправкой в Сизиф не тестировался на systemd совсем?
Совсем. Я так понял, что мне был передан готовый рецепт. Но оказалось, что там было целых две ошибки. Правильно так: ExecStartPre=/usr/bin/cert-sh generate "ahttpd" Проверил, сертификат обновляется. Но всё равно теперь прошу провести приёмку перед отправкой в Сизиф: http://git.altlinux.org/tasks/85685/
(В ответ на комментарий №18) > Совсем. Я так понял, что мне был передан готовый рецепт. Но оказалось, что > там было целых две ошибки. Правильно так: > > ExecStartPre=/usr/bin/cert-sh generate "ahttpd" > > Проверил, сертификат обновляется. Но всё равно теперь прошу провести приёмку > перед отправкой в Сизиф: http://git.altlinux.org/tasks/85685/ генерация сертификата работает. Нужно убрать из юнита директиву Also, она тут не нужна.
А ты в курсе, что просто по # systemctl start ahttpd.service сервер не работает, поскольку процесс сразу же завершается. Необходимо, чтобы сокет уже прослушивался (ahttpd.socket был запущен) к моменту запуска ahttpd.service. Видимо, я его слишком заточил на socket activation. И вроде бы именно это и рекомендуется в мануале: --- Type=simple --- In this mode, if the process offers functionality to other processes on the system its communication channels should be installed before the daemon is started up (e.g. sockets set up by systemd, via socket activation). --- И хотя директива Also=ahttpd.socket не помогает запускать прослушивание сокета при старте службы, она хотя бы синхронизирует enable/disable. Точно нужно убрать её?
(В ответ на комментарий №20) > А ты в курсе, что просто по > > # systemctl start ahttpd.service > > сервер не работает, поскольку процесс сразу же завершается. Необходимо, чтобы > сокет уже прослушивался (ahttpd.socket был запущен) к моменту запуска > ahttpd.service. Видимо, я его слишком заточил на socket activation. > > И вроде бы именно это и рекомендуется в мануале: > --- Type=simple --- > In this mode, if the process offers functionality to other processes on the > system its communication channels should be installed before the daemon is > started up (e.g. sockets set up by systemd, via socket activation). > --- > > И хотя директива Also=ahttpd.socket не помогает запускать прослушивание сокета > при старте службы, она хотя бы синхронизирует enable/disable. Точно нужно > убрать её? 1. Зачем делать "systemctl start ahttpd.service", как и enable, если используется socket активация? 2. Ты не правильно трактуешь документацию 3. Почему реализовал поддержку socket активации в ahttpd, выкинув возможность работы без оной? (cups работает как с socket активацией, так и без нее) 4. Параметр "Alsо" не нужен
(В ответ на комментарий №21) > 1. Зачем делать "systemctl start ahttpd.service", как и enable, если > используется socket активация? Я просто не знаю, как происходит загрузка системы с systemd. Если ты считаешь, что это нормальное поведение, то так и скажи. > 2. Ты не правильно трактуешь документацию Очень возможно. > 3. Почему реализовал поддержку socket активации в ahttpd, выкинув возможность > работы без оной? (cups работает как с socket активацией, так и без нее) Здесь тонкий момент. Прямой запуск ahttpd работает без всяких дополнительных сокетов, и обратная совместимость сохранена. Но при запуске через `systemctl start ahttpd` процесс моментально завершается. Может быть systemd передаёт ему закрытый сокет? Буду разбираться. > 4. Параметр "Alsо" не нужен ОК. Эту багу можно считать закрытой?
alterator-fbi-5.28-alt5 -> sisyphus: * Mon Dec 10 2012 Paul Wolneykien <manowar@altlinux> 5.28-alt5 - Add the 'PIDFile' option to the service unit. - Remove the 'Also=ahttpd.socket' option. - Fix the service unit file syntax and the SSL generator command (closes: 27987).
(In reply to comment #23) > alterator-fbi-5.28-alt5 -> sisyphus: > > * Mon Dec 10 2012 Paul Wolneykien <manowar@altlinux> 5.28-alt5 > - Add the 'PIDFile' option to the service unit. Зачем PIDFile? Разве его кто-то создает для simple service?
(В ответ на комментарий №24) > (In reply to comment #23) > > alterator-fbi-5.28-alt5 -> sisyphus: > > > > * Mon Dec 10 2012 Paul Wolneykien <manowar@altlinux> 5.28-alt5 > > - Add the 'PIDFile' option to the service unit. > > Зачем PIDFile? Разве его кто-то создает для simple service? Я думал, что может быть это поможет идентифицировать процесс, запущенный не через systemd. Но раз не нужен, уберу тогда.
alterator-fbi-5.28-alt6 -> sisyphus: * Mon Dec 10 2012 Paul Wolneykien <manowar@altlinux> 5.28-alt6 - Remove the 'PIDFile' option from the service unit file (closes: 27987).
Итак, что мы имеем в alterator-fbi-5.28-alt6: - ahttpd.service упакован, это хорошо; - ahttpd.socket упакован, это хорошо; - systemctl start ahttpd.service не работает, см. https://bugzilla.altlinux.org/show_bug.cgi?id=27987#c20 , это плохо; - ahttpd.service включается по умолчанию при установке пакета, что в сочетании с предыдущим пунктом получается плохо; - ahttpd.socket не включается по умолчанию при установке пакета, что в сочетании с предыдущим пунктом получается совсем плохо. 2 manowar@, amike@: Пожалуйста, относитесь к своей работе профессионально! Мне надоело исполнять обязанности QA и в который раз уже переоткрывать этот баг. Или вам не надо, чтобы ahttpd работал из коробки в дистрибутивах? Напрягитесь уже, что ли, заставьте себя внимательнее прочитать документацию по systemd, если без этого не получается, тестируйте тщательнее!
(В ответ на комментарий №27) > - systemctl start ahttpd.service не работает, см. > https://bugzilla.altlinux.org/show_bug.cgi?id=27987#c20 , это плохо; Дим, ну работает же. # rpm -q alterator-fbi alterator-fbi-5.28-alt6 # systemctl status ahttpd.socket ahttpd.socket - Alterator WWW frontend server (socket) Loaded: loaded (/lib/systemd/system/ahttpd.socket; enabled) Active: inactive (dead) since Wed, 2012-12-12 13:27:20 MSK; 11s ago CGroup: name=systemd:/system/ahttpd.socket # systemctl status ahttpd.service ahttpd.service - Alterator WWW frontend server Loaded: loaded (/lib/systemd/system/ahttpd.service; enabled) Active: inactive (dead) since Wed, 2012-12-12 13:27:17 MSK; 39s ago Process: 27846 ExecStart=/usr/sbin/ahttpd (code=killed, signal=TERM) Process: 27838 ExecStartPre=/usr/bin/cert-sh generate ahttpd (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/ahttpd.service # systemctl start ahttpd.service # systemctl status ahttpd.service ahttpd.service - Alterator WWW frontend server Loaded: loaded (/lib/systemd/system/ahttpd.service; enabled) Active: active (running) since Wed, 2012-12-12 13:28:16 MSK; 7s ago Process: 2764 ExecStartPre=/usr/bin/cert-sh generate ahttpd (code=exited, status=0/SUCCESS) Main PID: 2772 (ahttpd) CGroup: name=systemd:/system/ahttpd.service └ 2772 /usr/bin/guile18 -s /usr/sbin/ahttpd Я бы не стал закрывать баг, если бы не работало.
(В ответ на комментарий №27) > Итак, что мы имеем в alterator-fbi-5.28-alt6: > - ahttpd.service включается по умолчанию при установке пакета… > - ahttpd.socket не включается по умолчанию при установке пакета… Ничего нового, про %post_service/%preun_service или их аналоги на altlinux.org не написано (плохо искал?). Я сделал вывод, что текущее поведение умолчательное и правильное. Там ещё пачка триггеров, использующих /sbin/service и /sbin/chkconfig. Что с ними-то делать?
(In reply to comment #28) > (В ответ на комментарий №27) > > - systemctl start ahttpd.service не работает, см. > > https://bugzilla.altlinux.org/show_bug.cgi?id=27987#c20 , это плохо; > > Дим, ну работает же. Стало быть, "работает в некоторых случаях" и "работает в конфигурации по умолчанию" это теперь одно и то же?
(В ответ на комментарий №30) > (In reply to comment #28) > > (В ответ на комментарий №27) > > > - systemctl start ahttpd.service не работает, см. > > > https://bugzilla.altlinux.org/show_bug.cgi?id=27987#c20 , это плохо; > > > > Дим, ну работает же. > > Стало быть, "работает в некоторых случаях" и "работает в конфигурации по > умолчанию" это теперь одно и то же? 1. Удалил alterator-fbi и все конфиги. Перезагрузил. 2. Поставил alterator-fbi. Теперь уже точно «конфигурация по умолчанию». 3. Наблюдаю и ahttpd.service, и ahttpd.socket в состоянии disabled, в то время как ты пишешь, что один из них включается сам при установке пакета. Что я делаю не так? 4. Включаю оба юнита и перезагружаюсь. Панель управления доступна через браузер. По поводу включения юнитов при установке. Могу добавить в спек строки вроде /bin/systemctl enable ahttpd.socket || chkconfig ahttpd on Или есть лучший способ?
> 4. Включаю оба юнита и перезагружаюсь. Панель управления доступна через > браузер. Все-таки хотелось бы уточнить: а если enabled только ahttpd.service?
(В ответ на комментарий №32) > > 4. Включаю оба юнита и перезагружаюсь. Панель управления доступна через > > браузер. > > Все-таки хотелось бы уточнить: а если enabled только ahttpd.service? Отключил ahttpd.socket. Перезагрузился. Служба работает и доступна.
(В ответ на комментарий №31) > (В ответ на комментарий №30) > > (In reply to comment #28) > > > (В ответ на комментарий №27) > > > ahttpd.service включается по умолчанию при установке пакета… > > > ahttpd.socket не включается по умолчанию при установке пакета > По поводу включения юнитов при установке. Могу добавить в спек строки вроде > > /bin/systemctl enable ahttpd.socket || chkconfig ahttpd on > > Или есть лучший способ? Посмотрел openssh.spec и в его историю. Ничего про включение юнитов при установке не нашёл — только /sbin/service и chkconfig. Есть общепринятый способ это сделать? Или [пока ещё] нет? Может быть тогда просто делать нужные ссылки в /etc/systemd/system/*.target.wants ?
(В ответ на комментарий №34) > Посмотрел openssh.spec и в его историю. Ничего про включение юнитов при > установке не нашёл — только /sbin/service и chkconfig. Есть общепринятый способ > это сделать? Или [пока ещё] нет? > > Может быть тогда просто делать нужные ссылки в > /etc/systemd/system/*.target.wants ? Сейчас этот вопрос решается с ldv@, т.к. chkonfig ничего не знает о .socket, .path и .target юнитах. Так же не включаются по умолчанию сервисы с имеющимися init-скриптами.
(В ответ на комментарий №35) > (В ответ на комментарий №34) > > Посмотрел openssh.spec и в его историю. Ничего про включение юнитов при > > установке не нашёл — только /sbin/service и chkconfig. Есть общепринятый способ > > это сделать? Или [пока ещё] нет? > > > > Может быть тогда просто делать нужные ссылки в > > /etc/systemd/system/*.target.wants ? > > Сейчас этот вопрос решается с ldv@, т.к. chkonfig ничего не знает о .socket, > .path и .target юнитах. > Так же не включаются по умолчанию сервисы с имеющимися init-скриптами. 2ldv@, glebfm@, boyarsh@: Очень(!) прошу решить "этот вопрос", уже пора!
Насколько мне известно, всё давно уже готово.
