[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Any idea why chroot temporarily "cannot find name for group ID 0"?



Ok, even more mystery, check out this session: Basically, I mentioned I have two nearly-identical chroots, and that sometimes one works while the other one doesn't. Here's an example of that, combined with the broken chroot fixing itself almost instantly:

Last login: Mon Jun 30 07:15:52 2008 from c-98-207-97-133.hsd1.ca.comcast.net
[root@XXXX ~]# cd /svn
[root@XXXX svn]# chroot staging/www
root@XXXX:/# exit
[root@XXXX svn]# chroot staging/db
id: cannot find name for group ID 0
id: cannot find name for group ID 1
id: cannot find name for group ID 2
id: cannot find name for group ID 3
id: cannot find name for group ID 4
id: cannot find name for group ID 6
id: cannot find name for group ID 10
I have no name!@XXXX:/# ls -latr /etc/group
-rw-r--r-- 1 0 root 461 Jun 28 23:34 /etc/group
I have no name!@XXXX:/# ls -latr /etc/passwd
-rw-r--r-- 1 root root 761 Jun 28 23:34 /etc/passwd
I have no name!@XXXX:/# ls -latr /etc/group
-rw-r--r-- 1 root root 461 Jun 28 23:34 /etc/group
I have no name!@XXXX:/# exit
[root@XXXX svn]# chroot staging/db
root@XXXX:/#


Basically, I go into staging/www, and it works fine. Then I go into staging/db, and it has the problem. I immediately check the group permissions, and note that now group IDs are being resolved to group names, but user IDs aren't getting resolved. I then check the passwd permissions, and note that both user and group names are now working. I go right back to the group file, and now group and usernames are working fine. I exit the broken DB chroot, and re-enter just fine.

All this happened in probably under a minute; that's the entire transcript, unaltered. There are no other SSH sessions on that box.

As for nsswitch.conf, here it is: I haven't changed it, but I'm not familiar with the file so I don't know if it's right or not:

-------------------------------------------------------------------
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis
-------------------------------------------------------------------


As for cron, I've got none inside the chroots, and none that I think would touch them. I'll need to check on that. But the timing would need to be consistently coincidental (or it could be going at very high frequency). Furthermore, I'm not sure what a cron job could do that would trigger this in the first place.

As for nscd... Aha! This is a good candidate: it turns out I *do* have this installed on the host system. I don't know anything about this; I'll need to read up on it. But looking over the config file, it looks like a very likely explanation:

-------------------------------------------------------------------
#       logfile                 /var/log/nscd.log
#       threads                 6
#       max-threads             128
        server-user             nscd
#       stat-user               nocpulse
        debug-level             0
#       reload-count            5
        paranoia                no
#       restart-interval        3600

        enable-cache            passwd          yes
        positive-time-to-live   passwd          600
        negative-time-to-live   passwd          20
        suggested-size          passwd          211
        check-files             passwd          yes
        persistent              passwd          yes
        shared                  passwd          yes
        max-db-size             passwd          33554432

        enable-cache            group           yes
        positive-time-to-live   group           3600
        negative-time-to-live   group           60
        suggested-size          group           211
        check-files             group           yes
        persistent              group           yes
        shared                  group           yes
        max-db-size             group           33554432

        enable-cache            hosts           yes
        positive-time-to-live   hosts           3600
        negative-time-to-live   hosts           20
        suggested-size          hosts           211
        check-files             hosts           yes
        persistent              hosts           yes
        shared                  hosts           yes
        max-db-size             hosts           33554432
-------------------------------------------------------------------


I'm putting my money on nscd for now, though why this would screw up email sending from PHP within the chroot, I don't know. (But then again, maybe that's an entirely different erratic problem.)

Thanks for all your help!

-david

Daniel Burrows wrote:
On Mon, Jun 30, 2008 at 12:06:02AM -0700, David Barrett <dbarrett@quinthar.com> was heard to say:
[root@XXXX svn]# chroot staging/www
id: cannot find name for group ID 0
id: cannot find name for group ID 1
id: cannot find name for group ID 2
id: cannot find name for group ID 3
id: cannot find name for group ID 4
id: cannot find name for group ID 6
id: cannot find name for group ID 10

  I wonder what you would get while this is happening if you run "strace id";
of course you might have to install strace in the chroot first.  Also,
did you check whether there's anything odd in nsswitch.conf? (I suppose
probably not since you didn't mention setting anything up there, but
it's worth a check)

Aha!  it's fixed!  30 minutes after the first attempt it's suddenly working.

  What cron jobs are scheduled?  (system jobs as well as user jobs)
Maybe one of them is causing this problem?

  Do you have nscd installed in the chroots or on the main system?

So one theory is something is changing the permissions of /etc/group and /etc/passwd. But I can't figure out what that might be. Next time I'm going to check the permissions first thing.

  It seems unlikely that this is related to your problem.  Your shell
was unable to determine its user name, but it was running as root and
root could read /etc/passwd.

  Daniel




Reply to: