Epoptes is running commands with wrong locale
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
|
#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/
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
|
#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:
NAME=Aluno #01
OLDPWD=
OS=GNU/Linux
PATH=[local PATH]:/
PORT=789
RAM=3925
SERVER=proinfo0
<<<<<<
[remote]
SHLVL=4
======
[local]
SHLVL=2
>>>>>>
SOCAT_PID=4924
SOCAT_PPID=4924
SOCAT_VERSION=
TYPE=standalone
UID=1001
VERSION=0.5.6
VGA=4 Series Chipset Integrated Graphics Controller [2e32]
WINDOWPATH=7
<<<<<<
[remote]
XTERM_LOCALE=C
======
[local]
XTERM_
>>>>>>
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
|
#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/
http://
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
|
#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
|
#5 |
Another information: in openSUSE there's a file named /etc/profile.
#
# lang.sh: Set interactive language environment
#
# Used configuration files:
#
# /etc/sysconfig/
# $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/
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/
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_IDENTIFIC
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
|
#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
|
#7 |
I've created file /etc/xdg/
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.
As a last test, if I open a xterm with Epoptes' execute dialog and explicitly source /etc/profile.
Revision history for this message
|
#8 |
Please paste the contents of your /etc/xdg/
Revision history for this message
|
#9 |
[Desktop Entry]
Name=Epoptes client service
Name[el]=Υ������α ��λά�
Epoptes
Comment=Epoptes computer lab administation tool client service
Comment[
λογι��ικο� η���� Epoptes
Exec=/usr/
Icon=epoptes
Terminal=false
Type=Application
Categories=
# X-GNOME-
Revision history for this message
|
#10 |
Also another test:
from the xterm which was started from /etc/xdg/
That will automatically replace the one started from /etc/xdg/
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
|
#11 |
Laércio, since it appears you're currently online, can you come to the IRC channel to debug this live?
webchat.
Revision history for this message
|
#12 |
Hey, I guess I've found the bug!
The script /usr/sbin/
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/
}
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/
I've editted my /usr/sbin/
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
|
#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
|
#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
|
#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
|
#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... :(