Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladimir D. Seleznev]

On Sun, Dec 06, 2020 at 12:12:19PM +0000, Girar awaiter (vseleznv) wrote:
> http://git.altlinux.org/tasks/262991/logs/events.1.1.log
> 
> subtask  name   aarch64  armh  i586  ppc64le  x86_64
>    #100  acpid       42  1:01    42       53      40
> 
> 2020-Dec-06 12:07:49 :: task #262991 for sisyphus started by vseleznv:
> #100 build acpid-2.0.32-alt2.src.rpm
> 2020-Dec-06 12:07:49 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build start
> 2020-Dec-06 12:07:49 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build start
> 2020-Dec-06 12:07:49 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build start
> 2020-Dec-06 12:07:49 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build start
> 2020-Dec-06 12:07:49 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build start
> 2020-Dec-06 12:08:29 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> 2020-Dec-06 12:08:31 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> 2020-Dec-06 12:08:31 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build OK
> 2020-Dec-06 12:08:42 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build OK
> 2020-Dec-06 12:08:50 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build OK
> 2020-Dec-06 12:09:07 :: #100: acpid-2.0.32-alt2.src.rpm: build check OK
> 2020-Dec-06 12:09:07 :: build check OK
> 2020-Dec-06 12:09:09 :: noarch check OK
> 2020-Dec-06 12:09:11 :: plan: src +1 -1 =17766, aarch64 +2 -2 =29375, armh +2 -2 =27064, i586 +2 -2 =30390, noarch +1 -1 =17448, ppc64le +2 -2 =29342, x86_64 +2 -2 =30804
> #100 acpid 2.0.32-alt1 -> 1:2.0.32-alt2
>  Sun Dec 06 2020 Vladimir D. Seleznev <vseleznv@altlinux> 1:2.0.32-alt2
>  - fix init script

Прошу пропустить задание в Сизиф.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Dmitry V. Levin]

On Sun, Dec 06, 2020 at 03:33:31PM +0300, Vladimir D. Seleznev wrote:
> On Sun, Dec 06, 2020 at 12:12:19PM +0000, Girar awaiter (vseleznv) wrote:
> > http://git.altlinux.org/tasks/262991/logs/events.1.1.log
> > 
> > subtask  name   aarch64  armh  i586  ppc64le  x86_64
> >    #100  acpid       42  1:01    42       53      40
> > 
> > 2020-Dec-06 12:07:49 :: task #262991 for sisyphus started by vseleznv:
> > #100 build acpid-2.0.32-alt2.src.rpm
> > 2020-Dec-06 12:07:49 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build start
> > 2020-Dec-06 12:07:49 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build start
> > 2020-Dec-06 12:07:49 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build start
> > 2020-Dec-06 12:07:49 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build start
> > 2020-Dec-06 12:07:49 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build start
> > 2020-Dec-06 12:08:29 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > 2020-Dec-06 12:08:31 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > 2020-Dec-06 12:08:31 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > 2020-Dec-06 12:08:42 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > 2020-Dec-06 12:08:50 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > 2020-Dec-06 12:09:07 :: #100: acpid-2.0.32-alt2.src.rpm: build check OK
> > 2020-Dec-06 12:09:07 :: build check OK
> > 2020-Dec-06 12:09:09 :: noarch check OK
> > 2020-Dec-06 12:09:11 :: plan: src +1 -1 =17766, aarch64 +2 -2 =29375, armh +2 -2 =27064, i586 +2 -2 =30390, noarch +1 -1 =17448, ppc64le +2 -2 =29342, x86_64 +2 -2 =30804
> > #100 acpid 2.0.32-alt1 -> 1:2.0.32-alt2
> >  Sun Dec 06 2020 Vladimir D. Seleznev <vseleznv@altlinux> 1:2.0.32-alt2
> >  - fix init script
> 
> Прошу пропустить задание в Сизиф.

А что в нём?


-- 
ldv

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladimir D. Seleznev]

On Sun, Dec 06, 2020 at 03:49:21PM +0300, Dmitry V. Levin wrote:
> On Sun, Dec 06, 2020 at 03:33:31PM +0300, Vladimir D. Seleznev wrote:
> > On Sun, Dec 06, 2020 at 12:12:19PM +0000, Girar awaiter (vseleznv) wrote:
> > > http://git.altlinux.org/tasks/262991/logs/events.1.1.log
> > > 
> > > subtask  name   aarch64  armh  i586  ppc64le  x86_64
> > >    #100  acpid       42  1:01    42       53      40
> > > 
> > > 2020-Dec-06 12:07:49 :: task #262991 for sisyphus started by vseleznv:
> > > #100 build acpid-2.0.32-alt2.src.rpm
> > > 2020-Dec-06 12:07:49 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > 2020-Dec-06 12:07:49 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > 2020-Dec-06 12:07:49 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > 2020-Dec-06 12:07:49 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > 2020-Dec-06 12:07:49 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > 2020-Dec-06 12:08:29 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > 2020-Dec-06 12:08:31 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > 2020-Dec-06 12:08:31 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > 2020-Dec-06 12:08:42 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > 2020-Dec-06 12:08:50 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > 2020-Dec-06 12:09:07 :: #100: acpid-2.0.32-alt2.src.rpm: build check OK
> > > 2020-Dec-06 12:09:07 :: build check OK
> > > 2020-Dec-06 12:09:09 :: noarch check OK
> > > 2020-Dec-06 12:09:11 :: plan: src +1 -1 =17766, aarch64 +2 -2 =29375, armh +2 -2 =27064, i586 +2 -2 =30390, noarch +1 -1 =17448, ppc64le +2 -2 =29342, x86_64 +2 -2 =30804
> > > #100 acpid 2.0.32-alt1 -> 1:2.0.32-alt2
> > >  Sun Dec 06 2020 Vladimir D. Seleznev <vseleznv@altlinux> 1:2.0.32-alt2
> > >  - fix init script
> > 
> > Прошу пропустить задание в Сизиф.
> 
> А что в нём?

Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
/run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
/var/{run,lock}.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Dmitry V. Levin]

On Sun, Dec 06, 2020 at 04:21:50PM +0300, Vladimir D. Seleznev wrote:
> On Sun, Dec 06, 2020 at 03:49:21PM +0300, Dmitry V. Levin wrote:
> > On Sun, Dec 06, 2020 at 03:33:31PM +0300, Vladimir D. Seleznev wrote:
> > > On Sun, Dec 06, 2020 at 12:12:19PM +0000, Girar awaiter (vseleznv) wrote:
> > > > http://git.altlinux.org/tasks/262991/logs/events.1.1.log
> > > > 
> > > > subtask  name   aarch64  armh  i586  ppc64le  x86_64
> > > >    #100  acpid       42  1:01    42       53      40
> > > > 
> > > > 2020-Dec-06 12:07:49 :: task #262991 for sisyphus started by vseleznv:
> > > > #100 build acpid-2.0.32-alt2.src.rpm
> > > > 2020-Dec-06 12:07:49 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > 2020-Dec-06 12:07:49 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > 2020-Dec-06 12:07:49 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > 2020-Dec-06 12:07:49 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > 2020-Dec-06 12:07:49 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > 2020-Dec-06 12:08:29 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > 2020-Dec-06 12:08:31 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > 2020-Dec-06 12:08:31 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > 2020-Dec-06 12:08:42 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > 2020-Dec-06 12:08:50 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > 2020-Dec-06 12:09:07 :: #100: acpid-2.0.32-alt2.src.rpm: build check OK
> > > > 2020-Dec-06 12:09:07 :: build check OK
> > > > 2020-Dec-06 12:09:09 :: noarch check OK
> > > > 2020-Dec-06 12:09:11 :: plan: src +1 -1 =17766, aarch64 +2 -2 =29375, armh +2 -2 =27064, i586 +2 -2 =30390, noarch +1 -1 =17448, ppc64le +2 -2 =29342, x86_64 +2 -2 =30804
> > > > #100 acpid 2.0.32-alt1 -> 1:2.0.32-alt2
> > > >  Sun Dec 06 2020 Vladimir D. Seleznev <vseleznv@altlinux> 1:2.0.32-alt2
> > > >  - fix init script
> > > 
> > > Прошу пропустить задание в Сизиф.
> > 
> > А что в нём?
> 
> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> /var/{run,lock}.

К сожалению, пакет собран не из git, но можно отразить хотя бы эту суть
изменения в %changelog пакета?


-- 
ldv

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladimir D. Seleznev]

On Sun, Dec 06, 2020 at 04:38:49PM +0300, Dmitry V. Levin wrote:
> On Sun, Dec 06, 2020 at 04:21:50PM +0300, Vladimir D. Seleznev wrote:
> > On Sun, Dec 06, 2020 at 03:49:21PM +0300, Dmitry V. Levin wrote:
> > > On Sun, Dec 06, 2020 at 03:33:31PM +0300, Vladimir D. Seleznev wrote:
> > > > On Sun, Dec 06, 2020 at 12:12:19PM +0000, Girar awaiter (vseleznv) wrote:
> > > > > http://git.altlinux.org/tasks/262991/logs/events.1.1.log
> > > > > 
> > > > > subtask  name   aarch64  armh  i586  ppc64le  x86_64
> > > > >    #100  acpid       42  1:01    42       53      40
> > > > > 
> > > > > 2020-Dec-06 12:07:49 :: task #262991 for sisyphus started by vseleznv:
> > > > > #100 build acpid-2.0.32-alt2.src.rpm
> > > > > 2020-Dec-06 12:07:49 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > > 2020-Dec-06 12:07:49 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > > 2020-Dec-06 12:07:49 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > > 2020-Dec-06 12:07:49 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > > 2020-Dec-06 12:07:49 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build start
> > > > > 2020-Dec-06 12:08:29 :: [x86_64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > > 2020-Dec-06 12:08:31 :: [aarch64] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > > 2020-Dec-06 12:08:31 :: [i586] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > > 2020-Dec-06 12:08:42 :: [ppc64le] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > > 2020-Dec-06 12:08:50 :: [armh] #100 acpid-2.0.32-alt2.src.rpm: build OK
> > > > > 2020-Dec-06 12:09:07 :: #100: acpid-2.0.32-alt2.src.rpm: build check OK
> > > > > 2020-Dec-06 12:09:07 :: build check OK
> > > > > 2020-Dec-06 12:09:09 :: noarch check OK
> > > > > 2020-Dec-06 12:09:11 :: plan: src +1 -1 =17766, aarch64 +2 -2 =29375, armh +2 -2 =27064, i586 +2 -2 =30390, noarch +1 -1 =17448, ppc64le +2 -2 =29342, x86_64 +2 -2 =30804
> > > > > #100 acpid 2.0.32-alt1 -> 1:2.0.32-alt2
> > > > >  Sun Dec 06 2020 Vladimir D. Seleznev <vseleznv@altlinux> 1:2.0.32-alt2
> > > > >  - fix init script
> > > > 
> > > > Прошу пропустить задание в Сизиф.
> > > 
> > > А что в нём?
> > 
> > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> > /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> > /var/{run,lock}.
> 
> К сожалению, пакет собран не из git, но можно отразить хотя бы эту суть
> изменения в %changelog пакета?

Done.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Alexey V. Vissarionov]

On 2020-12-06 16:21:50 +0300, Vladimir D. Seleznev wrote:

 >>>> #100 acpid 2.0.32-alt1 -> 1:2.0.32-alt2
 >>>> Sun Dec 06 2020 Vladimir D. Seleznev <vseleznv@altlinux>
 >>>> 1:2.0.32-alt2
 >>>> - fix init script
 >>> Прошу пропустить задание в Сизиф.
 >> А что в нём?
 > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы
 > в /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
 > /var/{run,lock}.

И в общем-то должен был увидеть...

Оптимальное решение: ln -s var/run run

Допустимое решение: ln -s ../run var/run (хотя админы на линки с ".."
сердито ворчат из-за их хреновой читаемости глазами).

Кривое решение: любой из предыдущих вариантов с абсолютными линками.

А переделывать все скрипты - вообще не решение. Хотя унификация - это
действительно хорошо.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladimir D. Seleznev]

On Mon, Dec 07, 2020 at 02:19:13AM +0300, Alexey V. Vissarionov wrote:
> On 2020-12-06 16:21:50 +0300, Vladimir D. Seleznev wrote:
> 
>  >>>> #100 acpid 2.0.32-alt1 -> 1:2.0.32-alt2
>  >>>> Sun Dec 06 2020 Vladimir D. Seleznev <vseleznv@altlinux>
>  >>>> 1:2.0.32-alt2
>  >>>> - fix init script
>  >>> Прошу пропустить задание в Сизиф.
>  >> А что в нём?
>  > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы
>  > в /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
>  > /var/{run,lock}.
> 
> И в общем-то должен был увидеть...
> 
> Оптимальное решение: ln -s var/run run
> 
> Допустимое решение: ln -s ../run var/run (хотя админы на линки с ".."
> сердито ворчат из-за их хреновой читаемости глазами).
> 
> Кривое решение: любой из предыдущих вариантов с абсолютными линками.
> 
> А переделывать все скрипты - вообще не решение. Хотя унификация - это
> действительно хорошо.

Хотя бы в рамках пакета пути не должны разъезжаться. А сделать миграцию
в репозитории /var/run в симлинк /run (или наоборот) -- нетривиальная
задача.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Alexey V. Vissarionov]

On 2020-12-07 02:28:54 +0300, Vladimir D. Seleznev wrote:

 >>>>>> - fix init script
 >>>>> Прошу пропустить задание в Сизиф.
 >>>> А что в нём?
 >>> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы
 >>> в /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
 >>> /var/{run,lock}.
 >> И в общем-то должен был увидеть...
 >> Оптимальное решение: ln -s var/run run
 >> Допустимое решение: ln -s ../run var/run (хотя админы на линки с
 >> ".." сердито ворчат из-за их хреновой читаемости глазами).
 >> Кривое решение: любой из предыдущих вариантов с абсолютными
 >> линками.
 >> А переделывать все скрипты - вообще не решение. Хотя унификация
 >> - это действительно хорошо.
 > Хотя бы в рамках пакета пути не должны разъезжаться.

Внутри пакета - совершенно точно.

 > А сделать миграцию в репозитории /var/run в симлинк /run

Ну да.

 > (или наоборот)

Наоборот уж точно не надо.

 > -- нетривиальная задача.

А кому и зачем может понадобиться ее решение именно в виде миграции?
Вся эта ботва делается один раз при установке системы и в дальнейшем
не меняется. Соответственно и выглядит оно (там, где об этом думали)
как отдельный пакет, который ставится один раз и в дальнейшем уже не
обновляется.

У нас что-то похожее ожидается от пакета filesystem, но он не очень
тщательно продуман и для практического применения малопригоден.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 543 bytes --]

06.12.2020 16:21, Vladimir D. Seleznev пишет:
> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> /var/{run,lock}.

$ l /var/{run,lock}
lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run

что ему мешает и кому вообще нужен sysvinit?

-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Andrey Savchenko]

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

On Mon, 7 Dec 2020 09:24:16 +0300 Валерий Иноземцев wrote:
> 06.12.2020 16:21, Vladimir D. Seleznev пишет:
> > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> > /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> > /var/{run,lock}.
> 
> $ l /var/{run,lock}
> lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
> lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
> 
> что ему мешает и кому вообще нужен sysvinit?

sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 

Best regards,
Andrew Savchenko

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

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Антон Мидюков]

07.12.2020 14:43, Andrey Savchenko пишет:
> On Mon, 7 Dec 2020 09:24:16 +0300 Валерий Иноземцев wrote:
>> 06.12.2020 16:21, Vladimir D. Seleznev пишет:
>>> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
>>> /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
>>> /var/{run,lock}.
>> $ l /var/{run,lock}
>> lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
>> lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
>>
>> что ему мешает и кому вообще нужен sysvinit?
> sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion.
>
На всех новых инсталляциях p9 и Сизифа создаются симлинки /var/lock -> 
../run/lock и /var/run -> ../run

Те, кто обновлялись с p8 или очень давно сидят на Сизифе должны перейти 
на симлинки сами. У нас множество пакетов не будет работать правильно на 
sysvinit, если не перейти на эти симлинки.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladislav Zavjalov]

On Mon, Dec 07, 2020 at 03:03:36PM +0700, Антон Мидюков wrote:
> На всех новых инсталляциях p9 и Сизифа создаются симлинки /var/lock -> 
> ../run/lock и /var/run -> ../run
> 
> Те, кто обновлялись с p8 или очень давно сидят на Сизифе должны перейти 
> на симлинки сами. У нас множество пакетов не будет работать правильно на 
> sysvinit, если не перейти на эти симлинки.

Спасибо за информацию, я это пропустил.

На домашнем компьютере у меня сейчас /var/run и /run - хардлинки,
а /var/lock и /run/lock - разные директории. Систему ставил года три назад
(server-light, насколько я помню), вряд ли это можно назвать "очень давно".

Более того, на рабочих компьютерах (ставил год назад, с какой-то
свежей regular сборки) это все разные директории, симлинков нет.

Проблем, связанных с этим, я не замечал, но, может,
я просто не теми программами пользуюсь.

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Антон Мидюков]

07.12.2020 17:48, Vladislav Zavjalov пишет:
> On Mon, Dec 07, 2020 at 03:03:36PM +0700, Антон Мидюков wrote:
>> На всех новых инсталляциях p9 и Сизифа создаются симлинки /var/lock ->
>> ../run/lock и /var/run -> ../run
>>
>> Те, кто обновлялись с p8 или очень давно сидят на Сизифе должны перейти
>> на симлинки сами. У нас множество пакетов не будет работать правильно на
>> sysvinit, если не перейти на эти симлинки.
> Спасибо за информацию, я это пропустил.
>
> На домашнем компьютере у меня сейчас /var/run и /run - хардлинки,
> а /var/lock и /run/lock - разные директории. Систему ставил года три назад
> (server-light, насколько я помню), вряд ли это можно назвать "очень давно".
>
> Более того, на рабочих компьютерах (ставил год назад, с какой-то
> свежей regular сборки) это все разные директории, симлинков нет.
Точно не помню, но где-то около года назад, я исправил это в live. 
Значит, Вы чуть раньше успели поставить неисправленный вариант.
> Проблем, связанных с этим, я не замечал, но, может,
> я просто не теми программами пользуюсь.
Видимо, да. Но могут возникнуть в будущем. Впрочем, у нас ещё есть 
пакеты, которые не адаптированы для создания каталогов в /run при загрузке.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 990 bytes --]

07.12.2020 10:43, Andrey Savchenko пишет:
> On Mon, 7 Dec 2020 09:24:16 +0300 Валерий Иноземцев wrote:
>> 06.12.2020 16:21, Vladimir D. Seleznev пишет:
>>> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
>>> /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
>>> /var/{run,lock}.
>>
>> $ l /var/{run,lock}
>> lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
>> lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
>>
>> что ему мешает и кому вообще нужен sysvinit?
> 
> sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 

с некрофилами все понятно, лично мне вся эта некрофилия не интересна
интересен ответ на первую часть вопроса

-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Andrey Savchenko]

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

On Mon, 7 Dec 2020 13:10:50 +0300 Валерий Иноземцев wrote:
> 07.12.2020 10:43, Andrey Savchenko пишет:
> > On Mon, 7 Dec 2020 09:24:16 +0300 Валерий Иноземцев wrote:
> >> 06.12.2020 16:21, Vladimir D. Seleznev пишет:
> >>> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> >>> /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> >>> /var/{run,lock}.
> >>
> >> $ l /var/{run,lock}
> >> lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
> >> lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
> >>
> >> что ему мешает и кому вообще нужен sysvinit?
> > 
> > sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 
> 
> с некрофилами все понятно, лично мне вся эта некрофилия не интересна
> интересен ответ на первую часть вопроса

У нас в дистрибутиве поддерживают разные решения для разных людей.
Мало того, на международной арене нашим дистрибутивом интересуются
именно потому, что есть возможность полноценно работать без systemd.

А вот когда мейнтенер закрывает свой пакет по acl и блокирует
исправление неинтересных ему багов — это абсолютно, категорически
неприемлемо. 

Best regards,
Andrew Savchenko

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

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 2604 bytes --]

07.12.2020 13:18, Andrey Savchenko пишет:
> On Mon, 7 Dec 2020 13:10:50 +0300 Валерий Иноземцев wrote:
>> 07.12.2020 10:43, Andrey Savchenko пишет:
>>> On Mon, 7 Dec 2020 09:24:16 +0300 Валерий Иноземцев wrote:
>>>> 06.12.2020 16:21, Vladimir D. Seleznev пишет:
>>>>> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
>>>>> /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
>>>>> /var/{run,lock}.
>>>>
>>>> $ l /var/{run,lock}
>>>> lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
>>>> lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
>>>>
>>>> что ему мешает и кому вообще нужен sysvinit?
>>>
>>> sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 
>>
>> с некрофилами все понятно, лично мне вся эта некрофилия не интересна
>> интересен ответ на первую часть вопроса
> 
> У нас в дистрибутиве поддерживают разные решения для разных людей.
> Мало того, на международной арене нашим дистрибутивом интересуются
> именно потому, что есть возможность полноценно работать без systemd.
> 
> А вот когда мейнтенер закрывает свой пакет по acl и блокирует
> исправление неинтересных ему багов — это абсолютно, категорически
> неприемлемо. 

много букав и не одной по существу

[root@basalt ~]# rpmquery -a \*systemd\*
systemd-utils-242-alt12.x86_64
libsystemd-242-alt12.x86_64
[root@basalt ~]# rpmquery -a \*sysvinit\*
sysvinit-2.88-alt5.x86_64
sysvinit-utils-2.88-alt5.x86_64
[root@basalt ~]# rpmquery -a acpid\*
acpid-events-power-2.0.32-alt1.noarch
acpid-2.0.32-alt1.x86_64
[root@basalt ~]# service acpid status
acpid is running
[root@basalt ~]# service acpid restart
Stopping acpid service:


              [ DONE ]
Starting acpid service:


              [ DONE ]
[root@basalt ~]# service acpid status
acpid is running
[root@basalt ~]# l /var/{run,lock}
lrwxrwxrwx 1 root root  6 Jan 29  2020 /var/run -> ../run/
lrwxrwxrwx 1 root root 11 Jan 29  2020 /var/lock -> ../run/lock/

-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Michael Shigorin]

On Mon, Dec 07, 2020 at 01:51:23PM +0300, Валерий Иноземцев wrote:
> >>>>> Исправление init-скрипта.
> >>>> что ему мешает и кому вообще нужен sysvinit?

Если есть возможность поставлять когерентную конфигурацию,
так и надо делать, а не полагаться на то, что или установка
новая, или хозяин точно прочёл/понял/применил рекомендации.

> >>> sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 
> >> с некрофилами все понятно, лично мне вся эта некрофилия не интересна

А это что было, крофил ты наш?

> [root@basalt ~]# rpmquery -a \*systemd\*
> systemd-utils-242-alt12.x86_64
> libsystemd-242-alt12.x86_64
> [root@basalt ~]# rpmquery -a \*sysvinit\*
> sysvinit-2.88-alt5.x86_64
> sysvinit-utils-2.88-alt5.x86_64

> >> интересен ответ на первую часть вопроса
> > А вот когда мейнтенер закрывает свой пакет по acl и блокирует
> > исправление неинтересных ему багов
> много букав и не одной по существу

Раз тебе бага неинтересна -- добавь, пожалуйста, @qa в ACL.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 2115 bytes --]

07.12.2020 14:00, Michael Shigorin пишет:
> On Mon, Dec 07, 2020 at 01:51:23PM +0300, Валерий Иноземцев wrote:
>>>>>>> Исправление init-скрипта.
>>>>>> что ему мешает и кому вообще нужен sysvinit?
> 
> Если есть возможность поставлять когерентную конфигурацию,
> так и надо делать, а не полагаться на то, что или установка
> новая, или хозяин точно прочёл/понял/применил рекомендации.
> 
>>>>> sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 
>>>> с некрофилами все понятно, лично мне вся эта некрофилия не интересна
> 
> А это что было, крофил ты наш?

реальный тест на некрофильной системе, а не какое то там словоблудие.
если у вас в некрофильной системе нет нужных симлинков, то это проблема
не конкретного acpid (сколько еще таких?), а того кто осуществлял этот
переход и не обеспечил совместимость

$ rpmquery -f /var/run
filesystem-2.3.18-alt1.aarch64

>> [root@basalt ~]# rpmquery -a \*systemd\*
>> systemd-utils-242-alt12.x86_64
>> libsystemd-242-alt12.x86_64
>> [root@basalt ~]# rpmquery -a \*sysvinit\*
>> sysvinit-2.88-alt5.x86_64
>> sysvinit-utils-2.88-alt5.x86_64
> 
>>>> интересен ответ на первую часть вопроса
>>> А вот когда мейнтенер закрывает свой пакет по acl и блокирует
>>> исправление неинтересных ему багов
>> много букав и не одной по существу
> 
> Раз тебе бага неинтересна -- добавь, пожалуйста, @qa в ACL.
> 


-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Michael Shigorin]

On Mon, Dec 07, 2020 at 02:08:21PM +0300, Валерий Иноземцев wrote:
> > Если есть возможность поставлять когерентную конфигурацию,
> > так и надо делать, а не полагаться на то, что или установка
> > новая, или хозяин точно прочёл/понял/применил рекомендации.

Здесь вопросы есть?

> >>>>> sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 
> >>>> с некрофилами все понятно, лично мне вся эта некрофилия не интересна
> > А это что было, крофил ты наш?
> реальный тест на некрофильной системе, а не какое то там словоблудие.

Словоблудие -- вот:

> если у вас в некрофильной системе нет нужных симлинков, то это
> проблема не конкретного acpid (сколько еще таких?), а того кто
> осуществлял этот переход и не обеспечил совместимость

Моё участие в ALT Linux Team началось с того, что webalizer
"из коробки" смотрел в /usr/local/apache насчёт логов, надо
было каждый раз делать тривиальную (и предсказуемую) правку
на /var/log/httpd/ для того, чтоб он заработал.

Альт взлетал не за счёт создания всех возможных рогаток
(разве что нужных вроде listen = 127.0.0.1 ;-), а за счёт
прагматичных решений.  В том числе автоматизации рутины.
Если бы был разумный вариант те симлинки переставить --
его бы уже сделали.  Желающие могут перечитать
http://bugzilla.altlinux.org/32358

PS: прекрати обкладывать всех чем попало, да не обложен будешь;
[самоцензура].  Но, блин, с такими фанатиками я лучше пойду ОС
Эльбрус пилить -- там всё древнее в плане инфраструктуры, зато
[самоцензура], см. тж. http://systemd.io/RANDOM_SEEDS ("берите
intel hwrng, вы же ему доверяете").

PPS 2 shaba: спасибо тебе, что как можешь -- прикрываешь,
но это примерно как пограничник на большой войне, увы.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Mikhail Novosyolov]

07.12.2020 14:27, Michael Shigorin пишет:
> Словоблудие -- вот:
>
>> если у вас в некрофильной системе нет нужных симлинков, то это
>> проблема не конкретного acpid (сколько еще таких?), а того кто
>> осуществлял этот переход и не обеспечил совместимость
> Моё участие в ALT Linux Team началось с того, что webalizer
> "из коробки" смотрел в /usr/local/apache насчёт логов, надо
> было каждый раз делать тривиальную (и предсказуемую) правку
> на /var/log/httpd/ для того, чтоб он заработал.
>
> Альт взлетал не за счёт создания всех возможных рогаток
> (разве что нужных вроде listen = 127.0.0.1 ;-), а за счёт
> прагматичных решений.  В том числе автоматизации рутины.
> Если бы был разумный вариант те симлинки переставить --
> его бы уже сделали.  Желающие могут перечитать
> http://bugzilla.altlinux.org/32358
>
> PS: прекрати обкладывать всех чем попало, да не обложен будешь;
> [самоцензура].  Но, блин, с такими фанатиками я лучше пойду ОС
> Эльбрус пилить -- там всё древнее в плане инфраструктуры, зато
> [самоцензура], см. тж. http://systemd.io/RANDOM_SEEDS ("берите
> intel hwrng, вы же ему доверяете").

Но ведь это тоже фанатизм, только в обратную сторону ;-) Большинству людей удобен systemd, он решает их конкретные задачи и делает это лучше, чем sysvinit, они жертвуют простотой и предсказуемостью ради функционала, удобства работы, автоматизации иных задач.

Думаю, если бы я сопровождал пакеты с демонами, а любители sysvinit регулярно капали на мозг или так или иначе отвлекали, было бы немудрено слегка сорваться. Должно же быть ощущение небесполезности работы по качественному сопровождению init-скрипта. А когда в твоем пакете лежит НЕЧТО, за работу чего ты толком не отвечаешь, т.к., например, у тебя банально нет sysvinit, но понимаешь, что так делать неправильно, нарушается душевное равновесия.

Может, проще init-скрипты вынести в отдельный пакет, которым будет рулить группа любителей sysvinit? Такой вариант в Альте никогда не обсуждался?

>
> PPS 2 shaba: спасибо тебе, что как можешь -- прикрываешь,
> но это примерно как пограничник на большой войне, увы.
>

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Alexey Gladkov]

On Mon, Dec 07, 2020 at 03:25:51PM +0300, Mikhail Novosyolov wrote:
> Может, проще init-скрипты вынести в отдельный пакет, которым будет
> рулить группа любителей sysvinit? Такой вариант в Альте никогда не
> обсуждался?

Не обсуждался. Потому что такой подход обречён на провал. init-скрипт
будет в роли догоняющего и в какой-то момент случится так, что сервис
поменяется, а init-скрипт не будет это учитывать.

Я видел идеи по конвертации systemd-сервисов в init-скрипты, но нормальной
реализации не видел, а писать что-то такое для альта нет мотивации.

-- 
Rgrds, legion

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Mikhail Novosyolov]

07.12.2020 15:43, Alexey Gladkov пишет:
> On Mon, Dec 07, 2020 at 03:25:51PM +0300, Mikhail Novosyolov wrote:
>> Может, проще init-скрипты вынести в отдельный пакет, которым будет
>> рулить группа любителей sysvinit? Такой вариант в Альте никогда не
>> обсуждался?
> Не обсуждался. Потому что такой подход обречён на провал. init-скрипт
> будет в роли догоняющего и в какой-то момент случится так, что сервис
> поменяется, а init-скрипт не будет это учитывать.
Смотря какое качество сопровождения init-скриптов в среднем по больнице сейчас и что будет в будущем, когда то, что в них запускается, будет меняться, а тестировать старые скрипты в новых версиях пакетов большинство мейнтейнеров не будет.
> Я видел идеи по конвертации systemd-сервисов в init-скрипты, но нормальной
> реализации не видел, а писать что-то такое для альта нет мотивации.
Полноценно конвертировать нельзя. Например, в systemd-сервисе выставляются capabilities, создается особый mount-namespace, включается учет статистики потребления сетевого трафика и i/o. Запускать setcap внутри чего-то внутри чего-то внутри чего-то и надеяться, что выстроенная цепочка утилит отработает правильно? Или забивать на такое и запускать просто от root?

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Alexey Gladkov]

On Mon, Dec 07, 2020 at 04:04:01PM +0300, Mikhail Novosyolov wrote:
> 07.12.2020 15:43, Alexey Gladkov пишет:
> > On Mon, Dec 07, 2020 at 03:25:51PM +0300, Mikhail Novosyolov wrote:
> >> Может, проще init-скрипты вынести в отдельный пакет, которым будет
> >> рулить группа любителей sysvinit? Такой вариант в Альте никогда не
> >> обсуждался?
> > Не обсуждался. Потому что такой подход обречён на провал. init-скрипт
> > будет в роли догоняющего и в какой-то момент случится так, что сервис
> > поменяется, а init-скрипт не будет это учитывать.
> Смотря какое качество сопровождения init-скриптов в среднем по больнице
> сейчас и что будет в будущем, когда то, что в них запускается, будет
> меняться, а тестировать старые скрипты в новых версиях пакетов
> большинство мейнтейнеров не будет.

Это известная проблема (aka "я в домике"). Она существует и для обратного
случая. Например, у меня нет systemd и сервисы для него в моих пакетах
мной не тестируются.

> > Я видел идеи по конвертации systemd-сервисов в init-скрипты, но
> > нормальной реализации не видел, а писать что-то такое для альта нет
> > мотивации.
> Полноценно конвертировать нельзя. Например, в systemd-сервисе
> выставляются capabilities, создается особый mount-namespace, включается
> учет статистики потребления сетевого трафика и i/o. Запускать setcap
> внутри чего-то внутри чего-то внутри чего-то и надеяться, что
> выстроенная цепочка утилит отработает правильно? Или забивать на такое и
> запускать просто от root?

Также как миграция sysv-скриптов в systemd-сервисы не всё учитывает, так и
обратная операция не обязательно всё сможет подхватить.

Для sysvinit мы реализовывали гибкое выставление rlimit. Ничего не мешает
добавить поддержку namespace (для них у меня где-то валялся набросок) и
capabilities.

Утилитам я доверяю больше т.к. их удобнее отлаживать.

-- 
Rgrds, legion

[devel] (без темы)

[Vladislav Zavjalov]

On Mon, Dec 07, 2020 at 01:43:30PM +0100, Alexey Gladkov wrote:
> On Mon, Dec 07, 2020 at 03:25:51PM +0300, Mikhail Novosyolov wrote:
> > Может, проще init-скрипты вынести в отдельный пакет, которым будет
> > рулить группа любителей sysvinit? Такой вариант в Альте никогда не
> > обсуждался?
> 
> Не обсуждался. Потому что такой подход обречён на провал. init-скрипт
> будет в роли догоняющего и в какой-то момент случится так, что сервис
> поменяется, а init-скрипт не будет это учитывать.
> 
> Я видел идеи по конвертации systemd-сервисов в init-скрипты, но нормальной
> реализации не видел, а писать что-то такое для альта нет мотивации.

Произвольные инит-скрипты в одном месте собирать, кажется, имеет смысл
только для пакетов, в которых инит-скрипты не интересны ни апстриму
ни мантейнеру. Да и то, может быть, лучше делать отдельные пакеты с
инит-скриптами (что-то типа *-sysv), и смотреть по месту, где будут
жить их исходники: в самом пакете или отдельно. Но от пользователей
потребуется помнить про эти дополнительные пакеты - это большой минус
живущих отдельно инит-скриптов.

Тут еще параллельно идет обсуждение prefdm, который и является
собранными в одном месте инит-скриптами от *dm:
https://bugzilla.altlinux.org/show_bug.cgi?id=26405
Такой частный случай, кажется, еще имеет какой-то смысл. Но и про него
есть мнение, что смысла не так уж много.

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladislav Zavjalov]

On Mon, Dec 07, 2020 at 11:31:55PM +0300, Vladislav Zavjalov wrote:
> Произвольные инит-скрипты в одном месте собирать, кажется, имеет смысл
> только для пакетов, в которых инит-скрипты не интересны ни апстриму
> ни мантейнеру. Да и то, может быть, лучше делать отдельные пакеты с
> инит-скриптами (что-то типа *-sysv), и смотреть по месту, где будут
> жить их исходники: в самом пакете или отдельно. Но от пользователей
> потребуется помнить про эти дополнительные пакеты - это большой минус
> живущих отдельно инит-скриптов.
> 
> Тут еще параллельно идет обсуждение prefdm, который и является
> собранными в одном месте инит-скриптами от *dm:
> https://bugzilla.altlinux.org/show_bug.cgi?id=26405
> Такой частный случай, кажется, еще имеет какой-то смысл. Но и про него
> есть мнение, что смысла не так уж много.

Прошу прощения за потерянную тему в письме.

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vitaly Lipatov]

Alexey Gladkov писал 7.12.20 15:43:
> On Mon, Dec 07, 2020 at 03:25:51PM +0300, Mikhail Novosyolov wrote:
>> Может, проще init-скрипты вынести в отдельный пакет, которым будет
>> рулить группа любителей sysvinit? Такой вариант в Альте никогда не
>> обсуждался?
> 
> Не обсуждался. Потому что такой подход обречён на провал. init-скрипт
> будет в роли догоняющего и в какой-то момент случится так, что сервис
> поменяется, а init-скрипт не будет это учитывать.
> 
> Я видел идеи по конвертации systemd-сервисов в init-скрипты, но 
> нормальной
> реализации не видел, а писать что-то такое для альта нет мотивации.
Плохая реализация есть в репозитории в виде пакета anyservice (запускает 
на sysvinit service-файлы через monit). Готов её улучшить, если 
понравится кому-то. Пока что оно в состоянии «у меня работает».

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Michael Shigorin]

On Mon, Dec 07, 2020 at 03:25:51PM +0300, Mikhail Novosyolov wrote:
> Думаю, если бы я сопровождал пакеты с демонами, а любители
> sysvinit регулярно капали на мозг или так или иначе отвлекали,
> было бы немудрено слегка сорваться. Должно же быть ощущение
> небесполезности работы по качественному сопровождению
> init-скрипта.

Тёзка, тут NMU готовое прислали.  А "пинками в светлое будущее"
мы уже в изводе других глобализаторов проходили, спасибо, хватит.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Mikhail Novosyolov]

07.12.2020 15:48, Michael Shigorin пишет:
> On Mon, Dec 07, 2020 at 03:25:51PM +0300, Mikhail Novosyolov wrote:
>> Думаю, если бы я сопровождал пакеты с демонами, а любители
>> sysvinit регулярно капали на мозг или так или иначе отвлекали,
>> было бы немудрено слегка сорваться. Должно же быть ощущение
>> небесполезности работы по качественному сопровождению
>> init-скрипта.
> Тёзка, тут NMU готовое прислали.  А "пинками в светлое будущее"
> мы уже в изводе других глобализаторов проходили, спасибо, хватит.
>
Тут да. Но у такой реакции наверняка есть какие-то предпосылки.

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladimir D. Seleznev]

On Mon, Dec 07, 2020 at 02:08:21PM +0300, Валерий Иноземцев wrote:
> 07.12.2020 14:00, Michael Shigorin пишет:
> > On Mon, Dec 07, 2020 at 01:51:23PM +0300, Валерий Иноземцев wrote:
> >>>>>>> Исправление init-скрипта.
> >>>>>> что ему мешает и кому вообще нужен sysvinit?
> > 
> > Если есть возможность поставлять когерентную конфигурацию,
> > так и надо делать, а не полагаться на то, что или установка
> > новая, или хозяин точно прочёл/понял/применил рекомендации.
> > 
> >>>>> sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 
> >>>> с некрофилами все понятно, лично мне вся эта некрофилия не интересна
> > 
> > А это что было, крофил ты наш?
> 
> реальный тест на некрофильной системе, а не какое то там словоблудие.
> если у вас в некрофильной системе нет нужных симлинков, то это проблема
> не конкретного acpid (сколько еще таких?), а того кто осуществлял этот
> переход и не обеспечил совместимость
> 
> $ rpmquery -f /var/run
> filesystem-2.3.18-alt1.aarch64
> 
> >> [root@basalt ~]# rpmquery -a \*systemd\*
> >> systemd-utils-242-alt12.x86_64
> >> libsystemd-242-alt12.x86_64
> >> [root@basalt ~]# rpmquery -a \*sysvinit\*
> >> sysvinit-2.88-alt5.x86_64
> >> sysvinit-utils-2.88-alt5.x86_64
> > 
> >>>> интересен ответ на первую часть вопроса
> >>> А вот когда мейнтенер закрывает свой пакет по acl и блокирует
> >>> исправление неинтересных ему багов
> >> много букав и не одной по существу

А можно просто пропустить исправление в Сизиф?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Dmitry V. Levin]

On Mon, Dec 07, 2020 at 02:08:21PM +0300, Валерий Иноземцев wrote:
[...]
> если у вас в некрофильной системе нет нужных симлинков, то это проблема
> не конкретного acpid (сколько еще таких?), а того кто осуществлял этот
> переход и не обеспечил совместимость

Разве кто-то осуществлял переход?
На мой взгляд, происходит неорганизованное переползание,
которое начали одни, а страдают из-за этого, как водится, другие.

Но всё это не имеет отношение к предмету обсуждения.


-- 
ldv

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladislav Zavjalov]

On Mon, Dec 07, 2020 at 10:43:17AM +0300, Andrey Savchenko wrote:
> On Mon, 7 Dec 2020 09:24:16 +0300 Валерий Иноземцев wrote:
> > 06.12.2020 16:21, Vladimir D. Seleznev пишет:
> > > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> > > /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> > > /var/{run,lock}.
> > 
> > $ l /var/{run,lock}
> > lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
> > lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
> > 
> > что ему мешает и кому вообще нужен sysvinit?
> 
> sysvinit нужен много кому, в т.ч. мне, vseleznev, mike, legion. 

Я тоже использую.

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Sergey Bolshakov]

>>>>> "Валерий" == Валерий Иноземцев <shrek-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > 06.12.2020 16:21, Vladimir D. Seleznev пишет:
 >> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
 >> /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
 >> /var/{run,lock}.

 > $ l /var/{run,lock}
 > lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
 > lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run

 > что ему мешает и кому вообще нужен sysvinit?

Да собственно и acpid ..
Нажатие Самой Важной Кнопки замечательно обрабатывается и без него.

-- 

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Sergey V Turchin]

On Monday, 7 December 2020 14:08:58 MSK Sergey Bolshakov wrote:

[...]
>  > что ему мешает и кому вообще нужен sysvinit?
> Да собственно и acpid ..
nvidia раньше необходим был; сейчас не знаю, давно не пробовал без него.

> Нажатие Самой Важной Кнопки замечательно обрабатывается и без него.
acpid-events-power уже давно не устанавливается там, где замечательно 
обрабатывается без него.

-- 
Regards, Sergey.

Re: [devel] кому вообще нужен sysvinit

[Dmitry V. Levin]

On Mon, Dec 07, 2020 at 09:24:16AM +0300, Валерий Иноземцев wrote:
> 06.12.2020 16:21, Vladimir D. Seleznev пишет:
> > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> > /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> > /var/{run,lock}.
> 
> $ l /var/{run,lock}
> lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
> lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
> 
> что ему мешает и кому вообще нужен sysvinit?

Альтернативы, к сожалению, оказались хуже, хотя и были такими
многообещающими.  Вот, например, так выглядит один популярный вариант:

$ ldd /proc/1/exe
	linux-vdso.so.1 (0x00007ffc93c5c000)
	libsystemd-shared-247.so => /lib/systemd/libsystemd-shared-247.so (0x00007ff631f84000)
	librt.so.1 => /lib64/librt.so.1 (0x00007ff631f75000)
	libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007ff631f53000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007ff631f27000)
	libmount.so.1 => /lib64/libmount.so.1 (0x00007ff631ec9000)
	libpam.so.0 => /lib64/libpam.so.0 (0x00007ff631eb7000)
	libaudit.so.1 => /lib64/libaudit.so.1 (0x00007ff631e89000)
	libkmod.so.2 => /lib64/libkmod.so.2 (0x00007ff631e6f000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ff631cab000)
	libacl.so.1 => /lib64/libacl.so.1 (0x00007ff631ca0000)
	libblkid.so.1 => /lib64/libblkid.so.1 (0x00007ff631c50000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007ff631c48000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007ff631c0e000)
	libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007ff631aef000)
	libip4tc.so.2 => /lib64/libip4tc.so.2 (0x00007ff631ae5000)
	liblz4.so.1 => /lib64/liblz4.so.1 (0x00007ff631ac2000)
	libzstd.so.1 => /lib64/libzstd.so.1 (0x00007ff631a0c000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007ff6319df000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007ff6319d8000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff6319b7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff6323c0000)
	libpcre.so.3 => /lib64/libpcre.so.3 (0x00007ff631971000)
	libz.so.1 => /lib64/libz.so.1 (0x00007ff631954000)
	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007ff631680000)
	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007ff63165c000)

Возможно, вас это устраивает, но для других это blocker.


-- 
ldv

Re: [devel] кому вообще нужен sysvinit

[Sergey V Turchin]

On Monday, 7 December 2020 14:55:09 MSK Dmitry V wrote:
> On Mon, Dec 07, 2020 at 09:24:16AM +0300, Валерий Иноземцев wrote:
> > 06.12.2020 16:21, Vladimir D. Seleznev пишет:
> > > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> > > /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> > > /var/{run,lock}.
> > 
> > $ l /var/{run,lock}
> > lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
> > lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
> > 
> > что ему мешает и кому вообще нужен sysvinit?
> 
> Альтернативы, к сожалению, оказались хуже, хотя и были такими
> многообещающими.  Вот, например, так выглядит один популярный вариант:
> 
> $ ldd /proc/1/exe
> 	linux-vdso.so.1 (0x00007ffc93c5c000)
> 	libsystemd-shared-247.so => /lib/systemd/libsystemd-shared-247.so
> (0x00007ff631f84000) librt.so.1 => /lib64/librt.so.1 (0x00007ff631f75000)
> 	libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007ff631f53000)
> 	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007ff631f27000)
[...]
> 	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007ff631680000)
> 	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007ff63165c000)
> 
> Возможно, вас это устраивает, но для других это blocker.
Там многое делали опциональным недавно, вроде.

-- 
Regards, Sergey.

Re: [devel] кому вообще нужен sysvinit

[Mikhail Novosyolov]

07.12.2020 15:02, Sergey V Turchin пишет:
>
>> Альтернативы, к сожалению, оказались хуже, хотя и были такими
>> многообещающими.  Вот, например, так выглядит один популярный вариант:
>>
>> $ ldd /proc/1/exe
>> 	linux-vdso.so.1 (0x00007ffc93c5c000)
>> 	libsystemd-shared-247.so => /lib/systemd/libsystemd-shared-247.so
>> (0x00007ff631f84000) librt.so.1 => /lib64/librt.so.1 (0x00007ff631f75000)
>> 	libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007ff631f53000)
>> 	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007ff631f27000)
> [...]
>> 	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007ff631680000)
>> 	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007ff63165c000)
>>
>> Возможно, вас это устраивает, но для других это blocker.
> Там многое делали опциональным недавно, вроде.
>
Ага, dlopen() захадкоженного soname с надеждой на провиденье, что необходимый ABI есть в библиотеке. set-versions и пр. идут лесом.

Re: [devel] кому вообще нужен sysvinit

[Sergey V Turchin]

On Monday, 7 December 2020 15:21:16 MSK Mikhail Novosyolov wrote:

[...]
> > Там многое делали опциональным недавно, вроде.
> 
> Ага, dlopen() захадкоженного soname с надеждой на провиденье, что
> необходимый ABI есть в библиотеке. set-versions и пр. идут лесом.
Значит, для нас просто ничего не изменилось.

-- 
Regards, Sergey.

Re: [devel] кому вообще нужен sysvinit

[Mikhail Novosyolov]

07.12.2020 15:24, Sergey V Turchin пишет:
> On Monday, 7 December 2020 15:21:16 MSK Mikhail Novosyolov wrote:
>
> [...]
>>> Там многое делали опциональным недавно, вроде.
>> Ага, dlopen() захадкоженного soname с надеждой на провиденье, что
>> необходимый ABI есть в библиотеке. set-versions и пр. идут лесом.
> Значит, для нас просто ничего не изменилось.
>
Почему не изменилось? То пакетная система гарантировала несломанность ABI в systemd, а то не гарантирует.

Re: [devel] кому вообще нужен sysvinit

[Sergey V Turchin]

On Monday, 7 December 2020 15:28:21 MSK Mikhail Novosyolov wrote:
> 07.12.2020 15:24, Sergey V Turchin пишет:
> > On Monday, 7 December 2020 15:21:16 MSK Mikhail Novosyolov wrote:
> > 
> > [...]
> > 
> >>> Там многое делали опциональным недавно, вроде.
> >> 
> >> Ага, dlopen() захадкоженного soname с надеждой на провиденье, что
> >> необходимый ABI есть в библиотеке. set-versions и пр. идут лесом.
> > 
> > Значит, для нас просто ничего не изменилось.
> 
> Почему не изменилось? То пакетная система гарантировала несломанность ABI в
> systemd, а то не гарантирует.
Его будет нельзя слинковать?

-- 
Regards, Sergey.

Re: [devel] кому вообще нужен sysvinit

[Mikhail Novosyolov]

07.12.2020 15:38, Sergey V Turchin пишет:
> On Monday, 7 December 2020 15:28:21 MSK Mikhail Novosyolov wrote:
>> 07.12.2020 15:24, Sergey V Turchin пишет:
>>> On Monday, 7 December 2020 15:21:16 MSK Mikhail Novosyolov wrote:
>>>
>>> [...]
>>>
>>>>> Там многое делали опциональным недавно, вроде.
>>>> Ага, dlopen() захадкоженного soname с надеждой на провиденье, что
>>>> необходимый ABI есть в библиотеке. set-versions и пр. идут лесом.
>>> Значит, для нас просто ничего не изменилось.
>> Почему не изменилось? То пакетная система гарантировала несломанность ABI в
>> systemd, а то не гарантирует.
> Его будет нельзя слинковать?
>
пока нет. https://github.com/systemd/systemd/issues/17769

Re: [devel] кому вообще нужен sysvinit

[Sergey V Turchin]

On Monday, 7 December 2020 15:49:50 MSK Mikhail Novosyolov wrote:

[...]
> >>>> Ага, dlopen() захадкоженного soname с надеждой на провиденье, что
> >>>> необходимый ABI есть в библиотеке. set-versions и пр. идут лесом.
> >>> 
> >>> Значит, для нас просто ничего не изменилось.
> >> 
> >> Почему не изменилось? То пакетная система гарантировала несломанность ABI
> >> в
> >> systemd, а то не гарантирует.
> > 
> > Его будет нельзя слинковать?
> 
> пока нет. https://github.com/systemd/systemd/issues/17769
Закиньте туда на всякий ссылку https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gfc-internals/Symbol-Versioning.html .
Пусть попробует такие версии ABI пооткрывать. ;-)

-- 
Regards, Sergey.

Re: [devel] кому вообще нужен sysvinit

[Mikhail Novosyolov]

07.12.2020 16:04, Sergey V Turchin пишет:
> On Monday, 7 December 2020 15:49:50 MSK Mikhail Novosyolov wrote:
>
> [...]
>>>>>> Ага, dlopen() захадкоженного soname с надеждой на провиденье, что
>>>>>> необходимый ABI есть в библиотеке. set-versions и пр. идут лесом.
>>>>> Значит, для нас просто ничего не изменилось.
>>>> Почему не изменилось? То пакетная система гарантировала несломанность ABI
>>>> в
>>>> systemd, а то не гарантирует.
>>> Его будет нельзя слинковать?
>> пока нет. https://github.com/systemd/systemd/issues/17769
> Закиньте туда на всякий ссылку https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gfc-internals/Symbol-Versioning.html .
> Пусть попробует такие версии ABI пооткрывать. ;-)

Это обсуждается здесь: https://github.com/systemd/systemd/pull/17416

Готовится обновление формата ELF

Re: [devel] [JT] кому вообще нужен sysvinit

[Arseny Maslennikov]

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

On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
> On Mon, Dec 07, 2020 at 09:24:16AM +0300, Валерий Иноземцев wrote:
> > 06.12.2020 16:21, Vladimir D. Seleznev пишет:
> > > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> > > /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> > > /var/{run,lock}.
> > 
> > $ l /var/{run,lock}
> > lrwxrwxrwx 1 root root 11 дек  2  2019 /var/lock -> ../run/lock
> > lrwxrwxrwx 1 root root  6 дек  2  2019 /var/run -> ../run
> > 
> > что ему мешает и кому вообще нужен sysvinit?
> 
> Альтернативы, к сожалению, оказались хуже, хотя и были такими
> многообещающими.  Вот, например, так выглядит один популярный вариант:
> 
> $ ldd /proc/1/exe
> 	linux-vdso.so.1 (0x00007ffc93c5c000)
> 	libsystemd-shared-247.so => /lib/systemd/libsystemd-shared-247.so (0x00007ff631f84000)
> 	librt.so.1 => /lib64/librt.so.1 (0x00007ff631f75000)
> 	libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007ff631f53000)
> 	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007ff631f27000)
> 	libmount.so.1 => /lib64/libmount.so.1 (0x00007ff631ec9000)
> 	libpam.so.0 => /lib64/libpam.so.0 (0x00007ff631eb7000)
> 	libaudit.so.1 => /lib64/libaudit.so.1 (0x00007ff631e89000)
> 	libkmod.so.2 => /lib64/libkmod.so.2 (0x00007ff631e6f000)
> 	libc.so.6 => /lib64/libc.so.6 (0x00007ff631cab000)
> 	libacl.so.1 => /lib64/libacl.so.1 (0x00007ff631ca0000)
> 	libblkid.so.1 => /lib64/libblkid.so.1 (0x00007ff631c50000)
> 	libcap.so.2 => /lib64/libcap.so.2 (0x00007ff631c48000)
> 	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007ff631c0e000)
> 	libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007ff631aef000)
> 	libip4tc.so.2 => /lib64/libip4tc.so.2 (0x00007ff631ae5000)
> 	liblz4.so.1 => /lib64/liblz4.so.1 (0x00007ff631ac2000)
> 	libzstd.so.1 => /lib64/libzstd.so.1 (0x00007ff631a0c000)
> 	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007ff6319df000)
> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007ff6319d8000)
> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff6319b7000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007ff6323c0000)
> 	libpcre.so.3 => /lib64/libpcre.so.3 (0x00007ff631971000)
> 	libz.so.1 => /lib64/libz.so.1 (0x00007ff631954000)
> 	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007ff631680000)
> 	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007ff63165c000)
> 
> Возможно, вас это устраивает, но для других это blocker.

А в чём именно заключается этот блокер / эта претензия?
Эти слова можно было понять как "слишком толстый pid 1" — такое
эстетическое "фи", принимается.
Или как "слишком забито адресное пространство очень привилегированного и
важного процесса" — тоже принимается. Но тогда где грань между допустимым и
недопустимым?

Я не принимаю какую-либо из сторон, как обычно, правы все; просто интересуюсь.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] кому вообще нужен sysvinit

[Michael Shigorin]

On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
> $ ldd /proc/1/exe
[...]
> Возможно, вас это устраивает, но для других это blocker.

Для меня блокером оказалось уже то, что оно умеет *сегфолтиться*.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] кому вообще нужен sysvinit

[Arseny Maslennikov]

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

On Mon, Dec 07, 2020 at 03:27:53PM +0300, Michael Shigorin wrote:
> On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
> > $ ldd /proc/1/exe
> [...]
> > Возможно, вас это устраивает, но для других это blocker.
> 
> Для меня блокером оказалось уже то, что оно умеет *сегфолтиться*.

Бывают страшилки и пострашнее: как насчёт повисания на write(2) в
пространстве ядра на попытке записи в /dev/console, которая смотрит на
fb на мониторе? Виснет даже /bin/echo > /dev/console.
/proc/$$/stack закончится на redirected_tty_write, если память не
изменяет. Процесс становится неубиваемым.
Самое ужасное, что поди воспроизведи — на парке из 250 машин я
это ловил чуть меньше десятка раз за 2016-2019.

Мейнтейнеры ядра же что к vt-подсистеме, что к tty-подсистеме на
пушечный выстрел боятся подойти.

Где в архитектуре системы такое надо объезжать — вопрос, конечно,
с неоднозначным ответом.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] кому вообще нужен sysvinit

[Alexey Gladkov]

On Mon, Dec 07, 2020 at 04:01:32PM +0300, Arseny Maslennikov wrote:
> On Mon, Dec 07, 2020 at 03:27:53PM +0300, Michael Shigorin wrote:
> > On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
> > > $ ldd /proc/1/exe
> > [...]
> > > Возможно, вас это устраивает, но для других это blocker.
> > 
> > Для меня блокером оказалось уже то, что оно умеет *сегфолтиться*.
> 
> Бывают страшилки и пострашнее: как насчёт повисания на write(2) в
> пространстве ядра на попытке записи в /dev/console, которая смотрит на
> fb на мониторе? Виснет даже /bin/echo > /dev/console.
> /proc/$$/stack закончится на redirected_tty_write, если память не
> изменяет. Процесс становится неубиваемым.
> Самое ужасное, что поди воспроизведи — на парке из 250 машин я
> это ловил чуть меньше десятка раз за 2016-2019.
> 
> Мейнтейнеры ядра же что к vt-подсистеме, что к tty-подсистеме на
> пушечный выстрел боятся подойти.

Можно поподробнее тут и в отдельный тред ?

-- 
Rgrds, legion

Re: [devel] кому вообще нужен sysvinit

[Dmitry V. Levin]

On Mon, Dec 07, 2020 at 04:01:32PM +0300, Arseny Maslennikov wrote:
> On Mon, Dec 07, 2020 at 03:27:53PM +0300, Michael Shigorin wrote:
> > On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
> > > $ ldd /proc/1/exe
> > [...]
> > > Возможно, вас это устраивает, но для других это blocker.
> > 
> > Для меня блокером оказалось уже то, что оно умеет *сегфолтиться*.
> 
> Бывают страшилки и пострашнее

Это не страшилки, а рутинные баги в systemd:
https://bugzilla.redhat.com/show_bug.cgi?id=1902819

Чем сложнее и запутанней pid 1, тем чаще это происходит.


-- 
ldv

Re: [devel] кому вообще нужен sysvinit

[Alexey Sheplyakov]

Добрый вечер!

On 07.12.2020 16:27, Michael Shigorin wrote:
> On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
>> $ ldd /proc/1/exe
> [...]
>> Возможно, вас это устраивает, но для других это blocker.
> 
> Для меня блокером оказалось уже то, что оно умеет *сегфолтиться*.
> 
Ядро (Linux) умеет падать и виснуть гораздо лучше. Поэтому для устойчивости
системы в целом нет разницы, кто там рулевой в userspace - systemd, runit,
или GNU shepherd какой.


Программа, избавленная от глюков, впадает в нирвану. В нирване програмы
не глючат, но и не работают.

Re: [devel] кому вообще нужен sysvinit

[Andrey Savchenko]

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

On Mon, 7 Dec 2020 19:18:45 +0400 Alexey Sheplyakov wrote:
> Добрый вечер!
> 
> On 07.12.2020 16:27, Michael Shigorin wrote:
> > On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
> >> $ ldd /proc/1/exe
> > [...]
> >> Возможно, вас это устраивает, но для других это blocker.
> > 
> > Для меня блокером оказалось уже то, что оно умеет *сегфолтиться*.
> > 
> Ядро (Linux) умеет падать и виснуть гораздо лучше. Поэтому для устойчивости
> системы в целом нет разницы, кто там рулевой в userspace - systemd, runit,
> или GNU shepherd какой.
> 
> 
> Программа, избавленная от глюков, впадает в нирвану. В нирване програмы
> не глючат, но и не работают.

Однако, TeX работает уже то ли 10, то ли 15 лет.
И преложение Кнута о выплатах за найденные ошибки в силе, тем не
менее, не находят уже давно.

Best regards,
Andrew Savchenko

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

Re: [devel] кому вообще нужен sysvinit

[Arseny Maslennikov]

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

On Mon, Dec 07, 2020 at 06:49:03PM +0300, Andrey Savchenko wrote:
> On Mon, 7 Dec 2020 19:18:45 +0400 Alexey Sheplyakov wrote:
> > Добрый вечер!
> > 
> > Ядро (Linux) умеет падать и виснуть гораздо лучше. Поэтому для устойчивости
> > системы в целом нет разницы, кто там рулевой в userspace - systemd, runit,
> > или GNU shepherd какой.
> > 
> > 
> > Программа, избавленная от глюков, впадает в нирвану. В нирване програмы
> > не глючат, но и не работают.
> 
> Однако, TeX работает уже то ли 10, то ли 15 лет.
> И преложение Кнута о выплатах за найденные ошибки в силе, тем не
> менее, не находят уже давно.

Много ли в реализации TeX сетевого и межпроцессного взаимодействия?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] кому вообще нужен sysvinit

[Andrey Savchenko]

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

On Mon, 7 Dec 2020 18:59:24 +0300 Arseny Maslennikov wrote:
> On Mon, Dec 07, 2020 at 06:49:03PM +0300, Andrey Savchenko wrote:
> > On Mon, 7 Dec 2020 19:18:45 +0400 Alexey Sheplyakov wrote:
> > > Добрый вечер!
> > > 
> > > Ядро (Linux) умеет падать и виснуть гораздо лучше. Поэтому для устойчивости
> > > системы в целом нет разницы, кто там рулевой в userspace - systemd, runit,
> > > или GNU shepherd какой.
> > > 
> > > 
> > > Программа, избавленная от глюков, впадает в нирвану. В нирване програмы
> > > не глючат, но и не работают.
> > 
> > Однако, TeX работает уже то ли 10, то ли 15 лет.
> > И преложение Кнута о выплатах за найденные ошибки в силе, тем не
> > менее, не находят уже давно.
> 
> Много ли в реализации TeX сетевого и межпроцессного взаимодействия?

Это не имеет значения, там много других сложностей, но прямые руки
и грамотный, неторопливый подход к написанию кода, а не модный
нынче тяп-ляп-продакшн.

Best regards,
Andrew Savchenko

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

Re: [devel] кому вообще нужен sysvinit

[Vladimir D. Seleznev]

On Mon, Dec 07, 2020 at 07:18:45PM +0400, Alexey Sheplyakov wrote:
> Добрый вечер!
> 
> On 07.12.2020 16:27, Michael Shigorin wrote:
> > On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
> >> $ ldd /proc/1/exe
> > [...]
> >> Возможно, вас это устраивает, но для других это blocker.
> > 
> > Для меня блокером оказалось уже то, что оно умеет *сегфолтиться*.
> > 
> Ядро (Linux) умеет падать и виснуть гораздо лучше. Поэтому для устойчивости
> системы в целом нет разницы, кто там рулевой в userspace - systemd, runit,
> или GNU shepherd какой.

От падения ядра ничего не спасёт. Разве что лучшее ядро. С другой
стороны, я давно не помню падений ядра. Усложнять pid1 (да и вообще
увеличивать сложность системы) -- плохая мысль, больше точек отказал. А
в случае systemd гораздо веселее -- падение какого-нибудь системного
dbus оставляет систему в несопровождаемом состоянии.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] кому вообще нужен sysvinit

[Arseny Maslennikov]

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

On Mon, Dec 07, 2020 at 07:14:22PM +0300, Vladimir D. Seleznev wrote:
> On Mon, Dec 07, 2020 at 07:18:45PM +0400, Alexey Sheplyakov wrote:
> > Добрый вечер!
> > 
> > On 07.12.2020 16:27, Michael Shigorin wrote:
> > > On Mon, Dec 07, 2020 at 02:55:09PM +0300, Dmitry V. Levin wrote:
> > >> $ ldd /proc/1/exe
> > > [...]
> > >> Возможно, вас это устраивает, но для других это blocker.
> > > 
> > > Для меня блокером оказалось уже то, что оно умеет *сегфолтиться*.
> > > 
> > Ядро (Linux) умеет падать и виснуть гораздо лучше. Поэтому для устойчивости
> > системы в целом нет разницы, кто там рулевой в userspace - systemd, runit,
> > или GNU shepherd какой.
> 
> От падения ядра ничего не спасёт. Разве что лучшее ядро. С другой
> стороны, я давно не помню падений ядра. Усложнять pid1 (да и вообще
> увеличивать сложность системы) -- плохая мысль, больше точек отказал. А
> в случае systemd гораздо веселее -- падение какого-нибудь системного
> dbus оставляет систему в несопровождаемом состоянии.

...Как и падение logind.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] кому вообще нужен sysvinit

[Alexey V. Vissarionov]

On 2020-12-07 19:18:45 +0400, Alexey Sheplyakov wrote:

 >>> $ ldd /proc/1/exe
 >> [...]
 >>> Возможно, вас это устраивает, но для других это blocker.
 >> Для меня блокером оказалось уже то, что оно умеет
 >> *сегфолтиться*.
 > Ядро (Linux) умеет падать и виснуть гораздо лучше.

Умеет. Но там проблемный кусок кода можно отключить. А как ты
отключишь, например, чудесную особенность systemd, когда все
процессы уже running, а target все еще никак не reached?

 > Поэтому для устойчивости системы в целом нет разницы, кто там
 > рулевой в userspace - systemd, runit, или GNU shepherd какой.

Разница существенная, и измеряется она в рублях: промышленная
эксплуатация ОС с systemd обходится в среднем на 10...15% дороже,
чем аналогичной ОС с sysVinit.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] кому вообще нужен sysvinit

[Mikhail Novosyolov]

08.12.2020 00:22, Alexey V. Vissarionov пишет:
> On 2020-12-07 19:18:45 +0400, Alexey Sheplyakov wrote:
>
>  >>> $ ldd /proc/1/exe
>  >> [...]
>  >>> Возможно, вас это устраивает, но для других это blocker.
>  >> Для меня блокером оказалось уже то, что оно умеет
>  >> *сегфолтиться*.
>  > Ядро (Linux) умеет падать и виснуть гораздо лучше.
>
> Умеет. Но там проблемный кусок кода можно отключить. А как ты
> отключишь, например, чудесную особенность systemd, когда все
> процессы уже running, а target все еще никак не reached?
>
>  > Поэтому для устойчивости системы в целом нет разницы, кто там
>  > рулевой в userspace - systemd, runit, или GNU shepherd какой.
>
> Разница существенная, и измеряется она в рублях: промышленная
> эксплуатация ОС с systemd обходится в среднем на 10...15% дороже,
> чем аналогичной ОС с sysVinit.
>
> Когда количество машин измеряется хотя бы сотнями - это означает
> найм дополнительных админов и (в случае провайдеров) регулярные
> выплаты неустоек.
Вы забыли учесть время, сэкономленное на борьбу с инит-скриптами - системд делает то, что можно было бы долго делать руками.
>

Re: [devel] кому вообще нужен sysvinit

[Alexey V. Vissarionov]

On 2020-12-08 00:32:44 +0300, Mikhail Novosyolov wrote:
 >>>>> $ ldd /proc/1/exe
 >>>>> Возможно, вас это устраивает, но для других это blocker.
 >>>> Для меня блокером оказалось уже то, что оно умеет
 >>>> *сегфолтиться*.
 >>> Ядро (Linux) умеет падать и виснуть гораздо лучше.
 >> Умеет. Но там проблемный кусок кода можно отключить. А как ты
 >> отключишь, например, чудесную особенность systemd, когда все
 >> процессы уже running, а target все еще никак не reached?
 >>> Поэтому для устойчивости системы в целом нет разницы, кто там
 >>> рулевой в userspace - systemd, runit, или GNU shepherd какой.
 >> Разница существенная, и измеряется она в рублях: промышленная
 >> эксплуатация ОС с systemd обходится в среднем на 10...15% дороже,
 >> чем аналогичной ОС с sysVinit.
 >> Когда количество машин измеряется хотя бы сотнями - это означает
 >> найм дополнительных админов и (в случае провайдеров) регулярные
 >> выплаты неустоек.
 > Вы забыли учесть время, сэкономленное на борьбу с инит-скриптами
 > - системд делает то, что можно было бы долго делать руками.

Стоимость эксплуатации включает в себя в том числе и рабочее время
админов. И оно, разумеется, учтено.

Так что systemd - это просто дорого. Как бы оно ни нравилось вам и
всем вашим единомышленникам.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] кому вообще нужен sysvinit

[mikhailnov]

08.12.2020 00:44, Alexey V. Vissarionov пишет:
> On 2020-12-08 00:32:44 +0300, Mikhail Novosyolov wrote:
>  >>>>> $ ldd /proc/1/exe
>  >>>>> Возможно, вас это устраивает, но для других это blocker.
>  >>>> Для меня блокером оказалось уже то, что оно умеет
>  >>>> *сегфолтиться*.
>  >>> Ядро (Linux) умеет падать и виснуть гораздо лучше.
>  >> Умеет. Но там проблемный кусок кода можно отключить. А как ты
>  >> отключишь, например, чудесную особенность systemd, когда все
>  >> процессы уже running, а target все еще никак не reached?
>  >>> Поэтому для устойчивости системы в целом нет разницы, кто там
>  >>> рулевой в userspace - systemd, runit, или GNU shepherd какой.
>  >> Разница существенная, и измеряется она в рублях: промышленная
>  >> эксплуатация ОС с systemd обходится в среднем на 10...15% дороже,
>  >> чем аналогичной ОС с sysVinit.
>  >> Когда количество машин измеряется хотя бы сотнями - это означает
>  >> найм дополнительных админов и (в случае провайдеров) регулярные
>  >> выплаты неустоек.
>  > Вы забыли учесть время, сэкономленное на борьбу с инит-скриптами
>  > - системд делает то, что можно было бы долго делать руками.
>
> Стоимость эксплуатации включает в себя в том числе и рабочее время
> админов.
мастеров кунг-фу по написанию баш-портянок по щелчку пальцев со встроенным в головной мозг shellcheck(1). Их рабочее время недешево должно быть.
> И оно, разумеется, учтено.
>
> Так что systemd - это просто дорого. Как бы оно ни нравилось вам и
> всем вашим единомышленникам.

Re: [devel] кому вообще нужен sysvinit

[Anton Farygin]

On 08.12.2020 00:22, Alexey V. Vissarionov wrote:
> Разница существенная, и измеряется она в рублях: промышленная
> эксплуатация ОС с systemd обходится в среднем на 10...15% дороже,
> чем аналогичной ОС с sysVinit.

Это фантазии, реальные же проблемы есть и там и там и выбор systemd 
никак не сказывается на стоимости эксплуатации.

Re: [devel] кому вообще нужен sysvinit

[Alexey V. Vissarionov]

On 2020-12-08 06:52:45 +0300, Anton Farygin wrote:

 >> Разница существенная, и измеряется она в рублях: промышленная
 >> эксплуатация ОС с systemd обходится в среднем на 10...15% дороже,
 >> чем аналогичной ОС с sysVinit.
 > Это фантазии, реальные же проблемы есть и там и там и выбор
 > systemd никак не сказывается на стоимости эксплуатации.

Расскажи об этих своих фантазиях провайдерам, которые до сих пор
используют CentOS 6...


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] кому вообще нужен sysvinit

[Anton Farygin]

On 08.12.2020 07:48, Alexey V. Vissarionov wrote:
> On 2020-12-08 06:52:45 +0300, Anton Farygin wrote:
>
>   >> Разница существенная, и измеряется она в рублях: промышленная
>   >> эксплуатация ОС с systemd обходится в среднем на 10...15% дороже,
>   >> чем аналогичной ОС с sysVinit.
>   > Это фантазии, реальные же проблемы есть и там и там и выбор
>   > systemd никак не сказывается на стоимости эксплуатации.
>
> Расскажи об этих своих фантазиях провайдерам, которые до сих пор
> используют CentOS 6...

Главная тема не раскрыта - как это связано со стоимостью эксплуатации ? 
У меня есть знакомые провайдеры, успешно использующие решения с systemd 
в своей работе.

Re: [devel] кому вообще нужен sysvinit

[Alexey Sheplyakov]

On 08.12.2020 01:22, Alexey V. Vissarionov wrote:
> On 2020-12-07 19:18:45 +0400, Alexey Sheplyakov wrote:
> 
>  >>> $ ldd /proc/1/exe
>  >> [...]
>  >>> Возможно, вас это устраивает, но для других это blocker.
>  >> Для меня блокером оказалось уже то, что оно умеет
>  >> *сегфолтиться*.
>  > Ядро (Linux) умеет падать и виснуть гораздо лучше.
> 
> Умеет. Но там проблемный кусок кода можно отключить.

Ну отключил я CONFIG_ACPI, и что дальше? "Если у них нет хлеба, пусть едят пирожные"?

(А для начала вообще надо найти, что отключить)


 А как ты
> отключишь, например, чудесную особенность systemd, когда все
> процессы уже running, а target все еще никак не reached?

Если NNN.target Requires=foobar.socket, то по определению reached он
будет после того, как на сокете кто-то начнет слушать. И это хорошо.
Потому что можно описать зависимости вида "apache нужно стартовать тогда,
когда mysql уже слушает". Или "ceph нужно стартовать после того, как появились
такие-то блочные устройства". Кстати, как там дела у sysv с такого рода
зависимостями?

Если NNN.target Requires=xyz.service, у которого Type=notify, и этот самый
xyz завтыкал (не уведомил systemd в положенный таймаут), то тоже никак.
И это тоже хорошо. Что толку от наличия процесса, если он затупил (возможно
не по своей вине, а из-за недостатка ресурсов)?

>  > Поэтому для устойчивости системы в целом нет разницы, кто там
>  > рулевой в userspace - systemd, runit, или GNU shepherd какой.
> 
> Разница существенная, и измеряется она в рублях: промышленная
> эксплуатация ОС с systemd обходится в среднем на 10...15% дороже,
> чем аналогичной ОС с sysVinit.

Наблюдаю строго обратную ситуацию. Requires=такой-то.socket, и тривиальный патч
с sd_notify - и больше не надо держать эникейщиков, которые смотрели в netstat
и перезапускали сервис. Видимо, они и пишут гневные тексты о том, что systemd не нужен.

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Vladislav Zavjalov]

On Sun, Dec 06, 2020 at 04:21:50PM +0300, Vladimir D. Seleznev wrote:
> > > Прошу пропустить задание в Сизиф.
> > 
> > А что в нём?
> 
> Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> /var/{run,lock}.

А все-таки, в чем проблема с этим изменением?
Вне зависимости от того, нужен ли sysvinit, стоят ли у пользователей
правильные симлинки и т.п., было бы правильно приводить все к
/run/{,lock}, если это считается правильным местом. Если кто-то пишет
файл в /var/run, а ищут его в /run, то это выглядит как ошибка, даже
если симлики расставлены.

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Dmitry V. Levin]

On Mon, Dec 07, 2020 at 02:41:15PM +0300, Vladislav Zavjalov wrote:
> On Sun, Dec 06, 2020 at 04:21:50PM +0300, Vladimir D. Seleznev wrote:
> > > > Прошу пропустить задание в Сизиф.
> > > 
> > > А что в нём?
> > 
> > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> > /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> > /var/{run,lock}.
> 
> А все-таки, в чем проблема с этим изменением?

Теперь, когда в %changelog отражена суть изменения, проблема в том,
что исправленный пакет почему-то ещё не в Сизифе.

> Вне зависимости от того, нужен ли sysvinit, стоят ли у пользователей
> правильные симлинки и т.п., было бы правильно приводить все к
> /run/{,lock}, если это считается правильным местом. Если кто-то пишет
> файл в /var/run, а ищут его в /run, то это выглядит как ошибка, даже
> если симлики расставлены.

+1


-- 
ldv

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Dmitry V. Levin]

On Mon, Dec 07, 2020 at 02:48:49PM +0300, Dmitry V. Levin wrote:
> On Mon, Dec 07, 2020 at 02:41:15PM +0300, Vladislav Zavjalov wrote:
> > On Sun, Dec 06, 2020 at 04:21:50PM +0300, Vladimir D. Seleznev wrote:
> > > > > Прошу пропустить задание в Сизиф.
> > > > 
> > > > А что в нём?
> > > 
> > > Исправление init-скрипта. acpid сейчас создаёт pid- и lock-файлы в
> > > /run/{,lock} соответственно, а init-скрипт ожидал их увидеть в
> > > /var/{run,lock}.
> > 
> > А все-таки, в чем проблема с этим изменением?
> 
> Теперь, когда в %changelog отражена суть изменения, проблема в том,
> что исправленный пакет почему-то ещё не в Сизифе.

Поскольку бездействие мантейнера не было аргументировано,
я отправляю эту сборку в Сизиф.

> > Вне зависимости от того, нужен ли sysvinit, стоят ли у пользователей
> > правильные симлинки и т.п., было бы правильно приводить все к
> > /run/{,lock}, если это считается правильным местом. Если кто-то пишет
> > файл в /var/run, а ищут его в /run, то это выглядит как ошибка, даже
> > если симлики расставлены.
> 
> +1


-- 
ldv

Re: [devel] [#262991] EPERM srpm=acpid-2.0.32-alt2.src.rpm

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 605 bytes --]

08.12.2020 13:00, Dmitry V. Levin пишет:
> Поскольку бездействие мантейнера не было аргументировано,
> я отправляю эту сборку в Сизиф.

"не" здесь лишнее

$ ssh git-alt task show 262991
id=262991 locked=no shared=no fail_early=yes test_only=no repo=sisyphus
owner=vseleznv state=DONE try=4 iter=1 age=0w
build_time=2020-Dec-08/10:05:11
 100:userid=vseleznv
 200:srpm=acpid-2.0.32-alt2.src.rpm
 200:userid=vseleznv
 200:approved_by=root_ldv shrek
 200:pkgname=acpid

-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]