From: Lars Braeuer (lbraeuer_at_mpex.net)
Date: Sat 27 Mar 2004 - 19:11:53 GMT
I've had a problem when updating from 2.4.20ctx-17_quota to 2.4.24/vserver 1.26 (+quota) two weeks ago.
The system hasn't been able to map the long unique uid's to usernames anymore after booting the new
kernel. For now we are using the old kernel again and I'm kind of stuck in solving this problem.
The first thing that seemed weird to me, is that when listing the files from outside the vserver,
some files have a uid of 0 (root) and others have a long uid (i.e. 458752) which also seems to map
to root (inside the vserver). Here's an example (listing via "ls -lagn /vserver/<name>"):
drwxr-x--- 2 458752 458752 4096 Nov 19 02:08 service/
drwxrwxrwt 3 0 0 8192 Mar 27 19:45 tmp/
drwxr-xr-x 14 0 0 4096 Oct 16 11:36 usr/
drwxr-xr-x 20 0 0 4096 Oct 15 01:38 var/
The same listing from inside the vserver ("vserver <name> exec ls -lagn /"):
drwxr-x--- 2 0 0 4096 Nov 19 02:08 service
drwxrwxrwt 3 0 0 8192 Mar 27 19:45 tmp
drwxr-xr-x 14 0 0 4096 Oct 16 11:36 usr
drwxr-xr-x 20 0 0 4096 Oct 15 01:38 var
When updating to the new kernel the files with the long uid's are not properly mapped anymore. We
noticed this because mysql wouldn't start in any of the 10 vservers on this system. After chown'ing
the related mysql.pid files and directories the mysql server started. But there are tons of files
with wrong uid's left, so this wouldn't be a solution, just a temporary patch.
I wasn't able to test this issue anymore, because it's on a production system. I'll be starting
another try next week, so if there are any other things I could check, please tell me.
Thanks in advance for your help.
Vserver mailing list