ALT Linux Bugzilla – #37572

/var/run/alteratord/.socket действительно нет.

Да, только что хотел написать, что "wrong-type-arg" --- это не настоящая ошибка, а следствие несовершенства проброса исключений в альтераторе.

А почему файла сокета нет, ты понимаешь?

Created attachment 8443 [details]
облом установки

(В ответ на комментарий №2)
> А почему файла сокета нет, ты понимаешь?

Не понимаю. Как он там оказаться должен?

Собрал устнаовочный образ, там при переходе на шаг разбивки, на перезагрузку уходит, не может найти altinst

Дело не в переходе на симлинки. Что-то сломали вчера. В сегодняшних регулярках ловится, а в них всё по-старому. Вчерашние норм.

> Что-то сломали вчера.

Тогда вопрос: а точно дело в симлинках? Если сейчас _перед_ запуском инсталлятора смонтировать настоящий /var/run и потом запустить инсталлятор, то проблема уйдёт?

(В ответ на комментарий №5)
> > Что-то сломали вчера.
> 
> Тогда вопрос: а точно дело в симлинках? Если сейчас _перед_ запуском
> инсталлятора смонтировать настоящий /var/run и потом запустить инсталлятор, то
> проблема уйдёт?

Дело не в симлинках. В сегодняшних регулярках, где /var/run не симлинк, проблема есть.

Откатил версию alterator-browser-qt5, не помогло.

Сделал в лайве downgrade на 2.12.2019. Затем обновлял пакеты по одному до сегодняшнего дня. Проблема возникает после обновления пакета guile-evms.

(В ответ на комментарий №3)
> (В ответ на комментарий №2)
> > А почему файла сокета нет, ты понимаешь?
> 
> Не понимаю. Как он там оказаться должен?

Смотри, вот у меня система p9, обновлённая до Сизифа:

# grep 'run' /proc/mounts
runfs /run tmpfs rw,relatime,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k,mode=755 0 0
runfs /var/run tmpfs rw,relatime,mode=755 0 0
tmpfs /run/user/500 tmpfs rw,nosuid,nodev,noexec,relatime,size=151920k,mode=700,uid=500,gid=500 0 0
tmpfs /var/run/user/500 tmpfs rw,nosuid,nodev,noexec,relatime,size=151920k,mode=700,uid=500,gid=500 0 0

# netstat -lpn | grep 'alteratord'
unix  2      [ ACC ]     STREAM     LISTENING     12223  1/init              /run/alteratord/.socket

# LANG=C stat /var/run/alteratord/.socket | grep 'Inode'
Device: 15h/21d	Inode: 12224       Links: 1

# LANG=C stat /run/alteratord/.socket | grep 'Inode'
Device: 15h/21d	Inode: 12224       Links: 1

# grep 'Listen' /lib/systemd/system/alteratord.socket 
ListenStream=/var/run/alteratord/.socket

То-есть:
1. такой файл сокета существует;
2. это один и тот же файл в двух местах одновременно;
3. ни одна из директорий /var/run и /run не является симлинком;
4. в alteratord.socket записан путь с /var/run.

Вероятно, /var и /var/run связаны через mount -o bind, но как это проверить я не знаю.

(В ответ на комментарий №8)
> То-есть:
> 1. такой файл сокета существует;
> 2. это один и тот же файл в двух местах одновременно;
> 3. ни одна из директорий /var/run и /run не является симлинком;
> 4. в alteratord.socket записан путь с /var/run.
> 
> Вероятно, /var и /var/run связаны через mount -o bind, но как это проверить я
> не знаю.

Да, на системах с systemd они связаны mount -o bind. Это создаёт иногда проблемы с размонтированием /run при выключении. Именно поэтому нужно перейти на симлинк.
Я имел в виду, что я не знаю, когда именно он там должен появиться, и почему он там не появился.

Но это всё к проблеме отношения не имеет. Вопрос: почему обновление guile-evms поломало альтератор? Достаточно ли пересборки или что-то более серьёзное?

Может быть Сергей Большаков что-то подскажет

А я тем временем посмотрю на проброс исключений в альтераторе: чтобы мы видели действительное сообщение об ошибке.

(In reply to comment #10)
> Может быть Сергей Большаков что-то подскажет
я посмотрю

(In reply to comment #7)
> Сделал в лайве downgrade на 2.12.2019. Затем обновлял пакеты по одному до
> сегодняшнего дня. Проблема возникает после обновления пакета guile-evms.

Посмотрел одно изменение. Не могу сообразить, всё ли здесь хорошо:

From 3d6df0d9b6e451ab8ad99e59f473d0812795c89b Mon Sep 17 00:00:00 2001
From: Sergey Bolshakov <sbolshakov@altlinux.org>
Date: Tue, 3 Dec 2019 12:58:50 +0300
Subject: [PATCH] make space for terminating zero

---
 appstructs.i |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/appstructs.i b/appstructs.i
index 3d17671..a304601 100644
--- a/appstructs.i
+++ b/appstructs.i
@@ -442,7 +442,7 @@ static char * mangle_name(char * sname)
 {
 	static char name[EVMS_MAX_NAME_SIZE+1];
 	char *s;
-	s = strncpy(name, sname, EVMS_MAX_NAME_SIZE+1);
+	s = strncpy(name, sname, EVMS_MAX_NAME_SIZE);
 	while((s = strchr(s, '/')) != NULL)
 		*s++ = '|';
 	return name;
-- 
1.7.3.3

До изменения, если длина sname была EVMS_MAX_NAME_SIZE+1, т.е. в sname[EVMS_MAX_NAME_SIZE+1] был 0, то в name копировалось всё, кроме 0 в конце, и строка name оказывалась не null-terminated. Все EVMS_MAX_NAME_SIZE+1 байтов name были заполнены при этом.

Так что раньше нормально обрабатывались строки длиной <= EVMS_MAX_NAME_SIZE.

После изменения, если длина sname EVMS_MAX_NAME_SIZE, т.е. в sname[EVMS_MAX_NAME_SIZE] был 0, то в name копируется всё, кроме 0 в конце. EVMS_MAX_NAME_SIZE байтов name были заполнены при этом, последний name[EVMS_MAX_NAME_SIZE] не трогался. Строка name окажется не null-terminated, если name[EVMS_MAX_NAME_SIZE] не был уже инициализирован в 0.

А инициализируются ли static-массивы в 0?.. По-мрему, да. Так что не вижу тут ошибок при обработке строк той же длины, что обрабатывались раньше.

Нормально ли возвращать указатель на статический массив, который будет изменён при следующем вызове этой функции, а не копировать?... Выглядит не очень хорошо, но без изучения остального кода невозможно понять. (Также это не thread-safe.)

(In reply to comment #13)

> Нормально ли возвращать указатель на статический массив, который будет изменён
> при следующем вызове этой функции, а не копировать?... Выглядит не очень
> хорошо, но без изучения остального кода невозможно понять. (Также это не
> thread-safe.)

Используется, например, так:

appstructs.i:479 http://git.altlinux.org/gears/g/guile-evms.git?p=guile-evms.git;a=blob;f=appstructs.i#l479 :

%extend storage_object_info_s {
         char *sname() {
                 return mangle_name(self->name);
         }



evms.scm:248 http://git.altlinux.org/gears/g/guile-evms.git?p=guile-evms.git;a=blob;f=evms.scm#l248 :

(define storage-id
  (let ((ids '()))
    (lambda (in)
      (case (storage-object-info-t-object-type in)
        ((disk)
         (let ((name (storage-object-info-t-sname in)))
           (if (pair? (assoc name ids)) (assoc-ref ids name)
               (let ((id (and-let*
                          ((port (false-if-exception
                                  (open-input-pipe
                                   (cond ((string-prefix? "sd" name)
                                          (string-append "cat /sys/block/" name "/device/model"))
                                         ((string-prefix? "hd" name)
                                          (string-append "cat /proc/ide/" name "/model"))
                                         (#t "cat /dev/null")))))
                           (id (false-if-exception (read-line port 'trim))))
                          (close-pipe port)
                          (if (eof-object? id) #f
                              id))))
                 (set! ids (acons name id ids))
                 id))))
        (else #f)))))

Эта строка сохраняется в списке ids, но, наверное, при превращении из C в guile она представляется по-другому и туда копируется, так что проблем быть не должно -- https://www.gnu.org/software/guile/manual/html_node/Conversion-to_002ffrom-C.html#Conversion-to_002ffrom-C :

C Function: SCM scm_from_locale_string (const char *str)
C Function: SCM scm_from_locale_stringn (const char *str, size_t len)

    Creates a new Scheme string that has the same contents as str when interpreted in the character encoding of the current locale.

    For scm_from_locale_string, str must be null-terminated.

    For scm_from_locale_stringn, len specifies the length of str in bytes, and str does not need to be null-terminated. If len is (size_t)-1, then str does need to be null-terminated and the real length will be found with strlen.

    If the C string is ill-formed, an error will be raised.

    Note that these functions should not be used to convert C string constants, because there is no guarantee that the current locale will match that of the execution character set, used for string and character constants. Most modern C compilers use UTF-8 by default, so to convert C string constants we recommend scm_from_utf8_string. 

C Function: SCM scm_take_locale_string (char *str)
C Function: SCM scm_take_locale_stringn (char *str, size_t len)

    Like scm_from_locale_string and scm_from_locale_stringn, respectively, but also frees str with free eventually. Thus, you can use this function when you would free str anyway immediately after creating the Scheme string. In certain cases, Guile can then use str directly as its internal representation. 

если не функции scm_take_*string* используются.

ох, сколько всего мы узнали -- но я думаю, что первое, что сделаю завтра утром --  пересоберу guile-evms с помощью gcc8

(In reply to comment #15)
> ох, сколько всего мы узнали --

ну интерсно же, побольше понять о том, как это всё работает.

> но я думаю, что первое, что сделаю завтра утром
> --  пересоберу guile-evms с помощью gcc8

разумно

пока известно вот что:
alt10 из p9 или архива + актуальный сизиф => работает
он же, пересобранный что gcc8, что gcc9 => проблема.

(В ответ на комментарий №17)
> пока известно вот что:
> alt10 из p9 или архива + актуальный сизиф => работает
> он же, пересобранный что gcc8, что gcc9 => проблема.

С заданием
[#242352] TESTED guile-evms.git=guile-evms-0.5-alt12

на проблемном лайве установка прошла успешно.

оперативно, спасибо

Собрал сегодня regular-lxde, regular-server-systemd, regular-server-sysv. Все нормально установились.