Batiskaf
3 года, 3 месяца назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
Поставил из Testing следующую версию пакета dhcpcd 7.2.2 — 3-ий день полет нормальный.
До этого ядро LTS успело 2 раза обновиться, еще разные пакеты по мелочи — проблема не решалась — раза по 3-4 в течение дня вылетал инет.
Может кому будет полезно.
Batiskaf
3 года, 3 месяца назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
_GoinG_
Пользуюсь ядром LTS, версия 4.19.44-1-lts.
Актуальная версия - 5.х.х Сознательно на четвертой сидите?
LTS-версия 5.x.x.? Нет не специально, все автоматом обновляется по 
pacman -Syu
И, да, у меня актуальная версия: https://www.archlinux.org/packages/?sort=&q=linux-lts&maintainer=&flagged=
x86_64 	Core 	linux-lts 	4.19.44-1 	The Linux-lts kernel and modules 	2019-05-17
x86_64 	Core 	linux-lts-docs 	4.19.44-1 	Kernel hackers manual - HTML documentation that comes with the Linux-lts kernel 	2019-05-17
x86_64 	Core 	linux-lts-headers 	4.19.44-1 	Header files and scripts for building modules for Linux-lts kernel 	2019-05-17
Batiskaf
3 года, 3 месяца назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
Добрый день, всем!
В Арче, стоящем на ПК-роутере, дважды за сегодня падал dhcpcd во время работы. Первый раз через пару минут после включения YouTube-видео на одном из домашнем компов, второй раз - аналогично - просто во время работы в интернете с домашнего ПК.
Обновлялся вчера ночью.
Вроде на форуме archlinux.org народ ругается на что-то подобное ([1], [2]), но винят другое.
Сейчас стоит версия 7.2.1-1. Пользуюсь ядром LTS, версия 4.19.44-1-lts.
мая 18 20:46:09 router systemd-coredump[1475]: Process 390 (dhcpcd) of user 0 dumped core.

                                                  Stack trace of thread 390:
                                                  #0  0x0000563d92b78bb2 dhcp_handledhcp (dhcpcd)
                                                  #1  0x0000563d92b79cee dhcp_readudp (dhcpcd)
                                                  #2  0x0000563d92b6372b eloop_start (dhcpcd)
                                                  #3  0x0000563d92b5dd2d main (dhcpcd)
                                                  #4  0x00007fef12914ce3 __libc_start_main (libc.so.6)
                                                  #5  0x0000563d92b5e47e _start (dhcpcd)
-- Subject: Процесс 390 (dhcpcd) сбросил дамп памяти
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
--
-- Процесс 390 (dhcpcd) завершился из-за критической ошибки.
-- Записан дамп памяти.
--
-- Вероятно, это произошло из-за ошибки, допущенной в коде программы.
-- Рекомендуется сообщить её разработчикам о возникшей проблеме.
мая 18 21:05:14 router dhcpcd[1632]: dhcpcd not running
На сайте разработчика dhcpcd версия новее - 7.2.2.

Если кто сталкивался и решил - поделитесь советом.

Кстати, может кто подскажет, как его перезапускать, а то ip link <enpNs0> set down и up не помогли, а служба такая - disabled, хотя когда работает, в процессах он висит (dhcpcd -4 -q -t 30 -L enpNs0), значит, его кто-то запускает.

P.S. На одном из домашних ПК стоит Manjaro, тоже вчера обновлялась. Проблем не было сегодня. Пакет такой установлен, но в процессах dhcpcd нет.
Batiskaf
3 года, 6 месяцев назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
vs220
https://archlinux.org.ru/forum/post/214005/
Спасибо!
Патч из bug'а помог - я так и думал, что поможет файл в pam.d.
Batiskaf
3 года, 6 месяцев назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
Если для кого-то актуально - помогал перезапуск сразу двух служб aksusbd и haspsbd (если не ошибаюсь) после загрузки рабочего стола KDE. Потом также случайно стало все, как надо.
Но я все равно не смог использовать 1С из-за библиотеки webkitgtk, которую надо было подбирать из AUR, компилить по многу часов, а она все равно слетала после обновления, прилетающего с системой.
Batiskaf
3 года, 6 месяцев назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
Добрый день!
2 недели не обновлялся, сегодня обновил систему (linux-lts (4.19.19-1 -> 4.19.23-1)).
После перезагрузки VSFTPD перестал пускать под пользователем, под которым я всегда захожу. Пользователь не виртуальный, но интерактивный вход ему запрещен. Проверил, пользователь активен, срок действия пароля не истек (проверил командой "sudo -u user1 htop" - успех).
До обновления /var/log/vsftpd.log:
Sun Feb 17 17:43:05 2019 [pid 2] CONNECT: Client "192.168.0.2"
Sun Feb 17 17:43:05 2019 [pid 2] FTP response: Client "192.168.0.2", "220 (vsFTPd 3.0.3)"
Sun Feb 17 17:43:05 2019 [pid 2] FTP command: Client "192.168.0.2", "USER user1"
Sun Feb 17 17:43:05 2019 [pid 2] [user1] FTP response: Client "192.168.0.2", "331 Please specify the password."
Sun Feb 17 17:43:07 2019 [pid 2] [user1] FTP command: Client "192.168.0.2", "PASS <password>"
Sun Feb 17 17:43:07 2019 [pid 1] [user1] OK LOGIN: Client "192.168.0.2"
Sun Feb 17 17:43:07 2019 [pid 3] [user1] FTP response: Client "192.168.0.2", "230 Login successful."
После обновления:
Sun Feb 17 17:52:49 2019 [pid 2] CONNECT: Client "192.168.0.5"
Sun Feb 17 17:52:49 2019 [pid 2] FTP response: Client "192.168.0.5", "220 (vsFTPd 3.0.3)"
Sun Feb 17 17:52:51 2019 [pid 2] FTP command: Client "192.168.0.5", "USER user1"
Sun Feb 17 17:52:51 2019 [pid 2] [user1] FTP response: Client "192.168.0.5", "331 Please specify the password."
Sun Feb 17 17:52:51 2019 [pid 2] [user1] FTP command: Client "192.168.0.5", "PASS <password>"
Sun Feb 17 17:52:51 2019 [pid 1] [user1] FAIL LOGIN: Client "192.168.0.5"
Sun Feb 17 17:52:52 2019 [pid 2] [user1] FTP response: Client "192.168.0.5", "530 Login incorrect."
Sun Feb 17 17:52:53 2019 [pid 2] FTP command: Client "192.168.0.5", "QUIT"
Sun Feb 17 17:52:53 2019 [pid 2] FTP response: Client "192.168.0.5", "221 Goodbye."
В логе службы vsftpd после перезагрузки появились записи при попытках коннекта к FTP (раньше их не было):
фев 17 17:52:51 router vsftpd[484]: pam_warn(ftp:auth): function=[pam_sm_authenticate] flags=0 service=[ftp] terminal=[ftp] user=[user1] ruser=[user1] rhost=[192.168.0.5]
фев 17 17:53:01 router vsftpd[487]: pam_warn(ftp:auth): function=[pam_sm_authenticate] flags=0 service=[ftp] terminal=[ftp] user=[user1] ruser=[user1] rhost=[192.168.0.5]
фев 17 17:54:07 router vsftpd[492]: pam_warn(ftp:auth): function=[pam_sm_authenticate] flags=0 service=[ftp] terminal=[ftp] user=[user1] ruser=[user1] rhost=[192.168.0.5]
фев 17 23:09:37 router vsftpd[1090]: pam_warn(ftp:auth): function=[pam_sm_authenticate] flags=0 service=[ftp] terminal=[ftp] user=[user1] ruser=[user1] rhost=[192.168.0.5]
cat /etc/vsftpd.conf | grep -E "^[A-Z,a-z]":
seccomp_sandbox=NO
log_ftp_protocol=YES
listen=YES
background=YES
anonymous_enable=NO
local_enable=YES
chroot_local_user=YES
passwd_chroot_enable=YES
write_enable=YES
xferlog_enable=YES
userlist_enable=YES
userlist_file=/etc/vsftpd/user_list
userlist_deny=NO
force_dot_files=YES
allow_writeable_chroot=YES
local_umask=066
dirmessage_enable=YES
/etc/vsftpd/user_list содержит единственную строку, состоящую из слова "user1"

Буду очень благодарен за конструктивную помощь!
Batiskaf
4 года, 12 месяцев назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
RusWolf
Ну так попробуй ещё то ядро на котором раньше работало.
Насколько я понимаю, когда ещё работало уже было ядро 4.9, только минорная версия меньше. Штатными средствами Manjaro ядро «даунгрейдить» можно только по мажорным версиям.
RusWolf
Тут ещё вопрос, какие ещё пакеты обновились, после того как перестал работать ключ.
К сожалению, я не засёк точно момент, когда сломалось. Я загружаю то Linux, то Windows, 1С, естественно не каждый раз запускал. А тут игруху перепроходил на винде, так что недели 2 в Linux почти не заходил. Помню, что примерно за это время было 2 обновления пакетов в Manjaro (Octopi высвечивает уведомление).
vasek
Batiskaf, для конвертации *.deb пакета в *.pkg.tar.xz можешь воспользоваться утилитой, описанной в этом топике
Спасибо, буду пробовать.
Batiskaf
5 лет назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
Downgrade на ядро 4.8 не помог :(
Batiskaf
5 лет назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
RusWolf
Batiskaf, а что говорят на родном форуме manjaro?
В прошлый раз мне здесь хорошо помогли, также думаю, что сообщество ArchLinux больше Manjaro, поэтому сюда написал.

RusWolf
Ну так поставь обратно "старое" ядро.
Сейчас пробую...

В Debian посмотрел ядро 4.9.0, а здесь 4.9.47.

Одной из задач поста было «прощупать почву» — может кто сталкивался с таким же. В AUR'е давно комментариев не было на странице aksusbd, может по результатам этого обсуждения можно будет туда добавить решение моей проблемы для остальных.
Batiskaf
5 лет назад
Темы: 4
Сообщения: 25
Участник с: 15 июля 2017
Некоторое время назад (2-4 недели) перестал работать аппаратный ключ защиты 1С - после загрузки системы в нём не горит красная лампочка. Драйвер aksusbd установлен, работает, systemctl status никаких ошибок не показывает (включено, работает). Сам ключ точно рабочий, т.к. продолжает работать в других ОС: Win 7, Debian 9.
По localhost:1947 показывает, что ключей не видно ни одного.

[user@user ~]$ uname -a
Linux oleg 4.9.47-1-MANJARO #1 SMP PREEMPT Sat Sep 2 07:29:38 UTC 2017 x86_64 GNU/Linux

Подозреваю, что "виновато" новое ядро, больше особо ничего не менял, не устанавливал. Только обновлялся.
Ещё раз хочу уточнить, что раньше — ключ работал.
Прошу помощи.
 

© 2006-2022, Русскоязычное сообщество Arch Linux.
Название и логотип Arch Linux ™ являются признанными торговыми марками.
Linux ® — зарегистрированная торговая марка Linus Torvalds и LMI.