# wget https://basealt.ru --2024-09-25 21:33:18-- https://basealt.ru/ Resolving basealt.ru (basealt.ru)... Неверный системный вызов Появилось после обновления wget-1.21.3-alt1 p10+305270.100.3.1 1660840341 removed wget-1.24.5-alt2 p10+357453.100.2.1 1727185605 installed Что-то похожее на https://bugzilla.altlinux.org/45799
Помог бы репродюсер. builder@x86_64-p10:/tmp$ wget https://basealt.ru --2024-09-25 18:46:52-- https://basealt.ru/ Resolving basealt.ru (basealt.ru)... 194.107.17.249 Connecting to basealt.ru (basealt.ru)|194.107.17.249|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.basealt.ru/ [following] --2024-09-25 18:46:52-- https://www.basealt.ru/ Resolving www.basealt.ru (www.basealt.ru)... 194.107.17.249 Connecting to www.basealt.ru (www.basealt.ru)|194.107.17.249|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 70433 (69K) [text/html] Saving to: 'index.html' index.html 100%[=========>] 68.78K --.-KB/s in 0.006s 2024-09-25 18:46:52 (11.3 MB/s) - 'index.html' saved [70433/70433]
Не удаётся воспроизвести: $ rpm -q wget && wget https://basealt.ru wget-1.24.5-alt2.x86_64 --2024-09-26 09:16:21-- https://basealt.ru/ Resolving basealt.ru (basealt.ru)... 194.107.17.249 Connecting to basealt.ru (basealt.ru)|194.107.17.249|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.basealt.ru/ [following] --2024-09-26 09:16:21-- https://www.basealt.ru/ Resolving www.basealt.ru (www.basealt.ru)... 194.107.17.249 Connecting to www.basealt.ru (www.basealt.ru)|194.107.17.249|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 70433 (69K) [text/html] Saving to: 'index.html' index.html 100%[========>] 68.78K --.-KB/s in 0.01s 2024-09-26 09:16:21 (5.78 MB/s) - 'index.html' saved [70433/70433] Какой у вас дистрибутив установлен?
Может что-то через LD_PRELOAD загружается?
(Ответ для Alexander Makeenkov на комментарий #2) ... > Какой у вас дистрибутив установлен? Я собрал жалобы уже от трёх человек, плюс легко воспроизвёл сам выполнением обновления. Дистрибутивы: Рабочая станция К Simply Linux
(Ответ для Vitaly Lipatov на комментарий #4) > (Ответ для Alexander Makeenkov на комментарий #2) > ... > > Какой у вас дистрибутив установлен? > Я собрал жалобы уже от трёх человек, плюс легко воспроизвёл сам выполнением > обновления. > Дистрибутивы: > Рабочая станция К > Simply Linux Какие пакеты не из дистрибутива установлены ?
(Ответ для Vitaly Lipatov на комментарий #4) > Я собрал жалобы уже от трёх человек, плюс легко воспроизвёл сам выполнением > обновления. > Дистрибутивы: > Рабочая станция К > Simply Linux Проверили на нескольких рабочих системах ALT Workstation K и ALT Workstation, ошибки не возникает. Увидел жалобы в чате eepm, судя по сообщениям, ошибка возникает только при запуске самого epm (считаю, что вам стоило бы про это уточнить при заведении ошибки). На версии eepm-3.62.12-alt1, которая сейчас в р10, воспроизвести не удалось: ``` $ epm play chrome $ /usr/bin/env bash /etc/eepm/play.d/chrome.sh --run $ epm --short --version $ eget -q -O- https://eepm.ru/releases/3.62.12/app-versions/google-chrome-stable Installing The popular and trusted web browser by Google (Stable Channel) from the official site as google-chrome-stable package ... Warning: Specifying the version is not supported by vendor. Downloading latest version ... $ epm install --repack https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_129.0.6668.70-1_amd64.deb $ eget --latest https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_129.0.6668.70-1_amd64.deb $ /usr/bin/wget --tries 1 --content-disposition https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_129.0.6668.70-1_amd64.deb --2024-09-27 09:06:43-- https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_129.0.6668.70-1_amd64.deb Resolving dl.google.com (dl.google.com)... 2a00:1450:4010:c1e::5b, 2a00:1450:4010:c1e::5d, 2a00:1450:4010:c1e::88, ... Connecting to dl.google.com (dl.google.com)|2a00:1450:4010:c1e::5b|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 111860972 (107M) [application/x-debian-package] Saving to: 'google-chrome-stable_129.0.6668.70-1_amd64.deb' ```
Надо всё-таки выяснить что именно привело к такой ошибке.
Created attachment 16916 [details] strace Удалось воспроизвести только на одной машине: ALT Workstation K 10.3 x86_64 ASUS VivoBook X513EAN Ядро: 6.1.111-un-def-alt1 CPU: Intel Core i3-1115G4 Прикладываю файлы с backtrace и coredump падения, а также лог запуска wget под strace.
Created attachment 16917 [details] coredump
Created attachment 16918 [details] backtrace
Может epm и не виноват, но как это воспроизводить стабильно пока не понятно.
Alexander, спасибо. Можно ли получить доступ к тестовой системе?
(Ответ для Vitaly Chikunov на комментарий #12) > Можно ли получить доступ к тестовой системе? Это рабочий ноутбук сотрудника, который сейчас работает из дома ...
В таком случае, можно ли получить содержимое /etc/wgetrc /etc/openssl/cipher-list.conf /etc/nsswitch.conf /etc/host.conf /etc/resolv.conf
(Ответ для Vitaly Chikunov на комментарий #14) > В таком случае, можно ли получить содержимое > ... Добрый день. Отправила данные на почту.
Благодарю, воспроизвелось с такой записью в /etc/resolv.conf: nameserver fe80::1%wlan0 Видимо, связано с сочетанием wi-fi, ipv6 и тем, что добавляет эту запись. root@x86_64-p10:/.in# wget https://basalt.ru --2024-09-27 09:50:18-- https://basalt.ru/ Resolving basalt.ru (basalt.ru)... Bad system call (core dumped)
1. В p10: # export SECCOMP_DEFAULT_ACTION=trap # strace wget https://basalt.ru ... --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7faaaab91e27, si_syscall=__NR_access, si_arch=AUDIT_ARCH_X86_64} --- Тестовая конфигурация которая временно обходит ошибку для p10: # export SECCOMP_DEFAULT_ACTION=trap SECCOMP_SYSCALL_ALLOW=access Если этого будет достаточно то будет понятно что пофиксить. 2. В Сизифе такой resolv.conf не дает ошибки. Но в Сизифе просто запуск от rooter в хешере (с сетью) если в resolv.conf любой валидный ipv4 ресолвер - дает другую ошибку root@x86_64:/.in# wget https://basalt.ru --2024-09-27 10:07:06-- https://basalt.ru/ Resolving basalt.ru (basalt.ru)... 5.23.55.42 Connecting to basalt.ru (basalt.ru)|5.23.55.42|:443... connected. Bad system call (core dumped) # export SECCOMP_DEFAULT_ACTION=trap # strace wget https://basalt.ru --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7f55fcfd49aa, si_syscall=__NR_semtimedop, si_arch=AUDIT_ARCH_X86_64} --- Тестовая конфигурация, которая на Сизифе обходит ошибку # export SECCOMP_DEFAULT_ACTION=trap SECCOMP_SYSCALL_ALLOW=semtimedop:msgsnd:msgrcv А тут скорее всего обновление glibc повлияло, но тесты этого не заметили.
Тестовое задание для sisyphus 358476 Тестовое задание для p10 358477 Пожалуйста, сообщите воспроизводится ли с ними проблема.
(Ответ для Vitaly Chikunov на комментарий #18) > Тестовое задание для sisyphus 358476 > Тестовое задание для p10 358477 > > Пожалуйста, сообщите воспроизводится ли с ними проблема. Проверила с заданием для p10 358477 - ошибка не воспроизводится.
wget-1.24.5-alt3 -> sisyphus: Fri Sep 27 2024 Vitaly Chikunov <vt@altlinux> 1.24.5-alt3 - Fix a crash caused by seccomp filtering by permitting additional DNS-resolving syscalls (ALT#51563).
Опять неправильное закрытие бага в p10 по заданию в Сизифе.
*** Bug 51655 has been marked as a duplicate of this bug. ***
Наверное, нужно перезапустить задание 358477, две недели без wget на стабильном бранче это не очень... 2024-Sep-27 11:37:56 :: #100: src package `wget' version `1.24.5-alt3' is greater than its version `1.24.5-alt2' in `sisyphus'
wget-1.24.5-alt4 -> p11: Sat Sep 28 2024 Vitaly Chikunov <vt@altlinux> 1.24.5-alt4 - Make some syscalls allowed only for libfakeroot. Fri Sep 27 2024 Vitaly Chikunov <vt@altlinux> 1.24.5-alt3 - Fix a crash caused by seccomp filtering by permitting additional DNS-resolving syscalls (ALT#51563).
Среднее время прохождение задания через отдел тестирования 2 недели. Так как теперь есть p11, то это добавляет еще 2 недели. Задание для p10 358577 было готово еще 27 сентября, но ожидало прохождения задания 358576 в p11. У меня возникла идея, что можно сделать control, чтоб в случае подобной ситуации администратор мог отключать seccomp для wget в своей системе. Сейчас это ничем не поможет, но в будущем может помочь.
wget-1.24.5-alt4 -> p10: Sat Sep 28 2024 Vitaly Chikunov <vt@altlinux> 1.24.5-alt4 - Make some syscalls allowed only for libfakeroot. Fri Sep 27 2024 Vitaly Chikunov <vt@altlinux> 1.24.5-alt3 - Fix a crash caused by seccomp filtering by permitting additional DNS-resolving syscalls (ALT#51563).
На Сизифе имею всё ту же проблему. Как диагностировать? $ wget https://basealt.ru --2025-01-18 10:57:24-- https://basealt.ru/ Resolving basealt.ru (basealt.ru)... 194.107.17.249 Connecting to basealt.ru (basealt.ru)|194.107.17.249|:443... connected. Неверный системный вызов (образ памяти сброшен на диск) $ rpm -q wget wget-1.25.0-alt1 $ cat /etc/resolv.conf # Generated by resolvconf # Do not edit manually, use # /etc/net/ifaces/<interface>/resolv.conf instead. search office.etersoft.ru nameserver 192.168.0.210 nameserver 192.168.0.1
Как вообще у нас может существовать код, который использует неверный сисколл, пусть даже этот код не должен вызываться. Program terminated with signal SIGSYS, Bad system call. #0 0x00007fffe115e982 in gettimeofday () (gdb) bt #0 0x00007fffe115e982 in gettimeofday () #1 0x00007fc9a34088ac in ossl_time_now () at crypto/time.c:37 #2 0x00007fc9a3428457 in SSL_SESSION_new () at ssl/ssl_sess.c:116 #3 0x00007fc9a34287fe in ssl_get_new_session (s=0x5596f53d55d0, session=0) at ssl/ssl_sess.c:442
$ wget https://basealt.ru --2025-01-23 19:17:48-- https://basealt.ru/ Resolving basealt.ru (basealt.ru)... 194.107.17.249 Connecting to basealt.ru (basealt.ru)|194.107.17.249|:443... connected. Неверный системный вызов (образ памяти сброшен на диск) $ rpm -qa wget wget-1.25.0-alt1.x86_64
Та же версия wget на процессоре Intel работает без проблем. Падает на AMD. Версия openssl: openssl-3.3.2-alt1
(Ответ для Vitaly Chikunov на комментарий #25) ... > У меня возникла идея, что можно сделать control, чтоб в случае подобной > ситуации администратор мог отключать seccomp для wget в своей системе. > Сейчас это ничем не поможет, но в будущем может помочь. Спасибо за control, отключил hardened и жизнь продолжается: $ sudo control wget unconfined
Спасибо, в новой сборке починилось. * Сб янв 25 2025 Vitaly Chikunov <vt@altlinux.org> 1.25.0-alt2 - Use less strict seccomp (and thus more robust) hardening by default (without aborting whole process). - Add '--no-sandbox' command line and 'sandbox = off' config options to make it easier to turn off sandboxing for end users.
