XMonad: dmenu not launching/spawning on startup - linux

Question

New to XMonad and loving it so far. I have a fairly vanilla / regular XMonad setup and am having problems with dmenu. When I login and hit mod+p nothing happens. If I then open a terminal and hit xmonad --restart then mod+p, dmenu will be working.
There must be something wrong with my xmonad.hs? I tried a no-customization setup of XMonad and things were working normally (i.e. dmenu was working after login).
My questions:
Is there something wrong with my xmonad.hs?
Why won't dmenu work unless I xmonad --restart ?
Could something fail in xmonad.start that would prevent dmenu from loading properly when starting xmonad?
Here are my files (borrowed from overthink). :
xmonad.hs
import System.IO
import XMonad
import XMonad.Hooks.DynamicLog
import XMonad.Hooks.ManageDocks
import XMonad.Hooks.SetWMName
import XMonad.Util.EZConfig(additionalKeys)
import XMonad.Util.Run(spawnPipe)
import XMonad.Hooks.ICCCMFocus
myWorkspaces = ["1", "2", "3", "4", "5", "6"]
myManageHook = composeAll
[ className =? "Gimp" --> doFloat
, className =? "Vncviewer" --> doFloat
]
main = do
xmproc <- spawnPipe "/usr/bin/xmobar /home/aaron/.xmobarrc"
xmonad $ defaultConfig { terminal = "urxvt" }
{ manageHook = manageDocks <+> manageHook defaultConfig
, startupHook = takeTopFocus >> setWMName "LG3D" -- fix for Java apps
, layoutHook = avoidStruts $ layoutHook defaultConfig
, logHook = dynamicLogWithPP xmobarPP
{ ppOutput = hPutStrLn xmproc
, ppTitle = xmobarColor "green" "" . shorten 50
}
, modMask = mod4Mask -- Rebind Mod to the Windows key
, workspaces = myWorkspaces
} `additionalKeys`
[ ((mod4Mask .|. shiftMask, xK_l), spawn "gnome-screensaver-command --lock") ]
xmonad.desktop
[Desktop Entry]
Encoding=UTF-8
Name=Xmonad-****
Comment=Ligthweight, pretentious tiling window manager
Exec=xmonad.start
Icon=xmonad.png
Type=XSession
xmonad.start
#!/bin/bash
xrdb -merge .Xresources
trayer --edge top --align right --SetDockType true --SetPartialStrut true --expand true --widthtype percent --width 10 --heighttype pixel --height 20 --transparent true --alpha 0 --tint 0x333333 &
# settings daemon is a prereq for some other gnome apps
gnome-settings-daemon &
# Network monitor (connections, vpns) applet in tray
if [ -x /usr/bin/nm-applet ] ; then
nm-applet --sm-disable &
fi
# volume indicator in tray
if [ -x /usr/bin/gnome-sound-applet ] ; then
gnome-sound-applet &
fi
eval $(gnome-keyring-daemon --start)
export GNOME_KEYRING_SOCKET
export GNOME_KEYRING_PID
#exec xmonad
dbus-launch --exit-with-session xmonad
Thanks for your help!

Answer 1

I have a vague feeling that when you first launch xmonad, it uses one executable+configuration, and then when you recompile, it finds the "right" one. In xmonad.desktop, try changing the Exec= line to include a full path to your xmonad.start.
Exec=/full/path/to/xmonad.start
Or you might try changing the last line in xmonad.start to include the full path to your xmonad executable.
dbus-launch --exit-with-session /full/path/to/xmonad
Another thing to try is changing the last two lines to:
exec xmonad
#dbus-launch --exit-with-session xmonad
If any of these options change the behaviour you're seeing, that might give us a clue.
EDIT: Let's try a different way of launching it, to see if we can learn anything. Don't start any window manager, log into a plain terminal instead. Type the command xinit -- xmonad or xinit -- /full/path/to/xmonad.
Alternatively, create the file .xinitrc with one line in it:
xmonad
Then type the command startx.
I also found this on the Xmonad FAQ, which may help:
2.6 not found errors or changes to xmonad.hs won't take effect
Ensure that ghc, and the xmonad executable are both in the environment
PATH from which you start X. Alternatively symlink them to locations
already in the PATH. ghc-pkg list should show ghc, xmonad, X11, etc.
without brackets, e.g. {xmonad} is bad. ghc-pkg check will tell you if
you have inconsistent dependencies or other registration problems.
The mod-q action calls the xmonad binary to recompile itself, so if
your display manager is starting it with /path/to/xmonad you'll also
have to edit your xmonad.hs mod-q binding to use the full path and
restart X (or in newer versions use 'xmonad --restart') to restart
xmonad with the new mod-q full path binding.

Answer 2

UPDATE:
The fix that seems to have solved the problem is changing:
exec xmonad
To:
touch ~/.xmonad/xmonad.hs
exec xmonad
in
/usr/local/bin/xmonad.start (or .xinitrc/.xsession if xmonad is started using startx)
OLD:
How about changing:
} `additionalKeys`
[ ((mod4Mask .|. shiftMask, xK_l), spawn "gnome-screensaver-command --lock") ]
To:
} `additionalKeys`
[ ((mod4Mask .|. shiftMask, xK_l), spawn "gnome-screensaver-command --lock")
, ((mod4Mask, xK_p), spawn "dmenu_run -b -nb black") ]
I had the same issue as you and it was because I had used something like:
((mod4Mask, xK_p), spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"")
which, for some reason, only works properly after a "xmonad --restart". Changing the binding to simply "dmenu-run" fixed the problem. In your case, though, it looks like you're missing the binding at all.