Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 41

Thread: Very slow reboot or shutdown

  1. #21
    Join Date
    Aug 2008
    Location
    Texas, US
    Posts
    277

    Default Re: Very slow reboot or shutdown

    I had a failure of ending Session 2 of my user and a 1:29 wait. The resulting shutdown.txt file is 8400 lines of text.

    Using the journalctl command I get:
    Code:
    RYZEN9:~ # journalctl -b -1 -u *.target
    -- Logs begin at Sat 2021-07-17 14:12:25 CDT, end at Fri 2021-07-23 13:02:42 CDT. --
    -- No entries --
    


    which makes no sense since the journal file is 56MB in size. This is the complete path the system made for the journal after I created the directory that was specified:
    Code:
    /var/log/journal/3186ca150be445b6a880d1695718cde1/

  2. #22
    Join Date
    Sep 2012
    Posts
    6,775

    Default Re: Very slow reboot or shutdown

    Quote Originally Posted by purevw View Post
    Code:
    RYZEN9:~ # journalctl -b -1 -u *.target
    -- Logs begin at Sat 2021-07-17 14:12:25 CDT, end at Fri 2021-07-23 13:02:42 CDT. --
    -- No entries --
    which makes no sense since[/FONT]
    Show full output of "journalctl -b -1", not arbitrary filtered content.

  3. #23
    Join Date
    Sep 2013
    Location
    Norfolk, UK
    Posts
    1,874

    Default Re: Very slow reboot or shutdown

    Quote Originally Posted by purevw View Post
    I had a failure of ending Session 2 of my user and a 1:29 wait. The resulting shutdown.txt file is 8400 lines of text. ...
    And... did you look at the file?

    The test one I created on this system (ref post #19) was 7909 lines.

    Open the file in a text editor and go to the last line, although the file is large it's quite easy to quickly scroll back watching the times at the beginning of each line to find the point at which the shutdown pauses. Remember, you're looking for a 90 second gap, so it should be fairly obvious, even when scrolling quickly.

    What was Session 2 of your user doing? Perhaps you should have terminated that first before closing the system down?
    Regards, Paul

  4. #24
    Join Date
    Sep 2013
    Location
    Norfolk, UK
    Posts
    1,874

    Default Re: Very slow reboot or shutdown

    Additionally, you may find this thread informative:

    https://unix.stackexchange.com/quest...ion-c2-of-user
    Regards, Paul

  5. #25
    Join Date
    Aug 2008
    Location
    Texas, US
    Posts
    277

    Default Re: Very slow reboot or shutdown

    Quote Originally Posted by tannington View Post
    And... did you look at the file?

    The test one I created on this system (ref post #19) was 7909 lines.

    Open the file in a text editor and go to the last line, although the file is large it's quite easy to quickly scroll back watching the times at the beginning of each line to find the point at which the shutdown pauses. Remember, you're looking for a 90 second gap, so it should be fairly obvious, even when scrolling quickly.

    What was Session 2 of your user doing? Perhaps you should have terminated that first before closing the system down?
    All files within the journal directory are in machine language and not viewable in a text editor.

    I never open a second session under my user. It is something that the system is doing on it's own. I thought that it had something to so with using "su", but I did not use "su" last night and still got the Session 2 shutdown delay.

    The shutdown.txt file content has no time stamps. I'm currently looking at the journalctl content for clues.

  6. #26
    Join Date
    Aug 2008
    Location
    Texas, US
    Posts
    277

    Default Re: Very slow reboot or shutdown

    Using journalctl -b -1 I got a very long output. From what I see, "kdesud" is the culprit in this case:
    Code:
    Jul 24 00:42:54 RYZEN9 systemd-logind[1431]: Got message type=signal sender=:1.0 destination=n/a path=/org/freedeskto>
    Jul 24 00:43:48 RYZEN9 systemd[1]: systemd-timesyncd.service: Got notification message from PID 1325 (WATCHDOG=1)
    Jul 24 00:43:48 RYZEN9 systemd[1]: systemd-journald.service: Got notification message from PID 911 (WATCHDOG=1)
    Jul 24 00:44:23 RYZEN9 systemd-logind[1431]: Got message type=signal sender=:1.0 destination=n/a path=/org/freedeskto>
    Jul 24 00:44:23 RYZEN9 systemd-logind[1431]: Got message type=signal sender=:1.0 destination=n/a path=/org/freedeskto>
    Jul 24 00:44:23 RYZEN9 systemd-logind[1431]: Sent message type=method_call sender=n/a destination=org.freedesktop.sys>
    Jul 24 00:44:23 RYZEN9 systemd[3308]: Received SIGTERM from PID 1 (systemd).
    Jul 24 00:44:23 RYZEN9 systemd[3308]: Activating special unit exit.target
    Jul 24 00:44:23 RYZEN9 systemd[1]: session-2.scope: Stopping timed out. Killing.
    Jul 24 00:44:23 RYZEN9 systemd[1]: session-2.scope: Killing process 3838 (kdesud) with signal SIGKILL.
    Jul 24 00:44:23 RYZEN9 systemd[1]: session-2.scope: Failed with result 'timeout'.
    Jul 24 00:44:23 RYZEN9 systemd[1]: session-2.scope changed stop-sigterm -> failed
    Jul 24 00:44:23 RYZEN9 systemd[1]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1>
    Jul 24 00:44:23 RYZEN9 systemd[1]: session-2.scope: Failed to destroy cgroup /user.slice/user-1000.slice/session-2.sc>
    Jul 24 00:44:23 RYZEN9 systemd[1]: session-2.scope: Job 3946 session-2.scope/stop finished, result=done
    Jul 24 00:44:23 RYZEN9 systemd[1]: Stopped Session 2 of user ronnie.
    I did not use a "su" terminal last night that I remember, but I always use Yast Online Update immediately after every boot.

    This may only address half of the problem. If I get a shutdown delay for my user (not Session 2), it is usually after I have been accessing my larger hard drives, even if I shut down 30 minutes after gkrellm shows that any file moves have completed. My primary concern with that is that twice now I have lost the mappings to a large drive upon shutdown and have to manually re-create the Luks mapping after the next boot. My primary concern is possible data loss if the drive is being forcibly shut down. The drives in question are several Terabytes in size.
    The next time I get a shutdown error that is not Session 2, I will go back and search for the cause.

  7. #27
    Join Date
    Sep 2013
    Location
    Norfolk, UK
    Posts
    1,874

    Default Re: Very slow reboot or shutdown

    Quote Originally Posted by purevw View Post
    All files within the journal directory are in machine language and not viewable in a text editor. ...
    I was referring to "shutdown-log.txt", not the journal.

    I never open a second session under my user. It is something that the system is doing on it's own. I thought that it had something to so with using "su", but I did not use "su" last night and still got the Session 2 shutdown delay.
    OK - Then the shutdown-log could contain the answers...

    The shutdown.txt file content has no time stamps. I'm currently looking at the journalctl content for clues.
    Really ?? - Then something is very amiss in it's creation. Again from the test one I created on this system (ref post #19):

    Code:
    paul@Orion-15:~$ cd /
    paul@Orion-15:/$ ls
    bin   dev  home  lib64       mnt  proc  run   shutdown-log.txt  sys  usr
    boot  etc  lib   lost+found  opt  root  sbin  srv               tmp  var
    paul@Orion-15:/$ tail -n 20 shutdown-log.txt
    [  201.639555] systemd-shutdown[1]: Detaching loop devices.
    [  201.639572] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [  201.639599] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [  201.639629] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [  201.639683] systemd-shutdown[1]: All loop devices detached.
    [  201.639686] systemd-shutdown[1]: Stopping MD devices.
    [  201.639692] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [  201.639705] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [  201.639727] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [  201.639766] systemd-shutdown[1]: All MD devices stopped.
    [  201.639770] systemd-shutdown[1]: Detaching DM devices.
    [  201.639776] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [  201.639788] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [  201.639808] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [  201.639846] systemd-shutdown[1]: All DM devices detached.
    [  201.639851] systemd-shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached.
    [  201.640131] systemd-shutdown[1]: Successfully forked off '(sd-executor)' as PID 1593.
    [  201.662719] [1593]: Successfully forked off '(direxec)' as PID 1594.
    [  201.663171] [1593]: Successfully forked off '(direxec)' as PID 1595.
    [  201.853498] EXT4-fs (sdc1): re-mounted. Opts: acl,user_xattr. Quota mode: none.
    paul@Orion-15:/$
    Regards, Paul

  8. #28
    Join Date
    Aug 2008
    Location
    Texas, US
    Posts
    277

    Default Re: Very slow reboot or shutdown

    Quote Originally Posted by tannington View Post
    I was referring to "shutdown-log.txt", not the journal.



    OK - Then the shutdown-log could contain the answers...



    Really ?? - Then something is very amiss in it's creation. Again from the test one I created on this system (ref post #19):

    Code:
    paul@Orion-15:~$ cd /
    paul@Orion-15:/$ ls
    bin   dev  home  lib64       mnt  proc  run   shutdown-log.txt  sys  usr
    boot  etc  lib   lost+found  opt  root  sbin  srv               tmp  var
    paul@Orion-15:/$ tail -n 20 shutdown-log.txt
    [  201.639555] systemd-shutdown[1]: Detaching loop devices.
    [  201.639572] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [  201.639599] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [  201.639629] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [  201.639683] systemd-shutdown[1]: All loop devices detached.
    [  201.639686] systemd-shutdown[1]: Stopping MD devices.
    [  201.639692] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [  201.639705] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [  201.639727] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [  201.639766] systemd-shutdown[1]: All MD devices stopped.
    [  201.639770] systemd-shutdown[1]: Detaching DM devices.
    [  201.639776] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [  201.639788] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [  201.639808] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [  201.639846] systemd-shutdown[1]: All DM devices detached.
    [  201.639851] systemd-shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached.
    [  201.640131] systemd-shutdown[1]: Successfully forked off '(sd-executor)' as PID 1593.
    [  201.662719] [1593]: Successfully forked off '(direxec)' as PID 1594.
    [  201.663171] [1593]: Successfully forked off '(direxec)' as PID 1595.
    [  201.853498] EXT4-fs (sdc1): re-mounted. Opts: acl,user_xattr. Quota mode: none.
    paul@Orion-15:/$
    I guess it was my mistake. I do not see time stamps. I would call those index numbers and have no idea how to interpret "minutes" and "seconds". I do note a difference between your output and mine. Mine was never able to finalize the final DM device and apparently forced it.
    Code:
    [ 3238.254689] systemd-shutdown[1]: All filesystems unmounted.
    [ 3238.254691] systemd-shutdown[1]: Deactivating swaps.
    [ 3238.254715] systemd-shutdown[1]: All swaps deactivated.
    [ 3238.254717] systemd-shutdown[1]: Detaching loop devices.
    [ 3238.254726] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [ 3238.254742] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [ 3238.254766] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [ 3238.254816] systemd-shutdown[1]: All loop devices detached.
    [ 3238.254817] systemd-shutdown[1]: Detaching DM devices.
    [ 3238.254820] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [ 3238.254825] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [ 3238.254837] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [ 3238.254987] systemd-shutdown[1]: Not all DM devices detached, 1 left.
    [ 3238.255104] systemd-shutdown[1]: Detaching DM devices.
    [ 3238.255107] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs
    [ 3238.255113] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus
    [ 3238.255126] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class
    [ 3238.255249] systemd-shutdown[1]: Not all DM devices detached, 1 left.
    [ 3238.255251] systemd-shutdown[1]: Cannot finalize remaining DM devices, continuing.
    [ 3238.255395] systemd-shutdown[1]: Successfully forked off '(sd-executor)' as PID 11207.
    [ 3238.256992] [11207]: Successfully forked off '(direxec)' as PID 11208.
    [ 3238.257147] [11207]: Successfully forked off '(direxec)' as PID 11209.
    [ 3238.257296] [11207]: Successfully forked off '(direxec)' as PID 11210.
    [ 3238.263967] EXT4-fs (dm-0): re-mounted. Opts: (null)
    I would note that my / is encrypted, which may be the DM that couldn't be finalized because it was being written to.

  9. #29
    Join Date
    Sep 2012
    Posts
    6,775

    Default Re: Very slow reboot or shutdown

    Quote Originally Posted by purevw View Post
    I would call those index numbers and have no idea how to interpret "minutes" and "seconds".
    Default dmesg timestamp is in seconds since boot (this does not include time when system was suspended).

  10. #30
    Join Date
    Sep 2013
    Location
    Norfolk, UK
    Posts
    1,874

    Default Re: Very slow reboot or shutdown

    Quote Originally Posted by purevw View Post
    ... I do not see time stamps. I would call those index numbers and have no idea how to interpret "minutes" and "seconds". I do note a difference between your output and mine. ...
    OK. Time stamp or index number, you need to look further back in the shutdown-log.txt to find the point at which the 90 sec timeout begins, look at what is happening in the log for several lines immediately prior to that for any possible clues.
    Regards, Paul

Page 3 of 5 FirstFirst 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •