xinetd has wrong locale

Bug #1790783 reported by latimerio
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xinetd (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

I have a system which somehow had the wrong locale settings.
This leads to timestamps in log files from xinetd in the wrong date format.
Normally all our systems (>200) are set to US English and the locale settings are as below.
cat /etc/default/locale
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8

They should stay like this no matter what keyboard is attached.
Somehow on the affected system the settings in /etc/default/locale got changed to this:
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8

I have changed them back to the US English default and invoked locale-gen.
Entering 'locale' at the shell prompt now gives the expected results but xinetd still shows the wrong values.
I restarted xinetd and even uninstalled and reinstalled it but no success.
I guess a reboot may solve the problem but I would like to avoid this.
What makes xinetd stick to the wrong locale settings?

cat /etc/default/xinetd # gives no special settings as shown below

# Default settings for xinetd. This file is sourced by /bin/sh from
# /etc/init.d/xinetd

# enable xinetd Inetd compat mode
INETD_COMPAT=Yes

# Options to pass to xinetd
#
# -stayalive comes by default : it can be removed if xinetd is expected
# not to start when no service is configured
#
XINETD_OPTS="-stayalive"

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: xinetd 1:2.3.15-6
ProcVersionSignature: Ubuntu 4.4.0-134.160-generic 4.4.140
Uname: Linux 4.4.0-134-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Wed Sep 5 08:29:05 2018
SourcePackage: xinetd
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
latimerio (fomember) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I was wondering if it would just "iniherit" the bad lang from the parent until that is respawned with the fresh settings, but that would be init which doesn't have a lang env set usually - so that should be odd to check (as you say that would be a reboot).

I wonder about your "but xinetd still shows the wrong values" - how are you checking this?

Something like the following:
# xargs --null --max-args=1 echo < /proc/$(pidof xinetd)/environ | grep LANG
LANG=en_US.UTF-8

If not what is the way you are doing it?
And what would above report for you?

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Actually I realized the two LANG lists in your bug report are the same.
Which exactly did change?

I see the proc environ of the bug atatchments shows many LANG settings.
They are ALL English - so is the problem that is has all "EN" while you'd expect some to be "de"?

Check for LC and LANG in your active env, as your report has them as LC env vars:
$ xargs --null --max-args=1 echo < /proc/$(pidof xinetd)/environ | grep -i -e lang -e lc

Revision history for this message
latimerio (fomember) wrote :

Sorry I had copied the wrong locale settings.
As can be seen in the attached procenviron.txt the settings were US English when I submitted the bug report.
Strangely the xinetd seems to remember the previous German settings for time and date even if I uninstall and reinstall it.
The phenomenon manifests when I connect to the system with the tape backup process from dataprotector on port 5555. This writes a log file with German timestamps which brakes my backup monitoring process.
I also tested it with a custom written service which just invokes a local script which echoes the environment back.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Maybe it inherits the LANG settings, but the parent should be init right.
Maybe even through the restart from your ssh shell or something?

If you start an xinet process yourself (not the service).
What will its LANG be?
Please ensure your shell doing so has the ones you want.

Like:
ensure env is good
xinetd &
check proc/<pid>/environ

If that is good, modify something and see if it inherits it all.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Can't it also be that the client connecting to xinetd is supplying its own locale settings? ssh does this by default, to cite one example.

Changed in xinetd (Ubuntu):
status: New → Incomplete
Revision history for this message
latimerio (fomember) wrote :

The main problem comes from the dataprotector (omniback) connection where xinetd writes German timestamps in the log file.
I have written a small xinetd test service which just runs the locale command on a specific port to check the output.
We have >200 linux systems which are backed up with dataprotector and only 2 systems that show the problem. One of them got rebooted and the problem was gone.
Thus it is not the client connection but a setting somewhere on the system.
I had done an apt-get remove xinetd and an apt-get install xinetd without success.
If I start a single xinetd the locale is OK but if I start xinetd from the service it still shows the wrong locale.
Please see the attached log.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for xinetd (Ubuntu) because there has been no activity for 60 days.]

Changed in xinetd (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.