Summary: | [PATCH] lone systemd service support | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | viy <viy> |
Component: | service | Assignee: | placeholder <placeholder> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P3 | CC: | aen, glebfm, ldv, legion, piastryyy, placeholder, zerg |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux | ||
URL: | http://git.altlinux.org/people/viy/packages/?p=service.git;a=commit;h=a4217a0e9b96b5ba35590b913a60e5d27c8ade52 | ||
Bug Depends on: | |||
Bug Blocks: | 27685, 28704, 28705 |
Description
viy
2012-05-31 23:57:40 MSK
Proper support of a systemd-only service means that certain chkconfig calls are replaced by corresponding systemctl cals; just omitting chkconfig calls wouldn't qualify to be called "a support". (В ответ на комментарий №1)
> Proper support of a systemd-only service means that certain chkconfig calls are replaced by corresponding systemctl cals; just omitting chkconfig calls
> wouldn't qualify to be called "a support".
Let me recall that the corresponding systemctl calls are performed during the service(8) call (namely, /sbin/service "$1" condrestart), which is _NOT_ omitted in the proposed patch.
I recall, systemd services can be in enabled or disabled state, but system V scripts also have "not installed/uninstalled" state (when a system V script exists, but there are no symlinks in /etc/rc.d) so they need an additional chkconfig call.
systemd scripts does not have this state and just don't need an additional chkconfig call, so we are right to just skip it.
"у нас все точно" (С).
the whole idea about the service(8) command is that this command is a portable wrapper that hides the actual implementation (sysV, systemd, upstart,...) is used. So anayway using the actual systemd calls instead of service would be a bad style. For example, if user did use sysV init, nothing good happen if we call systemctl. How do you propose to implement "systemctl daemon-reload" and "systemctl disable specified.service" commands with "service"? Up to now this is implemented in chkconfig. (В ответ на комментарий №4) > How do you propose to implement "systemctl daemon-reload" and "systemctl > disable specified.service" commands with "service"? Up to now this is > implemented in chkconfig. Indeed. And I was even patching that code... I am deeply sorry. Proposed patch is invalid, chkconfig should be tuned instead. I created a patch that seems to fix the problem for me: http://git.altlinux.org/people/piastry/packages/?p=service.git;a=commitdiff;h=950540de8cf8e5987c5694a529efded393ed8bfa Thoughts? (В ответ на комментарий №6) > I created a patch that seems to fix the problem for me: > http://git.altlinux.org/people/piastry/packages/?p=service.git;a=commitdiff;h=950540de8cf8e5987c5694a529efded393ed8bfa Thanks! This is an important fix. service-0.5.24-alt1 -> sisyphus: * Thu Feb 28 2013 Dmitry V. Levin <ldv@altlinux> 0.5.24-alt1 - Implemented systemd-only service support in {post,preun}_service (closes: #27390) and native support of systemd services. Due to systemctl limitations, when systemd is active, post_service will no longer be able to enable sysv-only services. - Added /sbin/sd_booted utility. chkconfig --add some.service не работает. При этом systemctl enable some.service отрабатывает нормально Т.е. %post_service не работает. (In reply to comment #9) > chkconfig --add some.service > не работает. При этом > systemctl enable some.service > отрабатывает нормально > > Т.е. %post_service не работает. Если systemd активен, то %post_service использует systemctl вместо chkconfig, и если при этом сервис sysvinit-only, то он не будет включен. Об этом написано в %changelog'е пакета. См. тж. systemd.preset(5) и /lib/systemd/system-preset/99-default.preset Тогда вручную должно работать, как systemctl enable тотжесамый.service (В ответ на комментарий №11) > См. тж. systemd.preset(5) и /lib/systemd/system-preset/99-default.preset Т.е. вне зависимости от наличия %post_service в пакете, сервисы, указанные в preset-е включаются специальными триггерами? (In reply to comment #12) > Тогда вручную должно работать, как > systemctl enable тотжесамый.service systemctl enable тотжесамый.service работает. (In reply to comment #13) > (В ответ на комментарий №11) > > См. тж. systemd.preset(5) и /lib/systemd/system-preset/99-default.preset > Т.е. вне зависимости от наличия %post_service в пакете, сервисы, указанные в > preset-е включаются специальными триггерами? Нет, автоматически preset-ы сейсас никто не включает, их включает %post_service при первой установке пакета. Хотя это действительно можно было бы реализовать файлтриггерами, %post_service все равно нужен, так что зачем? Зачем пытаться кое-что кое-где возможно если повезет включить, когда надо *включить* ? Или firetrigger нужно сделать и игнорировать chkconfig в %post_service или chkconfig должен включать вне зависимости от preset-ов. Оказывается, механизм, аналогичый system-preset присутствует в init-файлах, но в каждом индивидуально. В поле "chkconfig:" первым параметром написано, запускать ли его не каких-то runlevel-ах по умолчанию. Аналог этой информации для systemd у нас на данный момент отсутствует. Может, убрать из %post_service поддержку systemd и сделать firetrigger для включения systemd-шных сервисов? А то как-то странновато в результате получается в случае с systemd. И удобно будет: положил preset и не паришься больше ни о чем. Иначе приходится городить костыли. У меня, например, installer-feature-kdesktop-services, а у других свои. |