You are not logged in.
Hi,
thought I share this small script, which I wrote for those applications that need both, X and an Internet connection.
In my case that is Dropbox (not connecting well if Internet is not up when starting), Skype (annoying me with an animated icon if not connected) and a Conky setup checking for Arch and TeXlive updates (makes no sense without Internet and just rechecks after an hour).
Proposals in similar topics (like https://bbs.archlinux.org/viewtopic.php?id=143152 or https://bbs.archlinux.org/viewtopic.php?id=120554) all had some problems for me:
Autostarting by .xinitrc, desktop environment or window manager: Exactly those problems – Dropbox not connecting, Skype waiting for connection and spinning, Conky not being able to check for updates
Autostarting, but checking Internet connection: Unnecessary rechecking even if I am not near any Internet connection, one-shot solution only, does not handle disconnections and reconnections during session
Starting/stopping by network management (e.g., /etc/wicd/scripts/): Not working if Internet is up before X is there, e.g., due to race condition on startup or manual starting X
So, I came up with the script below that contains everything to start and stop the corresponding applications (at least in my case, you would have to adopt it to your needs). Before starting, it checks if both, X and Internet, are there. I execute it with start argument at X startup (from ~/.config/openbox/autostart in my case) as well as at network connection (from a one-liner in /etc/wicd/scripts/postconnect/ in my case) and with stop argument at network disconnection (from a one-liner in /etc/wicd/scripts/predisconnect/ in my case). The script takes care of starting only one instance of all apps and only if X and Internet are available.
#!/bin/bash
# Script to manage applications that need both X and Internet access
#
# Problem:
# - X applications (e.g., tray apps) that also need access to Internet
# - Autostarted by X:
# not trying hard enough for upcoming network (e.g., Dropbox)
# or at least annoying (e.g., animated "trying to connect" of Skype)
# - Autostarted by network management (e.g., /etc/wicd/scripts):
# not started if X is coming up later than network (race condition or
# manual startx)
#
# Solution:
# - Script to start and stop all of these apps together
# - Tests for both, X and Internet, before starting, does nothing, otherwise
# - Appropriate method for all apps to test if (already/still) running to avoid
# duplicate instances and error messages
# - Side benefit: properly start apps with nohup and collect their output in
# /tmp/<name>.out
# - Invoked from X session autostart and network up and down, e.g.:
# "xnetapps start"
# in ~/.config/openbox/autostart
# "su -c 'DISPLAY=:0 /home/<user>/bin/xnetapps start' <user>"
# in script in /etc/wicd/scripts/postconnect/
# "su -c 'DISPLAY=:0 /home/<user>/bin/xnetapps stop' <user>"
# in script in /etc/wicd/scripts/predisconnect
#
# Caveats:
# - Just tests for running process with name "X", might not be accessible by
# the user (need to set DISPLAY or not at all on multi-user/server)
# - Just tests single HEAD query on "http://www.google.com/", might be false
# negative if Google is down or blocked (perhaps replace to liking)
# - Small race condition if two script instances test for running app at
# *exactly* the same time and then *both* try to start/stop it
# - ps/nohup/killall way to handle apps relies on process name (might change),
# /tmp/<name>.out not used otherwise (shamelessly overwritten) and only one
# instance on machine (killall kills all [sic!] of them)
#
# Requirements:
# - /usr/bin/bash from core/bash (base)
# - /usr/bin/ps from core/procps-ng (base)
# - /usr/bin/curl from core/curl (dependency of, i.a., pacman itself)
#
# Requirements for standard way to handle apps (like Dropbox and Skype below):
# - /use/bin/nohup from core/coreutils (base)
# - /usr/bin/killall from core/psmisc (base)
#
# Requirements specific to /these/ apps to start:
# - /usr/bin/dropboxd from aur/dropbox
# - /usr/bin/skype from mulitilib/skype
# - /usr/bin/conky from extra/conky
# - own "conkyctl" Python script
# Need full path, at least from /etc/wicd/scripts:
CONKYCTL="/home/sean/bin/conkyctl"
start_apps() {
# Start dropbox if it is not already running
[ "$(ps --no-headers -C dropbox)" ] || nohup dropboxd > /tmp/dropbox.out &
# Start skype if it is not already running
[ "$(ps --no-headers -C skype)" ] || nohup skype > /tmp/skype.out &
# Start conky if it is not already running
$CONKYCTL updates running || $CONKYCTL updates start
}
stop_apps() {
# Stop dropbox if it is running
[ "$(ps --no-headers -C dropbox)" ] && killall dropbox
# Stop skype if it is running
[ "$(ps --no-headers -C skype)" ] && killall skype
# Stop conky if it is running
$CONKYCTL updates running && $CONKYCTL updates stop
}
are_Net_and_X_up() {
# Check for process with name "X" and HEAD request on Google:
if [ "$(ps --no-headers -C X)" ] &&
curl --silent --head http://www.google.com/ > /dev/null; then
return 0
else
return 1
fi
}
# Very minimal initscript-like interface:
case "$1" in
start)
are_Net_and_X_up && start_apps
;;
stop)
stop_apps
;;
*)
echo "Usage: $0 [start|stop]"
exit 1
esac
Do you have any comments or see possibilities for improvement of this method?
PS: I don't know if this really fits in the "Community Contributions" section. Feels rather small compared to the rest, here. Do we have a section for How-Tos somewhere?
Last edited by HeptaSean (2013-08-26 23:21:09)
Offline
Two comments - first, why not just use a systemd service file with a "requires" line?
If you do go with the script, shouldn't it do something else in the start block if the net and X aren't up? Like a loop that rechecks every minute until they are, then runs the apps. Otherwise this will either just succeed or fail, so it wouldn't really serve much purpose.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Two comments - first, why not just use a systemd service file with a "requires" line?
Since I am starting X by startx (either manually or from .bash_profile), there is nothing for putting "We have a tray and a desktop for our apps" in the requires line.
If you are starting X and a display manager from systemd it could work, although I doubt it, since the display manager also has no possibility to display tray icons (and also wouldn't allow users to execute conky). Probably, it would be better to test not for X, but for the window manager in my script in those cases, though.
If you do go with the script, shouldn't it do something else in the start block if the net and X aren't up? Like a loop that rechecks every minute until they are, then runs the apps. Otherwise this will either just succeed or fail, so it wouldn't really serve much purpose.
It is the whole idea that it succeeds or fails and does not keep running indefinitely. If it fails due to X not being there (but network is there), it will again get executed by openbox' autostart and succeed then. If it fails due to Internet being down (but X is there), it will again get executed by wicd on connect and succeed then.
Put differently, the idea is not to sit there and stupidly retry at intervals (leaving the user to wait if interval is long, wasting resources – OK, not many, but still – if the interval is short), but only intelligently retrying whenever something changes that could make it succeed.
Hope that makes it a little clearer.
Offline
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Cool! Did not know that at all. Will have to look at it in more detail.
Offline
OK, after looking into this (in fact, switching to systemd --user):
How do I achieve the thing proposed in this thread by systemd?
There is no target that I could require for "Is the Internet up and running?".
Offline
You should be warned that if you are using systemd --user to start your X session, this setup will break whenever the newer versions of systemd hit [core]. You can hack around the limitations to get things kind of working, but it is not quite as seamlessly awesome as it was before.
Offline
You should be warned that if you are using systemd --user to start your X session, this setup will break whenever the newer versions of systemd hit [core]. You can hack around the limitations to get things kind of working, but it is not quite as seamlessly awesome as it was before.
Thanks! I just came around the https://bbs.archlinux.org/viewtopic.php?id=167115 thread myself.
So, I better rollback these changes.
Too bad, kind of liked them.
Offline
Oh, I loved "systemd --user" managing my X session. But if you want to still use systemd --user for other things, in systemd 206, if you just set the XDG_RUNTIME_DIR you can still pretty reliably start applications and such. It is just that getting logind to actually track your session takes quite a bit of hackery. XDG_RUNTIME_DIR is something that will eventually be set in the systemd --user stuff anyway, but for now it is not considered ready, so is therefore not fully set up.
Offline
Do you know if the changes are a "feature" or is it a regression which some later version may hopefully fix?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline