Comment # 14 on bug 1137748 from Hubert Mantel

(In reply to Franck Bui from comment #13)
> (In reply to Hubert Mantel from comment #12)
> > I think we might see multiple issues here. Shutting down taking several
> > minutes sounds like a systemd issue to me. I know that several other people
> > also observed this.
> 
> Again I don't see how you came to this conclusion. In fact systemd is not
> involved at all when the actual suspend process starts, only the kernel is.

I still can press ESC and see messages "Target shutdown reached". Michael
Calmer did some debugging on this and found some KDE process that would not
exit. So finally after some minutes it seems this process gets killed and
power-off finally works. But I admit that I'm somewhat biased when it comes to
systemd :)

> > Not powering off the system via suspend to RAM might be a kernel issue.
> > 
> > The network being non-functional after suspend from hibernate I do not know.
> > And even after restarting the network manually after resume leads to virtual
> > machines no longer being reachable.
> 
> Unless you're using systemd-networkd, which I doubt, your network is most
> likely managed by either wicked or NM.

Please note that I do not know whether this is a regression! I never used
hibernate before. Only after suspend-to-RAM got broken with the upgrade to 15.1
I tried it as a workaround. I added another disk (did not have a swap partition
of sufficient size) and was quite happy to see that the system immediately
powered off successfully! Also resume is of acceptable size, but the shutdown
network makes this feature  almost unusable for me :(

> > I'm suspending the system by simply clicking on the mini applet in the lower
> > right corner of the task bar in KDE.
> 
> Can you try to suspend your system with ?
> 
>   # echo -n mem >/sys/power/state

Ok, will give this a try in the evening. Do not want to do that remote as I
could not judge whether it's successful :)