Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#24544 - [dcron] Locale is not set by DCron init script

Attached to Project: Community Packages
Opened by Paul Gideon Dann (giddie) - Thursday, 02 June 2011, 09:12 GMT
Last edited by Evangelos Foutras (foutrelis) - Thursday, 17 January 2013, 01:57 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No


The dcron init script clears the environment (with "env -i"), and manually adds a PATH. I have a daily backup script that invokes bsdtar, which chokes on /etc/ssl/certs, stating that it can't convert linkpaths to UTF8.

The following demonstrates this issue from a normal shell on my system:

# LANG= LC_CTYPE= bsdtar cf test.tar -C /etc/ssl certs

To prevent this, I believe the dcron init script should not be clearing out locale environment variables when it's started.

Additional info:
Version: 4.5-2
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Thursday, 17 January 2013, 01:57 GMT
Reason for closing:  Won't fix
Additional comments about closing:  systemd has made init scripts obsolete and unsupported now.
Comment by Fabian Homborg (alfa) - Tuesday, 09 August 2011, 00:42 GMT
This seems to be more of a feature request than a bug.
(It changes much of the context in which cron scripts are started, and could potentially break those)

Could you report this upstream?
Although it seems "" is down.

Also, could you try setting the locale manually in your backup script? That might be easier.
What I mean is:

# LANG=en_US.UTF-8 bsdtar cf test.tar -C /etc/ssl certs
Comment by Radu Potop (wooptoo) - Thursday, 15 September 2011, 22:10 GMT
I am still experiencing this bug too. dcron launches man-db which launches col, which throws a warning.  FS#18722 
Comment by Eric (eric2) - Saturday, 26 November 2011, 15:22 GMT
To get rid of the error messages (col: Invalid or incomplete multibyte or wide character), I had to _export_ the locale variables.

In the case of man-db (/etc/cron.daily/man-db):
I had to add 'export LC_CTYPE=zh_CN.UTF-8' at the beginning of the file (just below '#!/...'). Adding 'LC_CTYPE=zh_CN.UTF-8' (without 'export') will result in the same error messages.
What will also work is add 'LC_CTYPE=zh_CN.UTF-8 ' in front of '${UPDATEMANDB}' (on the same line), just like in Fabian's example.

Make sure you have the locale by doing 'locale -a', and I believe that '*.utf8' is the same as '*.UTF-8'.
Comment by Paul Gideon Dann (giddie) - Saturday, 26 November 2011, 17:27 GMT
@Fabian => Given that the issue is in the init script, and not in dcron itself, I don't think there's much upstream can do about it. I've been using a modified version of the init script for over 5 months now, and the system cron jobs are fine. I really think this should be fixed. If nothing else, the dcron init script should respect DAEMON_LOCALE from rc.conf.
Comment by Fabian Homborg (alfa) - Saturday, 26 November 2011, 22:12 GMT _seems_ like "env -i" was added due to  FS#22085 .

What I was referring to was a different page about dcron not supporting inheriting environment variables in general, however, I can't seem to find that now.
(I'm not even sure that's right, might have misunderstood)

However, the Gentoo guide ( mentions:
"Dcron aims to be a simple, elegant and secure implementation of cron. It does not allow the specification of environment variables in crontabs and all cron-jobs are run from /bin/sh. "

About DAEMON_LOCALE....I think that's not the right solution, as I generally want my daemons error messages to be english (for better bug reporting)

UPDATE: Checked, says "Unlike other fatter cron daemons, though, this cron doesn't even try to manage
environment variables or act as a shell. All jobs are run with `/bin/sh` for
conformity and portability."
Now do I misunderstand that or does it mean that inheriting environment variables with dcron doesn't work?
Comment by Paul Gideon Dann (giddie) - Sunday, 27 November 2011, 17:18 GMT
I don't get it. If you want your daemon's error messages to be in English, why not simply set DAEMON_LOCALE to No, and let all your daemons be started in the C locale? Personally, I want cron to start in the locale I set (en_GB.UTF-8). Isn't that specifically what DAEMON_LOCALE is supposed to let us control?

I'm pretty sure that jobs do in fact inherit environment variables. The Readme indicates that dcron does nothing special with environment variables, so we can assume it doesn't make any effort to mask them. It simply spawns /bin/sh and passes in the command from the crontab.
Comment by Fabian Homborg (alfa) - Sunday, 27 November 2011, 21:31 GMT
Well, if dcron _does_ inherit locale,
it seems that leaves me with 2 choices (once the init script doesn't clean it anymore) :
1) Let it run in the default locale, in my case de_DE.UTF-8
2) Let it run as C

Now I don't want 1, because that gives me german error messages when dcron fails,
and I don't want 2, because that chokes on UTF-8 paths.

What would work would be to be able to set "DAEMON_LOCALE=en_GB.UTF-8" and run any daemon as english in UTF-8.

This would need a patch to initscripts though.
Comment by Paul Gideon Dann (giddie) - Sunday, 27 November 2011, 22:58 GMT
Hmm; I have a vague recollection that this was once briefly discussed on one of the mailing lists. Maybe it would be worth bringing it up again, with this particular case as an example?
Comment by Fabian Homborg (alfa) - Monday, 28 November 2011, 07:36 GMT
Maybe the attached patch does it.

If DAEMON_LOCALE is [yY][eE][sS] or [nN][oO] (or unset/empty) do as usual,
else assume DAEMON_LOCALE is a valid locale and set accordingly.
Now because every daemon-script sources /etc/rc.d/functions,
this should set the locale for every one of those properly.

NOTE: I do _NOT_ know what this does if DAEMON_LOCALE is set to an invalid LOCALE (like
Comment by Fabian Homborg (alfa) - Monday, 28 November 2011, 07:43 GMT
Deleting attached files somehow doesn't work (on firefox and rekonq).
Forgot one export, so I attached the fixed patch again.

Sorry for the noise.
Comment by Paul Gideon Dann (giddie) - Monday, 28 November 2011, 10:14 GMT
I like this approach. We still need to make the DCron init script honour this, though. Any idea what we need to do to get this patch reviewed & merged?
Comment by Fabian Homborg (alfa) - Monday, 28 November 2011, 13:23 GMT
About the dcron script:
Simply removing "env -i" should suffice, maybe even stop overriding $PATH (or even reuse the cronie script, they look the same)

Merging the patch:
I probably need to send it to [arch-projects] and have Tom Gundersen (initscripts maintainer) take a look at it and see what he thinks.
I'll try to do that when I get time, I'm setting up my new laptop right now.