Arch Linux

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 "http://www.jimpryor.net/linux/dcron.html" 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

I am still experiencing this bug too. dcron launches man-db which launches col, which throws a warning.  FS#18722 

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'.

@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.

Hmm...it _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 (http://www.gentoo.org/doc/en/cron-guide.xml) 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, http://www.jimpryor.net/linux/dcron-README 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?

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.

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.

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?

Maybe the attached patch does it.

Description:
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
"no_LANG.UTF-3.14")

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.

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?

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.