DynamicLog causes xmonad to hang when the output pipe is full

[GoogleCodeExporter]

When dynamicLog's output pipe becomes full xmonad hangs.  We should use
some sort of non-blocking IO to ensure that xmonad continues to run even if
a status bar program has crashed or wasn't started correctly.

Original issue reported on code.google.com by SpencerJ...@gmail.com on 19 Nov 2007 at 11:19

[GoogleCodeExporter]

This hasn't caused any real problems in the wild (as far as we know), so it is
probably not worth the trouble.

Original comment by SpencerJ...@gmail.com on 16 Mar 2008 at 7:56

• Changed state: WontFix

[GoogleCodeExporter]

I spoke too soon!  Lukas Mai sent a patch to ignore SIGPIPE, which seems to be
sufficient.

Original comment by SpencerJ...@gmail.com on 23 Mar 2008 at 4:19

• Changed state: Fixed

[GoogleCodeExporter]

can you add the patch to the bug?
I think I have the same issue.

Original comment by blufox on 13 Feb 2009 at 11:19

[GoogleCodeExporter]

http://article.gmane.org/gmane.comp.lang.haskell.xmonad/4931/match=sigpipe 
includes
that patch. Or just run darcs xmonad/xmonad-contrib! ;-)

Original comment by wirtwo...@gmail.com on 13 Feb 2009 at 11:42

[GoogleCodeExporter]

Hmm, unfortunately, looks like this needs to be re-opened.

Run either of these configs with latest darcs, or Config.Sjanssen, or 
anything that spawnPipes and hPutStrLn's to a status bar. Then kill the bar
and hold down mod-j till xmonad freezes. Asgaroth worked out can find pipe
fd via lsof, so to clear it to restart xmonad can use something like:

ls /proc/`pgrep xmonad`/fd/`lsof | grep xmonad | \
 egrep '[ur] *FIFO' |  sed -n 's/.*\([0-9]\)[ur].*/\1/ p'`

and cat the appropriate pipe.

import XMonad
import XMonad.Hooks.DynamicLog
{- 
import XMonad.Hooks.ManageDocks
import XMonad.Util.Run
import System.IO
main = do
  h <- spawnPipe "xmobar"
  xmonad $ defaultConfig
      { layoutHook = avoidStruts $ layoutHook defaultConfig
      , logHook = dynamicLogWithPP $ xmobarPP { ppOutput = hPutStrLn h }
      }
  -}      -- or equivalent plus kebinding--

main = xmonad =<< statusBar "xmobar" xmobarPP strutkey defaultConfig
  where strutkey (XConfig {modMask = modm}) = (modm, xK_b)

Original comment by wirtwo...@gmail.com on 16 Feb 2009 at 12:18

[GoogleCodeExporter]

Ugh, should have warned, if you're going to do this it's convenient to use a
workspace full of terminals in which you've already got pipe catting commands in
shell history, since mouse will no longer copy paste.

Also, after my response to the fedora 10 blog post a different xmonad user 
emailed me that this pipe issue had been extremely frustrating for him. Probably
our documentation and awareness of the issue is better at this point than when 
he
was looking for help, but my impression is it bites more people than we think.

Original comment by wirtwo...@gmail.com on 16 Feb 2009 at 12:29

[GoogleCodeExporter]

see also 
xmonad stops responding after running xscreensaver
http://code.google.com/p/xmonad/issues/detail?id=97

Original comment by wirtwo...@gmail.com on 2 Mar 2009 at 4:55

[GoogleCodeExporter]

From "The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 
Edition", execve:

  Signals set to the default action (SIG_DFL) in the calling process image shall be
  set to the default action in the new process image. Except for SIGCHLD, signals set
  to be ignored (SIG_IGN) by the calling process image shall be set to be ignored by
  the new process image. Signals set to be caught by the calling process image shall
  be set to the default action in the new process image (see <signal.h>).

Then SIGPIPE should be handled (and do nothing) instead of ignored. Ignored 
signals
are inherited by child processes which may break if they rely on the default
behaiviour of a SIGPIPE signal. Instead, handled signal are reset when exec is 
called.

Original comment by dnie...@gmail.com on 6 Nov 2009 at 4:27

[GoogleCodeExporter]

> Ignored signals are inherited by child processes which may break if they rely 
on
the default behaiviour of a SIGPIPE signal.

Has this caused problems for you?  I don't believe we've had any reports of 
issues
with inheriting SIGPIPE.  Regardless, I've pushed a patch to darcs xmonad that 
resets
this signal in processes fork()ed by xmonad.

Original comment by SpencerJ...@gmail.com on 6 Nov 2009 at 10:45

[GoogleCodeExporter]

Yes, I have some problems because of an application which is not checking for 
errors
returned by printf.

I'm using a bash script to process the output of this app and feed xmobar with 
the
result. It looks like:

app | ( while read;do
   # blah
   echo blah || exit # output is connected to a pipe read by xmobar. exit on error
done )

When xmobar is killed the pipeline is broken and the script should end. The 
right
side of the pipe handles the error when echoing and finnishes correctly. (I 
tried
with trap but it didn't work)

However, app keeps running forever as it cannot handle EPIPE errors.

I've been further investigating the issue and this is not only caused by 
xmonad's
handlers but also by ghc itself. See: 
http://hackage.haskell.org/trac/ghc/ticket/1619

I'm no sure what has to be done here. I think I should fix the application 
either by
reenabling SIGPIPE or properly handling EPIPE errors.

But this is specially problematic for shell scripts because when a 
non-interactive
shell is started while some signals have SIG_IGN as its handler the script 
cannot set
traps on those signals.

Original comment by dnie...@gmail.com on 6 Nov 2009 at 11:57

[GoogleCodeExporter]

I've been researching this bug for a long-ish time. It might be that the way 
EPIPE is
handled by xmonad or GHC has some relevance to this, but it's very likely not 
the
primary cause.

I've been rather exhaustively trying different combinations of EPIPE handlers in
xmonad (including not handling it at all, setting arbitrary handlers and using 
the
default handler), and nothing so far has affected the buggy behaviour that I'm 
able
to reproduce ~30% of the time with the config on comment 5.

One fairly sure sign that GHC itself has much to do with this, although I 
haven't
been able to replicate the behaviour outside xmonad, is that even setting a 
timeout
to each log write will still cause xmonad to hang.

I mentioned this in #haskell@freenode and it turns out people have experienced
similar issues with fdRead (assuming pipe writes are ultimately calling that, 
though
I haven't been able to follow the code to this point). In
http://upcycle.it/~blackh,/Server.hs, the issue with fdRead was fixed 
apparently by
adapting the code from ghc-6.12. Since this fixes the issue with fdRead, it 
seems it
may well be the case that just using GHC-6.12 would fix pipe writes as well (so
presumably fdWrite).

It seems the reason for this is that up to GHC-6.10, fdRead (and presumably 
fdWrite?
Haven't been able to verify this yet) were implemented using unsafe ccalls 
whereas
they now use safe ones. Following the discussion on #haskell, the unsafe ccalls 
might
then starve the threads of their process, which would be consistent with seeing
'timeout' not halting the IO writes.

Original comment by elias.ku...@gmail.com on 12 Nov 2009 at 9:52