FS#18722 - [man-db] col throws warning/error after upgrade

Attached to Project: Arch Linux
Opened by Radu Potop (wooptoo) - Wednesday, 17 March 2010, 14:16 GMT
Last edited by Andrea Scarpino (BaSh) - Tuesday, 21 June 2011, 05:59 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Andreas Radke (AndyRTR)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
col throws the warning/error below after man-db upgrade. This happens when /etc/cron.daily/man-db is executed (I keep receiving this on system email).

col: Invalid or incomplete multibyte or wide character

Package versions:
col: util-linux-ng 2.17.1-1
man-db 2.5.7-1
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Tuesday, 21 June 2011, 05:59 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#24544 
Comment by Radu Potop (wooptoo) - Thursday, 08 April 2010, 14:38 GMT
I still have this issue.
Comment by Andreas Radke (AndyRTR) - Saturday, 14 August 2010, 21:10 GMT
"man col" is working well for me. is it solved meanhile?
Comment by Radu Potop (wooptoo) - Saturday, 14 August 2010, 21:30 GMT
No, I still have this issue.
Comment by Andreas Radke (AndyRTR) - Saturday, 14 August 2010, 21:42 GMT
[root@workstation64 andyrtr]# /usr/bin/mandb | grep col
[root@workstation64 andyrtr]#

I cannot confirm this.
Comment by Radu Potop (wooptoo) - Saturday, 25 September 2010, 22:26 GMT
Fixed. I don't know after which upgrade exactly.
Comment by x2b (x2b) - Friday, 03 June 2011, 06:54 GMT
  • Field changed: Percent Complete (100% → 0%)
The problem still occurs with man-db 2.6.0.2, util-linux 2.19.1 and dcron 4.5
Comment by Radu Potop (wooptoo) - Friday, 03 June 2011, 10:00 GMT
I am still experiencing this too.
It wasn't fixed before. Postfix failed to start for some reason and I wasn't receiving system mail. Oops.
Comment by x2b (x2b) - Friday, 03 June 2011, 15:18 GMT
To reproduce I would recommend to remove the index entirely before rebuilding it:

$ rm /var/cache/man/index.db
$ LANG=C /etc/cron.daily/man-db
col: Invalid or incomplete multibyte or wide character

If I use the default LANG, i.e. en_US.UTF-8 then there are no errors.

The col command is used in mandb, but I expect that it doesnt show up because mandb is written in C and not bash.
Comment by Radu Potop (wooptoo) - Friday, 03 June 2011, 15:41 GMT
I could reproduce the bug using x2b's instructions.
I guess a patch for /etc/cron.daily/man-db could be:

37c37
< ${UPDATEMANDB}
---
> LANG=$LANG ${UPDATEMANDB}
Comment by Colin Watson (cjwatson) - Saturday, 04 June 2011, 06:37 GMT
Thanks for your report. I've fixed this upstream (at least, assuming a UTF-8 locale is available somewhere on the system, which it is at least in x2b's case). Here's the patch, if you want to backport it:

http://bazaar.launchpad.net/~cjwatson/man-db/trunk/revision/1361
Comment by Patrick Palka (orlandu63) - Tuesday, 07 June 2011, 08:22 GMT
problem still persists after update
Comment by Andreas Radke (AndyRTR) - Tuesday, 07 June 2011, 08:31 GMT
here's how I've built it: http://projects.archlinux.org/svntogit/packages.git/tree/man-db/trunk/

I can't reproduce it. Colin, any idea?
Comment by Colin Watson (cjwatson) - Tuesday, 07 June 2011, 11:20 GMT
Somebody with this problem is going to have to provide more information than "problem still persists"! For example, arranging for mandb to be run with the --debug option and posting the output of that would be helpful.
Comment by roko (roko) - Saturday, 18 June 2011, 12:11 GMT
I cannot reproduce it on my machine with man-db 2.6.0.2-2, util-linux 2.19.1-2 and cronie 1.4.7-8.

I've successfully executed:

# rm /var/cache/man/index.db
# LANG=C /etc/cron.daily/man-db
Comment by Radu Potop (wooptoo) - Saturday, 18 June 2011, 13:01 GMT
It happens when run by dcron, not manually.
Comment by Andreas Radke (AndyRTR) - Saturday, 18 June 2011, 13:29 GMT
Who's still affected? Can you try if using cronie instead of dcron makes a difference?
Comment by roko (roko) - Saturday, 18 June 2011, 13:40 GMT
Hm.. I've used this: http://serverfault.com/questions/85893/running-a-cron-job-manually-and-immediately to simulate cron behaviour. Still no problems.

wooptoo: Can you please add

* * * * * /usr/bin/env > /home/username/cron-env

to your root crontab then wait for a minute or so and then post here the contents of cron-env.

Comment by Radu Potop (wooptoo) - Saturday, 18 June 2011, 13:45 GMT
This was the output:


SHELL=/bin/sh
USER=root
PATH=/sbin:/usr/sbin:/bin:/usr/bin
PWD=/root
SHLVL=1
HOME=/root
LOGNAME=root
_=/usr/bin/env
Comment by Radu Potop (wooptoo) - Saturday, 18 June 2011, 14:01 GMT
That did the trick. I ran the run-as-cron script and it produced the col warning.
So it seems that the cron env contains no LANG.
Comment by roko (roko) - Saturday, 18 June 2011, 14:04 GMT
On my machine the only difference was in PATH=/usr/bin:/bin. Having changed it to yours still does not make any difference to me.
Can you please try this approach to simulate cron http://serverfault.com/questions/85893/running-a-cron-job-manually-and-immediately to see if you get an error, just to check if simulation works.
Comment by roko (roko) - Saturday, 18 June 2011, 14:12 GMT
Ah, so the simulation works. The point is I do _not_ have LANG also...
Comment by Dave Reisner (falconindy) - Saturday, 18 June 2011, 15:20 GMT
So the point is that LANG is not being set, properly, whereas it seems to be set for most people.

Have you set a valid locale in /etc/rc.conf?

Is LANG set for the cron process itself?
$ sudo bash -c "tr '\0' '\n' < /proc/$(pidof crond)/environ"

I'm thinking that this might be pointing to a larger problem in our initscripts. After some digging, I've found 'telinit -e', which claims to be able to modify the environment in which init launches processes. However, it doesn't appear to work as it advertises.
Comment by Radu Potop (wooptoo) - Saturday, 18 June 2011, 15:54 GMT
> Have you set a valid locale in /etc/rc.conf?
Yes, I do: LOCALE="en_US.UTF-8"

> Is LANG set for the cron process itself?
# cat /proc/$(pidof crond)/environ
PATH=/sbin:/usr/sbin:/bin:/usr/bin

No it isn't.
Comment by roko (roko) - Saturday, 18 June 2011, 16:00 GMT
So in my rc.conf I have

LOCALE="en_US.UTF-8"
DAEMON_LOCALE="no"

And $ sudo bash -c "tr '\0' '\n' < /proc/$(pidof crond)/environ" gives me

CONSOLE=/dev/console
TERM=linux
SHELL=/bin/sh
INIT_VERSION=sysvinit-2.88
PATH=/sbin:/usr/sbin:/bin:/usr/bin
vga=795
RUNLEVEL=3
PWD=/
LANG=C
PREVLEVEL=N
HOME=/
SHLVL=2
_=/usr/sbin/crond

What about you, wooptoo?

Dave, does man-db uses LANG of parent process i.e. crond? (There is no LANG in the environment of the program executed by crond.)
Comment by Dave Reisner (falconindy) - Saturday, 18 June 2011, 16:03 GMT
@wooptoo: That's wrong on multiple levels. How is cron being launched? My bone stock VM shows the following when crond is launched from /etc/rc.conf via rc.multi:

# tr '\0' '\n' < /proc/$(pidof crond)/environ
CONSOLE=/dev/console
TERM=linux
SHELL=/bin/sh
INIT_VERSION=sysvinit-2.88
PATH=/sbin:/usr/sbin:/bin:/usr/bin
RUNLEVEL=3
PWD=/
LANG=C
PREVLEVEL=N
SHLVL=2
_=/usr/sbin/crond

Comment by Dave Reisner (falconindy) - Saturday, 18 June 2011, 16:12 GMT
I'm not familiar with the environment that crond launches its processes in, but it can only create an environment for children from two things:

1) its own environ
2) anything the user sets

The larger issue here is #1 -- the environ for crond isn't being populated correctly, and I'm not sure why.
Comment by roko (roko) - Monday, 20 June 2011, 22:37 GMT
@woopto, How your cron is being launched?
Comment by roko (roko) - Monday, 20 June 2011, 22:41 GMT
I think it's the issue of dcron. See  FS#24544 . What do you think, Dave?
Comment by Dave Reisner (falconindy) - Monday, 20 June 2011, 23:11 GMT
Uh, yeah. That'd be the problem right there. If a user wants a "clean" environment, we have rc.d which can do that (mimicking the environment a daemon gets when started via rc.multi).

Moving to close this as a dupe...

Loading...