So in every distro I use multiple DEs/WMs but I end up with XFCE as a DE because it is comfy and I've made some nice themes for it.

I've got a laptop, so I like the computer to sleep when the lid is closed. In the past, I've needed to be in XFCE with dbus for that to work. dbus also seems to be needed to get the reboot and shutdown options on the menu when exiting XFCE.

In the BLFS book, I read a simple way to get the laptop to sleep on lid close, even when in the console. I've tried it and it works. Nice.

In view of that, I wonder if there are also ways to get reboot/shutdown from within XFCE without dbus. If so, I could run without dbus?

I forget if dbus is used for the battery power-level notices. That's also kind of important.

If I do put dbus in, will there be a conflict between the existing lid-close detection and however dbus & XFCE handle it?

p.s. currently not running xfce, running treewm because zero dependencies (aside from xorg itself).

Assuming that you're talking about PM-Utils, whether or not conflicts will exist will depend entirely on what actions are taken by the scripts in /usr/lib/pm-utils/sleep.d or anything that overrides it in /etc/pm/sleep.d.

If you want the full scope of functionality, you'll probably need several different things that are there to perform specific tasks, but are almost always installed together and are part of most Linux distribution bases. As far as I know, there is only group of tools that are currently maintained for these desktop-specific tasks: GLib, D-Bus, PolicyKit, UPower, ACPId, LM_Sensors, PCIUtils and their associated dependencies. You might also need USBUtils and UDisks if you want to sleep peripherals and/or have drives spin down when idle.

You could try looking at some embedded solutions, like BusyBox, etc. too see if they have anything to replace those. You may also get by with just pm-utils, glib and acpid but, I doubt they'll do everything you might want.

As for conflicts, most of these things take actions based on something that is configurable: scripts, run-levels, policies, units, etc. You'll need to dig into them to find out if the same action is being pushed from multiple sources. These things tend to be triggered by system-wide events and more than one thing can answer.

I may have found your problem when I was going through some change logs for the current version of Mate Desktop.

UPower use to work with PM-Utils directly. A couple of years ago, UPower dropped PM-Utils support in favor of Systemd. While a lot of folks will jump to conclusions, I'm more inclined to believe that this was due to one or two primary issues. First, PM-Utils hasn't seen a commit in years and the scripts required root, suid or sudo entries to allow regular users access. DBus and PolicyKit changed that and that's where development went. Since then, ConsoleKit2 was introduced, and if I understand correctly, it will work with PM-Utils, sending requests through DBus.

So, that might be what you need: ConsoleKit2 to get pm-utils working the way you want, without Systemd.

Yikes. I suppose this is my fault for not being more precise in my posting.

The method I use for sleep on lid-close, originally specified in the BLFS 8 book. Makde file called /etc/acpi/events/lid, edit it to look like this:
Create a file named /etc/acpi/lid.sh, edit it to look like this:
and make it executable.

Oh, and have acpid started at boot time. That's also documented in the book and I will skip that detail for this post.

My original question, restated is, will any part of DBUS and/or XFCE conflict with the above lid-closing system? Again, as stated originally, I have not yet installed XFCE nor DBUS. The purpose of my question is to ascertain things before going ahead and perhaps creating a mess.

Okay, I understand now. The answer is, it could, but it may not. ACPId + PM-Utils makes this a daemon-to-kernel chain of events. The command isn't coming from a user so privilege isn't the problem. However, notification may be as there may be daemons, open files, mount points, etc. that need to be cleaned up before or after pm-suspend.

Here is my suggestion: Download a distro that still uses pm-utils, but also has acpid, xfce and dbus available from package managers or is preinstalled. Slackware comes to mind, as does Debian. Install the distro on a virtual machine, along with dbus and xfce and then take a look at the /etc/acpi/lid.sh file and see what's in it. If you see something that looks like this:
Then you know something is needed before suspend takes place. There might even be a setup that sleeps the script and waits for a reply from dbus. I know that some profile-based wifi utilities won't reconnect properly if not notified before or after the suspend. A desktop widget that automounts usb drives could corrupt files if not cleanly unmounted before suspend, etc. The bottom line is to look for a setup similar to yours and see how people before you have set it up.

OK: was finally able to check my old Slackware partition. There is no lid.sh, however, the /etc/acpi/events directory has a "default" file that just calls one generic script for *any* event. That script in turns ignores everything but a button-press to turn the machine off. So no conflict?

Maybe I should just, after a backup, install dbus & XFCE and see what heppens?

I probably don't want to know ... but...
"still" implies approaching obsolescence? What else would one use?

Whether or not it is in conflict depends on whether or not something needs to be notified before the machine goes into suspend. That's where dbus would come in.

What I do know: pm-utils is depreciated and people have reported that it doesn't work with current versions of UPower. There doesn't appear to have been significant work on it in more than 7 years. However, there is a branch version maintained by Gentoo that maintains it for use with more recent versions of UPower. Have a look at their ebuild respository, there are patches and configuration files in there that may help you work out what you need.

Here's another notice about this, found in a google search.

Note the bit about Xfce integrating the functionality. That may be why your Xfce still works and the command line no longer does. For the shell, you can either use their adaptations to pm-utils or probably use acpid to call a script that tells dbus to suspend the machine. You'll probably have to put a policy in to allow non-root to do so.

Wow: thank you for all of the info.

After looking at these a bit more, I have a better understanding now. Things change over time and we don't always pay attention to how or why when that's happening.

The older tools, used primarily before all the recent Linux plumbing work over the last decade...

ACPId: Monitored the system for power-related events and launched scripts.

PM-Utils: Provides the commands that make the system-calls that react to power events. More importantly, pm-utils provided event hooks for scripts that happened before or after power events. These were in the form of /usr/lib/pm-utils/{sleep.d, hibernate.d, shutdown.d, etc.} These would run scripts that did things like sleep wifi devices, disconnect usb or remote volumes. Some even send syscalls to clear certain kinds of memory on computers with shared ram, etc. In conclusion, writing a script that just tells the kernel to hibernate may not be sufficient and may corrupt files or even lock up the machine when it wakes.

Laptop Mode Tools: Added functionality for mobile PCs, spooling down hard drives, changing CPU power mode and shutting off backlights based on profiles, timers, etc.

...Then came the 2.6.32 kernel, Udev, DBus, PolicyKit, Systemd & UPower.

Udev: Monitors all kinds of system events, not just ACPI events. ACPId can still be used, but it is sort of redundant.

DBus: Allows udev to announce events system wide. Can be used in place of scripts in pm-utils to react to events.

PolKit: Allows non-root users to take root actions without using SUID, sudo, su, etc. Communicates through dbus.

Systemd: Everyone knows what it is, but one of the things it can do is react to power events (or any other type) like pm-utils. Event wants target, etc.

UPower: Monitors things like power usage, battery levels, charging rates, etc. Unlike ACPId or Udev, it's an ongoing thing and probably replaced some of what laptop mode tools used be for. It use to run scripts through pm-utils, but that was depreciated for systemd, probably do to lack of features or ongoing development.


What to use? Depends on what you're doing. If you're running SysV-Init, you can get events through ACPId or Eudev. PM-Utils is likely your best option for hooks, but the upstream won't work with UPower anymore. I don't know how well laptop mode tools is maintained, but UPower has forks for PM-Utils. ConsoleKit2 or eLogind can likely be used to hook in GUI shutdown requests with pm-utils, but dbus may be required for some things to work like UPower showing battery remaining in the GUI.

If you're running Systemd you can skip PM-Utils. Additionally, Udev, PolKit, DBus and UPower work natively with it. That said, nothing prevents you from using ACPId and other old utilities if you prefer them. Some things in Systemd, like networkd are very basic, but I don't think event handling is one of them.

Anyway... That's what I see on closer examination, but I could have misunderstood something if I'm incorrect on any of those points.