The watchdog did not stop! line is normal behavior. systemd sets a "hardware watchdog" timer as a failsafe, to ensure that if the normal shutdown process freezes/fails that the computer will still shutdown after the specified period of time. This time period is defined in the variable ShutdownWatchdogSec= in the file /etc/systemd/system.conf. Here is the ...
Strictly speaking, no you don't need acpid in a virtual machine nor on a real system. But you should install acpid in a VM as it typically handles the power button press which is simulated by the hypervisor if you shutdown a VM.
So for practically reasons, yes you should install acpid on a VM.
P.S: acpid doesn't really do power management
ACPI is a low-level interface for mainboard vendors to provide information about built-in devices that cannot be (reliably) autodetected to the operating system. It also provides methods for power management and hardware monitoring to the kernel. One interesting thing ACPI provides are so called ACPI events. To create these, the hardware emits a special ...
I would leave it. I believe ACPI does more than just power management. For example I believe there is a ACPI event that is sent in via the VM Host to the guests when you want them to shutdown or reboot.
Excerpt from Manual:KVM:
issue ACPI shut-down command to KVM guest, if guest does not
support ACPI, command have no effect.
RHEL 7 and therefore Centos 7 have made the switch from System V (SysV) startup scripts and runlevels to systemd. The commands to activate acpid should thus be:
systemctl start acpid
systemctl enable acpid
ACPI is the subsystem that uses information from the BIOS to control hardware, mostly for power management, temperature sensing, and related issues. SMBus is a simple two-wire communications protocol, used as side channel to access temperature sensors and other hardware.
So your BIOS contains sloppy ACPI data that specifies the wrong buffer size for a write ...
Disabling suspend on lid close
The disabling of suspend on lid close is well covered on this site as well as other SE sites. Here's a list of Q&A's on that particular part of your question:
GNOME: disable sleep on lid close
How can I tell Ubuntu to do nothing when I close my laptop lid?
Enabling wake on lid open
In setting up an action for when the ...
You might try:
trying some other GNU/Linux distribution to see if it has the same problem (easiest using live CD, like Debian or Ubuntu)
changing your BIOS ACPI settings (if any)
trying to boot with acpi_osi='!Windows 2012' and/or other ACPI related options (see http://redsymbol.net/linux-kernel-boot-parameters/ for example)
booting with acpi.debug_layer=...
First, make sure acpid.service is actually being started during boot. After the host has rebooted, use this command to verify that:
# systemctl status acpid.service
It should say started and enabled. If it doesn't, then systemctl enable acpid.service might solve the problem for you, by actually starting the service on reboot.
Second, if the service is ...
intel_pstate manages compatible CPUs in a more fine-grained manner than the ACPI driver can, so in general you’re better off letting it handle things.
With recent kernels, it is possible to disable it, in some cases, after boot. To do so, write off to /sys/devices/system/cpu/intel_pstate/status; if this is successful (see the documentation for limitations), ...
As a general rule, yes, you do need the daemon running for a proper orderly shutdown. The kernel's ACPI modules just act as an intermediary for the userspace component which is what actually responds to events Note however that on some systems systemd may handle this without requiring acpid at all (though systemd is much less flexible in what it can do in ...
ok. SELinux issue. When creating some new stuff related to existing service, you need to make sure that the service will have appropriate access to your files. The log from your file proposes that it does not have (unless running as unconfined_t).
executing action "/etc/acpi/actions/lid.sh "button/lid LID open""
action exited with status 126
The execution ...
I am on a MIO single board computer with the same problem: sudo reboot or [CTRL]+[ALT]+[DEL] leads to hanging at
watchdog did not stop
None of the above worked for me, but thankfully a combination of them did the job:
Use GRUB_CMDLINE_LINUX="reboot=bios" (reboot=acpi did not work for me)
Use systemctl reboot -i, to successfully reboot the system. (...
The first column is the device class. The values come from the kernel drivers handling the respective ACPI devices. They are either of the form "class" (e.g. "battery") or "class/subclass" (e.g. "button/power").
The second column is the name the kernel uses for the device. There is a matching folders in /sys/bus/acpi/devices/ for every ACPI device. The ...
I had this problem too.
Essentially, what you'll see in your logs (if systemd is configured properly, either method above works--systemd translates the old 'service' commands for you... at least in CentOS7)
Nov 20 11:12:06 localhost systemd-logind: Power key pressed.
Nov 20 11:12:06 localhost systemd: SELinux policy denies access
So, you then need to ...
The acpid daemon should receive battery events by ACPI subsystem. When you unplug/plug the laptop there should be related battery events. The events can be associated with actions like power off/suspend/hibernate the system and so on.
Firstly, try to verify it by watching /var/log/messages or related log files when you unplug the laptop. There should be ...
The problem is that key code micmute is out of range, as explained in this bug report. So you need to remap scan code 0x1A to some other key code you are not using that is in range. If this workaround using prog2 doesn't work you have to pick some other key code. You can look in /usr/include/linux/input.h to see which key codes are defined and then look ...