initctl continuously takes 100% of CPU

After killing (kill -9, as kill-15 didn't have any effect) initctl, and rebooting the computer, initctl no longer shows up in the "top" command. Therefore, I cannot reproduce the issue on the same computer. Sorry for the noise!

The applications still are pretty slow to start: running libreoffice from a terminal results in more than 1 minute startup, with a freeze of my screen in the meantime (successive startup are fairly instantaneous though). Same for other applications: gnome-sudoku takes 5 seconds for the first startup, less than 1 for any following startup). I know this is not the place to report it, but how can I report this issue, as I don't know which package is involved?

Regards,

Cyril BUTTAY

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

Closing as invalid since the problem is not reproducible.

> The applications still are pretty slow to start: running libreoffice
> from a terminal results in more than 1 minute startup, with a
> freeze of my screen in the meantime (successive startup are fairly
> instantaneous though). Same for other applications:
> gnome-sudoku takes 5 seconds for the first startup, less than 1
> for any following startup). I know this is not the place to report
> it, but how can I report this issue, as I don't know which package
> is involved?

That doesn't sound like a package issue to me; it sounds like you just have a slow disk which it takes a long time to load data from.

I just had this on my 1 week old new laptop running Ubuntu 14.04.1. I ran "strace -s 128 -p <PID>" where PID was the pid of initctl, and the output looked like this (small excerpt only included):

poll([{fd=3, events=POLLIN}], 1, 4198964686) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964682) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964680) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964677) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964675) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964673) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964670) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964668) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964665) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964663) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964660) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964657) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964654) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964650) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964647) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964645) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964643) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964640) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964638) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964636) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964633) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964631) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 4198964628) = 1 ([{fd=3, revents=POLLIN}])

I looked in /proc/PID/fd, and it looked like this:

dr-x------ 2 root root 0 okt. 21 07:50 .
dr-xr-xr-x 9 root root 0 okt. 20 10:58 ..
lrwx------ 1 root root 64 okt. 21 07:50 0 -> /dev/null
lrwx------ 1 root root 64 okt. 21 07:50 1 -> /dev/pts/14
lrwx------ 1 root root 64 okt. 21 07:50 2 -> /dev/pts/14
lrwx------ 1 root root 64 okt. 21 07:50 3 -> socket:[10190]

I also ran "lsof | grep 10190", and the output looked like this:

initctl 1268 root 3u unix 0xffff8800d719d400 0t0 10190 socket

Not sure any of this helps, but that's what it is showing while using 100% cpu. My laptop is a Toshiba Portege Z30 with a dual core i7-4510U CPU. I'm running arch amd64.

any news? happens now often on Toshiba Tecra A50-A i7 - 14.04 64bits - kernel 3.17.0-rc7

I would also like to know if anyone has figured this out. I have a Toshiba Terca z50-A i7vPro 14.04 64Bit. It has this problem ever now and again.

Any update?

Same issue here, Ubuntu 14.04 64 bits on a Toshiba Portege Z30-A 18J, custom kernel 3.18.11 64 bits though. I suspect it has something to do with certain processes running on the system, such as perhaps Nautilus, but no hard evidence. The problem only occurs after a long uptime duration.
Strace gives the same result as #5 mentioned.

I confirm this issue on Ubuntu 14.04 64 bits after approx. 24 hours runtime.

Confirming for Ubuntu 15.10 64bit, HP Probook 4320s, after day-two uptime.

Can confirm this issue on Ubuntu 14.04 & 15.10 64bit, Toshiba Protege Z30, varying uptimes.

It's happening me to me in ubuntu 16.10 after a day of uptime maybe...

Happens on Ubuntu 16.10 (fresh install, Compiz fallback session) after a few hours of uptime.
htop reports 100% usage of one CPU for the command

/sbin/initctl emit indicator-services-start

which goes on indefinitely. Tracing (with only this initctl process around) yields similar to #5

$ sudo strace -p `pidof initctl`
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
[endless repeat]

/var/log/upstart is empty and dmesg/kern.log/syslog don't help.

The random battery drain is annoying (especially during presentations), and apt purging upstart depends on a little too much for comfort.

Suggestions?

Anyone found a fix or workaround for this problem? I have the same w/ Ubuntu 16.10

/sbin/initctl emit indicator-services-start

The initctl spinning out of control. This was NOT the case with the previous version 16.04 and it only started to happen with 16.10.

bump for #15. I am reporting the same issue on my machine.

bump
Having the same problem too with /sbin/initctl emit indicator-services-start

Any update on a fix to this problem?

My work around is to kill the initctl if/when I restart; I haven't noticed any adverse effect on anything I do on a daily basis and it is running more than 2+ weeks with no sign of initctl going crazy. Since I very rarely reboot (only after any updates and such), it is not a big deal for me now but would be nice to get a fix to this problem.

Not sure the following info helps but I am sure it will give some clue. I attached gdb and dumped the stack trace after a fresh reboot (i.e. when initctl is fine) as well as the same when it goes crazy to compare. Here are the two traces.

stack trace normal (siting in poll() normally)
==================
(gdb) where
#0 0x00007f00ff2ba0a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f00ff5ae78f in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#2 0x00007f00ff5ad3fe in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#3 0x00007f00ff596164 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#4 0x00007f00ff596c5c in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#5 0x0000559a959932c9 in ?? ()
#6 0x00007f00ff9e9ef0 in ?? () from /lib/x86_64-linux-gnu/libnih.so.1
#7 0x00007f00ff9ea513 in nih_command_parser () from /lib/x86_64-linux-gnu/libnih.so.1
#8 0x0000559a95990699 in ?? ()
#9 0x00007f00ff1de3f1 in __libc_start_main (main=0x559a95990620, argc=3,
    argv=0x7fff0ace82d8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fff0ace82c8) at ../csu/libc-start.c:291
#10 0x0000559a959906ea in ?? ()

stack trace w/ problem (appear to read something from FD 3 (a unix socket to upstart?)
======================
(gdb) where
#0 0x00007f7750af142d in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#1 0x00007f7750af5f41 in dbus_message_get_reply_serial () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#2 0x00007f7750aeb146 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#3 0x00007f7750aebc5c in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#4 0x0000557f7db2d2c9 in ?? ()
#5 0x00007f7750f3eef0 in ?? () from /lib/x86_64-linux-gnu/libnih.so.1
#6 0x00007f7750f3f513 in nih_command_parser () from /lib/x86_64-linux-gnu/libnih.so.1
#7 0x0000557f7db2a699 in ?? ()
#8 0x00007f77507333f1 in __libc_start_main (main=0x557f7db2a620, argc=3, argv=0x7fff51adf6d8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fff51adf6c8) at ../csu/libc-start.c:291
#9 0x0000557f7db2a6ea in ?? ()

@Arul, I found something similar in my comment above, at https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1173915/comments/5.

But it's been almost 4 years since this issue was reported, and over 2 years since I added my comment, and it's clearly not fixed yet, or even prioritised.

In fact, my general experience reporting Ubuntu issues here on launchpad is that this is a black hole, issues are left hanging until they are closed as irrelevant several years later. Critical issues undoubtedly get more attention, but issues such as this are still a problem. Annoying, so I don't really see the point in reporting issues here any more.

I have this same problem after a clean upgrade to 16.04 x64 with Intel i5-3570K on a Gigabyte Z77X-UD5H MB with 32 GB of memory. This never occurred on 14.04 on the same machine.

Same on fresh upgrade to 16.04 on Acer E1-531

This happens daily on my 14.04/64 bit

Just upgraded to 17.04 and this appears to be fixed i.e. I don't see the stupid 'initctl' running anymore!

I was bitten by this on 16.10

Realised that this was happening on a few 16.04 LTS machines I manage. It's one thing for me to kill the daemon periodically myself... and completely another to have annoyed users for months without being handled.

For now we settle with crontab -e
*/5 * * * * killall initctl

Killing initctl every 5 minutes looks really scary and it's hard to believe that this is the currently best solution.

@Arul: I'm still seeing it happen on 16.04. Upgrading to 17 isn't an option for some of us as we rely on third parties that don't support non-LTS releases (e.g., DSE Cassandra)
@Ketil: Couldn't agree more. Lower priority bugs are the red-headed stepchild on launchpad.

Have the same issue

 1504 root 20 0 103700 87464 1752 R 97.1 0.3 4525:02 initctl

> sudo strace -p `pidof initctl`
$ poll([{fd=3, events=POLLIN}], 1, 3729760780) = 1 ([{fd=3, revents=POLLIN}])

endless repeat...

This report is open since 2013 and I'm reporting in 2019. Is there any solution to this issue??

Thanks

Issue finally went away for me after upgrading to 18.04.3 LTS.