urfkilld use 100% cpu after resume

[Sergey]

 Ubuntu utopic, notebook Fujitsu-Siemens Amilo Pro 3505
Slow works after resume.
6185 root 20 0 35076 5220 4676 R 87,9 0,2 0:13.26 urfkilld
 6535 svs 20 0 6284 3684 2224 R 37,0 0,1 0:07.26 dbus-daemon
 6469 svs 20 0 7824 3912 3164 S 13,9 0,1 0:02.71 upstart
 6728 svs 20 0 469216 131052 98096 S 13,9 4,2 0:05.68 kded4

[Calin (calinuswork)]

This also happens on a Dell XPS developer edition laptop

[dbas (dbas)]

Happens to Dell Inspiron 17R SE (7720) as well

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniele Dellafiore (ildella)]

Confirm on Dell XPS Developer Edition, with Ubuntu 14.10. Never happened with older versions.

[Andrew Kennan (adkennan)]

Another Dell Inspiron 7720 here too.

[Calin (calinuswork)]

Confirm on Dell XPS Developer Edition, with Ubuntu 14.10. Never happened with older versions.

[Gary Trakhman (gary-trakhman)]

+1, Dell 7440 with 14.10, on mainline PPA kernel.

gary@gary-dell:~/$ uname -a
Linux gary-dell 3.18.0-031800rc2-generic #201410281737 SMP Tue Oct 28 21:38:57 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[Peter Wu (lekensteyn)]

Not sure why this was posted on the devkit-devel list. Anyway, please attach the backtrace of urfkilld when the buggy condition is triggered:

    sudo gdb -q -batch -ex bt -p $(pidof -s urfkilld)

Hopefully it will actually contain useful information, otherwise you need to rebuild the package with debugging symbols enabled.

[Sergey (svs1957)]

Executed after resume
sudo gdb -q -batch -ex bt -p $(pidof -s urfkilld)
[New LWP 8556]
[New LWP 8555]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
0xb76ecc7c in __kernel_vsyscall ()
#0 0xb76ecc7c in __kernel_vsyscall ()
#1 0xb725c228 in send () at ../sysdeps/unix/sysv/linux/i386/socket.S:95
#2 0xb7255c44 in __GI___vsyslog_chk (pri=<optimized out>, pri@entry=7, flag=flag@entry=1, fmt=fmt@entry=0xb772444a "%s%s", ap=ap@entry=0xbfcd40dc "ADr\267PW\034\270\001") at ../misc/syslog.c:279
#3 0xb7255e27 in __syslog_chk (pri=7, flag=1, fmt=0xb772444a "%s%s") at ../misc/syslog.c:129
#4 0xb771f957 in ?? ()
#5 0xb739ec29 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6 0xb739ee05 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7 0xb771a644 in ?? ()
#8 0xb73de8ee in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#9 0xb7397b13 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#10 0xb7397f29 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#11 0xb73982d9 in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0

[Sergey (svs1957)]

workaround
/etc/pm/sleep.d/urfkill
sudo /etc/init.d/urfkill restart
and visudo for /etc/init.d/urfkill
ALL ALL=NOPASSWD:/etc/init.d/urfkill

[flashingpumpkin (flashingpumpkin)]

Same issue with Dell XPS Developer Edition, Ubuntu 14.10:

```
[New LWP 627]
[New LWP 626]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f14b5001c23 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#0 0x00007f14b5001c23 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007f14b5001f6f in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f14b5ee7be3 in ?? ()
#3 0x00007f14b4ffab6d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007f14b4ffaf48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f14b4ffb272 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f14b5ee2451 in ?? ()
#7 0x00007f14b45dbec5 in __libc_start_main (main=0x7f14b5ee2090, argc=1, argv=0x7fff02ce9058, init=<optimised out>, fini=<optimised out>, rtld_fini=<optimised out>, stack_end=0x7fff02ce9048) at libc-start.c:287
#8 0x00007f14b5ee25e0 in ?? ()
```

[Marius B. Kotsbak (mariusko)]

I see this on my Dell precision M4800 after upgrade to 14.10.

[Alex Muntada (alex.muntada)]

I just tried to strace urfkilld and it loops all the time on this syscalls:

10945 read(3, "\2\0\0\0\0\0\0\0", 16) = 8
10945 write(3, "\1\0\0\0\0\0\0\0", 8) = 8
10945 read(11, 0x7f5bdff4bf60, 1024) = -1 ENODEV (No such device)
10945 write(3, "\1\0\0\0\0\0\0\0", 8) = 8
10945 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, events=POLLIN}], 3, 4294967295) = 2 ([{fd=3, revents=POLLIN}, {fd=11, revents=POLLIN|POLLERR|POLLHUP}])

These are the FD open for that PID:

$ sudo ls -l /proc/10945/fd
total 0
lrwx------ 1 root root 64 nov 20 15:39 0 -> /dev/null
lrwx------ 1 root root 64 nov 20 15:39 1 -> /dev/pts/3
lrwx------ 1 root root 64 nov 20 15:39 10 -> /dev/rfkill
lr-x------ 1 root root 64 nov 20 15:39 11 -> /dev/input/event4 (deleted)
lrwx------ 1 root root 64 nov 20 20:06 12 -> /dev/rfkill
lrwx------ 1 root root 64 nov 20 15:39 2 -> /dev/pts/3
lrwx------ 1 root root 64 nov 20 15:39 3 -> anon_inode:[eventfd]
lrwx------ 1 root root 64 nov 20 15:39 4 -> anon_inode:[eventfd]
lrwx------ 1 root root 64 nov 20 15:39 5 -> socket:[203561]
lrwx------ 1 root root 64 nov 20 15:39 6 -> socket:[203562]
lrwx------ 1 root root 64 nov 20 15:39 7 -> anon_inode:[eventfd]
lrwx------ 1 root root 64 nov 20 15:39 8 -> /dev/rfkill
lrwx------ 1 root root 64 nov 20 15:39 9 -> /dev/rfkill

Hope this helps!

[Calin (calinuswork)]

@Sergey (svs1957) can you elaborate on your workaround, the location of the files does not apply for ubuntu 14.10

[Mohamed Ragab (moragab)]

@Calin the following temporarily solves the issue after a suspend and resume on 14.10
sudo service urfkill restart

[Alex Muntada (alex.muntada)]

@Calin I can confirm that adding the following script as /etc/pm/sleep.d/urfkill and giving it exec permissions solved the problem for me:

#!/bin/sh
#
# urfkilld restart (LP#1385641)

[ -f /etc/init/urfkill.conf ] || exit 0

/usr/sbin/service urfkill restart

[Calin (calinuswork)]

@Alex will give it a try now, thanks.

[Calin (calinuswork)]

Looks like @Alex's workaround does the trick for me at least.

[Andrew Kennan (adkennan)]

@Alex, that works for me.

[Mohamed Ragab (moragab)]

@Alex, works for me as well

[Calin (calinuswork)]

I take that back, I still get the urfkill process running 100% on the CPU, admittedly is much rare now, but it still happens.

[dbas (dbas)]

@Alex, workaround solved it for me

[David Hoeffer (d-hoeffer)]

The workaround works for me (with Dell XPS Developer Edition).

Regarding what's actually happening, it looks like after suspend/resume the input device used by urfkill (in my case, /dev/input/event4) comes back with a different inode number, so that the file descriptor held by urfkill is invalid, as seen in Alex' /proc/<pid>/fd listing above as well. I assume the device driver deletes the file on suspend and recreates it on resume. Restarting urfkill makes it open the file during initialization, and consequently the file descriptor is valid and the issue does not occiur.

[David Hoeffer (d-hoeffer)]

In urf-input.c, there's a line
if (condition & G_IO_IN) {
which needs to be
if (condition & G_IO_IN & !(G_IO_ERR | G_IO_HUP)) {

This is because the actual condition passed to the function after suspend/resume and consequent new inode # for /dev/input/event4 is

(gdb) p condition
$2 = (G_IO_IN | G_IO_ERR | G_IO_HUP)

i.e. we're getting G_IO_IN and error conditions signalled at the same time. The simple fix above resolves the 100% CPU issue for me and urfkill still reacts correctly to messages like in http://blog.cyphermox.net/2014/01/call-for-testing-urfkill-getting-flight.html?showComment=1390402171662#c2157211606631495090 after resume.

I'd submit a patch if I knew how :)

[Mathieu Trudel-Lapierre (cyphermox)]

Great, thanks for figuring this out!

And yes, unfortunately urfkill still has a lot of rough edges, but that's why there was a call for testing.

I will add a patch for this case in the morning.

[Mathieu Trudel-Lapierre (cyphermox)]

Tagged this bitesize since it's a very straightforward fix; just requires the change specified in comment 24.

If someone's interested in getting to know how to do the patching for software like urfkill; a great starting point is here:
http://packaging.ubuntu.com/html/fixing-a-bug.html

I also did an IRC session about it a few years back: https://wiki.ubuntu.com/MeetingLogs/devweek1201/IncorporatingUpstreamChanges.

[Marius B. Kotsbak (mariusko)]

I would suggest starting with proposing the patch to the upstream source code here: https://github.com/lcp/urfkill/ (github pull request or a patch).

[Mathieu Trudel-Lapierre (cyphermox)]

We're not yet there, there needs to be further testing done, because making this changes makes the input handler stop working completely after resume.

[Mathieu Trudel-Lapierre (cyphermox)]

I've upload a copy of urfkill in my PPA for testing... Indeed I don't currently have a better solution, aside from disabling the input handler altogether on these systems -- unless it was to be reopened later, but this is a more involved change.

Please try https://launchpad.net/~mathieu-tl/+archive/ubuntu/ppa/+sourcepub/4626576/+listing-archive-extra if you're on vivid (the development release of Ubuntu), and see if this helps.

[Marius B. Kotsbak (mariusko)]

I used the copy package feature in Launchpad to get a backported version of the package for Utopic (14.10) published in my PPA here: https://launchpad.net/~mariusko/+archive/ubuntu/network-manager-bugfixes Will try to test it.

[Marius B. Kotsbak (mariusko)]

I have not experienced it after installing the fixed package after several sleep/wake cycles, so I guess it solves the problem.

[Yuan Yiyang (yuan3y)]

I applied the PPA in comment 30 on my system (XPS 13 L322X, ubuntu 14.10 utopic),
it solves the problem.
Can this be submitted to upstream source?

[Julia Palandri (julia-palandri)]

This has worked for me too! :D yay!
(XPS 13, running utopic)

[Jelle De Loecker (skerit)]

Works for me too, is still an issue on 15.04 though.

[victorhqc (victorhqc)]

This worked for me too! :) (XPS 13 using 14.10)

[Alex Muntada (alex.muntada)]

Still an issue in vivid with urfkill 0.6.0~20150318.103828.5539c0d.1-0ubuntu1, which seems newer than the one in comment #30.

Is there a newer version to try or should I fall back to my workaround restarting urfkilld after resuming meanwhile? I'm happy to help with the testing if you need it.

[Alex Muntada (alex.muntada)]

Sorry, I meant comment #29 instead.

[Nasreddine (nacer)]

I'm using Ubuntu 15.04 on Dell xps 13 dev edition, I tried to ally comment 16 solution, It works temporary.
I'm wondering if there is a final solution for the bug ?

[Alex Muntada (alex.muntada)]

The old workaround for pm-utils doesn't work anymore in vivid since pm-suspend is never run. Now systemd-sleep is used instead, so you'll have to put the following script in /lib/systemd/system-sleep/urfkill:

#!/bin/sh
#
# urfkilld restart (LP#1385641)

set -e

[ -f /etc/urfkill/urfkill.conf ] || exit 0

case $1 in
 post)
  echo "$0: restarting urfkill"
  /usr/sbin/service urfkill restart
  ;;
esac

[Nasreddine (nacer)]

@Alex Muntada,
It does not solve the problem in Ubuntu 15.04.
The process restart after resume.

[Alex Muntada (alex.muntada)]

@nacer I'm not sure I understand what you mean. The script I posted tells urfkill service to restart after resume to stop using too much CPU.

FWIW, restarting urfkill manually always fixed the CPU issue for me. The script only helps doing so after resume.

[Wren Turkal (wt-penguintechs-org)]

I just had this happen on 15.10.

[Warren Turkal (wt-b)]

This has been a problem for quite a while. What functionality would I lose by uninstalling urfkill?

[Peter Frandsen (pfrandsen)]

I can confirm this on 15.10 (Dell XPS developer edition). Makes the computer almost unusable and require it to be plugged in all the time. Makes me regret the upgrade from 15.04 :-(

[sanette (sanette-linux)]

same here after upgrade from kubuntu 15.04 to 15.10.

Dell XPS 13 too

[Andrea Cerisara (acerisara)]

Same here on a Dell XPS 13 with 15.10. Restarting urfkill solves the issue.

[eiro (eiro1980)]

Same after upgrade from Ubuntu 15.04 to 15.10. DELL INSPIRON N4050.

[Daniele Dellafiore (ildella)]

15.10 has this very frequently. With 15.04 was less frequent. I experience this all the time after resume but sometimes also after a fresh start.

[slash (slash-tux)]

The issue is still running.

[Karsten Rehberg (karsten-rehberg)]

Problem still exists on a Dell Inspiron 6500 after upgrading to 16.04.3 LTS.

The workaroundscript in /lib/systemd/system-sleep/urfkill works for me.

[Mike (mjd300)]

On Linux Mint have just encountered issue and confirmed is urfkill on 27/05/2018. Fan going nuts, cpmputer at a crawl, 'top' showed 100% CPU from urfkilld.

I suspected something was off for quite a while. I believe the this softwarealso led to a number of crashes and loss of unsaved data.

Whatever else happens, no software should be designed to hog resources like that. Productivity is the most important thing so why on earth is Linux still dependent on such poorly coded software?

This is exactly the type of thing that makes people run far away from Linux.

As urfkill is clearly not well built with the same issue since 2014, excuse my language but what did we lose if we uninstall this crap?