LINUX.ORG.RU

Сообщения Kircher

 

Debian несанкционированно перезагружается в 3 ночи - как выяснить причину?

Пару недель назад Debian 12 сервер стал несанкционированно перезагружаться ровно в 3 часа ночи. Первое время не каждый день, последние несколько дней - каждый день. Сначала подумал, что дело, возможно, в аппаратном сбросе, например через ИБП - но учитывая точное время перезагрузки - складывается впечатление, что перезагрузка программная.

В crontab нет никаких записей с перезагрузкой.

В логах systemd нет никакой информации указывающей на причины перезагрузки, вот пару примеров вывода journalctl соответствующего времени:

May 06 01:17:02 debi9 CRON[15085]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
May 06 01:17:02 debi9 CRON[15086]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
May 06 01:17:02 debi9 CRON[15085]: pam_unix(cron:session): session closed for user root
May 06 02:17:01 debi9 CRON[28717]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
May 06 02:17:01 debi9 CRON[28718]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
May 06 02:17:01 debi9 CRON[28717]: pam_unix(cron:session): session closed for user root
-- Boot c6a5eac4d88c464592b8a3f493fc39ff --
May 06 03:00:35 debi9 kernel: microcode: microcode updated early to revision 0x11d, date = 2023-08-29
May 06 03:00:35 debi9 kernel: Linux version 6.1.0-20-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)
May 06 03:00:35 debi9 kernel: Command line: BOOT_IMAGE=/vmlinuz-6.1.0-20-amd64 root=UUID=320c1ce7-c162-46bc-aa90-81ecafb4ecdb ro quiet split_lock_detect=off
May 06 03:00:35 debi9 kernel: x86/tme: not enabled by BIOS
May 06 03:00:35 debi9 kernel: x86/split lock detection: disabled
May 06 03:00:35 debi9 kernel: BIOS-provided physical RAM map:

May 07 01:41:11 debi9 systemd[1]: Starting man-db.service - Daily man-db regeneration...
May 07 01:41:11 debi9 systemd[1]: man-db.service: Deactivated successfully.
May 07 01:41:11 debi9 systemd[1]: Finished man-db.service - Daily man-db regeneration.
May 07 02:17:01 debi9 CRON[295327]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
May 07 02:17:01 debi9 CRON[295328]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
May 07 02:17:01 debi9 CRON[295327]: pam_unix(cron:session): session closed for user root
-- Boot bd603611c06946c5a44c30660beb7bf8 --
May 07 03:00:39 debi9 kernel: microcode: microcode updated early to revision 0x11d, date = 2023-08-29
May 07 03:00:39 debi9 kernel: Linux version 6.1.0-20-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)
May 07 03:00:39 debi9 kernel: Command line: BOOT_IMAGE=/vmlinuz-6.1.0-20-amd64 root=UUID=320c1ce7-c162-46bc-aa90-81ecafb4ecdb ro quiet split_lock_detect=off
May 07 03:00:39 debi9 kernel: x86/tme: not enabled by BIOS
May 07 03:00:39 debi9 kernel: x86/split lock detection: disabled
May 07 03:00:39 debi9 kernel: BIOS-provided physical RAM map:

Есть подозрение, что проблема как-то связана с ядром. За день до начала этих перезагрузок было проведено обновление системы с установкой ядра версии 6.1.0-18 с тех пор появились эти перезагрузки в 3 часа ночи, но не ежедневно. Несколько дней назад ядро было обновлено до 6.1.0-20 - с тех пор перезагрузки случаются каждую ночь.

Поиск обнаружил похожую тему: «PVE automatically reboots at 3 a.m. every day»: https://forum.proxmox.com/threads/pve-automatically-reboots-at-3-a-m-every-da... - симптомы очень похожи, но там нет никакого решения, тема заброшена.

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

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

 ,

Kircher
()
58 комментариев (стр. 2)

Debian 12: nvidia driver & tty1..6 login prompt

На Debian 12 (версия ядра 6.1.0-18-amd64) после установки nvidia-tesla-470-driver пропадает приглашение для входа у виртуальных терминалов tty1..6.

Сочетание клавиш [Ctrl]+[Alt]+[F1]..[Ctrl]+[Alt]+[F6] переключают на консоль, но там нет приглашения для входа, [Ctrl]+[Alt]+[F7] успешно переключает обратно на графический интерфейс. Процесс agetty при этом запущен и работает.

С драйвером nouveau при идентичной конфигурации системы всё работает нормально: в tty1..6 в этом случае приглашение для входа присутствует и работает как следует.

Возможно ли восстановить корректный доступ к tty1..6 при использовании nvidia-tesla-470-driver?

 , ,

Kircher
()
2 комментария

XMPP-сервер и веб-сервер для одного домена на разных IP

Подскажите, пожалуйста, как оптимальнее реализовать расположение XMPP-сервера и веб-сервера на разных хостах, но для одного и того же домена, с сертификатами Let’s encrypt.

 , , , ,

Kircher
()
8 комментариев

Влияние аппаратного обеспечения на качество виртуализии 32-разрядной windows server

Приветствую. Столкнулся с такой проблемой: в 64-разрядном Debian 11 на старом Intel Xeon E3-1220 v5 виртуальная машина с 32-разрядной Windows Server 2008 R2 SP2 работает хорошо, а на более свежем железе, Intel Core i5-10400F, та же самая виртуальная машина с точно такими же версиями Debian и VirtualBox и теми же самыми параметрами (или даже большим выделением ресурсов) - заметно тормозит, по сравнению с Xeon (сама виртуальная машина после включения загружается в 3-4 раза дольше, а также это сильно заметно при открытии и отрисовке приложений в терминальных сессиях). При этом, виртуальная машина с 64-разрядной Windows Server 2016 на i5 работает хорошо, без всяких тормозов. Пробовал выставлять разные параметры для виртуальной машины - ничего не повлияло, пришёл к выводу, что, вероятнее всего, это проблема аппаратной виртуализации 32-разрядной системы на более современном 64-разрядном процессоре.

Прошу подсказать специалистов или тех, кто сталкивался с аналогичной проблемой, что конкретно может на это влиять (может быть, поддержка каких-то специфических инструкций процессором?). Необходимо сохранить работоспособность виртуальной машины с 32-разрядным Windows Server, но перейти на более современное железо.

Старый Xeon, на котором виртуальная машина с 32-разрядным Windows Server работет хорошо:

$ lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           94
Model name:                      Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz
Stepping:                        3
CPU MHz:                         3404.313
CPU max MHz:                     3500.0000
CPU min MHz:                     800.0000
BogoMIPS:                        6000.00
Virtualization:                  VT-x
L1d cache:                       128 KiB
L1i cache:                       128 KiB
L2 cache:                        1 MiB
L3 cache:                        8 MiB
NUMA node0 CPU(s):               0-3
Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT disabled
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Mmio stale data:   Mitigation; Clear CPU buffers; SMT disabled
Vulnerability Retbleed:          Mitigation; IBRS
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:             Mitigation; Microcode
Vulnerability Tsx async abort:   Mitigation; Clear CPU buffers; SMT disabled
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sysca
                                 ll nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmu
                                 lqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_
                                 timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow 
                                 vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt
                                  intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

Более новый i5, на котором 32-разрядная виртуальная машина тормозит, а 64-разрядная работает корректно:

$ lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          12
On-line CPU(s) list:             0-11
Thread(s) per core:              2
Core(s) per socket:              6
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           165
Model name:                      Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz
Stepping:                        3
Frequency boost:                 enabled
CPU MHz:                         1999.995
CPU max MHz:                     2901.0000
CPU min MHz:                     800.0000
BogoMIPS:                        5799.77
Virtualization:                  VT-x
L1d cache:                       192 KiB
L1i cache:                       192 KiB
L2 cache:                        1.5 MiB
L3 cache:                        12 MiB
NUMA node0 CPU(s):               0-11
Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Mmio stale data:   Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable
Vulnerability Retbleed:          Mitigation; Enhanced IBRS
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Vulnerability Srbds:             Vulnerable: No microcode
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sysca
                                 ll nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmu
                                 lqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_time
                                 r aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_s
                                 hadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt i
                                 ntel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts md_clear flush_l1d arch_capabilities

 , ,

Kircher
()
10 комментариев

RSS подписка на новые темы