On Wed, Jan 24, 2018 at 8:14 PM, InvalidPath <invalid.path(a)gmail.com> wrote:
On Wed, Jan 24, 2018 at 7:55 PM, InvalidPath <invalid.path(a)gmail.com>
wrote:
>
>
> On Wed, Jan 24, 2018 at 7:54 PM, InvalidPath <invalid.path(a)gmail.com>
> wrote:
>
>>
>>
>> On Wed, Jan 24, 2018 at 7:48 PM, InvalidPath <invalid.path(a)gmail.com>
>> wrote:
>>
>>> Aaand this crap just happened again. Suspended for less than 4 hours
>>> and the damned thing shutdown at some point. Here's the related
journalctl
>>> entries..
>>>
>>>
>>>
>>> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.5343]
>>> manager: sleep requested (sleeping: no enabled: yes)
>>> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.5347]
>>> manager: sleeping...
>>> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.5368]
>>> device (wlp2s0): state change: activated -> deactivating (reason
'sleeping',
>>> internal state 'managed')
>>> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.5468]
>>> device (wlp2s0): state change: deactivating -> disconnected (reason '
>>> sleeping', internal state 'managed')
>>> Jan 24 14:24:40 Vostok NetworkManager[1354]: <info> [1516829080.6205]
>>> device (wlp2s0): state change: disconnected -> unmanaged (reason
'sleeping',
>>> internal state 'managed')
>>> Jan 24 14:24:41 Vostok systemd-sleep[30771]: Suspending system...
>>> Jan 24 14:24:54 Vostok kernel: ACPI: Preparing to enter system sleep
>>> state S3
>>> Jan 24 14:24:54 Vostok kernel: cache: parent cpu1 should not be sleeping
>>>
>>> Jan 24 14:24:54 Vostok kernel: cache: parent cpu2 should not be sleeping
>>>
>>> Jan 24 14:24:54 Vostok kernel: cache: parent cpu3 should not be sleeping
>>>
>>> Jan 24 14:24:54 Vostok kernel: cache: parent cpu4 should not be sleeping
>>>
>>> Jan 24 14:24:54 Vostok kernel: cache: parent cpu5 should not be sleeping
>>>
>>> Jan 24 14:24:54 Vostok kernel: cache: parent cpu6 should not be sleeping
>>>
>>> Jan 24 14:24:54 Vostok kernel: cache: parent cpu7 should not be sleeping
>>>
>>> Jan 24 14:24:54 Vostok kernel: ACPI: Waking up from system sleep state
>>> S3
>>> Jan 24 14:24:54 Vostok systemd-sleep[30771]: System resumed.
>>> Jan 24 14:24:54 Vostok systemd[1]: sleep.target: Unit not needed
>>> anymore. Stopping.
>>> Jan 24 14:24:54 Vostok systemd-logind[1313]: Operation 'sleep'
>>> finished.
>>> Jan 24 14:24:54 Vostok NetworkManager[1354]: <info> [1516829094.2648]
>>> manager: wake requested (sleeping: yes enabled: yes)
>>> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.3900]
>>> manager: sleep requested (sleeping: no enabled: yes)
>>> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.3907]
>>> manager: sleeping...
>>> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.3938]
>>> device (wlp2s0): state change: activated -> deactivating (reason
'sleeping',
>>> internal state 'managed')
>>> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.4077]
>>> device (wlp2s0): state change: deactivating -> disconnected (reason '
>>> sleeping', internal state 'managed')
>>> Jan 24 17:19:54 Vostok NetworkManager[1354]: <info> [1516839594.4957]
>>> device (wlp2s0): state change: disconnected -> unmanaged (reason
'sleeping',
>>> internal state 'managed')
>>> Jan 24 17:19:55 Vostok systemd-sleep[28758]: Suspending system...
>>>
>>>
>>>
>>> On Wed, Jan 24, 2018 at 6:33 PM, Wolfgang Pfeiffer <roto(a)gmx.net>
>>> wrote:
>>>
>>>> On Wed, 24 Jan 2018 22:22:59 +0100
>>>> Wolfgang Pfeiffer <roto(a)gmx.net> wrote:
>>>>
>>>> > Even better: reboot with X disabled (no idea how to do it)
>>>>
>>>> appending this to a kernel boot line should work:
>>>> systemd.unit=multi-user.target
>>>>
https://docs-old.fedoraproject.org/en-US/Fedora/19/html/Inst
>>>> allation_Guide/s1-grub-targets.html
>>>>
>>>> Good luck!
>>>> Wolfgang
>>>>
>>>> > and then same procedure as before: sleep, then wake up ....
>>>> _______________________________________________
>>>> users mailing list -- users(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
>>>>
>>>
>>>
>> Crap sorry, sorry I forgot to scroll to teh bottom.
>>
>>
>
> Anyway @wolfgang: So correct me if Im wrong but *GDM*.. that stuff is all
> related to Gnome yes?
>
Im not finding much in the way on the googles about the X11 error, but I
did disable kscreenlocker.
So since my log paste above I have suspended this guy two more times.. for
maybe 10 minutes then almost an hour respectively and both times the bloody
thing started up as a new boot. Each time I went to try sifting thru
journalctl again but got reather sidetracked on log entries that were
erronious or did not belong there.. i.e. Gnome pieces and parts. So A
minute ago I removed all of Gnome just to make sure nothing else might have
been affecting this suspend issue.