Suspend and Poweroff non exclusive??

hungerfish · 2015-08-14 14:04:39

Posting to find out if anybody else has had this, as I don't think this should be possible...

Just now I was in a hurry to go out, I did not want to power down my desktop, so I opted to suspend.
First, I used the 'suspend' option from MATE's System->Shutdown dialog but nothing (seemed to) happen.
Again, because I was in a hurry, I fired up a console, and just typed 'suspend' (which I assume is the same as 'systemctl suspend'), but again nothing seemed to be happening.
Finally I switched to a different tty and logged in as root, typed 'poweroff' (thinking some update must have broken suspend which normally 'just works') and the system immediately started powering down (I could see the messages being printed to screen).
But as my monitor switched off I noticed that the system was actually suspended after all (blinking leds..). So guess what happend after 'waking it' after I got back:
The system woke just fine to display all the poweroff-messages for about 1 second after which it happily continued to poweroff....

Obviously this kind of thing should not, never ever ever be possible... This is all on stock/default linux/archlinux/systemd defaults!

Last edited by hungerfish (2015-08-14 14:05:38)

Zucca · 2015-08-14 17:19:15

Did you just update systemd?
I've had problems like you have few times and downgrading systemd helped. Then after that I just waited until new, working, version of systemd is released.
I would not normally recommend to downgrade, but when it happened to me there was absolutely nothing out of ordinary in journal. So that was the only thing I could think of.

jasonwryan · 2015-08-14 19:22:42

Not a Sysadmin issue, moving to NC...

hungerfish · 2015-08-16 08:34:25

@jasonwryan
Seriously?? To quote:

This forum is for technical issues revolving around the ongoing maintenance and fine tuning of Arch systems.

A race condition (no matter how rare) between the suspend and poweroff mechanism of 'potentially every' installed arch box most definitely counts as a 'technical issue' in my book, but feel free to share your reasoning...

To topic:
No, I did not recently update systemd, I also went through my logs but found nothing of particular note, except I could find systemd's messages about shutdown progress, but seemingly nothing about 'going to sleep'...which I find weird.
This isn't really a huge problem for me ( I rarely suspend anyway) but I would like to know what happened and maybe stop this sort of thing of being possible in the first place.
I'll do some more testing later to see what I can find..

jasonwryan · 2015-08-16 08:58:28

hungerfish wrote:

@jasonwryan
Seriously?? To quote:
This forum is for technical issues revolving around the ongoing maintenance and fine tuning of Arch systems.
A race condition (no matter how rare) between the suspend and poweroff mechanism of 'potentially every' installed arch box most definitely counts as a 'technical issue' in my book, but feel free to share your reasoning...

Selective quoting. Read the sticky I linked to:

Sysadmin sticky wrote:

It is intended for challenging and interesting issues; solutions and posts here are expected to provide value to the more competent GNU/Linux users and established members of the community.

Then reread your first post: no logs, no journal entries, nothing that would support any effective suggestions/assistance; so it provides no value to anyone who would qualify as remotely competent.

That is my reasoning. Seriously.

hungerfish · 2015-08-16 14:22:29

I for one find this problem quite interesting and potentially also challenging. Obviously I was looking for guidance in solving it by posting here. This includes looking for pointers to where to dig further.

no logs, no journal entries, nothing that would support any effective suggestions/assistance; so it provides no value to anyone who would qualify as remotely competent.

You seem to assume quite a lot 'missing logs'. What you then mean by 'effective assistance' alludes me, especially given the inquisitive nature of my post:
I open with a question to which I cannot, without posting, know the answer to (is it just me/this system, are there others). What follows is an admittedly not very well versed nor technical description of what happened, however it should be quite clear 'to anyone who would qualify as remotely competent' that something is either working as intended or not(I suspect the latter).

Now from the nature of the problem and as Zucca immediately pointed out, systemd was in 'some way' involved. I only today got back to my machine to check up on this thread and obviously to update it if required. The two days worth delay should have given the post enough exposure to answer my initial post's primary question(no replies is also a valid response), however thanks to your, in my opinion, rather overzealous modding, I now cannot be certain of this...
So in the future, please continue to interfere in the workings of this forum behest your personal opinions about what qualifies as having 'value' even before the issues at hand can be explored any further.

dice · 2015-08-16 16:25:37

I don't see a reason to feel attacked personally when one's thread gets moved to NC. This actually does NOT mean you are a noob. In my opinion it is not that much important in which sub forum a thread is as long as people read it.

To your problem: the journal messages created during your observation would certainly help to figure out what was going on and in what order.

Trilby · 2015-08-16 16:31:13

(edit: thanks for getting back on course)

Last edited by Trilby (2015-08-20 22:03:30)

Alad · 2015-08-16 16:33:21

As said above, please focus on the issue at hand instead of making long debates on semantics.

Desktop environments add a few abstractions to the suspend/shutdown process. Also, don't assume arbitrary aliases like `suspend` actually exist. So, run:

 # systemctl suspend
 # systemctl poweroff

from within a simple window manager (like i3) and see what happens (as in again, journalctl logs).

Last edited by Alad (2015-08-16 16:36:55)

hungerfish · 2015-08-17 09:22:38

So I did some more testing. After posting last I was able to kind of 'reproduce' the issue, more specifically I found that 'systemctl suspend' just did nothing and even more suspiciously 'systemctl poweroff' though it did bring down all services and unmount the filesystems it failed to actually 'poweroff' the pc, which it normally always does just fine. (See last listing below)
I then tried again, this time without running a display-manager (lightdm) and just with a root tty login. Both suspend and poweroff worked just fine. The same when logged in as user via tty and then running MATE via startx.
So I thought lightdm to be the culprit, but to my dismay, after yet another reboot and a re-enabled lightdm, both suspend and poweroff worked fine

Now for you log-craving types
( I know they are quite long, tried trimming them as much I could).

I suspect some kind of permission problem to be causing the odd behaviour, but I don't yet know what causes it and apparently only 'sometimes'.
From the boot with failed suspend/poweroff:

Aug 16 10:10:54 BrilliantBert systemd[1]: Failed to start Verify integrity of password and group files.
Aug 16 10:10:54 BrilliantBert systemd[1]: shadow.service: Unit entered failed state.
Aug 16 10:10:54 BrilliantBert systemd[1]: shadow.service: Failed with result 'exit-code'.
...
Aug 16 10:11:02 BrilliantBert lightdm[810]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
...
Aug 16 10:11:12 BrilliantBert login[606]: pam_tally(login:auth): pam_get_uid; no such user
Aug 16 10:11:12 BrilliantBert lightdm[810]: pam_unix(lightdm-greeter:session): session closed for user lightdm
Aug 16 10:11:12 BrilliantBert lightdm[852]: pam_unix(lightdm:session): session opened for user wot by (uid=0)
...
Aug 16 10:11:28 BrilliantBert systemd[1]: Startup finished in 4.260s (kernel) + 44.045s (userspace) = 1min 4.588s.
...
Aug 16 10:28:51 BrilliantBert login[1695]: pam_tally(login:auth): pam_get_uid; no such user
Aug 16 10:29:03 BrilliantBert login[1695]: pam_unix(login:auth): check pass; user unknown
Aug 16 10:29:03 BrilliantBert login[1695]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost=
Aug 16 10:29:05 BrilliantBert login[1695]: FAILED LOGIN 3 FROM tty1 FOR :q, Authentication failure
Aug 16 10:29:17 BrilliantBert systemd[1]: getty@tty1.service: Service has no hold-off time, scheduling restart.
Aug 16 10:29:17 BrilliantBert systemd[1]: Stopped Getty on tty1.
Aug 16 10:29:17 BrilliantBert systemd[1]: Started Getty on tty1.
Aug 16 10:30:10 BrilliantBert agetty[1735]: checkname failed: Operation not permitted
...
Aug 16 16:23:09 BrilliantBert systemd[1]: Reached target Sleep.
Aug 16 16:23:09 BrilliantBert systemd[1]: Starting Suspend...
Aug 16 16:23:09 BrilliantBert systemd-sleep[2531]: Suspending system...
Aug 16 16:23:09 BrilliantBert kernel: PM: Syncing filesystems ... done.
Aug 16 16:23:09 BrilliantBert kernel: PM: Preparing system for mem sleep

That block with 'pam_tally' got repeated a dozen times and from the 'contents' of FOR (here :q - I use vim) I can summarize that something was leaking everything I typed to tty1 and the system was trying to log in with basically random strings as usernames!! I was running MATE, never even switched to tty1! This continues even after the last block about reaching sleep target which seems incomplete when compared to the second listing below.

Continued, here I log out, and back in via lightdm all the while 'things are going on':

Aug 16 16:28:58 BrilliantBert lightdm[852]: pam_unix(lightdm:session): session closed for user wot
...
Aug 16 16:28:59 BrilliantBert lightdm[2659]: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
Aug 16 16:28:59 BrilliantBert systemd-logind[577]: New session c3 of user lightdm.
Aug 16 16:28:59 BrilliantBert systemd[1]: Started Session c3 of user lightdm.
Aug 16 16:29:01 BrilliantBert systemd-logind[577]: Removed session c1.
Aug 16 16:29:01 BrilliantBert systemd-logind[577]: Removed session c2.
Aug 16 16:29:01 BrilliantBert systemd[1]: Stopping User Manager for UID 1000...
Aug 16 16:29:01 BrilliantBert systemd[1107]: Stopped target Default.
Aug 16 16:29:01 BrilliantBert systemd[1107]: Reached target Shutdown.
Aug 16 16:29:01 BrilliantBert systemd[1107]: Starting Exit the Session...
Aug 16 16:29:01 BrilliantBert systemd[1107]: Stopped target Basic System.
Aug 16 16:29:01 BrilliantBert systemd[1107]: Stopped target Timers.
Aug 16 16:29:01 BrilliantBert systemd[1107]: Stopped target Sockets.
Aug 16 16:29:01 BrilliantBert systemd[1107]: Stopped target Paths.
Aug 16 16:29:01 BrilliantBert systemd[1107]: Received SIGRTMIN+24 from PID 2686 (kill).
Aug 16 16:29:01 BrilliantBert systemd[1108]: pam_unix(systemd-user:session): session closed for user wot
Aug 16 16:29:01 BrilliantBert systemd[1]: Stopped User Manager for UID 1000.
Aug 16 16:29:01 BrilliantBert systemd[1]: Removed slice user-1000.slice.
...
Aug 16 16:29:04 BrilliantBert lightdm[2659]: pam_unix(lightdm-greeter:session): session closed for user lightdm
Aug 16 16:29:04 BrilliantBert lightdm[2683]: pam_unix(lightdm:session): session opened for user wot by (uid=0)
...
Aug 16 16:29:04 BrilliantBert systemd[1]: Created slice user-1000.slice.
Aug 16 16:29:04 BrilliantBert systemd[1]: Starting User Manager for UID 1000...
Aug 16 16:29:04 BrilliantBert systemd[2694]: user@1000.service: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory
Aug 16 16:29:04 BrilliantBert systemd-logind[577]: New session c4 of user wot.
Aug 16 16:29:04 BrilliantBert systemd[1]: Started User Manager for UID 1000.
Aug 16 16:29:04 BrilliantBert systemd[1]: Started Session c4 of user wot.

Finally I've had enough and want to reboot, which MATE wont let me, so I log in as root on tty2 and poweroff.

Aug 16 16:55:59 BrilliantBert mate-session[2695]: WARNING: Unable to restart system: There's already a shutdown or sleep operation in progress
Aug 16 16:56:54 BrilliantBert login[3319]: ROOT LOGIN ON tty2
Aug 16 17:00:40 BrilliantBert login[3319]: pam_unix(login:session): session closed for user root
Aug 16 17:00:40 BrilliantBert login[3319]: pam_systemd(login:session): Failed to release session: Interrupted system cal
...
Aug 16 17:00:41 BrilliantBert systemd[1]: Shutting down.
Aug 16 17:00:41 BrilliantBert systemd[1]: Hardware watchdog 'SP5100 TCO timer', version 0
Aug 16 17:00:41 BrilliantBert systemd[1]: Set hardware watchdog to 10min.
Aug 16 17:00:41 BrilliantBert kernel: sp5100_tco: Unexpected close, not stopping watchdog!

After all this the system remained powered as mentioned above. Now for comparison, from the log of the 'clean' boot->tty:

...
Aug 16 17:03:18 BrilliantBert systemd-logind[580]: New seat seat0.
Aug 16 17:03:18 BrilliantBert systemd[1]: Started Getty on tty1.
Aug 16 17:03:18 BrilliantBert systemd[1]: Reached target Login Prompts.
Aug 16 17:03:18 BrilliantBert systemd[1]: Started Login Service.
...
Aug 16 17:03:19 BrilliantBert systemd[1]: Startup finished in 5.594s (kernel) + 7.864s (userspace) = 38.719s.
...
Aug 16 17:03:31 BrilliantBert login[646]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Aug 16 17:03:31 BrilliantBert systemd[1]: Created slice user-0.slice.
Aug 16 17:03:31 BrilliantBert systemd[1]: Starting User Manager for UID 0...
Aug 16 17:03:31 BrilliantBert systemd-logind[580]: New session c1 of user root.
...
Aug 16 17:03:31 BrilliantBert systemd[800]: Startup finished in 17ms.
Aug 16 17:03:31 BrilliantBert systemd[1]: Started User Manager for UID 0.
Aug 16 17:03:31 BrilliantBert login[646]: ROOT LOGIN ON tty1
...
Aug 16 17:09:37 BrilliantBert systemd[1]: Reached target Sleep.
Aug 16 17:09:37 BrilliantBert systemd[1]: Starting Suspend...
Aug 16 17:09:37 BrilliantBert systemd-sleep[951]: Suspending system...
...
Aug 16 17:09:37 BrilliantBert kernel: PM: Syncing filesystems ... done.
Aug 16 17:09:37 BrilliantBert kernel: PM: Preparing system for mem sleep
Aug 16 17:09:53 BrilliantBert kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Aug 16 17:09:53 BrilliantBert kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Aug 16 17:09:53 BrilliantBert kernel: PM: Entering mem sleep
...
Aug 16 17:09:53 BrilliantBert kernel: ACPI: Preparing to enter system sleep state S3

And the resume followed by poweroff:

Aug 16 17:09:53 BrilliantBert kernel: ACPI: Low-level resume complete
...
Aug 16 17:09:53 BrilliantBert kernel: PM: resume of devices complete after 1918.257 msecs
Aug 16 17:09:53 BrilliantBert kernel: PM: Finishing wakeup.
Aug 16 17:09:53 BrilliantBert kernel: Restarting tasks ... done.
...
Aug 16 17:09:53 BrilliantBert systemd-sleep[951]: System resumed.
...
Aug 16 17:12:58 BrilliantBert systemd[800]: Reached target Shutdown.
...
Aug 16 17:12:58 BrilliantBert systemd-logind[580]: Failed to abandon session scope: Transport endpoint is not connected
...
Aug 16 17:12:59 BrilliantBert systemd[1]: Shutting down.
Aug 16 17:13:00 BrilliantBert systemd[1]: Hardware watchdog 'SP5100 TCO timer', version 0
Aug 16 17:13:00 BrilliantBert systemd[1]: Set hardware watchdog to 10min.
Aug 16 17:13:00 BrilliantBert kernel: sp5100_tco: Unexpected close, not stopping watchdog!
Aug 16 17:13:00 BrilliantBert systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Aug 16 17:13:00 BrilliantBert systemd-journal[267]: Journal stopped

So I obviously have a problem, at the same time I know that my system 'can' work just fine. I just double-checked and my current boot log compares nicely to the above 'clean-tty-boot' even though I'm using lightdm+mate.
So the question becomes, what triggered the misbehaviour a couple of boots back?

Raynman · 2015-08-17 09:36:25

Well, that's weird. One thing I notice is that before the "no such user"/"user unknown" messages from pam, shadow.service failed. I don't see it in any of the other boots, but you might have edited it out. Can't hurt to check the password and group files, anyway.

hungerfish · 2015-08-17 10:46:02

I didn't edit it out, it is just plain absent in other boots. As such I suspect it being the 'root' of all the other problems encountered during that run.
running 'pwck:

user 'ftp': directory '/srv/ftp' does not exist
user 'http': directory '/srv/http' does not exist
pwck: no changes

dice · 2015-08-17 12:21:12

I had problems with lightdm passing all key presses directly to the tty therefore trying to login with random garbage (see here). That is what is going on with your vim commands.
This also didn't occur always. But I can't say if it is related to the suspend/poweroff behaviour. Do those two problems always occur together on your system?

You could try to do this and see if it works.

Last edited by dice (2015-08-17 12:21:50)

hungerfish · 2015-08-17 13:02:29

This is from the log dating my initial post:

Aug 14 12:15:55 BrilliantBert pwck[625]: pwck: no changes
Aug 14 12:15:55 BrilliantBert systemd[1]: shadow.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Aug 14 12:15:55 BrilliantBert systemd[1]: Failed to start Verify integrity of password and group files.
Aug 14 12:15:55 BrilliantBert systemd[1]: shadow.service: Unit entered failed state.
Aug 14 12:15:55 BrilliantBert systemd[1]: shadow.service: Failed with result 'exit-code'.
...
Aug 14 12:17:24 BrilliantBert login[630]: pam_tally(login:auth): pam_get_uid; no such user
...
Aug 14 12:18:21 BrilliantBert login[630]: FAILED LOGIN 1 FROM tty1 FOR ITECHOEDMYPASSWORDRIGHTHERE, Authentication failure
Aug 14 12:18:23 BrilliantBert login[630]: pam_tally(login:auth): pam_get_uid; no such user
Aug 14 12:18:23 BrilliantBert sudo[4941]:      wot : TTY=pts/0 ; PWD=/home/wot ; USER=root ; COMMAND=/usr/bin/pacman -Syu
...
Aug 14 12:21:54 BrilliantBert login[5206]: FAILED LOGIN 1 FROM tty1 FOR sudo chmod +x, Authentication failure

I must have blindly read past them at first glance, so yes, it seems that both are connected. Weird though how this doesn't always seem to happen.
Did you by any chance experience random switches back to a tty whilst using lightdm? I never thought much of it before, but now this is beginning to paint a picture and its pretty bleak.
Note, that in the log-snip posted I redacted my actual password, but this is a potentially huge security problem!!!
How the hell is this even possible, that input going through X11 into xterm ends up on the tty?
I will keep lightdm disabled as its obviously broken in someway and see if the problem still creeps up..

Zucca · 2015-08-18 19:32:26

hungerfish wrote:

How the hell is this even possible, that input going through X11 into xterm ends up on the tty?
I will keep lightdm disabled as its obviously broken in someway and see if the problem still creeps up..

WOW! That might explain why I had some strange problems when trying to suspend/hibernate.
I'll change my DM asap. Anyone to suggest a replacement? I want simple and light.

dice · 2015-08-18 22:33:34

There is new version of lightdm in the repos since yesterday. Does it solve the problem?

Jeffska · 2015-08-20 21:58:56

Any more progress on this? I'm having the exact same symptoms (sleep doesn't work, subsequent poweroff goes to suspend, waking shuts down immediately). Not sure it has anything to do with lightdm since I'm using gdm. I'll do some comparisons w/ your logs as well.

Awebb · 2015-08-20 23:07:49

Have we already determined, where the binaries come from, with which {poweroff,suspend}?

Jeffska · 2015-08-21 03:39:28

One other thing I found was that restarting the systemd-suspend service while it was in it's "stuck" sleep attempt did allow the machine to suspend and returns it to normal behavior.

hungerfish · 2015-08-21 08:13:53

So, I've sadly not been able to test this more due to contracting some (stomach)bug...I'm feeling better again today, so maybe later.
Are you also seeing these strange login attempts on the tty in your logs? And also the probable cause, the 'corrupted passwd/shadow' entry?
Until now, I'm only assuming this is related to the shutdown/suspend problem, because I only have said problem when I have those log entries.
Do your shutdown/suspend problems occur on every boot?

@Awebb I was indeed referring to 'systemclt suspend/poweroff'.

Awebb · 2015-08-21 08:35:58

dice wrote:

There is new version of lightdm in the repos since yesterday. Does it solve the problem?

Please also respond to this, hungerfish.

I have so far been unable to reproduce your problem, my laptop goes into S3 without a noticeable delay the moment I hit return on "systemctl standby" or press the sleep hotkey. I'll try LightDM next. I wouldn't be surprised, display managers have caused all sorts of quirks for me over the years.

EDIT: I cannot reproduce the problem, even with LightDM+Mate.

Last edited by Awebb (2015-08-21 08:53:16)

hungerfish · 2015-08-21 09:05:34

No, I've also not yet tried with the new version, but as mentioned before, this doesn't seem to happen on every boot. I've yet to figure out what is actually the root-cause. I suspect that something non-lightdm related 'breaks', which in turn causes the observed behaviour. Before becoming sick myself, I intended to just run without lightdm/any-dm for a while to see if the problem reoccurs, and since I'm feeling better, this is what I will be doing next. Sorry for the delay.

EDIT:
So I just booted the system in question (lightdm being disabled) and I immediately saw

shadow.service - Verify integrity of password and group files

pwck complained about /srv/http & /srv/ftp directories missing, which are referenced in /etc/passwd for the ftp and http users. I've no clue if they are created by default, but as I recently cleared out the entire /srv directory I just recreated them, and after reboot (several in fact) the error has disappeared. So far so good. The question remains if this is even related...

Last edited by hungerfish (2015-08-21 09:34:18)

ayekat · 2015-08-21 09:31:59

journalctl | grep MYPASSWORDREDACTED

gives me some entries - but that's because sometimes my brain is taking a day off and I do things like typing my password in the username field (that doesn't add much help here, but at least it could explain the log entries).

hungerfish · 2015-08-21 09:36:53

If it were just the occasional password/username mismatch, I guess the solution would be easy
Sadly 'everything' was being echoed to tty, including my password!

dice · 2015-08-21 13:06:15

I didn't have the 'echoing to tty' anymore with the recent version of lightdm.
However it is still unclear if it is related to your suspend/poweroff issue.

Arch Linux

#1 2015-08-14 14:04:39

Suspend and Poweroff non exclusive??

#2 2015-08-14 17:19:15

Re: Suspend and Poweroff non exclusive??

#3 2015-08-14 19:22:42

Re: Suspend and Poweroff non exclusive??

#4 2015-08-16 08:34:25

Re: Suspend and Poweroff non exclusive??

#5 2015-08-16 08:58:28

Re: Suspend and Poweroff non exclusive??

#6 2015-08-16 14:22:29

Re: Suspend and Poweroff non exclusive??

#7 2015-08-16 16:25:37

Re: Suspend and Poweroff non exclusive??

#8 2015-08-16 16:31:13

Re: Suspend and Poweroff non exclusive??

#9 2015-08-16 16:33:21

Re: Suspend and Poweroff non exclusive??

#10 2015-08-17 09:22:38

Re: Suspend and Poweroff non exclusive??

#11 2015-08-17 09:36:25

Re: Suspend and Poweroff non exclusive??

#12 2015-08-17 10:46:02

Re: Suspend and Poweroff non exclusive??

#13 2015-08-17 12:21:12

Re: Suspend and Poweroff non exclusive??

#14 2015-08-17 13:02:29

Re: Suspend and Poweroff non exclusive??

#15 2015-08-18 19:32:26

Re: Suspend and Poweroff non exclusive??

#16 2015-08-18 22:33:34

Re: Suspend and Poweroff non exclusive??

#17 2015-08-20 21:58:56

Re: Suspend and Poweroff non exclusive??

#18 2015-08-20 23:07:49

Re: Suspend and Poweroff non exclusive??

#19 2015-08-21 03:39:28

Re: Suspend and Poweroff non exclusive??

#20 2015-08-21 08:13:53

Re: Suspend and Poweroff non exclusive??

#21 2015-08-21 08:35:58

Re: Suspend and Poweroff non exclusive??

#22 2015-08-21 09:05:34

Re: Suspend and Poweroff non exclusive??

#23 2015-08-21 09:31:59

Re: Suspend and Poweroff non exclusive??

#24 2015-08-21 09:36:53

Re: Suspend and Poweroff non exclusive??

#25 2015-08-21 13:06:15

Re: Suspend and Poweroff non exclusive??

Board footer