+++ This bug was initially created as a clone of Bug #1162809 +++

Description of problem:

I see an exception in tuned's log entries when I resume the laptop from hibernation

Version-Release number of selected component (if applicable):

2.4.1-1.fc20

How reproducible:

Just about every time I resume.

Steps to Reproduce:
1. tuned is active
2. hibernate
3. resume

Actual results:

Nov 11 08:58:47 gaspode tuned[941]: Exception in thread Thread-3:
Nov 11 08:58:47 gaspode tuned[941]: Traceback (most recent call last):
Nov 11 08:58:47 gaspode tuned[941]: File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
Nov 11 08:58:47 gaspode tuned[941]: self.run()
Nov 11 08:58:47 gaspode tuned[941]: File "/usr/lib/python2.7/site-packages/pyudev/monitor.py", line 402, in run
Nov 11 08:58:47 gaspode tuned[941]: for fd, _ in notifier.poll():
Nov 11 08:58:47 gaspode tuned[941]: IOError: [Errno 4] Interrupted system call


Expected results:

no exception.

Additional info:

I looked at tuned status while trying to troubleshoot bug 1161899 - suspecting that tuned somehow leaves/puts the SATA bus in a bad state upon resuming.  Is that possible?

--- Additional comment from Jaroslav Škarvada on 2014-11-21 11:39:45 CET ---

This is due to non-consistent behavior of python interpreter where some syscalls are restarted if interrupted and some aren't. I think this is something that we shouldn't try to workaround in libraries. There is already RHEL bug 1108921.

--- Additional comment from Jaroslav Škarvada on 2014-11-21 11:43:24 CET ---

(In reply to Dimitris from comment #0)
> I looked at tuned status while trying to troubleshoot bug 1161899 -
> suspecting that tuned somehow leaves/puts the SATA bus in a bad state upon
> resuming.  Is that possible?
>
Tuned uses kernel sysfs interface (and mostly only safe knobs), so it shouldn't be possible to put the SATA bus to bad state through it. I think this is very probably kernel (or firmware?) bug.

--- Additional comment from Fedora Admin XMLRPC Client on 2015-05-12 14:03:45 CEST ---

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

--- Additional comment from Fedora End Of Life on 2015-05-29 15:16:52 CEST ---

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Dimitris on 2015-05-30 22:29:12 CEST ---

Same under F21.

--- Additional comment from Théophane de Logivière on 2015-06-01 13:46:30 CEST ---

Hello,

I get the same exception after every SUSPEND action on Fedora Workstation 22
with last kernel 4.0.4-301.fc22.x86_64 and stock BALANCED profile activated.

Doing 'systemctl restart tuned' get it back on rails.

--- Additional comment from Jaroslav Škarvada on 2015-06-01 14:07:39 CEST ---

(In reply to Théophane de Logivière from comment #6)
> Hello,
> 
> I get the same exception after every SUSPEND action on Fedora Workstation 22
> with last kernel 4.0.4-301.fc22.x86_64 and stock BALANCED profile activated.
> 
> Doing 'systemctl restart tuned' get it back on rails.

"Interrupted system call" exception? It's Python bug 1108921. I am afraid it may take long to fix the bug in Python, so it could be worth workaround in Tuned.

--- Additional comment from Théophane de Logivière on 2015-06-01 17:08:13 CEST ---

(In reply to Jaroslav Škarvada from comment #7)
> (In reply to Théophane de Logivière from comment #6)
> > Hello,
> > 
> > I get the same exception after every SUSPEND action on Fedora Workstation 22
> > with last kernel 4.0.4-301.fc22.x86_64 and stock BALANCED profile activated.
> > 
> > Doing 'systemctl restart tuned' get it back on rails.
> 
> "Interrupted system call" exception? It's Python bug 1108921. I am afraid it
> may take long to fix the bug in Python, so it could be worth workaround in
> Tuned.

Exactly. Sadly, I'm not allowed to access to the bug report for my personal information but I effectively set up a workaround using systemd, to prevent the exception to be logged in journalctl. Maybe there is a better way ?

/etc/systemd/system/tuned_resume_workaround.service

[Unit]
Description=tuned sleep hook
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/systemctl stop tuned.service
ExecStop=/usr/bin/systemctl start tuned.service

[Install]
WantedBy=sleep.target

--- Additional comment from Jaroslav Škarvada on 2015-06-01 18:49:08 CEST ---

(In reply to Théophane de Logivière from comment #8)

This is really nice hack :)

But I will probably wrap the syscalls by restart handlers. This is the correct workaround for the underlying problem.

--- Additional comment from Jaroslav Škarvada on 2015-06-11 16:07:11 CEST ---

I cannot restart the syscall in Tuned, because it's happening in python-pyudev which spawns own thread, so I cannot catch the exception.

It's python 2 interpreter bug which will be hardly fixed upstream, thus I think it would be useful to have harmless workaround in python-pyudev. So cloning there.