On 2018-06-23 07:31, David C. Rankin wrote:
On 06/22/2018 04:44 AM, Carlos E. R. wrote:
I'm going to suggest that was intentional. People hibernate (and/or suspend)machines mostly to travel, home to work, on the road, etc. Expecting the same connection to be available, and preferred upon resume seems a corner case rather than the normal case. The IP set (manually or via DHCP) should never be trusted upon a resume. You may have moved from one network to another. That is debatable. Many people use a laptop at home instead of a desktop machine, and the laptop is sitting permanently on a table in the sitting room, occasionally going somewhere. And it is normal to hibernate machines when not in use, some do so automatically after a period of not being used.
It is perfectly valid to verify if the conditions before are still valid after, and if they are, restore the connections, and if not, find new ones.
I tend to agree with Carlos here. If I put my laptop to sleep at home, I expect that it will come back up with the same connection it went to sleep with. I have multiple adapters configured as well. You don't see windows going to sleep connected to Wi-fi and then awaking connected to a non-plugged in wired connection...
While I see the logic in the John's reasoning, I haven't seen any threads that have gotten wide-spread review of dhcpcd spoofing on awakening from sleep.
It might try on wake up DHCP on a new network that requires a different type of DHCP with password, and if not the network emails the admin with "intruder alert". If the location is different it should ask, IMO.
If you are not coming back from sleep connected to the same connection -- that's a problem.
It kills the existing NFS connection, different IP...
There has always been a bit of lack of gracefulness in the way Linux apps handle the recovery from sleep that seem to have been solved long ago on the dark side. I have not done any specific coding regarding return from sleep, but I suspect there is a common framework in windoze that apps can call to determine the connection state on wake-up that doesn't have a Linux companion that app developers have made wide-spread use of. (I have no doubt there is a companion, but given the diversity in the origin of apps for Linux, there isn't any coordinated push for all apps to make use of it)
I don't think there is a common frame in Linux: When I return from hibernation, some daemons complain: <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18757 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18756 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18756 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18753 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18759 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18762 seconds <2.4> 2018-06-23 08:11:14 Telcontar dovecot - - - imap: Warning: Time jumped forwards 18772 seconds Obviously dovecot was not aware the machine hibernated. I would expect, for instance, a signal named "SIGNTHAW" and applications capturing it and handling the event graciously.
I'll have to do more testing, but the times I have put 42.3 to sleep, it has always come back up with the correct connection. (I generally just leave it idling due to the ssh connections I have open normally -- I have a konsole dcop script that restores all my tabs and automatically makes the connections to the list of hosts specified). I have 15 virtualized, but not on metal, so I haven't tested there.
It is working now here, but I had to define both wired connection (fixed and dhcp) as "use this connection if available", so both compete on restore and who wins? I hope the previous one. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)