Occasionally I still get the ‘Start job for disk is runnig for…’ messages again. I thought this Leap 15 system had gotten past that.
I end up doing the same old, same old, of having to power down with the power button.
A black screen, and then it runs my Optical drive for a second or two when I do that , then shuts down.
Usually a restart goes ‘normally’ and I am back in an working(until the system stops responding for a few minutes[as reported in another thread, in applications])
Can you show us the exact message Bill?
Any stale entries in /etc/fstab?
cat /etc/fstab
sudo /usr/sbin/blkid
cat /proc/cmdline
Similar to this from an older thread >>>> **A Start Job is running for DEV-DISK-BY\X2UUIDTD733AD84\X2D5F44~LordyThisIsALongString~.DEVICE 1min 30sec
**And finally ends in my having to power down manually.
Not that I can tell
localhost:~> sudo /usr/sbin/blkid
/dev/sda1: LABEL="WesternDigital IDE 160" UUID="D2E8C97CE8C95F7B" TYPE="ntfs" PARTUUID="fb30b87c-01"
/dev/sdb1: LABEL="System Reserved" UUID="1A0CB3280CB2FE37" TYPE="ntfs" PARTUUID="00000001-01"
/dev/sdb2: LABEL="Windows 10 Home Release" UUID="0FCB1B290FCB1B29" TYPE="ntfs" PARTUUID="00000001-02"
/dev/sdb3: UUID="40888E43888E3804" TYPE="ntfs" PARTUUID="00000001-03"
/dev/sdb4: LABEL="Windows 7 64 Home" UUID="ACB2B4EEB2B4BDE0" TYPE="ntfs" PARTUUID="00000001-04"
/dev/sdc1: UUID="0f558cfc-c8f3-4c78-93a8-cc4a7acba25d" TYPE="swap" PARTUUID="d0f4738c-01"
/dev/sdc2: UUID="4e8d4f1f-f98f-4e94-adfc-bdf649be2f0f" TYPE="ext3" PTTYPE="dos" PARTUUID="d0f4738c-02"
/dev/sdc3: UUID="4a8eefe9-5576-4315-b7a2-9837e9957b42" TYPE="ext3" PARTUUID="d0f4738c-03"
/dev/sdc4: LABEL="data" UUID="6e1e2ac3-d36d-40f9-913d-b4e7fd194c12" TYPE="ext3" PARTUUID="d0f4738c-04"
localhost:~> cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp150.12.22-default root=UUID=4e8d4f1f-f98f-4e94-adfc-bdf649be2f0f showopts plymouth.enable=0 fastboot
I too find hung start jobs at shutdown are not uncommon, and also use the reset or power button or pull the plug when encountered. 90 second or longer waits for shutdown or reboot never that I can remember happened before systemd. ATM I’m at a loss to remember any of the start job types other than ntp. I’m unsure whether any have been DEV-DISK-BY.
Hold Alt-SysRq (aka PrtSc) and type:
reisub
usually will shut it down elegantly without risking disk problems.
Provided it’s enabled of course…
YaST > Kernel Settings > Enable SysRq Keys
BTW, that adds ‘kernel.sysrq = 1’ to /etc/sysctl.conf
It is partially enabled by default, some not, so it works anyway, but as for your follow-up post, yes, that enables full function for SysRq Keys.
I haven’t found that was the case.
On TW20181022 I don’t any such YaST2 selection “Kernel…”. Which yast2-* package might this be squirreled away in?
zypper se -s yast | egrep -i 'ern|sys'
produces nothing obvious.
The default setting was changed to 184.
Here is the output from the latest TW, and I highlighted the Magic Line in Bold & Red for you:
cat /usr/lib/sysctl.d/50-default.conf
#
# Distribution defaults.
# Use /etc/sysctl.conf to override.
#
# Disable response to broadcast pings to avoid smurf attacks.
net.ipv4.icmp_echo_ignore_broadcasts = 1
# enable route verification on all interfaces
net.ipv4.conf.all.rp_filter = 1
# avoid deleting secondary IPs on deleting the primary IP
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
# disable IPv6 completely
#net.ipv6.conf.all.disable_ipv6 = 1
# enable IPv6 forwarding
#net.ipv6.conf.all.forwarding = 1
# enable IPv6 privacy but do not use the temporary
# addresses for outgoing connections by default
# (bsc#678066,bsc#752842,bsc#988023,bsc#990838)
net.ipv6.conf.default.use_tempaddr = 1
# increase the number of possible inotify(7) watches
fs.inotify.max_user_watches = 65536
# Magic SysRq Keys enable some control over the system even if it
# crashes (e.g. during kernel debugging).
#
# 0 - disable sysrq completely
# 1 - enable all functions of sysrq
# >1 - bitmask of allowed sysrq functions:
# 2 - enable control of console logging level
# 4 - enable control of keyboard (SAK, unraw)
# 8 - enable debugging dumps of processes etc.
# 16 - enable sync command
# 32 - enable remount read-only
# 64 - enable signalling of processes (term, kill, oom-kill)
# 128 - allow reboot/poweroff
# 256 - allow nicing of all RT tasks
#
# For further information see /usr/src/linux/Documentation/sysrq.txt
# default 184 = 128+32+16+8
**kernel.sysrq = 184**
# Disable auto-closing of cd tray bnc#659153
dev.cdrom.autoclose = 0
# enable hard- and symlink protection (bnc#821585)
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
# restrict printed kernel ptrs (bnc#833774)
kernel.kptr_restrict = 1
and here is the same line from Leap 15.0 (Just the line, to save Forum space)
kernel.sysrq = 184
From a long ago thread (and you observed this at the time, as well ;)), following an in-depth writeup I did explaining Alt-SysRq and all its options, especially as the defaults changed in Leap starting with 42.2 that I was aware of at the time:
Alt-SysRq: How can it be made permanent please?
cat /proc/sys/kernel/sysrq
echo 1 > /proc/sys/kernel/sysrq
Turns out 42.2 and 42.3 keep reverting it back to 184 at boot.
However, just to make you blush, ol’ Down Under Pal, instead of quoting my own material, I will quote your answer in that thread:
You can define the necessary (eg kernel.sysrq = 1) in /etc/sysctl.conf, or a .conf file in the /etc/sysctl.d/ directory
To get current settings do
sysctl --system
If you run 'sysctl --system' it will show you the order that the settings were applied. The naming is important. I found that in order to override settings in /usr/lib/sysctl.d/50-default.conf, my configuration file in /etc/sysctl.d/ needed to be named something like 80-custom.conf (or similar) so that it was processed after the default configuration....
but, I am trying to remember what I did on 15.0 to stop it from reverting, perhaps that, or perhaps I used some other systemd method that I do not recall at the moment.
rotfl!
YaST2 -Kernel Settings
Right tab
Enable SysRq Keys
(enabled by default, but as I said, default setting is 184 instead of 1, which still enables enough keys from reisub to kill the process that is causing a shutdown hang and let the shutdown or reboot conclude).
Unfortunately, I see that the Help tab on that dialogue has incorrect information, so I am either going to have to file a bug, or I am going to have to fix that with a Pull Request in YaST at Github. I will probably do the latter, but not tonight, as it is my bday and it is very late.
Strange, I have two clean installs, (both Leap 15.0), one of which (running in a VBox environment) has ‘kernel.sysrq = 0’, the other (dual boot system) returns ‘kernel.sysrq = 184’. However, I can’t remember the last time I ever needed to invoke the magic SysRq key sequence to shutdown a AWOL Linux environment.
Just to keep my bald head in the loop here,
My HP Compaq desktop shows:
**kernel.sysrq = 184**
And the box in YaST2-Kernel settings is NOT checked.
SO? should it be 0 or 184?
184 means that Magic SysRq key combo is partially enabled…
# Magic SysRq Keys enable some control over the system even if it
# crashes (e.g. during kernel debugging).
#
# 0 - disable sysrq completely
# 1 - enable all functions of sysrq
# >1 - bitmask of allowed sysrq functions:
# 2 - enable control of console logging level
# 4 - enable control of keyboard (SAK, unraw)
# 8 - enable debugging dumps of processes etc.
# 16 - enable sync command
# 32 - enable remount read-only
# 64 - enable signalling of processes (term, kill, oom-kill)
# 128 - allow reboot/poweroff
# 256 - allow nicing of all RT tasks
#
# For further information see /usr/src/linux/Documentation/sysrq.txt
# default 184 = 128+32+16+8
kernel.sysrq = 184
Which means that you should be able to use the key combo to perform a ‘safe reboot’ (or other emergency tasks) if needed.
I’m not certain, but I think you do need to also check that box in the YaST settings.
To find out, you could try the Alt-SysRq-reisub routine I showed you above. If nothing happens, then you need to check the box. Otherwise, if the system reboots, then you do not need to check it, you can use that routine for when the system locks, f.e. when shutting down or rebooting, or while using.
Actually, this not necessary, depending on whether it was previously disabled via YaST. It is /usr/lib/sysctl.d/50-default.conf that sets the openSUSE default of ‘kernel.sysrq = 184’. Enabling it in YaST, sets ‘kernel.sysrq = 1’ (full Magic SysRq control) in /etc/sysctl.d/99-sysctl.conf (which is a link to /etc/sysctl.conf), which then takes precedence over 50-default.conf. So the YaST configuration utility completely enables or disables the Magic SysRq functionality. To reinstate the default value set by 50-default.conf, a manual edit is needed to remove the ‘kernel.sysrq=’ entry from /etc/sysctl.conf.
Thanks, good to know this information.