2

I'm running Arch Linux 64-bit on a Samsung RV511. I often connect external monitors using xrandr. As I run LXDE with Awesome as a window manager, I need to prepare the xrandr-command by killing certain GUI elements and restarting them afterwards to have them correctly positioned.

Here is my script:

#!/bin/sh
# kill conky and lxpanel
killall lxpanel
killall conky

# set monitor
xrandr --output LVDS1 --mode 1366x768 --pos 1680x282 --output VGA1 --mode  1680x1050 --pos 0x0 

# restart awesome
killall -HUP awesome

# restart lxpanel and conky
lxpanel -p LXDE &
conky &

Now I'm running into a strange problem. When I run all of the above commands in the same sequence from the command line, I get a neat monitor configuration. However, when I run the script, the GUI crashes, leaving a strange pattern of wallpaper and panel elements. I get the same problem if I launch the xrandr command without having killed the lxpanel first, which is why i assume the xrandr command somehow does not "wait" for the kill commands?

Or is there a different reason?

Edit: adding sleep 3 between the code blocks solved the problem, although I still have no idea what the basic problem is. Anyway, here is my current script for future reference:

#!/bin/bash

# kill conky and lxpanel
killall lxpanel
killall conky
sleep 4

# set monitor
xrandr --output LVDS1 --mode 1366x768 --pos 1680x282 --output VGA1 --mode  1680x1050 --pos 0x0 
sleep 4

# restart awesome
killall -HUP awesome

# restart lxpanel and conky
sleep 4
lxpanel -p LXDE &
conky &

Post-Edit: The problem cannot be considered completely solved after all. Sometimes I have to kill xinit after startup and startx again for it to work. There seems to be some uptime-related problem. Needless to say I have no idea what.

1

The first 4 commands should happen in sequence and the next should not run until the prior one has completed. Since you're backgrounding the last 2 commands I'd be tempted to insert a sleep statement there. Using a sleep in this fashion is a bit of a hack but would allow you to confirm your theory by playing with the amount of time to sleep. Since it's working in a interactive shell I wouldn't expect more than a sleep of maybe 5 or so to start.

lxpanel -p LXDE &
sleep 5
conky &

There are better methods such as waiting for some result to be returned from lxpanel which would mean that it's up, but I'm unfamiliar with lxpanel.

  • So, I messed around a bit with the sleep command. I needed to add it before and after xrandr and after the killall -HUP awesome command and set sleep to minimum 3 seconds for it to work. I also looked into wait, backgrounding all commands and appending a wait $!, which yielded the same problems as before. I'm still confused. Perhaps it's an awesome/lxde or driver related problem. – Levent B. Feb 11 '14 at 13:19
  • @LeventB. - Wait isn't going to work here most likely b/c this script is killing processes that aren't child processes to it, so that makes sense that it didn't work. I'm not sure why you'd need the sleeps after the killall's those shouldn't return until they're done, the one after the xrandr I can buy. – slm Feb 11 '14 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.