Poor responsiveness; slow window opening

There’s something weird happening, but it is hard to pin down.

I’m using a script “ff” to start firefox at the command line. The script does, roughly

some bookeeping stuff

firefox & #start firefox in background


If I enter the command:


then it takes 7 seconds before the firefox window shows up.

If, however, I use the command

ff; ls

then the firefox window shows up in less than 2 seconds.

This seems totally weird. There’s no good reason that I can see for this timing difference.

When I next reboot, I’ll try the older kernel to see if the same thing still happens with that.

Not seeing this issue here – Desktop – AMD CPU and Graphics – SSD system disk – KDE Plasma 5 GUI …

  • Kernel: 4.12.14-lp150.12.25-default
  • Having the script call ‘firefox &’ or ‘/usr/bin/firefox &’ also doesn’t seem to make any difference.
  • “ff; ls” also doesn’t seem to be different …
  • First line of the script is: “#!/bin/bash” …
  • This Firefox was running while testing – I’ll quit out of the Forum and try again …

Back again.
Not having an existing Firefox session running doesn’t seem to make any difference in the start-up time – regardless of “firefox” or “/usr/bin/firefox” it starts in less than a second …

But, the following warnings were logged in the Konsole window – the last 2 when the Firefox window was closed:

(firefox:32045): Gtk-WARNING **: Theme parsing error: <data>:1:34: Expected ')' in color definition

(firefox:32045): Gtk-WARNING **: Theme parsing error: <data>:1:77: Expected ')' in color definition

[Parent 32259, Gecko_IOThread] WARNING: pipe error (57): Connection reset by peer: file /home/abuild/rpmbuild/BUILD/firefox-60.3.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Parent 32259, Gecko_IOThread] WARNING: pipe error (57): Connection reset by peer: file /home/abuild/rpmbuild/BUILD/firefox-60.3.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353

I have an Intel CPU here – Ivy bridge.

My normal “ff” script actually starts firefox using another program that backgrounds it and disconnects it from the terminal. So I don’t see any output, though I have redirected that to file which I rarely look at.

This time I tried it more directly;

firefox &

It took 10 seconds for the “firefox” window to show up. In the meantime, I could not use my terminal session (“xterm”). Anything that I typed did not show up.

After the “firefox” windows showed up, I closed that window.

A few seconds later, I got the error messages from firefox (which I ignored). Then I got a “Done”. And only after that “Done” was I again able to use the terminal to enter another command.

I then tried

firefox &; ls

This time, the “firefox” window opened in a second or two. But I still could not enter anything at the terminal.
Again, I closed the “firefox” window. After that, I saw some firefox error messages, and then “Done”. And only then could I again use the terminal.

Hmm. I normally “csh” as my shell. So I tried with “bash”. And I do not see any of those problems using “bash”. So I’m suspecting that there’s a problem with how “csh” talks to the latest kernel.

I’m actually wondering whether this is related to the “tty1 to tty6” thread.

Good find Neil. I’m using bash, so that might explain why my two laptops (running openSUSE Leap 15) are not impacted. The OP in that thread you refer to has been very “economical” with providing information to help nail down the issue IMO.

I have rechecked this with my laptop. And I see the same thing.

User shell is “/bin/csh”. Currently “firefox” is not running, though it has run recently:

firefox &

It takes 10 seconds or more for firefox to start. And even after closing firefox, I cannot type anything in the terminal window for several more seconds.

firefox &; ls

Here firefox starts in 2 seconds or less. However, I still cannot type anything in the terminal for several seconds.

If I change to using “/bin/bash” as shell, then everything behaves normally. Firefox starts in 2 seconds or less, and I can immediately enter new commands in that terminal.

This is all using kernel 4.12.14-lp150.12.25-default.

If I reboot to kernel 4.12.14-lp150.12.22-default
then everything works correctly with “/bin/csh” as shell.

I’m about to open a bug report on this, which I will report as a kernel problem. And I’ll mention the “tty1 to tty6” thread as an example of another, possibly related, kernel issue.

I have reported this as
Bug 1116781 Kernel 4.12.14-lp150.12.25 and csh problems

I should add that I have been noticing this for a week or so. But I was unsure what I was seeing at first. Now that I know how to reproduce the problem, it was appropriate to report as a bug.

Thanks for helping progress this with a bug report Neil.