Epoptes is running commands with wrong locale

Asked by Laércio de Sousa

Firstly, I don't know it this is a problem with Epoptes itself or with its dependencies (screen, socat, etc.), but I'm having a strange behaviour in my setup: all commands executed by Epoptes' "Run command" dialog are running in english, instead of my default locale.

I have noticed, by launching a remote xterm, that my remote commands are run with environment variable LC_ALL set to "POSIX", which is wrong (this variable should be unset).

Do you have any suggestion of where should I begin to investigate the problem?

I'm currently running Bazaar revision 397 in openSUSE 12.3.

Question information

Language:
English Edit question
Status:
Solved
For:
Epoptes Edit question
Assignee:
No assignee Edit question
Solved by:
Laércio de Sousa
Solved:
Last query:
Last reply:
Revision history for this message
Alkis Georgopoulos (alkisg) said :
#1

There are 2 epoptes-client instances, the "system" one and the "session" one.
I assume we're talking about the "session" one, which is started from /etc/xdg/autostart/epoptes-client.desktop.
For example, if a user logs in, and you use epoptes Execute command dialog to execute `xterm` inside the user session, then you're using the "session" epoptes client.

epoptes-client doesn't mess with the locale, except for 4 lines of code, which shouldn't affect the "session" epoptes-client, and also shouldn't affect opensuse at all since I don't think it has an /etc/default/locale configuration file:

# When launched as a service, LANG might not be set.
if [ -z "$LANG" ] && [ -r /etc/default/locale ]; then
    . /etc/default/locale
    export LANG
fi

So, it's probably an issue with your installation. Log in to a client and attach the following:
1) Press Alt+F2 to open the local run command dialog, run xterm from there, and paste the output of `env`.
2) From epoptes, select that client, use the epoptes execute dialog to open xterm on the client (do not use the epoptes "open terminal" menu, use the execute dialog), and paste the output of `env`.

Those 2 should be the same. If they aren't, your DE launches /etc/xdg/autostart services with broken environment, and you should file a bug report in your distro bug tracker.

Also, which DE are you using?

Revision history for this message
Laércio de Sousa (lbssousa) said :
#2

Here is my "env" output from a remote xterm, i.e., that open by Epoptes' execute dialog. I've filtered out those parts that are equally present in my local "env" output. Conflicting parts between local and remote "env"s are marked with a pseudo-diff syntax:

COLUMNS=80
<<<<<<
    [remote]
    CPU=Pentium(R) Dual-Core CPU E6700 @ 3.20GHz
    ======
    [local]
    CPU=x86_64
>>>>>>
IP=192.168.2.11
<<<<<<
    [remote]
    LC_ALL=POSIX
    ======
    [local]
    "LC_ALL is unset"
>>>>>>
LINES=24
MAC=6C:62:6D:F6:9F:ED
NAME=Aluno #01
OLDPWD=/usr/share/epoptes-client
OS=GNU/Linux
PATH=[local PATH]:/sbin:/usr/sbin
PORT=789
RAM=3925
SERVER=proinfo0
<<<<<<
    [remote]
    SHLVL=4
    ======
    [local]
    SHLVL=2
>>>>>>
SOCAT_PID=4924
SOCAT_PPID=4924
SOCAT_VERSION=1.7.2.1
TYPE=standalone
UID=1001
VERSION=0.5.6
VGA=4 Series Chipset Integrated Graphics Controller [2e32]
WINDOWPATH=7
<<<<<<
    [remote]
    XTERM_LOCALE=C
    ======
    [local]
    XTERM_LOCALE=pt_BR.UTF-8
>>>>>>

As you can see, the main difference between local and remote "env"s is the LC_ALL setting (local leaves it unset, remote sets it to "POSIX"), which implies the different XTERM_LOCALE settings. Both "env"s have LANG set to my default locale, pt_BR.UTF8.

I'm using openSUSE 12.3 with KDE 4.11.

Revision history for this message
Alkis Georgopoulos (alkisg) said :
#3

Comparing local and remote ==> that's comparing 2 different PCs, which might have different locale settings.
It would be better to compare [remote invoked with epoptes] with [remote invoked with alt+f2], like I suggested.

Try putting this file to the standalone client, in /etc/xdg/autostart/xterm.desktop:
http://www.opensource.apple.com/source/X11apps/X11apps-44/xterm/xterm-269/xterm.desktop

That way, an xterm should open after login. Check the environment there. If it's the same as in the epoptes-client invoked xterm, then it's not an epoptes issue, it's an opensuse issue (or an installation issue).

Revision history for this message
Laércio de Sousa (lbssousa) said :
#4

Oh, sorry the confusion. Both "env" were executed on the same machine. When I say [local], I mean the xterm executed locally with alt+f2. When I say [remote], I mean the xterm executed remotely with Epoptes' execute dialog.

Revision history for this message
Laércio de Sousa (lbssousa) said :
#5

Another information: in openSUSE there's a file named /etc/profile.d/lang.sh, with the content below. It references another openSUSE-specific config file named /etc/sysconfig/language, whose relevant part is the setting RC_LANG="my locale", which is used by other programs to set LANG.

#
# lang.sh: Set interactive language environment
#
# Used configuration files:
#
# /etc/sysconfig/language
# $HOME/.i18n
#

#
# Already done by the remote SSH side
#
test -z "$SSH_SENDS_LOCALE" || return

#
# Already done by the GDM
#
test -z "$GDM_LANG" || return

#
# Get the system and after that the users configuration
#
if test -s /etc/sysconfig/language ; then
    while read line ; do
 case "$line" in
 \#*|"")
     continue
     ;;
 RC_*)
     eval ${line#RC_}
     ;;
 ROOT_USES_LANG*)
     eval $line
     test "$UID" != 0 && ROOT_USES_LANG=yes
     ;;
 esac
    done < /etc/sysconfig/language
fi
test -s $HOME/.i18n && . $HOME/.i18n

#
# Handle all LC and the LANG variable
#
for lc in LANG LC_CTYPE LC_NUMERIC LC_TIME \
   LC_COLLATE LC_MONETARY LC_MESSAGES \
   LC_PAPER LC_NAME LC_ADDRESS \
   LC_TELEPHONE LC_MEASUREMENT \
   LC_IDENTIFICATION LC_ALL
do
    eval val="\$$lc"
    if test "$ROOT_USES_LANG" = "yes" ; then
 if test -z "$val" ; then
     eval unset $lc
 else
     eval $lc=\$val
     eval export $lc
 fi
    elif test "$ROOT_USES_LANG" = "ctype" ; then
 test "$lc" = "LANG" && continue
 if test "$lc" = "LC_CTYPE" ; then
     LC_CTYPE=$LANG
     LANG=POSIX
     export LANG LC_CTYPE
 else
     eval unset $lc
 fi
    else
 if test "$lc" = "LANG" ; then
     LANG=POSIX
     export LANG
 else
     eval unset $lc
 fi
    fi
done

#
# Special LC_ALL handling because the LC_ALL
# overwrites all LC but not the LANG variable
#
if test -n "$LC_ALL" -a "$LC_ALL" != "$LANG" ; then
    export LC_ALL
else
    unset LC_ALL
fi

unset line ROOT_USES_LANG lc val
#
# end of lang.sh

Revision history for this message
Alkis Georgopoulos (alkisg) said :
#6

Hi Laércio,

please leave the status of the question to "Needs information", until you give feedback to what I asked in comment #3.

If a plain xterm ran from /etc/xdg/autostart has locale issues, then you should file the bug report against opensuse, not against epoptes.

Thank you.

Revision history for this message
Laércio de Sousa (lbssousa) said :
#7

I've created file /etc/xdg/autostart/xterm.desktop and rebooted my machine. The "env" output of the autostarted xterm is exactly the same I've got from alt+f2 launched one, but still DIFFERENT from that one launched via Epoptes' execute dialog.

Searching a bit further for the origin of that LC_ALL trouble, I've found a config file named /etc/rc.status, which exports LC_ALL=POSIX. Many openSUSE boot scripts and system daemons source this file, but that script /etc/profile.d/lang.sh gets rid of LC_ALL when LANG is set to a different value.

As a last test, if I open a xterm with Epoptes' execute dialog and explicitly source /etc/profile.d/lang.sh, LC_ALL goes away and I get the expected "env" output.

Revision history for this message
Alkis Georgopoulos (alkisg) said :
#8

Please paste the contents of your /etc/xdg/autostart/epoptes-client.desktop file.

Revision history for this message
Laércio de Sousa (lbssousa) said :
#9

[Desktop Entry]
Name=Epoptes client service
Name[el]=Υ������α ��λά�
                       η �
                          ο�
 Epoptes
Comment=Epoptes computer lab administation tool client service
Comment[el]=Υ������α ��λά�
                          η �
            δια��ί����� ε��α�ο�
 λογι��ικο� η���� Epoptes
Exec=/usr/sbin/epoptes-client
Icon=epoptes
Terminal=false
Type=Application
Categories=Settings;System;
# X-GNOME-AutoRestart=true

Revision history for this message
Alkis Georgopoulos (alkisg) said :
#10

Also another test:
from the xterm which was started from /etc/xdg/autostart/xterm, run epoptes-client.
That will automatically replace the one started from /etc/xdg/autostart/epoptes-client. And it should have the correct locale settings. You can verify that as usual.

It might be a problem with the opensuse packaging, e.g. they might be launching epoptes-client via some other method. Unfortunately I don't have opensuse to test with it...

Revision history for this message
Alkis Georgopoulos (alkisg) said :
#11

Laércio, since it appears you're currently online, can you come to the IRC channel to debug this live?
webchat.freenode.net/?channels=ltsp

Revision history for this message
Laércio de Sousa (lbssousa) said :
#12

Hey, I guess I've found the bug!

The script /usr/sbin/epoptes-client tries to source a file named /lib/lsb/init-functions, which should provide shell functions log_begin_msg() and log_end_msg() on Debian-based systems.

This file also exists in openSUSE 12.3, but with the contents below:

#
# Define init LSB shell functions
#

#
# Source SuSE's rc functions
#
. /etc/rc.status

#
# Be sure that start_daemon, killproc, and
# pidofproc will be script functions.
#
function start_daemon ()
{
    /sbin/start_daemon ${1+"$@"}
}

function killproc ()
{
    /sbin/killproc ${1+"$@"}
}

function pidofproc ()
{
    /sbin/pidofproc ${1+"$@"}
}

#
# Logging of succes messages
#
function log_success_msg ()
{
    echo -en "$@"
    echo -e "$rc_done"
}

#
# Logging of failure messages
#
function log_failure_msg ()
{
    echo -en "$@"
    echo -e "$rc_failed"
}

#
# Logging of warn messages
#
function log_warning_msg ()
{
    echo -en "$@"
    echo -e "${stat}${attn} warning${norm}"
}

As you can see, this version of /lib/lsb/init-functions does NOT provide the desired functions log_begin_msg() and log_end_msg(). Moreover, it sources /etc/rc.status, which injects that undesirable LC_ALL=POSIX.

I've editted my /usr/sbin/epoptes-client, commenting the part that sources /lib/lsb/init-functions, rebooted my system and... voilà: Epoptes now executes my programs with the right locale.

BTW: I've tried to enter IRC channel, but freenode.net has banned me:

You are banned from this server- Your host is an open proxy (HTTP CONNECT (Mikrotik-style) (3128)). Email <email address hidden> when corrected. (2013/9/16 08.38)

It seems freenode.net doesn't like my current squid setup. I'll check it later, so we can chat on IRC channel in other opportunities.

Revision history for this message
Laércio de Sousa (lbssousa) said :
#13

Last, but not least: feedback about your comment #10 (I've should write this first. Sorry.)

When I executed epoptes-client from autostarted xterm, I've got the same wrong "env", but I have noticed the absence of log_begin_msg and log_end_msg, which leaded me to comment #12.

Revision history for this message
Alkis Georgopoulos (alkisg) said :
#14

LSB was supposed to be a cross-distro standard... but unfortunately it appears it's not really portable :(
So we'll probably have to put a lot of distro-specific code there, if we want to have good start/stop daemon output in all distros and init systems...

Laércio, please close this question and file a related bug report in epoptes, I'll test 5-6 different distros and commit a fix when I have some free time. Thanks!

Revision history for this message
Laércio de Sousa (lbssousa) said :
#15

OK. I'll do it.

Just a last comment: have you ever considered the possiblity of porting epoptes-client to Python or even C? I know how you are concerned about lightness, but you can have a more "standardized" environment by moving away from shell, don't you?

Revision history for this message
Alkis Georgopoulos (alkisg) said :
#16

> I know how you are concerned about lightness, but you can have a more "standardized" environment by moving away from shell, don't you?

Unfortunately no. Init scripts are very distro specific, because one distro uses plymouth and requires function X for the output, the other one doesn't and requires function Y, one uses upstart, the other systemd, the other sysvinit etc etc... :(

http://xkcd.com/927/