subject:"Problem with systemd\-sleep in Jessie"

On 10/23/2014 10:25 PM, Michael Biebl wrote:
 Am 24.10.2014 um 04:58 schrieb Michael Biebl:
 Am 24.10.2014 um 04:19 schrieb Michael Biebl:

 For some reason, you seem to be getting acpi events which trigger the
 suspend request in logind. This might be a buggy ACPI implementation
 like in [1].

 To further debug this, you might install the evtest package and run
 the evtest binary as root.
 
 Another thing you can try is the following (run as root):
 $ systemctl stop systemd-logind.service
 $ /lib/systemd/systemd-logind
 
 This will show you, which input devices logind will monitor and which
 events it receives.

# /lib/systemd/systemd-logind
New seat seat0
Watching system buttons on /dev/input/event5 (Power Button)
Watching system buttons on /dev/input/event1 (Video Bus)
Watching system buttons on /dev/input/event4 (Power Button)
Watching system buttons on /dev/input/event2 (Lid Switch)
Watching system buttons on /dev/input/event3 (Sleep Button)
New session c1 of user lightdm
New session 1 of user root.
Suspending...
Power key pressed.
Operation finished.


As soon as I ran the command, that is what happened. The Power key
pressing was me waking it back up.

Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

On 10/23/2014 11:19 PM, Ric Moore wrote:
 
 To the OP: Stack. THANK YOU for starting an intelligent systemd QA.

I have voiced my systemd concerns before. At this time, I am simply
tying to figure out what is wrong with my laptop. Should systemd be the
default/only init system when Jessie releases, I would rather have all
these weird quirks fixed /before/ the release. Thus, I am trying to
learn about systemd and understand what is going on vs starting yet
another flamewar (there is enough of those at the moment...I really
don't want to add another).

 One feature I read about is that systemd will shut down under various
 conditions that would also prevent exhausting the battery on a
 laptop.

A good thought. The battery on this 8yr old laptop is long dead. I only
keep it in the laptop because it balances the weight (and there is an
awkward gap in the back without it). A new battery for this laptop is
90$. Not worth it for this laptop. In any case, I removed the battery
and I still have the issue.

 I don't suppose there is anyway to install fresh to get rid of old
 cruft??

I am sure I could, but it isn't easy as this laptop doesn't support USB
boot and the CD-ROM is long dead too. I have to PXE boot the network
image for the Debian install...

Besides, I would rather see if I can find what is wrong vs just blowing
it away and potentially losing whatever caused the problem. If I lose
that, then we can't file a bug report to have it fixed which in turn
means others might have this same issue in the future. If at all
possible, I would like to find a proper fix.

 I'm of no help as I am just starting to learn it, but I am learning
 from your experience, so that you again. bows deeply Ric

I'm learning too. :-)

Thanks for the input.










signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

On 10/23/2014 11:06 PM, Michael Biebl wrote:
 That looks all fine.
 Can you remove the settings again from logind.conf and restart
 systemd-logind while monitoring what evtest logs and and also what
 systemd-logind logs.
 For the latter, you can either run systemd-logind in the foreground (as
 I described) or use Joey's method to filter journal entries via
 journalctl -u systemd-logind -f

I did as you asked. I had the F1 terminal set to start systemd-login, F2
terminal was watching journalctl, F3 was watching evtest for input 4 (I
also retested with the others, but similar results).

The /only/ thing that journalctl prints out is Suspending
Everything else is related to when I press the button to wake it back up.

As for the evtest, I get this message over and over again:
Event: time timestamp, type 1 (EV_KEY), code 116 (KEY_POWER), value 1

Thanks for helping me on this!




signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

On 10/23/2014 09:36 PM, ~Stack~ wrote:
 On 10/23/2014 08:29 PM, Don Armstrong wrote:
 You can also change /etc/systemd/logind.conf, and change the
 HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=,
 HandleLidSwitch= all to ignore temporarily.
 
 Done. That seems to work! The laptop isn't sleeping incessantly. :-)

Just because I was curious, I decided to test out which one of these is
actually the culprit. Thus, I edited logind.conf and commented out the
ignore line on all but one at a time. Then 'systemctl stop
systemd-logind.service' and then 'systemctl start
systemd-logind.service' (yeah, I could have probably done a restart, but
I wanted to ensure a full stop). Every time the laptop would instantly
go to sleep on start.

Except for HandleLidSwitch.

That is the one causing problems. Leaving that one set to ignore stops
the constant sleep cycle. Maybe the smarter people have already figured
that out, but for me it was nice to know the exact one being a pain. :-)

Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

2014-10-24 Thread Michael Biebl

Am 24.10.2014 um 14:46 schrieb ~Stack~:
 On 10/23/2014 11:06 PM, Michael Biebl wrote:
 That looks all fine.
 Can you remove the settings again from logind.conf and restart
 systemd-logind while monitoring what evtest logs and and also what
 systemd-logind logs.
 For the latter, you can either run systemd-logind in the foreground (as
 I described) or use Joey's method to filter journal entries via
 journalctl -u systemd-logind -f
 
 I did as you asked. I had the F1 terminal set to start systemd-login, F2
 terminal was watching journalctl, F3 was watching evtest for input 4 (I
 also retested with the others, but similar results).
 
 The /only/ thing that journalctl prints out is Suspending
 Everything else is related to when I press the button to wake it back up.
 
 As for the evtest, I get this message over and over again:
 Event: time timestamp, type 1 (EV_KEY), code 116 (KEY_POWER), value 1

So, it doesn't look like you get spurious SW_LID events.
We discussed that on #debian-systemd, and it's likely that this is
because of the change that was committed in [1]:

logind is now a lot more aggressive when suspending the machine due to
a closed laptop lid. Instead of acting only on the lid close action, it
will continuously watch the lid status and act on it.

We suspect, that either your laptop reports an incorrect lid state or
the heuristic to determine the lid state is not correct.

I extracted the lid state switch into a small test program.
Can you compile the attach test program (make switch). I hard-coded the
lid switch button to /dev/input/input1. You'll need to change that if
that's different on your system (check with evtest). You need to run
that binary as root.

What do you get if your that program when your lid is closed/opened?

It should return 0 if the lid is open and 1 if closed.



[1]
http://cgit.freedesktop.org/systemd/systemd/commit/?id=ed4ba7e4f652150310d062ffbdfefb4521ce1054
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
#include stdio.h
#include stdint.h
#include sys/ioctl.h
#include unistd.h
#include linux/input.h
#include errno.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h



int main(int argc, char **argv) {
	int fd;
	int lid_closed;
	uint8_t switches[SW_MAX/8+1] = {};

	fd = open(/dev/input/event1, O_RDONLY);
if (fd  0)
return -EINVAL;

if (ioctl(fd, EVIOCGSW(sizeof(switches)), switches)  0)
return -errno;

lid_closed = (switches[SW_LID/8]  (SW_LID % 8))  1;

	printf(State: %i\n, lid_closed);

	return(0);
	
}


signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

2014-10-24 Thread Michael Biebl

Am 24.10.2014 um 17:23 schrieb Michael Biebl:
 What do you get if your that program when your lid is closed/opened?

The output of
$ cat /proc/acpi/button/lid/LID/state
when lid is closed / open would be helpful as well.

If you don't have an external monitor, you can run

sleep 30  cat /proc/acpi/button/lid/LID/state

and then quickly close your lid.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Problem with systemd-sleep in Jessie

Greetings,

I have been running Jessie i386 on a spare laptop just so I can see how
all the big changes that are coming will impact me. For the last few
months, nothing too big has really hit me (at least none that don't have
a bug filed already). Well, that is until now.

I think I last booted/updated this laptop last weekend. I booted it up
tonight to mess around on it and the first thing, as always, was to run
updates. A bunch of systemd stuff updated. Now the laptop is dang near
unusable.

It boots and it will sit at the log in screen for quite some time like
everything is good and happy. If I log in either via GUI (LXDE) or via
command line, the laptop goes to sleep anywhere between 2 and 15 seconds
later. I have to hit the power button (no other button on the laptop is
responsive) and it will wake up again but promptly go back to sleep 2-15
seconds later. And repeat.

It took me over a minute simply trying to log in via the CLI just run a
'tail -f /var/log/syslog' because for whatever reason it really just
wants to go to sleep. The only thing that I really see is a line that reads:
time hostname systemd-sleep: suspending session

Nothing before it of any consequence, and after is just logs about the
system going into sleep mode.

So I have been digging around trying to figure out what is going on and
I can't seem to stop it. Here is what I know:

* There is nothing in the /etc/systemd/sleep.conf file.
* It is technically going into a suspend.
* I have no idea what dictates how long it will last before going back
to sleep.
* I tried to reinstall systemd with no luck (that took forever...when it
takes 3-5 seconds for NetworkManger to bring up the wireless connection
and the window for activity is 2-15 seconds...well I am kinda surprised
I didn't jack up the install when it went to sleep in the middle of the
install...twice!).
* Unless I have something specific to search for, the system logs are
worthless because they are _flooded_ with the information about
going-to/waking-up-from sleep.

I haven't really figured out systemd yet but I am not making much
progress with online searching at the moment.

Can anyone help me figure out how to stop systemd from trying to go to
sleep all the time? This is quite annoying...

Thank you!
~Stack~



signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

2014-10-23 Thread Joel Rees

2014/10/24 9:57 ~Stack~ i.am.st...@gmail.com:

 Greetings,

 I have been running Jessie i386 on a spare laptop just so I can see how
 all the big changes that are coming will impact me. For the last few
 months, nothing too big has really hit me (at least none that don't have
 a bug filed already). Well, that is until now.

 I think I last booted/updated this laptop last weekend. I booted it up
 tonight to mess around on it and the first thing, as always, was to run
 updates. A bunch of systemd stuff updated. Now the laptop is dang near
 unusable.

 It boots and it will sit at the log in screen for quite some time like
 everything is good and happy. If I log in either via GUI (LXDE) or via
 command line, the laptop goes to sleep anywhere between 2 and 15 seconds
 later.

CLI? From a virtual (CTRL-ALT-fN) terminal?

 I have to hit the power button (no other button on the laptop is
 responsive) and it will wake up again but promptly go back to sleep 2-15
 seconds later. And repeat.

 It took me over a minute simply trying to log in via the CLI just run a
 'tail -f /var/log/syslog' because for whatever reason it really just
 wants to go to sleep. The only thing that I really see is a line that
reads:
 time hostname systemd-sleep: suspending session

 Nothing before it of any consequence, and after is just logs about the
 system going into sleep mode.

 So I have been digging around trying to figure out what is going on and
 I can't seem to stop it. Here is what I know:

 * There is nothing in the /etc/systemd/sleep.conf file.
 * It is technically going into a suspend.
 * I have no idea what dictates how long it will last before going back
 to sleep.
 * I tried to reinstall systemd with no luck (that took forever...when it
 takes 3-5 seconds for NetworkManger to bring up the wireless connection
 and the window for activity is 2-15 seconds...well I am kinda surprised
 I didn't jack up the install when it went to sleep in the middle of the
 install...twice!).
 * Unless I have something specific to search for, the system logs are
 worthless because they are _flooded_ with the information about
 going-to/waking-up-from sleep.

 I haven't really figured out systemd yet but I am not making much
 progress with online searching at the moment.

 Can anyone help me figure out how to stop systemd from trying to go to
 sleep all the time? This is quite annoying...

 Thank you!
 ~Stack~


I'd suspect something in power management, maybe, but who knows?

Is sshd running so you could try logging in from the network? If it doesn't
go to sleep when logged in from the network, that would be a data point.

And, assuming the translating from binary to text didn't get in the way, it
would allow you to do a looped tail on the log files to try to watch while
you logged in from the keyboard.

Of course, having another user logged in might trigger the Can't log off
while other users are logged. condition, but that would be yet another
data point.

Or have you tried booting a live image on an external device so you can
read the logs at better leisure, grep, etc.?

--
Joel Rees

Re: Problem with systemd-sleep in Jessie

2014-10-23 Thread Don Armstrong

On Thu, 23 Oct 2014, ~Stack~ wrote:
 It boots and it will sit at the log in screen for quite some time like
 everything is good and happy. If I log in either via GUI (LXDE) or via
 command line, the laptop goes to sleep anywhere between 2 and 15
 seconds later. I have to hit the power button (no other button on the
 laptop is responsive) and it will wake up again but promptly go back
 to sleep 2-15 seconds later. And repeat.

For starters, if you append systemd.unit=rescue.target to the kernel
command line, you'll get a rescue shell that you can use to interrogate
the system.

I'm suspecting that you have some sort of contest between pm-utils or
similar trying to suspend the laptop, but I'm not certain.

You should be able to examine the logs and use journalctl to see
precisely what systemd is trying to do at that point.

You can also change /etc/systemd/logind.conf, and change the
HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=,
HandleLidSwitch= all to ignore temporarily.
 

-- 
Don Armstrong  http://www.donarmstrong.com

To steal ideas from one person is plagiarism; to steal from many is
research.
 -- Steven Wright


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141024012922.gz28...@teltox.donarmstrong.com

Re: Problem with systemd-sleep in Jessie

On 10/23/2014 08:32 PM, Joel Rees wrote:
 2014/10/24 9:57 ~Stack~ i.am.st...@gmail.com
 mailto:i.am.st...@gmail.com:
snip
 It boots and it will sit at the log in screen for quite some time like
 everything is good and happy. If I log in either via GUI (LXDE) or via
 command line, the laptop goes to sleep anywhere between 2 and 15 seconds
 later.
 
 CLI? From a virtual (CTRL-ALT-fN) terminal?

That is correct.


 I'd suspect something in power management, maybe, but who knows?
 
 Is sshd running so you could try logging in from the network? If it
 doesn't go to sleep when logged in from the network, that would be a
 data point.
 
 And, assuming the translating from binary to text didn't get in the way,
 it would allow you to do a looped tail on the log files to try to watch
 while you logged in from the keyboard.
 
 Of course, having another user logged in might trigger the Can't log
 off while other users are logged. condition, but that would be yet
 another data point.

It does go to sleep when logged in remotely.

 
 Or have you tried booting a live image on an external device so you can
 read the logs at better leisure, grep, etc.?

Unfortunately, there are a number of reason why this is a test laptop.
The CD-ROM being busted is one...not booting from USB is another...To
install Jessie I rigged a PXE boot menu to launch the contents for a
network install.

Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

Hi,

Am 24.10.2014 um 02:40 schrieb ~Stack~:
I think I last booted/updated this laptop last weekend. I booted it up
tonight to mess around on it and the first thing, as always, was to run
updates. A bunch of systemd stuff updated. Now the laptop is dang near
unusable.

Could you please check, from which version you updated, so we know which
version did not exhibit this behaviour and which version does.
See /var/log/dpkg.

Which version do you currently run?

It boots and it will sit at the log in screen for quite some time like
everything is good and happy. If I log in either via GUI (LXDE) or via
command line, the laptop goes to sleep anywhere between 2 and 15 seconds
later. I have to hit the power button (no other button on the laptop is
responsive) and it will wake up again but promptly go back to sleep 2-15
seconds later. And repeat.

It took me over a minute simply trying to log in via the CLI just run a
'tail -f /var/log/syslog' because for whatever reason it really just
wants to go to sleep. The only thing that I really see is a line that reads:
time hostname systemd-sleep: suspending session

Nothing before it of any consequence, and after is just logs about the
system going into sleep mode.

So I have been digging around trying to figure out what is going on and
I can't seem to stop it.

Once you're logged in, run systemd-inhibit --what=sleep /bin/sleep
3600 [1]. This should block any suspend requests for one hour.

Or for a permanent change, you can edit /etc/systemd/logind.conf and set
HandleSuspendKey and HandleLidSwitch to ignore.

Could you describe your hardware in more detail. What type of computer,
which graphics card and driver, monitor setup etc.

For some reason, you seem to be getting acpi events which trigger the
suspend request in logind. This might be a buggy ACPI implementation
like in [1].

Michael

[1]
https://wiki.archlinux.org/index.php/Acer_Aspire_One#Suspend_on_lid.2C_shutdown_on_power_button

[1] http://www.freedesktop.org/software/systemd/man/systemd-inhibit.html
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

On 10/23/2014 08:29 PM, Don Armstrong wrote:
 On Thu, 23 Oct 2014, ~Stack~ wrote:
 It boots and it will sit at the log in screen for quite some time like
 everything is good and happy. If I log in either via GUI (LXDE) or via
 command line, the laptop goes to sleep anywhere between 2 and 15
 seconds later. I have to hit the power button (no other button on the
 laptop is responsive) and it will wake up again but promptly go back
 to sleep 2-15 seconds later. And repeat.
 
 For starters, if you append systemd.unit=rescue.target to the kernel
 command line, you'll get a rescue shell that you can use to interrogate
 the system.

Thanks! That does appear to work well to get me in un-interrupted.

 
 I'm suspecting that you have some sort of contest between pm-utils or
 similar trying to suspend the laptop, but I'm not certain.
 
 You should be able to examine the logs and use journalctl to see
 precisely what systemd is trying to do at that point.

Errr...fraid this is all rather new to me but at the moment I am not
getting much of anything out of journalctl. Let me bust out my
search-foo and see if I can get something useful.

 
 You can also change /etc/systemd/logind.conf, and change the
 HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=,
 HandleLidSwitch= all to ignore temporarily.

Done. That seems to work! The laptop isn't sleeping incessantly. :-)




So while I was waiting on a response, I copied off the syslog to another
box to examine it (in only 3 tries! :-). There is a re-occuring theme
and it does look like I may have just missed the info previous to the
systemd-sleep. See snippet below. The CTRL-EVENT-SCAN-STARTED /always*/
starts the problem and the nm-dispatcher /always*/ ends.

*Where always == every time I have found it in my logs so far. :-)

There are usually several seconds between CTRL-EVENT-SCAN-STARTED and
whatever happened in the log before it. After this, the pattern is
almost identical every time and takes about the same amount of time.


sysctl snippet:

Oct 23 19:15:37 Senta wpa_supplicant[877]: wlan0: CTRL-EVENT-SCAN-STARTED
Oct 23 19:15:38 Senta NetworkManager[582]: info sleep requested
(sleeping: no  enabled: yes)
Oct 23 19:15:38 Senta NetworkManager[582]: info sleeping...
Oct 23 19:15:38 Senta NetworkManager[582]: info (wlan0): device state
change: activated - unmanaged (reason 'sleeping') [100 10 37]
Oct 23 19:15:38 Senta NetworkManager[582]: info (wlan0): deactivating
device (reason 'sleeping') [37]
Oct 23 19:15:38 Senta NetworkManager[582]: info (wlan0): canceled DHCP
transaction, DHCP client pid 2400
Oct 23 19:15:38 Senta kernel: [  394.584207] wlan0: deauthenticating
from 00:16:01:2d:98:ae by local choice (Reason: 3=DEAUTH_LEAVING)
Oct 23 19:15:38 Senta wpa_supplicant[877]: wlan0:
CTRL-EVENT-DISCONNECTED bssid=00:16:01:2d:98:ae reason=3 locally_generated=1
Oct 23 19:15:38 Senta systemd-udevd[197]: Network interface NamePolicy=
disabled on kernel commandline, ignoring.
Oct 23 19:15:38 Senta kernel: [  394.610725] cfg80211: Calling CRDA to
update world regulatory domain
Oct 23 19:15:38 Senta kernel: [  394.685745] cfg80211: World regulatory
domain updated:
Oct 23 19:15:38 Senta kernel: [  394.685754] cfg80211:  DFS Master
region: unset
Oct 23 19:15:38 Senta kernel: [  394.685758] cfg80211:   (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Oct 23 19:15:38 Senta kernel: [  394.685765] cfg80211:   (2402000 KHz -
2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A)
Oct 23 19:15:38 Senta kernel: [  394.685771] cfg80211:   (2457000 KHz -
2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A)
Oct 23 19:15:38 Senta kernel: [  394.685777] cfg80211:   (2474000 KHz -
2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A)
Oct 23 19:15:38 Senta kernel: [  394.685782] cfg80211:   (517 KHz -
525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A)
Oct 23 19:15:38 Senta kernel: [  394.685788] cfg80211:   (525 KHz -
533 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s)
Oct 23 19:15:38 Senta kernel: [  394.685794] cfg80211:   (549 KHz -
573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s)
Oct 23 19:15:38 Senta kernel: [  394.685799] cfg80211:   (5735000 KHz -
5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A)
Oct 23 19:15:38 Senta kernel: [  394.685804] cfg80211:   (5724 KHz -
6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A)
Oct 23 19:15:38 Senta dbus[586]: [system] Activating via systemd:
service name='org.freedesktop.nm_dispatcher'
unit='dbus-org.freedesktop.nm-dispatcher.service'
Oct 23 19:15:38 Senta systemd-sleep[2471]: Suspending system...
Oct 23 19:15:38 Senta dbus[586]: [system] Successfully activated service
'org.freedesktop.nm_dispatcher'
Oct 23 19:15:38 Senta nm-dispatcher: Dispatching action 'down' for wlan0




One other thing that is very odd is that I see a lot of these messages
below. They are usually very-tightly grouped and again there is usually
a few seconds gap surrounding these messages. Should I be worried about
this?

Oct 23 19:15:19 Senta

Re: Problem with systemd-sleep in Jessie

Am 24.10.2014 um 04:19 schrieb Michael Biebl:

 Once you're logged in, run systemd-inhibit --what=sleep /bin/sleep
 3600 [1]. This should block any suspend requests for one hour.

Hm, actually, it's probably better to block the handling of the
lid-switch, power and suspend/hibernate keys.

Please try this:

systemd-inhibit
--what=handle-lid-switch:handle-power-key:handle-suspend-key:handle-hibernate-key
/bin/sleep 3600

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

On 10/23/2014 09:19 PM, Michael Biebl wrote:
Hi,

Could you please check, from which version you updated, so we know which
version did not exhibit this behaviour and which version does.
See /var/log/dpkg.

It looks like I went from 204-14 to 215-5+b1 if I am reading this
correctly.

Which version do you currently run?

215-5+b1

Nothing before it of any consequence, and after is just logs about the
system going into sleep mode.

So I have been digging around trying to figure out what is going on and
I can't seem to stop it.

Once you're logged in, run systemd-inhibit --what=sleep /bin/sleep
3600 [1]. This should block any suspend requests for one hour.

Thanks. I made the temp modifications from Don Armstrong's suggestion
which seems to have given me relief.

Or for a permanent change, you can edit /etc/systemd/logind.conf and set
HandleSuspendKey and HandleLidSwitch to ignore.

Yup. That's the suggestion. :-)

Could you describe your hardware in more detail. What type of computer,
which graphics card and driver, monitor setup etc.

Sure, here is the laptop:
http://linuxcertified.com/linux-laptop-lc2100dc.html

It has run a flavor of Linux for...geez...like 8 years...and I have
never had an issue with any Linux distro running on it (the reason why I
bought it :-).

For some reason, you seem to be getting acpi events which trigger the
suspend request in logind. This might be a buggy ACPI implementation
like in [1].

Michael

[1]
https://wiki.archlinux.org/index.php/Acer_Aspire_One#Suspend_on_lid.2C_shutdown_on_power_button

[1] http://www.freedesktop.org/software/systemd/man/systemd-inhibit.html

Thanks!

signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

Am 24.10.2014 um 04:19 schrieb Michael Biebl:

 For some reason, you seem to be getting acpi events which trigger the
 suspend request in logind. This might be a buggy ACPI implementation
 like in [1].

To further debug this, you might install the evtest package and run
the evtest binary as root.
Please post the shown list
You might get an entry like /dev/input/event1: Lid Switch
If you select that event number (1), do you get any lid switch events
event though the lid is not closed or when the lid switch is closed?
Do you have other input devices which generate the SW_LID event?
You can try them one by one.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

Am 24.10.2014 um 04:36 schrieb ~Stack~:

 So while I was waiting on a response, I copied off the syslog to another
 box to examine it (in only 3 tries! :-). There is a re-occuring theme
 and it does look like I may have just missed the info previous to the
 systemd-sleep. See snippet below. The CTRL-EVENT-SCAN-STARTED /always*/
 starts the problem and the nm-dispatcher /always*/ ends.
 
 *Where always == every time I have found it in my logs so far. :-)
 

That's a red herring. NM simply listens to the logind sleep requests and
disables the network interface on sleep and re-enables it on resume.
That's why those events coincide. It's not the cause for it, but a reaction.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

Am 24.10.2014 um 04:58 schrieb Michael Biebl:
 Am 24.10.2014 um 04:19 schrieb Michael Biebl:
 
 For some reason, you seem to be getting acpi events which trigger the
 suspend request in logind. This might be a buggy ACPI implementation
 like in [1].
 
 To further debug this, you might install the evtest package and run
 the evtest binary as root.

Another thing you can try is the following (run as root):
$ systemctl stop systemd-logind.service
$ /lib/systemd/systemd-logind

This will show you, which input devices logind will monitor and which
events it receives.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

On 10/23/2014 10:01 PM, Michael Biebl wrote:
 Am 24.10.2014 um 04:36 schrieb ~Stack~:
 
 So while I was waiting on a response, I copied off the syslog to another
 box to examine it (in only 3 tries! :-). There is a re-occuring theme
 and it does look like I may have just missed the info previous to the
 systemd-sleep. See snippet below. The CTRL-EVENT-SCAN-STARTED /always*/
 starts the problem and the nm-dispatcher /always*/ ends.

 *Where always == every time I have found it in my logs so far. :-)

 
 That's a red herring. NM simply listens to the logind sleep requests and
 disables the network interface on sleep and re-enables it on resume.
 That's why those events coincide. It's not the cause for it, but a reaction.
 

Rats. I was afraid of that. Just hoping that it would be simple. ;-)

Thanks.




signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie

2014-10-23 Thread Joey Hess

Try running this:

journalctl -u systemd-logind -f

That will show messages logged by logind, for example:

Oct 23 23:30:10 darkstar systemd-logind[733]: Lid closed.
Oct 23 23:30:12 darkstar systemd-logind[733]: Lid opened.

It should also log if it thinks a suspend key is being pressed. It's
possible this old laptop has a screw loose somewhere and is generating
spurious events.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Problem with systemd-sleep in Jessie

On 10/23/2014 09:58 PM, Michael Biebl wrote:
 Am 24.10.2014 um 04:19 schrieb Michael Biebl:
 
 For some reason, you seem to be getting acpi events which trigger the
 suspend request in logind. This might be a buggy ACPI implementation
 like in [1].
 
 To further debug this, you might install the evtest package and run
 the evtest binary as root.
 Please post the shown list
 You might get an entry like /dev/input/event1:   Lid Switch

I do have this.

 If you select that event number (1), do you get any lid switch events
 event though the lid is not closed or when the lid switch is closed?
 Do you have other input devices which generate the SW_LID event?
 You can try them one by one.

Sure. I am not familiar with this tool so I am not sure what I am
looking at currently. Thus, here is what I did:
* I tested the Lid Switch by closing and opening the lid; the screen
turns off then back on again.
* I tested the Sleep Button; nothing happened
* I tested Power Button 3; nothing happened
* I tested Power Button 4; result below.

Do I need to remove those entries I put in /etc/systemd/logind.conf? I
worry if I do remove them, then I won't get a good test...



root@Senta:~# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Lid Switch
/dev/input/event2:  Sleep Button
/dev/input/event3:  Power Button
/dev/input/event4:  Power Button
/dev/input/event5:  Video Bus
/dev/input/event6:  PC Speaker
/dev/input/event7:  HDA Digital PCBeep
/dev/input/event8:  SynPS/2 Synaptics TouchPad
Select the device event number [0-8]: 1
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x5 version 0x0
Input device name: Lid Switch
Supported events:
  Event type 0 (EV_SYN)
  Event type 5 (EV_SW)
Event code 0 (SW_LID)
Properties:
Testing ... (interrupt to exit)
Event: time 1414121647.010196, type 5 (EV_SW), code 0 (SW_LID), value 0
Event: time 1414121647.010196, -- EV_SYN 

^C
root@Senta:~# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Lid Switch
/dev/input/event2:  Sleep Button
/dev/input/event3:  Power Button
/dev/input/event4:  Power Button
/dev/input/event5:  Video Bus
/dev/input/event6:  PC Speaker
/dev/input/event7:  HDA Digital PCBeep
/dev/input/event8:  SynPS/2 Synaptics TouchPad
Select the device event number [0-8]: 2
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x3 version 0x0
Input device name: Sleep Button
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 142 (KEY_SLEEP)
Properties:
Testing ... (interrupt to exit)

^C
root@Senta:~# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Lid Switch
/dev/input/event2:  Sleep Button
/dev/input/event3:  Power Button
/dev/input/event4:  Power Button
/dev/input/event5:  Video Bus
/dev/input/event6:  PC Speaker
/dev/input/event7:  HDA Digital PCBeep
/dev/input/event8:  SynPS/2 Synaptics TouchPad
Select the device event number [0-8]: 3
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x1 version 0x0
Input device name: Power Button
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 116 (KEY_POWER)
Properties:
Testing ... (interrupt to exit)
^C
root@Senta:~# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Lid Switch
/dev/input/event2:  Sleep Button
/dev/input/event3:  Power Button
/dev/input/event4:  Power Button
/dev/input/event5:  Video Bus
/dev/input/event6:  PC Speaker
/dev/input/event7:  HDA Digital PCBeep
/dev/input/event8:  SynPS/2 Synaptics TouchPad
Select the device event number [0-8]: 4
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x1 version 0x0
Input device name: Power Button
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 116 (KEY_POWER)
Properties:
Testing ... (interrupt to exit)
Event: time 1414121702.744549, type 1 (EV_KEY), code 116 (KEY_POWER),
value 1
Event: time 1414121702.744549, -- EV_SYN 
Event: time 1414121702.744566, type 1 (EV_KEY), code 116 (KEY_POWER),
value 0
Event: time 1414121702.744566, -- EV_SYN 
^C
root@Senta:~#

Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Problem with systemd-sleep in Jessie