xmonad --restart doesn't seem to work

[GoogleCodeExporter]

What steps will reproduce the problem?
1. running xmonad --restart at the terminal apparently does nothing
2. hitting mod-q apparently does nothing
3.

What is the expected output? What do you see instead?
xmonad restarts and reruns my configuration startups etc.

What version of the product are you using? On what operating system?
darcs up to date version 0.12 on Ubuntu 14.04.  Logging directly into xmonad 
from the dm.

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".

No output.  Compiles without errors.

Please provide any additional information below.

If I exit to the dm and log back in, xmonad restarts without any problems.  It 
is only when I try to restart the running xmonad session that it seems to fail.

Original issue reported on code.google.com by tmartin....@gmail.com on 22 Jan 2015 at 1:43

Attachments:

• xmonad.hs

[GoogleCodeExporter]

For one, you are overriding the default mod-q. This override (a) relies on 
"xmonad --restart" and (b) will fail if any of the "pkill" commands fails, 
because they are chained together with "&&".

That said, I don't see where this is preventing the "restart" mechanism... 
unless you are perhaps running the compiled config executable directly; this 
does not process the --restart parameter, only the main executable does.

Original comment by allber...@gmail.com on 22 Jan 2015 at 2:19

[GoogleCodeExporter]

I'm aware of the override on mod-q, I put it in to make each restart work 
cleanly.  I should add that it was working fine and stopped working for reasons 
I can't fathom.  AFAIK, when I restart, the xmonad that is being run is the 
compiled version that cabal puts in ~/.cabal/bin/, which folder is in my path 
and contains the only xmonad binary.  I'm not running the xmonad-x86_64-linux 
compiled into ~/.xmonad/ explicitly, but typing xmonad --restart into a 
terminal, with no observable effect.

Original comment by tmartin....@gmail.com on 22 Jan 2015 at 4:46

[GoogleCodeExporter]

A little experimentation reveals something which, to me, is unexpected.  If I 
delete the copy of xmonad in ~/.cabal/bin/ and do a clean and install of my 
darcs xmonad, I get a new version of xmonad in the ...darcs/xmonad/dist 
subdirectory which is 4.8Mb in size.  The copy that reappears in ~/.cabal/bin/ 
is 2.7Mb in size.  I'd assumed that, as part of the installation, the same 
version of xmonad was being put into cabal's binary path.  What's happening?

TIA

Original comment by tmartin....@gmail.com on 22 Jan 2015 at 5:03

[GoogleCodeExporter]

cabal is running strip to reduce the executable size before putting it in bin.

Original comment by daniel.w...@gmail.com on 23 Jan 2015 at 5:02

[GoogleCodeExporter]

Thanks Daniel, at least I know that's not the issue.  I'm looking at main.hs 
and can only see a test for the --replace arg.  I see no explicit test for 
--restart.  The call to restart is present here...

handle e@ClientMessageEvent { ev_message_type = mt } = do
    a <- getAtom "XMONAD_RESTART"
    if (mt == a)
        then restart "xmonad" True
        else broadcastMessage e

but this is far beyond my capacity to follow.

Original comment by tmartin....@gmail.com on 23 Jan 2015 at 5:51

[GoogleCodeExporter]

In xmonad-0.11, Main.hs:47 contains the code to handle the --restart argument. 
It does little more than set the XMONAD_RESTART atom which the code you posted 
is watching for -- essentially a form of IPC -- which kicks off the (restart 
"xmonad" True) action.

Original comment by daniel.w...@gmail.com on 25 Jan 2015 at 10:17

[GoogleCodeExporter]

Thanks for clarifying the principle, Daniel.  I've downloaded the source for 
0.11 via cabal and could not find any other reference to XMONAD_RESTART in the 
source.  A comparison with the darcs version 0.12 I am running shows no 
significant difference AFAICS - looks mostly like a different way of hooking up 
C libraries, but I'm out of my depth to be sure.  The only other reference to 
args that I can see (after the check for the presence of --replace) are not 
tests for presence.

Original comment by tmartin....@gmail.com on 25 Jan 2015 at 11:23

[GoogleCodeExporter]

I don't really know what other pieces you're looking for, to be honest. Let's 
be clear about what's happening and see if you still think there's something 
missing.

Let's start the story when you log in. Your login manager starts up a process 
named xmonad, which notices that there's a configuration file named 
~/.xmonad/xmonad.hs. It builds ~/.xmonad/xmonad-arch-os, and straight away 
hands over all control to xmonad-arch-os, disappearing at the same time.

Now you come along and change xmonad.hs, then run (from your command line, say) 
xmonad --restart. So there are now two processes running: xmonad-arch-os, and 
xmonad --restart. The --restart process sets the XMONAD_RESTART atom and dies, 
leaving just one process. Then X tells xmonad-arch-os that the XMONAD_RESTART 
atom has been set; so the xmonad-arch-os process builds a fresh copy of the 
~/.xmonad/xmonad-arch-os file, then hands all control over to the *new* 
xmonad-arch-os, disappearing at the same time.

Does this architecture make sense? Do you now understand how the --restart 
argument is handled, and how the code reflects that handling? If so, where does 
that leave you in terms of understanding the behavior you see happening?

Original comment by daniel.w...@gmail.com on 29 Jan 2015 at 6:16

[GoogleCodeExporter]

I now understand how xmonad is meant to behave and it makes a lot more sense.  
Where it leaves me is with the possibility that there is something in my 
xmonad.hs that is preventing it from responding to XMONAD_RESTART.  I have 
absolutely no idea what that might be.  I've tried commenting out my override 
on mod-q but as expected it made no difference - if running xmonad --restart at 
the command line doesn't work then it's unlikely to work in xmonad-arch-os.

So I'm baffled by the fault, but better informed on how xmonad works.

Original comment by tmartin....@gmail.com on 29 Jan 2015 at 9:38

Attachments:

• xmonad.hs

[GoogleCodeExporter]

Hm. Is xmessage installed on your system?

xmonad checks to see if it can find itself in $PATH before restarting and puts 
up a message if it can't; also, if the exec() fails it continues running as is 
(without a message, I believe). But many recent Linux distributions don't 
install xmessage, and the replacements aren't quite compatible with the 
original.

Original comment by allber...@gmail.com on 29 Jan 2015 at 9:47

[GoogleCodeExporter]

Come to think of it, it might be instructive to attach to the running xmonad 
with strace in one terminal, and then run "xmonad --restart" in another and see 
what the trace shows.

Original comment by allber...@gmail.com on 29 Jan 2015 at 9:48

[GoogleCodeExporter]

Both conditions good.  xmobar is on the PATH and xmessage is installed.  I've 
attached the strace.  --resume argument list too long, perhaps?

tony@tony-HP:~$ echo $PATH
/home/tony/.cabal/bin:/home/tony/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u
sr/bin:/sbin:/bin:/usr/games:/usr/local/games
tony@tony-HP:~$ whereis xmessage
xmessage: /usr/bin/xmessage /usr/bin/X11/xmessage 
/usr/share/man/man1/xmessage.1.gz

Original comment by tmartin....@gmail.com on 29 Jan 2015 at 11:26

Attachments:

• trace_during_restart

[GoogleCodeExporter]

Right, that's a sign that the layout state is too complex to be successfully 
passed as a parameter to --resume (I think we have a bug open for this already 
but I'm not spotting it in a quick scan). We need to find a different way to 
pass the state around; using parameters or environment can trigger that 
failure, writing it to a file can introduce other complications.

Original comment by allber...@gmail.com on 29 Jan 2015 at 11:39

[GoogleCodeExporter]

Ah, so I probably broke it as my xmonad.hs became increasingly complex.  I 
guess I will just have to log out and in again until another way of passing the 
parameters has been implemented.  How quickly do these things usually move?

Thanks all for helping me understand the problem.  It may not be solved but 
I've learned a lot along the way.

Original comment by tmartin....@gmail.com on 30 Jan 2015 at 6:22