Edit /etc/systemd/logind.conf and make sure you have,
which will make it ignore the lid being closed. (You may need to also undo the other changes you've made).
Then, you'll want to reload logind.conf to make your changes go into effect (thanks to Ehtesh Choudhury for pointing this out in the comments):
systemctl restart systemd-...
For Ubuntu and Debian, usbcore is compiled in the kernel, so create entries on /etc/modprobe.d will NOT work: we need to change the kernel boot parameters.
Edit the /etc/default/grub file and change the GRUB_CMDLINE_LINUX_DEFAULT line to add the usbcore.autosuspend=-1 option:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.autosuspend=-1"
Note that quit ...
That's the equivalent of pressing Ctrl+Z in other commands.
It suspends the shell and gives control back to parent shell or process if any.
bash-4.4$ cd /
zsh: suspended (signal) bash
 + continued bash
The feature comes from csh, the shell of BSD (where job control comes from) in the ...
Install GNOME Tweak Tool and go to the Power section. There's an option to disable the automatic suspend on lid close.
I compared dconf before and after to find the option, but it turns out that's not how it's implemented. Instead, Tweak Tool creates ~/.config/autostart/ignore-lid-switch-tweak.desktop. The autostart is a script which ...
If you start a shell from another shell, you can suspend the inner one. Say when using su, and wanting to switch back to the regular user for a moment:
root# do something
user$ do something as the ordinary user again
(If you do that, don't forget the privileged shell open in the background...)
Task freezing is documented in detail in the kernel documentation.
User-space processes can’t refuse to freeze; they do get frozen, but the signalling between the kernel and processes is handled automatically by the signal-handling code (freezing uses a fake signal).
If you’re seeing “tasks refusing to freeze” messages, that means that a kernel thread is ...
According to the kernel tree documentation, the autosuspend idle-delay time is controlled by the autosuspend module parameter in usbcore. Setting the initial default idle-delay to -1 will prevent the autosuspend of any USB device. You should still be able to to enable autosuspend for selected devices.
The usbcore.autosuspend kernel parameter can be set when ...
sleep.target is specific to system services. The reason is, sleep.target is not a magic target that automatically gets activated when going to sleep. It's just a regular target that puts the system to sleep – so the 'user' instances of course won't have an equivalent. (And unfortunately the 'user' instances currently have no way to depend on systemwide ...
There are a couple of examples in the Arch Wiki.
Basically, it involves creating a service file for your screen locker and ensuring it is hooked to either the suspend, hibernate or sleep targets.
If you use a simple screen locker like slock, /etc/systemd/system/lock.service would look like this:
Description=Lock the screen on resume from suspend
Here's a small script that checks for the battery level and calls a custom command, here pm-hibernate, in case the battery level is below a certain threshold.
# Usage: system-low-battery
# Checks if the battery level is low. If “low_threshold” is exceeded
# a system ...
I found these methods on Ubuntu Forums in a thread titled: Thread: How do I lock the screen in XFCE?.
excerpted from 2 of the answers in that thread
Method #1 - Keyboard shortcut
Open the settings manager > keyboard > shortcuts and you can see that the default shortcut to lock the screen is ctrl-alt-del. If you want to change it, click add on the left, ...
In short, you should generally prefer the suspend mode integrated by your distro. For distros that ship systemd, that's typically systemctl suspend.
For instance, the Arch Linux wiki says:
systemd provides native commands for suspend, hibernate and a hybrid suspend, see "Power management with systemd" for details. This is the default interface used in ...
There are many ways to handle suspend and hibernate capabilities, many of the old methods are deprecated. This has made searching for solutions difficult, as it seems every solution is completely unrelated to the next. With that said...
The method currently recommended, advocated from http://pm-utils.freedesktop.org/wiki/, should be available for most ...
I've solved this issue by installing new linux kernel "4.5.2-040502-generic" following this guidelines:
Install new kernel (4.5.2):
I know your pain, this has been annoying me for months now.
1) The only way to fix the desktop I've found is brute force, I made a shortcut to do this and run it every time I resume from standby:
killall plasmashell; kstart plasmashell
2) I can't properly answer this but I'm posting all the info I've got so I can link this from the bug report page. The ...
I haven't got the time for all details now, but
see the GNOME Power Manager's FAQ "How do I make my application stop the computer auto-suspending" which points to the Inhibit() and UnInhibit() DBus-calls.
A caveat: if the process calling Inhibit() exits, the inhibition is ended - dbus-send in a Shell script thus won't do, but some wrapper script (e.g. in ...
Suspending implies that the data you were working with is in the memory. This state will be lost if you run out of power. If you were writing a forum post, for example, it will be lost, but nothing more serious would happen. Think that it's less serious than unplugging and removing the battery, since the computer can sync before and even delay the suspension ...
Under Freedesktop-compliant environments, including XFCE4, sleep inhibition is communicated via D-Bus on the org.freedesktop.PowerManagement bus. I can't find any documentation about this; the xfce4 code has a list of methods which includes one called GetInhibitors so this should work:
dbus-send --print-reply --dest=org.freedesktop.PowerManagement /org/...
Sounds like you want suspend-to-both/hybrid suspend which should do all the steps of hibernating, including writing RAM to disk, but not actually turn the machine off; instead, it'll go into S3 (standby). If you wake the machine up before the battery dies, it'll be fairly quick; if the battery dies, it'll be just as if you'd hibernated it.
Try this as root:
Then check /var/log/pm-suspend.log for hints on what might go wrong.
If you can suspend, but not resume, there's a good article on the Ubuntu wiki on how to debug this problem.
There is no general facility for hibernating a single process, only the whole system.
However, if you don't care that the process image won't survive a reboot, there is a built-in facility for saving the process image to disk: swapping. Make sure you have enough swap space, and if there is memory pressure and the process is not active (for example because ...
I wrote a script. It seems to do what you ask for:
# Custom suspend
# (That 'zsh' up there can be switched to 'bash', or
# pretty much any shell - this doesn't do anything too fancy.)
# Dependencies are mostly xfce stuff:
# Set how dim we want the screen to go (percentage, out ...
PM_DEBUG and PM_TRACE are apparently the deepest debugging facilities there are right now. When you're getting nothing meaningful from higher level logs, AFAIK this is the only mechanism to fall back on when encountering the dreaded "mysterious blank screen on resume" symptom. Most often we're dealing with a, quite often subtly, broken device driver. You can ...
I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of systemd:
polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is ...
Making restartable snapshots of a process is very hard, because a process can have all kinds of interactions with the filesystem. As a rule, don't expect unix systems to support this. There have been unix variants with restartable core dumps, but I don't think this is the case on modern ones (they've become too complex).
Lisp systems typically have a dump ...
Upower no longer handles suspend/resume. That's done by logind.
Of course, I have what I believe to be the correct version of systemd (which provides logind) and the correct version of upower, and I still have problems (though not with crunchbang).
In any case, make sure you have at least systemd=215-5+b1, libpam-systemd=215-5+b1 and