Hello

I have a small laptop acting as a 'file server' etc that sits chugging away with the lid closed. The laptop's screen is broken and its wiring loom is removed to the main board. When rarely I need a monitor, I plug one in on the vga port.

A cron job is set to put the laptop to sleep overnight using 'rtcwake' and wake it up in the morning.

Previously on 14.1 there were seemingly no issues and everything worked fine; the machine went to sleep and woke up as instructed.

Fresh install of 14.2 completed, cron job back in place and this is no longer the case - the laptop will not hibernate.


Summary:

pm-hibernate and rtcwake will not put the laptop to sleep unless a vga monitor is connected, or the vncserver is not running.

I think it has something to do with X11 (or the kernel ?) expecting a physical display being available if the vncserver is running at the point the rtcwake or pm-hibernate is run. Might it be this or something else ?

Of course I could shutdown the vncserver and all should work, but i never required this previously.

How might I permanently disable the LVDS, or ensure that the LVDS is not required at hibernate time please ?



------------------------------------------------------
What I tried to get to the above summary 'conclusion':

The machine seems to attempt to hibernate and then a few seconds later, wakes back up again.

I've removed the cron 'rtcwake -m disk -s nnnnn' entry.
Then I manually tested rtcwake from the command line with the same cron entry. It appeared to try to hibernate and then immediately came back to life.

Instead of using rtcwake, I tried simply issuing a pm-hibernate command. Same result as with rtcwake. Nothing I tried seemed to work, so I left it to come back to.

I decided at some point to connect a monitor to the vga port and then tried again... all worked fine! No other changes made in between, just the connection of the monitor.

Removed the monitor and the problem returned.

On the laptop was running a vncserver session, so I shut it down and pm-hibernate and rtcwake worked as expected (without the VGA monitor connected).

Restarted the vncserver (no vga monitor connected) and the problem returned.

Connected the vga monitor (and with the vncserver running) everything fine.

Hi Betty,


Hmmm... curioser and curioser, eh?
Fortunately, we can probably just catch dbus.

If you want to hibernate instead of suspend, just change the last word in the script.
If you want to suppress the delightful debugging output that prints across the screen when you come out of suspend, redirect stdout to /dev/null.
You seem to need the "--print-reply " to block the script from exiting before DBUS can put the laptop in suspend.

BTW, I just stole that from some guy over on the arch wiki, truth be told, but it works without issue on 14.2 with XServer running and not running (on my laptop).
Hope that works as well for you

@dijetlo - many thanks for the reply.

That is interesting but it leaves me asking...what is going on with DBus etc in relation to this issue...and why do I need to use it (I did not previously - before going to 14.2).

In my mind I should be able to do as before and issue pm-hibernate (or rtcwake in cron) and it do just that. It tries but immediately wakes up (or never makes a full hibernate in the first place). Is that down to this flaming DBus thing ?

If it is DBus, then why if I attach a physical monitor does it work - what is it that DBUS is causing the machine to not be able to hibernate ? There must be a setting or something other than using the UPOwer work around ?

Any ideas.... any one ?


Thank you again for the contributions.

There are differences between Slackware 14.1 and 14.2 in the generation of ACPI lid events. What you describe seems to be the opposite of the issue discussed here, perhaps due to the removed wiring. Why it would be different with a monitor connected is a mystery though.

Mmm.. dbus is a cross application bus, it provides a way for applications to pass data to each other and the underlying OS. It doesn't have a thing to do with getting your machine into suspend, it's more like a system message queue. Upower is the portion of the script that is handling the suspend functionality, your just using dbus to signal it.

As for the rest, try to remember, you have a very non-standard use case. Your laptop was never intended to be used in a headless state (that's why they crazy glued a monitor in the lid). In addition, I imagine it's pretty old and to be honest, half-broken. I think it's fortunate we can get it to work at all.
Sometime, the amazing thing about the dancing bear is not how fast he dances, but that he dances at all.

@dijetlo - true, it is old and knackered...but it worked fine [in its current physical state] with 14.1. I'll keep trying until I get tired :-)

@allend - thanks for the link, I'll have a read..it may get me thinking to try other things. It is rather strange...plug in in the VGA and all is well! Its as if when X is running (as a result of the vncserver) the hibernate process gets interrupted as a result of a lack of a physical screen being found. Maybe I need to permanently disable a monitor - though not sure how to do that for the best yet (kernel boot parameter or X config setting etc).

Thank you both for contributing.

Im going to mark this as solved (sort of).

@allend's contribution re: the link supplied to another thread, had me looking at 'issues' relating to laptop lids.

So I left the lid open and tested pm-hibernate and rtcwake and both worked without requiring a physical screen attached.

Anyway, it the led me to checking out /proc/acpi/wakeup and noticing entries in there that are enabled/disabled in relation to devices capable of waking up the machine as I understood it.

There was one (four letter code in first column) in there that was enabled and disabling it appeared to help resolve the problem. Apparently the codes differ from machine to machine and are affected by the hardware and so forth that is present.

In addition I have run the xfce power manager settings (even though I dont use xfce) and set the lid to disable the screen on close - dont know what this will do when not running xfce, but it may have changed something when I ran it.

On that basis, at least for me, it has resolved it. Phew.