A Momentary Lapse of Reason

What a better title to start such a blog?

I’m not a writer, and I guess I never will. Nobody will read me anyway.
Some clumsy written wandering hitherto forgotten as time passes.

It ain’t my goal that anybody read this. Nor do I seek any kind of recognition.
Certainly not! For in this very place I share for the ones I am made of.
I just whish these thoughts finally find a place to rest.

Conntrack table flood

Recently we had problems with our gateway, connections were dropped and so on.
After a bit of investigation we found that it was due to a bugged game using Javascript which, when it ran on Firefox, opened connections in a loop flooding the connection tracking table in a matter of hours. Once found, it was easy to fix. This was also the occasion to tighten the timeouts values of nf_conntrack a little bit. Indeed 5 days timeouts for established connection doesn’t really make sense when your public IPv4 change every 36hours or so.

Start XScreensaver before going to sleep

It seems rational to request XScreensaver to lock your screen when you suspend your machine. This is possible in Debian via the /etc/default/acpi-support file, especially with this line :

# Comment this out to disable screen locking on resume
LOCK_SCREEN=true

However for some obscure reason this will lock the screen (i.e. issue the “xscreensaver-command -lock” command) after suspend, that is on resume. Since the locking process is not immediate your desktop will be available for anyone to watch (and use) for a duration of about one or two second. There is no need to say that this is unacceptable.

It is possible to avoid that by disabling the default screen locking mechanism and hooking it manually to PM. So you should add a script into /etc/pm/sleep.d. The following script is the first version of the script I used (beware it doesn’t work, see below) :

#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop
# to be shown for a few seconds when the system resumes from sleep.

case "$1" in
  hibernate|suspend)
    xscreensaver-command -lock
    sleep 1 # annoying sleep
    ;;
  *)
    exit 0;;
esac

You may notice that the script issues a sleep just after the xscreensaver-command has returned. It ensures that the screen will be really locked when the system effectively enters into sleep. This is needed because the xscreensaver-command will not lock the screen immediately, that is it is non-blocking in a certain way and you cannot ensure that the screen is effectively locked as soon as the command has returned.

However the script above doesn’t work. As Marcus Moeller commented, the above script won’t work by default on Debian and probably with most other distributions. That is because we don’t issue the xscreensaver lock command as the user owning the xscreensaver daemon. I quote his solution here :

#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop
# to be shown for a few seconds when the system resumes from sleep.

IS_ACTIVE="$( pidof /usr/bin/xscreensaver )"

case "$1" in 
  hibernate|suspend) 
    # check if xscreensaver is running. if not, just skip on. 
    if [ -z "$IS_ACTIVE" ] 
      then : 
      else 
      # run the lock command as the user who owns xscreensaver process, 
      # and not as root, which won't work.
      su "$( ps aux | grep xscreensaver | grep -v grep | grep $IS_ACTIVE | awk '{print $1}' )" 
             -c "/usr/bin/xscreensaver-command -lock" &
      sleep 1
    fi
    ;;
  *)
    exit 0;;
esac

Digging in xscreensaver’s code shows that what the command actually needs is a connection to the X server. If xscreensaver-command cannot find the display from either command line or environment variables, it will fall back to “:0.0“. But this will fail if root cannot connect to the X server (which is generally the case). That’s how the ‘user approach’ fixes it. However this won’t work anymore if there are multiple instance of xscreensaver running on different displays (only one of them will be locked). Another solution would be to issue the command on each display where root can connect to. However this poses two problems :

  1. It is not as easy as it seems to reliably list all available displays. (see http://stackoverflow.com/questions/11367354/obtaining-list-of-all-xorg-displays).
  2. It requires that each lockable session allows connections from root with “xhost si:localuser:root“.
Here is the modification I posted in response which uses the ‘display approach’ instead:
#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop to be shown
# for a few seconds when the system resumes from sleep.

case "$1" in
  hibernate|suspend)
  # The X server may not be running
  if [ ! -d /tmp/.X11-unix ]
  then
    exit 0
  fi 

  # Lock each available display
  for socket in $(ls /tmp/.X11-unix)
  do
    display=$(echo "$socket" | tr "X" ":")
    xscreensaver-command -display "$display" -lock
  done

  sleep 1 # annoying sleep
  ;;
  *)
   exit 0;;
esac

However we are not done yet. As you can see we still rely on sleep to ensure that the screen is locked before our script returns control to the suspend procedure. With usage it became clear that one second was not sufficient as the script would return too early from time to time. Incrementing the duration of the sleep would be more than annoying and it doesn’t offer any real guarantee anyway. The only solution would be to find a way to exit the script when we are sure that the display is effectively locked. This is possible by watching at the changes of states of the screensaver while issuing the lock command. There is a slight last problem however. If multiple displays are present we want to issue that “lock ‘n watch” procedure in paralell to avoid accumulating the locking delays. That’s the solution I use in the script below, note that we don’t rely on sleep anymore:

#!/bin/sh
# XScreensaver should be called BEFORE going to sleep to avoid the desktop to be
# shown for a few seconds when the system resumes from sleep.
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

lock_display() (
  socket="$1"
  display=$(echo "$socket" | tr "X" ":")

  # Temporary pid file for the watching command
  tpid=$(mktemp)

  # Wait until the display is actually locked.
  (timeout 2s xscreensaver-command -display "$display" -watch & echo $! > $tpid) | (
    # Issue the lock command only when we know that
    # the watching pipe is ready.
    xscreensaver-command -display "$display" -lock

    while read line
    do
      line=$(echo $line | cut -d' ' -f 1)

      if [ "$line" = LOCK ]
      then
        # We have to kill the watching command manually before breaking.
        kill -TERM $(cat $tpid)
        break
      fi
    done
  )

  rm $tpid
)

case "$1" in
  hibernate|suspend)
    # The X server may not be running
    if [ ! -d /tmp/.X11-unix ]
    then
      exit 0
    fi

    # Lock each available display
    for socket in $(ls /tmp/.X11-unix)
    do
        # Lock the display
        lock_display $socket &
    done

    # Wait until every displays are locked
    wait
    ;;
  *)
    exit 0;;
esac

As stated above you still need to allow connections from root to your display. You may for example use this command when your session start :

xhost si:localuser:root

Or, as the man page of xhost states, use the file /etc/X*.hosts to do that globally.

Pidgin current song and Audacious

There are many plugins to change the current song within your Pidgin status (by Pidgin I mean libpurple in general) coupled with your favorite media player. In particular there are such plugins for Audacious (a modern and worthy descendant of the mighty XMMS, love it). Although I don’t use them since there is a much simplier way to do that. You may send the song directly from Audacious up to Pidgin with purple-remote. There is a plugin in Audacious to execute a command when the song change. Just add these :

New song command: purple-remote "setstatus?message=(8) %a - %T"
End of playlist : purple-remote "setstatus?message="
Title change : purple-remote "setstatus?message=(8) %T"

This will update your status message with your current song. The status will be emptied when the playlist is over. Note that this also works with plugins such as Pidgin-PBar.

GTranslate and Weboob

This is a quick interface to translation tools. In particular it was made to interface a specific tool from Weboob. For those who don’t know Weboob is a collection of applications able to interact with websites without a browser and mostly from command line interfaces. This allows GTranslate to use web translation services such as Google-Translate. However it can also be used with others translation tools as long as they offer a simple command-line way to translate a text from one language to another. It can also be easily adapted to any tool to provide an interactive conversion from one type to another. I made this tool to try out GTK-3 and GtkBuilder and actually building interfaces with Glade is really easier.

You may found the github page at http://github.com/gawen947/gtranslate.
And a small project page at http://www.hauweele.net/~gawen/gtranslate.html.

GTranslate

Speaking about Weboob I think this is a very good initiative because I’m getting a bit sick of these overpowered web-browsers outshining the application landscape. I mean we should tend toward a web of services but instead we just spend our time recoding everything we already had in JavaScript and shiny HTML5 interfaces. And I think, or rather hope that the future of web lies outside the browsers.

Default applications with GTK-3, Chromium and beyond

Today I was surprised to see a GTK-3 application opening an HTTP URL with Opera. I don’t use  Opera and I just installed by curiosity long ago and forgot about it.  I configured the Debian alternatives however GTK-3 seems to use xdg-mime as confirmed with an strace of the concerned application and references to /usr/share/applications/defaults.list. Note that you may have to create a symlink for defaults.list to /usr/share/applications/mimeapps.list.

You can use the xdg-mime command to configure the default application for each protocol:

$ xdg-mime default chromium.desktop x-scheme-handler/http
$ xdg-mime default chromium.desktop x-scheme-handler/https

You can also configure this manually by editing /usr/share/applications/defaults.list.  Just add these two lines:

x-scheme-handler/http=chromium.desktop
x-scheme-handler/https=chromium.desktop

In the [Default Application] section. Thunar and Chromium also use this so you can configure them to open PDF and handle Skype calls properly. See:

[Default Applications]
x-scheme-handler/http=chromium.desktop
x-scheme-handler/https=chromium.desktop
x-scheme-handler/skype=skype.desktop
text/html=chromium.desktop
application/pdf=mupdf.desktop

This should do the trick. You can get the list of available MIME types with this command (note that the path depends on the location of the shared-mime-info database):

find /usr/local/share/mime -name "*.xml" -exec cat {} \; |g -E -o "type=\".*\"" | sort | uniq

Otherwise you may also use the dconf-editor from the dconf-tools package or gconf-editor to configure GNOME-2/3 default applications. With gconf you should search the following keys:

/desktop/gnome/applications
/desktop/gnome/url-handlers

With dconf instead you should search for:

/desktop/gnome/url-handlers
/org/gnome/desktop/applications