LINUX.ORG.RU

Проблемма при выключении или перезагрузки в Kali.

 , , ,


0

1

Добрый день,

При перезагрузке или выключении получаю:

A stop job is running for User Manager for UID 131
каждую секунду UID 131 меняется на 0

0 это мой root 131 это Debian-gdm

Debian-gdm:x:131:141:Gnome Display Manager:/var/lib/gdm3:/bin/false

uname -a Linux pc 4.19.0-kali4-amd64 #1 SMP Debian 4.19.28-2kali1 (2019-03-18) x86_64 GNU/Linux

При чем данное сообщение появляется не всегда(зависимость уловить не смог) предполагаю что проблема именно в демоне gdm3, ниже его конфиг:

# GDM configuration storage - modified by kali-root-login
#
# See /usr/share/gdm/gdm.schemas for a list of available options.

[daemon]
# Uncomment the line below to force the login screen to use Xorg
WaylandEnable=false
# Enabling automatic login
#  AutomaticLoginEnable = true
#  AutomaticLogin = root

# Enabling timed login
#  TimedLoginEnable = true
#  TimedLogin = user1
#  TimedLoginDelay = 10

# Reserving more VTs for test consoles (default is 7)
#  FirstVT = 9

[security]
AllowRoot = true

[xdmcp]

[greeter]
# Only include selected logins in the greeter
# IncludeAll = false
# Include = user1,user2

[chooser]

[debug]
# More verbose logs
# Additionally lets the X server dump core if it crashes
#  Enable = true

При работе проблем вроде не возникает.

service gdm3 status

● gdm.service - GNOME Display Manager
   Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor preset: enabled)
   Active: active (running) since Tue 2019-09-03 10:50:23 EDT; 29min ago
  Process: 639 ExecStartPre=/usr/share/gdm/generate-config (code=exited, status=0/SUCCESS)
 Main PID: 641 (gdm3)
    Tasks: 3 (limit: 4915)
   Memory: 8.7M
   CGroup: /system.slice/gdm.service
           └─641 /usr/sbin/gdm3

Sep 03 10:50:23 pc systemd[1]: Starting GNOME Display Manager...
Sep 03 10:50:23 pc systemd[1]: Started GNOME Display Manager.
Sep 03 10:50:23 pc gdm-launch-environment][645]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by (uid=0)
Sep 03 10:50:34 pc gdm-password][995]: pam_unix(gdm-password:session): session opened for user root by (uid=0)

Вывод last last -x | less

root     :1           :1               Tue Sep  3 10:50   still logged in
runlevel (to lvl 5)   4.19.0-kali4-amd Tue Sep  3 10:50   still running
reboot   system boot  4.19.0-kali4-amd Tue Sep  3 06:50   still running
shutdown system down  4.19.0-kali4-amd Tue Sep  3 10:50 - 06:50  (-3:59)
root     :1           :1               Tue Sep  3 10:45 - 10:48  (00:03)
runlevel (to lvl 5)   4.19.0-kali4-amd Tue Sep  3 10:45 - 10:50  (00:05)
reboot   system boot  4.19.0-kali4-amd Tue Sep  3 06:45 - 10:50  (04:05)
shutdown system down  4.19.0-kali4-amd Tue Sep  3 10:44 - 06:45  (-3:59)
root     :1           :1               Tue Sep  3 10:42 - down   (00:02)
runlevel (to lvl 5)   4.19.0-kali4-amd Tue Sep  3 10:42 - 10:44  (00:02)
reboot   system boot  4.19.0-kali4-amd Tue Sep  3 06:42 - 10:44  (04:02)
shutdown system down  4.19.0-kali4-amd Tue Sep  3 10:42 - 06:42  (-3:59)
root     :1           :1               Tue Sep  3 10:39 - 10:40  (00:01)
runlevel (to lvl 5)   4.19.0-kali4-amd Tue Sep  3 10:39 - 10:42  (00:03)
reboot   system boot  4.19.0-kali4-amd Tue Sep  3 06:39 - 10:42  (04:03)
shutdown system down  4.19.0-kali4-amd Tue Sep  3 10:39 - 06:39  (-3:59)
root     :1           :1               Tue Sep  3 10:37 - 10:37  (00:00)
runlevel (to lvl 5)   4.19.0-kali4-amd Tue Sep  3 10:36 - 10:39  (00:02)
reboot   system boot  4.19.0-kali4-amd Tue Sep  3 06:36 - 10:39  (04:02)
shutdown system down  4.19.0-kali4-amd Tue Sep  3 00:00 - 06:36  (06:36)  

Инфа из логов: egrep -ir "(shut|reboot)" /var/log/*

/var/log/syslog:Aug 29 11:31:34 pc kernel: [    0.000000] secureboot: Secure boot could not be determined (mode 0)
/var/log/syslog:Aug 29 11:31:34 pc systemd[1]: Starting Update UTMP about System Boot/Shutdown...
/var/log/syslog:Aug 29 11:31:34 pc systemd[1]: Started Update UTMP about System Boot/Shutdown.
/var/log/syslog:Aug 29 11:31:34 pc systemd[1]: Starting Restore /etc/resolv.conf if the system crashed before the ppp link was shut down...
/var/log/syslog:Aug 29 11:31:34 pc systemd[1]: Started Restore /etc/resolv.conf if the system crashed before the ppp link was shut down.
/var/log/syslog:Aug 29 11:31:34 pc cron[569]: (CRON) INFO (Running @reboot jobs)
/var/log/syslog:Aug 29 11:31:34 pc kernel: [    1.703977] nvme nvme0: Shutdown timeout set to 8 seconds
/var/log/syslog:Aug 29 11:33:07 pc geoclue[871]: Service not used for 60 seconds. Shutting down..
/var/log/syslog:Aug 29 12:57:03 pc kernel: [    0.000000] secureboot: Secure boot could not be determined (mode 0)
/var/log/syslog:Aug 29 12:57:03 pc systemd[1]: Starting Update UTMP about System Boot/Shutdown...
/var/log/syslog:Aug 29 12:57:03 pc systemd[1]: Started Update UTMP about System Boot/Shutdown.
/var/log/syslog:Aug 29 12:57:03 pc systemd[1]: Starting Restore /etc/resolv.conf if the system crashed before the ppp link was shut down...
/var/log/syslog:Aug 29 12:57:03 pc cron[567]: (CRON) INFO (Running @reboot jobs)
/var/log/syslog:Aug 29 12:57:03 pc systemd[1]: Started Restore /etc/resolv.conf if the system crashed before the ppp link was shut down.
/var/log/syslog:Aug 29 12:57:03 pc kernel: [    0.096493] Unless you actually understand what nomodeset does, you should reboot without enabling it
/var/log/syslog:Aug 29 12:57:03 pc kernel: [    1.495174] nvme nvme0: Shutdown timeout set to 8 seconds
/var/log/syslog:Aug 29 12:57:14 pc systemd[636]: Reached target Shutdown.
/var/log/syslog:Aug 29 13:25:12 pc kernel: [    0.000000] secureboot: Secure boot could not be determined (mode 0)
/var/log/syslog:Aug 29 13:25:12 pc systemd[1]: Starting Update UTMP about System Boot/Shutdown...
/var/log/syslog:Aug 29 13:25:12 pc systemd[1]: Started Update UTMP about System Boot/Shutdown.
/var/log/syslog:Aug 29 13:25:12 pc systemd[1]: Starting Restore /etc/resolv.conf if the system crashed before the ppp link was shut down...
/var/log/syslog:Aug 29 13:25:12 pc kernel: [    1.522109] nvme nvme0: Shutdown timeout set to 8 seconds
/var/log/syslog:Aug 29 13:25:12 pc systemd[1]: Started Restore /etc/resolv.conf if the system crashed before the ppp link was shut down.
/var/log/syslog:Aug 29 13:25:12 pc cron[552]: (CRON) INFO (Running @reboot jobs)
Binary file /var/log/syslog matches
/var/log/user.log:Aug 29 11:33:07 pc geoclue[871]: Service not used for 60 seconds. Shutting down..
Binary file /var/log/user.log matches
Binary file /var/log/wtmp matches

Ниже 4 'умных' паСана мне уже очень многим помогли ;)

Решение:

1. Мною ранее был выключен ipv6 в /etc/sysctl.conf, включил и все стало на свои места. Надеюсь данное решение кому то будет полезно и сэкономит время.

2. Перед тем как перезагружать или выключать, делать logout а уже после перезагружать.

Начался учебный год, опять школокакиры ставят кали на хард.

Kali/Blackarch и прочие пентестерские дистрибутывы не предназначены для использования в качестве повседневной ОС.

Поставь себе обычный дебиан и оставь вола в покое.

mersinvald ★★★★★ ()

А я предупреждал, что 1 сентября не решит кали-проблемы на ЛОРе.

burato ★★★★★ ()

Убей geoclue нахрен. Вообще снеси его.

rebforce ()

Kali не предназначен для использования в качестве повседневной оси, как уже сказали выше.

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

neocrust ★★★★★ ()
Ответ на: комментарий от beeen007

LFS ! Только LFS решает проблему ...

tinycore

это полумеры .

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.