[devel] обновления пакетов с поддержкой systemd

[devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

Всем привет.
Возможно я кого-то ввел в заблужение (сам ошибался) по поводу
использования родных для systemd файлов.

Вопрос из FAQ:
Q: I have a native systemd service file and a SysV init script
installed which share the same basename, e.g.
/lib/systemd/system/foobar.service vs. /etc/init.d/foobar -- which one
wins?

A: If both files are available the native unit file always takes
precedence and the SysV init script is ignored, regardless whether
either is enabled or disabled. Note that a SysV service that is
enabled but overriden by a native service does not have the effect
that the native service would be enabled, too. Enabling of native and
SysV services is completely independent. Or in other words: you cannot
enable a native service by enabling a SysV service by the same name,
and if a SysV service is enabled but a the respective native service
is not, this will not have the effect that the SysV script is
executed.

То есть, если мы раньше имели включеный сервис /etc/init.d/foobar, а
теперь подложили в rpm-пакет  /lib/systemd/system/foobar.service, то
этот сервис будет выключен и после перезагрузки не стартует.
Надо запустить что-то типа
if chkconfig foobar ; then
  chkconfig foobar on
fi
(если сервис включен, включить его ещё раз - в этот раз уже с
перенаправлением на systemd)
Предполагается, что chkconfig из people/shaba/systemd -
модифицированный для перенаправления команд к systemd.

либо
if chkconfig --no-redirect foobar ; then  # не перенаправлять на systemd
  systemctl enable foobar.sevice         # можно использовать сразу
systemctl, без перенаправления из chkconfig
fi


В fedore во всех пакетах, где добавляют поддержку нативных сервисов
добавляют тригер типа:
%triggerun -- httpd < 0.47.11-1
if /sbin/chkconfig httpd ; then
        /bin/systemctl enable httpd.service >/dev/null 2>&1 || :
fi

или

%triggerun -- avahi < 0.6.28-1
 if /sbin/chkconfig --level 5 avahi-daemon ; then
          /bin/systemctl --no-reload enable avahi-daemon.service
>/dev/null 2>&1 || :
 fi

Как лучше сделать у нас?
Я пока придумал только модифицировать post_service:

--- post_service.def	2011-03-17 01:41:42.000000000 +0300
+++ post_service	2011-05-17 07:02:27.640147135 +0400
@@ -1,5 +1,21 @@
 #!/bin/sh -e

+SYSTEMCTL=/bin/systemctl
+SYSTEMD_SERVICE_DIR=/lib/systemd/system
+SYSTEMD_CGROUP_DIR=/sys/fs/cgroup/systemd
+
+systemd_status=
+systemd_is_active()
+{
+	if [ -z "$systemd_status" ]; then
+		[ -x "$SYSTEMCTL" -a \
+		  -d "$SYSTEMD_CGROUP_DIR" ] &&
+		mountpoint -q "$SYSTEMD_CGROUP_DIR"
+		systemd_status=$?
+	fi
+	return $systemd_status
+}
+
 if ! [ "$RPM_INSTALL_ARG1" -ge 1 ] 2>/dev/null; then
 	echo "post_service: invalid or undefined variable: RPM_INSTALL_ARG1" >&2
 	exit 1
@@ -14,5 +30,9 @@
 	/sbin/chkconfig --add "$1"
 else
 	/sbin/chkconfig "$1" resetpriorities ||:
+	[ -f "$SYSTEMD_SERVICE_DIR/$1.service" ] &&
+		systemd_is_active &&
+		/sbin/chkconfig --no-redirect "$1" &&
+		/sbin/chkconfig "$1" on
 	/sbin/service "$1" condrestart ||:
 fi

Или это можно в какой-нибудь filetrigger сделать?
Как лучше?

-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Tue, May 17, 2011 at 07:12:07AM +0400, Alexey Shabalin wrote:
[...]
> Надо запустить что-то типа
> if chkconfig foobar ; then
>   chkconfig foobar on
> fi
> (если сервис включен, включить его ещё раз - в этот раз уже с
> перенаправлением на systemd)
[...]
> Я пока придумал только модифицировать post_service:
> 
> --- post_service.def	2011-03-17 01:41:42.000000000 +0300
> +++ post_service	2011-05-17 07:02:27.640147135 +0400
[...]
> @@ -14,5 +30,9 @@
>  	/sbin/chkconfig --add "$1"
>  else
>  	/sbin/chkconfig "$1" resetpriorities ||:
> +	[ -f "$SYSTEMD_SERVICE_DIR/$1.service" ] &&
> +		systemd_is_active &&
> +		/sbin/chkconfig --no-redirect "$1" &&
> +		/sbin/chkconfig "$1" on
>  	/sbin/service "$1" condrestart ||:
>  fi

Я бы предпочел, чтобы либо chkconfig resetpriorities выполнял эту
синхронизацию, либо появился еще один режим в chkconfig для синхронизации.
Вариант с resetpriorities предпочтительнее, поскольку тогда не придется
трогать пользователей chkconfig'а.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

17 мая 2011 г. 7:21 пользователь Dmitry V. Levin  написал:
> On Tue, May 17, 2011 at 07:12:07AM +0400, Alexey Shabalin wrote:
> [...]
>> Надо запустить что-то типа
>> if chkconfig foobar ; then
>>   chkconfig foobar on
>> fi
>> (если сервис включен, включить его ещё раз - в этот раз уже с
>> перенаправлением на systemd)
> [...]
>> Я пока придумал только модифицировать post_service:
>>
>> --- post_service.def  2011-03-17 01:41:42.000000000 +0300
>> +++ post_service      2011-05-17 07:02:27.640147135 +0400
> [...]
>> @@ -14,5 +30,9 @@
>>       /sbin/chkconfig --add "$1"
>>  else
>>       /sbin/chkconfig "$1" resetpriorities ||:
>> +     [ -f "$SYSTEMD_SERVICE_DIR/$1.service" ] &&
>> +             systemd_is_active &&
>> +             /sbin/chkconfig --no-redirect "$1" &&
>> +             /sbin/chkconfig "$1" on
>>       /sbin/service "$1" condrestart ||:
>>  fi
>
> Я бы предпочел, чтобы либо chkconfig resetpriorities выполнял эту
> синхронизацию, либо появился еще один режим в chkconfig для синхронизации.
> Вариант с resetpriorities предпочтительнее, поскольку тогда не придется
> трогать пользователей chkconfig'а.

Боюсь, что я этого не осилю. Максимум, что могу - сделать всегда
включение сервиса при resetpriorities :)

-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

17 мая 2011 г. 7:42 пользователь Alexey Shabalin <a.shabalin@gmail.com> написал:
> 17 мая 2011 г. 7:21 пользователь Dmitry V. Levin  написал:
>> On Tue, May 17, 2011 at 07:12:07AM +0400, Alexey Shabalin wrote:
>> [...]
>>> Надо запустить что-то типа
>>> if chkconfig foobar ; then
>>>   chkconfig foobar on
>>> fi
>>> (если сервис включен, включить его ещё раз - в этот раз уже с
>>> перенаправлением на systemd)
>> [...]
>>> Я пока придумал только модифицировать post_service:
>>>
>>> --- post_service.def  2011-03-17 01:41:42.000000000 +0300
>>> +++ post_service      2011-05-17 07:02:27.640147135 +0400
>> [...]
>>> @@ -14,5 +30,9 @@
>>>       /sbin/chkconfig --add "$1"
>>>  else
>>>       /sbin/chkconfig "$1" resetpriorities ||:
>>> +     [ -f "$SYSTEMD_SERVICE_DIR/$1.service" ] &&
>>> +             systemd_is_active &&
>>> +             /sbin/chkconfig --no-redirect "$1" &&
>>> +             /sbin/chkconfig "$1" on
>>>       /sbin/service "$1" condrestart ||:
>>>  fi
>>
>> Я бы предпочел, чтобы либо chkconfig resetpriorities выполнял эту
>> синхронизацию, либо появился еще один режим в chkconfig для синхронизации.
>> Вариант с resetpriorities предпочтительнее, поскольку тогда не придется
>> трогать пользователей chkconfig'а.
>
> Боюсь, что я этого не осилю. Максимум, что могу - сделать всегда
> включение сервиса при resetpriorities :)

В общем у меня получилось следущее:

	    return setService(name, type, where, 0);
         } else if (!strcmp(state, "reset"))
 	    return setService(name, type, where, -1);
-	else if (!strcmp(state, "resetpriorities"))
+	else if (!strcmp(state, "resetpriorities")) {
+	    if (!noRedirectItem && isOn(name, level)) {
+		forwardSystemd(name, type, "enable");
+	    }
 	    return setService(name, type, where, -2);
+	}
 	else
 	    usage(EXIT_FAILURE);
     }

Если используется systemd и если раньше сервис был включён, то при
запуске с resetpriorities ещё запускается systemctl enable для
сервиса.
Так устроит?

-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

On Tue, May 17, 2011 at 04:35:13PM +0400, Alexey Shabalin wrote:
> 17 мая 2011 г. 7:42 пользователь Alexey Shabalin <a.shabalin@gmail.com> написал:
> > 17 мая 2011 г. 7:21 пользователь Dmitry V. Levin  написал:
> >> On Tue, May 17, 2011 at 07:12:07AM +0400, Alexey Shabalin wrote:
> >> [...]
> >>> Надо запустить что-то типа
> >>> if chkconfig foobar ; then
> >>>   chkconfig foobar on
> >>> fi
> >>> (если сервис включен, включить его ещё раз - в этот раз уже с
> >>> перенаправлением на systemd)
> >> [...]
> >>> Я пока придумал только модифицировать post_service:
> >>>
> >>> --- post_service.def  2011-03-17 01:41:42.000000000 +0300
> >>> +++ post_service      2011-05-17 07:02:27.640147135 +0400
> >> [...]
> >>> @@ -14,5 +30,9 @@
> >>>       /sbin/chkconfig --add "$1"
> >>>  else
> >>>       /sbin/chkconfig "$1" resetpriorities ||:
> >>> +     [ -f "$SYSTEMD_SERVICE_DIR/$1.service" ] &&
> >>> +             systemd_is_active &&
> >>> +             /sbin/chkconfig --no-redirect "$1" &&
> >>> +             /sbin/chkconfig "$1" on
> >>>       /sbin/service "$1" condrestart ||:
> >>>  fi
> >>
> >> Я бы предпочел, чтобы либо chkconfig resetpriorities выполнял эту
> >> синхронизацию, либо появился еще один режим в chkconfig для синхронизации.
> >> Вариант с resetpriorities предпочтительнее, поскольку тогда не придется
> >> трогать пользователей chkconfig'а.
> >
> > Боюсь, что я этого не осилю. Максимум, что могу - сделать всегда
> > включение сервиса при resetpriorities :)
> 
> В общем у меня получилось следущее:
> 
> 	    return setService(name, type, where, 0);
>          } else if (!strcmp(state, "reset"))
>  	    return setService(name, type, where, -1);
> -	else if (!strcmp(state, "resetpriorities"))
> +	else if (!strcmp(state, "resetpriorities")) {
> +	    if (!noRedirectItem && isOn(name, level)) {
> +		forwardSystemd(name, type, "enable");
> +	    }
>  	    return setService(name, type, where, -2);
> +	}
>  	else
>  	    usage(EXIT_FAILURE);
>      }
> 
> Если используется systemd и если раньше сервис был включён, то при
> запуске с resetpriorities ещё запускается systemctl enable для
> сервиса.
> Так устроит?

Судя по описанию, да.

P.S. код я не смотрел.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

>> >>> Надо запустить что-то типа
>> >>> if chkconfig foobar ; then
>> >>>   chkconfig foobar on
>> >>> fi
>> >>> (если сервис включен, включить его ещё раз - в этот раз уже с
>> >>> перенаправлением на systemd)
>> >> [...]
>> >>> Я пока придумал только модифицировать post_service:
>> >>>
>> >>> --- post_service.def  2011-03-17 01:41:42.000000000 +0300
>> >>> +++ post_service      2011-05-17 07:02:27.640147135 +0400
>> >> [...]
>> >>> @@ -14,5 +30,9 @@
>> >>>       /sbin/chkconfig --add "$1"
>> >>>  else
>> >>>       /sbin/chkconfig "$1" resetpriorities ||:
>> >>> +     [ -f "$SYSTEMD_SERVICE_DIR/$1.service" ] &&
>> >>> +             systemd_is_active &&
>> >>> +             /sbin/chkconfig --no-redirect "$1" &&
>> >>> +             /sbin/chkconfig "$1" on
>> >>>       /sbin/service "$1" condrestart ||:
>> >>>  fi
>> >>
>> >> Я бы предпочел, чтобы либо chkconfig resetpriorities выполнял эту
>> >> синхронизацию, либо появился еще один режим в chkconfig для синхронизации.
>> >> Вариант с resetpriorities предпочтительнее, поскольку тогда не придется
>> >> трогать пользователей chkconfig'а.
>> >
>> > Боюсь, что я этого не осилю. Максимум, что могу - сделать всегда
>> > включение сервиса при resetpriorities :)
>>
>> В общем у меня получилось следущее:
>>
>>           return setService(name, type, where, 0);
>>          } else if (!strcmp(state, "reset"))
>>           return setService(name, type, where, -1);
>> -     else if (!strcmp(state, "resetpriorities"))
>> +     else if (!strcmp(state, "resetpriorities")) {
>> +         if (!noRedirectItem && isOn(name, level)) {
>> +             forwardSystemd(name, type, "enable");
>> +         }
>>           return setService(name, type, where, -2);
>> +     }
>>       else
>>           usage(EXIT_FAILURE);
>>      }
>>
>> Если используется systemd и если раньше сервис был включён, то при
>> запуске с resetpriorities ещё запускается systemctl enable для
>> сервиса.
>> Так устроит?
>
> Судя по описанию, да.
>
> P.S. код я не смотрел.

Чёрт, с этим исправлением возникает другая проблема.
В ALTLinux много имён init-скриптов не соответствуют названиям из upstream.
Например udev -> udevd,  bluetooth -> bluetoothd.service и т.п.
(добавляется d в конце имени).
Для работы с systemd на такие имена сделаны симлинки
# ls -l /lib/systemd/system/udevd.service
lrwxrwxrwx 1 root root 12 Май 21 17:39
/lib/systemd/system/udevd.service -> udev.service
[root@shabalin-nb ~]# ls -l /lib/systemd/system/bluetoothd.service
lrwxrwxrwx 1 root root 17 Май 21 17:39
/lib/systemd/system/bluetoothd.service -> bluetooth.service

Это работает  для start|stop (systemctl start|stop foo.service или
service foo start|stop ),
но не работает для enable|disable ( systemctk enable|disable
foo.service или chkconfig foo enable|disable)
Ругается что это symlink и хочет правильное имя.

Как это объезжать?
- привести имена init-скриптов к апстримному виду
- привести имена .service файлов к ALTLinux виду
- научить systemd делать enable|disable для симлинков (а симлинк может
быть и на /dev/null - для systemd это нормальный способ выключить или
замаскировать сервис).

-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On Sat, May 21, 2011 at 04:42:31PM +0400, Alexey Shabalin wrote:
> Чёрт, с этим исправлением возникает другая проблема.
> В ALTLinux много имён init-скриптов не соответствуют названиям из upstream.
> Например udev -> udevd,  bluetooth -> bluetoothd.service и т.п.
> (добавляется d в конце имени).

Вопрос, эти названия из upstream существуют в виде init-скриптов, или в
каком-то ином виде?  Например, если апстрим реализует некий демон
SERVICEd, то init-скрипт у нас с высокой вероятностью будет называться
SERVICEd а не SERVICE.  Просьба прояснить картину.

> Для работы с systemd на такие имена сделаны симлинки
> # ls -l /lib/systemd/system/udevd.service
> lrwxrwxrwx 1 root root 12 Май 21 17:39
> /lib/systemd/system/udevd.service -> udev.service
> [root@shabalin-nb ~]# ls -l /lib/systemd/system/bluetoothd.service
> lrwxrwxrwx 1 root root 17 Май 21 17:39
> /lib/systemd/system/bluetoothd.service -> bluetooth.service
> 
> Это работает  для start|stop (systemctl start|stop foo.service или
> service foo start|stop ),
> но не работает для enable|disable ( systemctk enable|disable
> foo.service или chkconfig foo enable|disable)
> Ругается что это symlink и хочет правильное имя.
> 
> Как это объезжать?
> - привести имена init-скриптов к апстримному виду

В этом случае сломаются обновление пакетов и привычки у людей.

> - привести имена .service файлов к ALTLinux виду

В этом случае может ухудшиться переносимость .service-файлов.

Если идти путем переименования, то придется рассматривать каждый случай
в отдельности.

> - научить systemd делать enable|disable для симлинков (а симлинк может
> быть и на /dev/null - для systemd это нормальный способ выключить или
> замаскировать сервис).

Если симлинк ведет на /dev/null, то как ему можно сделать enable|disable?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

27 мая 2011 г. 21:11 пользователь Dmitry V. Levin написал:
> On Sat, May 21, 2011 at 04:42:31PM +0400, Alexey Shabalin wrote:
>> Чёрт, с этим исправлением возникает другая проблема.
>> В ALTLinux много имён init-скриптов не соответствуют названиям из upstream.
>> Например udev -> udevd,  bluetooth -> bluetoothd.service и т.п.
>> (добавляется d в конце имени).
>
> Вопрос, эти названия из upstream существуют в виде init-скриптов, или в
> каком-то ином виде?  Например, если апстрим реализует некий демон
> SERVICEd, то init-скрипт у нас с высокой вероятностью будет называться
> SERVICEd а не SERVICE.  Просьба прояснить картину.

В виде init-скриптов для RedHat.  Да и другие дистрибутивы стараются
держать имена сервисов аналогичными с RedHat.
Ну и systemd делался изначально для федоры с оглядкой на имена
сервисов в федоре.
В .service файлах зависимости указываются по именам сервисов, а сервис
может быть как .service файл для systemd, так и init-скрит.

>> Для работы с systemd на такие имена сделаны симлинки
>> # ls -l /lib/systemd/system/udevd.service
>> lrwxrwxrwx 1 root root 12 Май 21 17:39
>> /lib/systemd/system/udevd.service -> udev.service
>> [root@shabalin-nb ~]# ls -l /lib/systemd/system/bluetoothd.service
>> lrwxrwxrwx 1 root root 17 Май 21 17:39
>> /lib/systemd/system/bluetoothd.service -> bluetooth.service
>>
>> Это работает  для start|stop (systemctl start|stop foo.service или
>> service foo start|stop ),
>> но не работает для enable|disable ( systemctk enable|disable
>> foo.service или chkconfig foo enable|disable)
>> Ругается что это symlink и хочет правильное имя.
>>
>> Как это объезжать?
>> - привести имена init-скриптов к апстримному виду
>
> В этом случае сломаются обновление пакетов и привычки у людей.
Для обновления можно использовать тригеры.
И возможно этот путь самый реалистичный.

>> - привести имена .service файлов к ALTLinux виду
>
> В этом случае может ухудшиться переносимость .service-файлов.
Да, придётся всё отслеживать. Можно в пакет добавлять
Provides/Requires типа systemd(foo).

> Если идти путем переименования, то придется рассматривать каждый случай
> в отдельности.
>
>> - научить systemd делать enable|disable для симлинков (а симлинк может
>> быть и на /dev/null - для systemd это нормальный способ выключить или
>> замаскировать сервис).
>
> Если симлинк ведет на /dev/null, то как ему можно сделать enable|disable?
не важно, можно ли сделать enable|disable на симлинк /dev/null, важно
что при start|stop ничего происходить не будет.
А сейчас enable|disable с любыми симлинками запрещены. Поэтому,
например, невохможно коректно обновить udev. post скрипт обламывется и
в системе остаётся два udev.

-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

27 мая 2011 г. 21:11 пользователь Dmitry V. Levin написал:

> Если идти путем переименования, то придется рассматривать каждый случай
> в отдельности.
Всё равно придётся рассматривать каждый случай отдельно.
Например, пакет udev несёт в себе все нужные симлинки для systemd, и
для него не надо делать enable|disable.
Если сервис обязательный для работы (как udev), он содержит симлинки в
/lib/systemd/system/multi-user.target.wants (или в другом target).
Если сервис не обязательный, то enable|disable создаёт|удаляет
симлинки в /etc/systemd/system/multi-user.target.wants (или в другом
target).

-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

30 мая 2011 г. 18:22 пользователь Alexey Shabalin написал:
> 27 мая 2011 г. 21:11 пользователь Dmitry V. Levin написал:
>
>> Если идти путем переименования, то придется рассматривать каждый случай
>> в отдельности.
> Всё равно придётся рассматривать каждый случай отдельно.
> Например, пакет udev несёт в себе все нужные симлинки для systemd, и
> для него не надо делать enable|disable.
> Если сервис обязательный для работы (как udev), он содержит симлинки в
> /lib/systemd/system/multi-user.target.wants (или в другом target).
> Если сервис не обязательный, то enable|disable создаёт|удаляет
> симлинки в /etc/systemd/system/multi-user.target.wants (или в другом
> target).

Здесь тоже нормально. Для таких общесистемных сервисов, которые несут
с собой нужные симлинки,
нужно что бы в .service файлах отсутствовала секция [Install]. Тогда
systemct не будет знать куда их прописывать для enable, и будет
игнорировать с предупреждением. Например:
# systemctl enable udev.service (или udevd.service - без разницы )
Unit files contain no applicable installation information. Ignoring.

-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

27 мая 2011 г. 21:11 пользователь Dmitry V. Levin написал:
> On Sat, May 21, 2011 at 04:42:31PM +0400, Alexey Shabalin wrote:
>> Чёрт, с этим исправлением возникает другая проблема.
>> В ALTLinux много имён init-скриптов не соответствуют названиям из upstream.
>> Например udev -> udevd,  bluetooth -> bluetoothd.service и т.п.
>> (добавляется d в конце имени).
>
> Вопрос, эти названия из upstream существуют в виде init-скриптов, или в
> каком-то ином виде?  Например, если апстрим реализует некий демон
> SERVICEd, то init-скрипт у нас с высокой вероятностью будет называться
> SERVICEd а не SERVICE.  Просьба прояснить картину.
>
>> Для работы с systemd на такие имена сделаны симлинки
>> # ls -l /lib/systemd/system/udevd.service
>> lrwxrwxrwx 1 root root 12 Май 21 17:39
>> /lib/systemd/system/udevd.service -> udev.service
>> [root@shabalin-nb ~]# ls -l /lib/systemd/system/bluetoothd.service
>> lrwxrwxrwx 1 root root 17 Май 21 17:39
>> /lib/systemd/system/bluetoothd.service -> bluetooth.service
>>
>> Это работает  для start|stop (systemctl start|stop foo.service или
>> service foo start|stop ),
>> но не работает для enable|disable ( systemctk enable|disable
>> foo.service или chkconfig foo enable|disable)
>> Ругается что это symlink и хочет правильное имя.
>>
>> Как это объезжать?
>> - привести имена init-скриптов к апстримному виду
>
> В этом случае сломаются обновление пакетов и привычки у людей.
>
>> - привести имена .service файлов к ALTLinux виду
>
> В этом случае может ухудшиться переносимость .service-файлов.
>
> Если идти путем переименования, то придется рассматривать каждый случай
> в отдельности.
>
>> - научить systemd делать enable|disable для симлинков (а симлинк может
>> быть и на /dev/null - для systemd это нормальный способ выключить или
>> замаскировать сервис).

в версии 28-alt3 я убрал ограничение на симлинки. Теперь можно делать
enable|disable на симлинки.
start|stop можно было делать и раньше.
Экспериментировал с bluetoothd.service - вроде все нормально.
Даже работает, если включать bluetoothd.service, а выключать уже
bluetooth.service - выдаёт предупреждение, но ошибок нет.

> Если симлинк ведет на /dev/null, то как ему можно сделать enable|disable?
про симлинки на /dev/null можно не беспокоится, ни start, ни enable
для них не работает.

-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Alexey Shabalin]

10 июня 2011 г. 22:49 пользователь Alexey Shabalin написал:
> 27 мая 2011 г. 21:11 пользователь Dmitry V. Levin написал:
>> On Sat, May 21, 2011 at 04:42:31PM +0400, Alexey Shabalin wrote:
>>> Чёрт, с этим исправлением возникает другая проблема.
>>> В ALTLinux много имён init-скриптов не соответствуют названиям из upstream.
>>> Например udev -> udevd,  bluetooth -> bluetoothd.service и т.п.
>>> (добавляется d в конце имени).
>>
>> Вопрос, эти названия из upstream существуют в виде init-скриптов, или в
>> каком-то ином виде?  Например, если апстрим реализует некий демон
>> SERVICEd, то init-скрипт у нас с высокой вероятностью будет называться
>> SERVICEd а не SERVICE.  Просьба прояснить картину.
>>
>>> Для работы с systemd на такие имена сделаны симлинки
>>> # ls -l /lib/systemd/system/udevd.service
>>> lrwxrwxrwx 1 root root 12 Май 21 17:39
>>> /lib/systemd/system/udevd.service -> udev.service
>>> [root@shabalin-nb ~]# ls -l /lib/systemd/system/bluetoothd.service
>>> lrwxrwxrwx 1 root root 17 Май 21 17:39
>>> /lib/systemd/system/bluetoothd.service -> bluetooth.service
>>>
>>> Это работает  для start|stop (systemctl start|stop foo.service или
>>> service foo start|stop ),
>>> но не работает для enable|disable ( systemctk enable|disable
>>> foo.service или chkconfig foo enable|disable)
>>> Ругается что это symlink и хочет правильное имя.
>>>
>>> Как это объезжать?
>>> - привести имена init-скриптов к апстримному виду
>>
>> В этом случае сломаются обновление пакетов и привычки у людей.
>>
>>> - привести имена .service файлов к ALTLinux виду
>>
>> В этом случае может ухудшиться переносимость .service-файлов.
>>
>> Если идти путем переименования, то придется рассматривать каждый случай
>> в отдельности.
>>
>>> - научить systemd делать enable|disable для симлинков (а симлинк может
>>> быть и на /dev/null - для systemd это нормальный способ выключить или
>>> замаскировать сервис).
>
> в версии 28-alt3 я убрал ограничение на симлинки. Теперь можно делать
> enable|disable на симлинки.
> start|stop можно было делать и раньше.
> Экспериментировал с bluetoothd.service - вроде все нормально.
> Даже работает, если включать bluetoothd.service, а выключать уже
> bluetooth.service - выдаёт предупреждение, но ошибок нет.

В новой версии 33-alt1 опять нельзя сделать enable|disable для симлинка.
Этот код сильно переписали, и я пока не нашёл способа изменить.

>> Если симлинк ведет на /dev/null, то как ему можно сделать enable|disable?
> про симлинки на /dev/null можно не беспокоится, ни start, ни enable
> для них не работает.
>
> --
> Alexey Shabalin
>



-- 
Alexey Shabalin

Re: [devel] обновления пакетов с поддержкой systemd

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]

On Tue, May 17, 2011 at 05:59:55PM +0400, Dmitry V. Levin wrote:
> On Tue, May 17, 2011 at 04:35:13PM +0400, Alexey Shabalin wrote:
> > 17 мая 2011 г. 7:42 пользователь Alexey Shabalin <a.shabalin@gmail.com> написал:
> > > 17 мая 2011 г. 7:21 пользователь Dmitry V. Levin  написал:
> > >> On Tue, May 17, 2011 at 07:12:07AM +0400, Alexey Shabalin wrote:
> > >> [...]
> > >>> Надо запустить что-то типа
> > >>> if chkconfig foobar ; then
> > >>>   chkconfig foobar on
> > >>> fi
> > >>> (если сервис включен, включить его ещё раз - в этот раз уже с
> > >>> перенаправлением на systemd)
> > >> [...]
> > >>> Я пока придумал только модифицировать post_service:
> > >>>
> > >>> --- post_service.def  2011-03-17 01:41:42.000000000 +0300
> > >>> +++ post_service      2011-05-17 07:02:27.640147135 +0400
> > >> [...]
> > >>> @@ -14,5 +30,9 @@
> > >>>       /sbin/chkconfig --add "$1"
> > >>>  else
> > >>>       /sbin/chkconfig "$1" resetpriorities ||:
> > >>> +     [ -f "$SYSTEMD_SERVICE_DIR/$1.service" ] &&
> > >>> +             systemd_is_active &&
> > >>> +             /sbin/chkconfig --no-redirect "$1" &&
> > >>> +             /sbin/chkconfig "$1" on
> > >>>       /sbin/service "$1" condrestart ||:
> > >>>  fi
> > >>
> > >> Я бы предпочел, чтобы либо chkconfig resetpriorities выполнял эту
> > >> синхронизацию, либо появился еще один режим в chkconfig для синхронизации.
> > >> Вариант с resetpriorities предпочтительнее, поскольку тогда не придется
> > >> трогать пользователей chkconfig'а.
> > >
> > > Боюсь, что я этого не осилю. Максимум, что могу - сделать всегда
> > > включение сервиса при resetpriorities :)
> > 
> > В общем у меня получилось следущее:
> > 
> > 	    return setService(name, type, where, 0);
> >          } else if (!strcmp(state, "reset"))
> >  	    return setService(name, type, where, -1);
> > -	else if (!strcmp(state, "resetpriorities"))
> > +	else if (!strcmp(state, "resetpriorities")) {
> > +	    if (!noRedirectItem && isOn(name, level)) {
> > +		forwardSystemd(name, type, "enable");
> > +	    }
> >  	    return setService(name, type, where, -2);
> > +	}
> >  	else
> >  	    usage(EXIT_FAILURE);
> >      }
> > 
> > Если используется systemd и если раньше сервис был включён, то при
> > запуске с resetpriorities ещё запускается systemctl enable для
> > сервиса.
> > Так устроит?
> 
> Судя по описанию, да.
> 
> P.S. код я не смотрел.

Посмотрел код.  Нет, так совсем не годится.  Надо сперва менять состояние
(т.е. вызывать setService, который, между прочим, вызывает
"systemctl daemon-reload"), а потом уже форвардить результат в systemd.
То же самое касается и "chkconfig reset".


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]