Cannot lookup child messages in Console

Hi, Andre —

I've never faced the situation, so I'm reticent to judge its significance unless you indicate that you're facing significant system unresponsiveness. Imo, repeated messages in console.log do not comprise such a situation — data lookups may often require multiple attempts without any problems.

Even "hundreds of messages like this" may only represent split-seconds — and are thus not implicitly problematic. If your system is "hanging" interminably — or causing netinfo or lookupd to crash — that would be a problem requiring attention. crash.logs would typically be written to <small> Library/Logs/CrashReporter/</small> in such cases.

Anyway, I profess no real expertise in this area, as I'm just learning about it myself. But I can help to provide a little perspective through some background information.

If you read through the two threads that result from a Google•Mac search for "cannot lookup child," several questions will probably come to mind. The following references may shed some light.

As explained in this oasxfaq UNIX tutorial, "Mac OS X uses NetInfo manager to maintain the authentication database" for multi-user operation. It is queried by lookupd.

KnowledgeBase Article 30770: Mac OS X: What is Lookupd? explains how lookupd manages this information-gathering process. As defined in its Man Page, the lookupd daemon —
]"<small> acts as an information broker and cache. It is called by various routines in the System framework to find information about user accounts, groups, printers, e-mail aliases and distribution lists, computer names, Internet addresses, and several other kinds of information.
]lookupd keeps a cache of recently requested items to improve system performance. It also implements a search strategy used to find information from the many information sources that are potentially available to a computer. These include the Domain Name System (DNS), Sun Microsystem's Network Information Services (NIS), Apple's NetInfo system, and a set of files found in the /etc directory. lookupd also has a channel to query Directory Services, allowing access to data from LDAP and other directory systems.
]The lookupd process is monitored by the system's mach server registry (the mach_init process), and is automatically restarted if it crashes or exits. lookupd responds to a HUP signal by exiting. This is the preferred mechanism for restarting / resetting the process.</small>"
In the worst case, the Netinfo database may need to be rebuilt, as explained in KBase Article 107210. But this should only be considered given significant system problems.
I hope this helps you to understand what you've found, and to put it in perspective. If you post back that what you've reported does represent signifcant problems with your system's performance, I'm over my head and must defer to our "UNIX-guru" participants to provide real assistance.
Warm regards,
Dean

Hi again, Andre —

Feeling "a bit lost" is easy enough when things go awry. We all feel that way sometimes — 'tis one of the reasons it's satisfying to post here, seeking help or trying to provide some.

Sounds to me that your external FireWire drive issues are independent of the question about netinfod. Unless you can strongly correlate the time(s) of writing-to-drive failure vs. the log entries, I think you should look in other directions.
/etc/ vs. NetInfo lookups. From what I've read, I'm a bit confused why you'd see repeated netinfod-related lookup errors in a single-user system. But I may not fully understand. Fyi, the Open Directory Programming Guide provides a good explanation in its <small>Concepts: Open Directory, lookupd, and NetInfo</small> section <small>(pp. 26-28 in the PDF version)</small> about how lookupd flexibly works with local or Open Directory queries. But . . .
Sorry, the osxFAQ reference link cited above should've been to the sidebar here — not to the index page. It says:
]"<small>For those of you familiar with other Unix systems, Mac OS X does not hold users and groups information in the usual /etc/passwd and /etc/groups flat files. These exist but are used only in single-user mode. For multi-user operation NetInfo is queried. One can see this by viewing /users and /groups entries in NetInfo. On the command line it is possible to use nidump</small>."
If you're interested, osxFAQ's Tips include explanations of a number of UNIX commands related to NetInfo and the 'ni Utilities' — see "weeks" 91 and 79 in the latter 'Tips' link.
But the specifics — or whether/how you "forgot a step" — are beyond my experience and understanding. Sorry. Hopefully another participant can help with this.
For now — with no related system problems, I'd tend to remain curious/skeptical but not concerned. I hope I was clear before in suggesting that rebuilding its database should be considered a "last resort." Please don't misunderstand the emphasis here.
FireWire drive. The external FireWire drive problem is different enough that I suggest you initiate a new "FireWire" thread about it unless you receive a solution from someone here soon.
[I've just visited your posts in Norman's Disk utility restore refuses destination thread. I can't tell — does your post there about using CCC suggest you've resolved this problem? If not...]
A few questions to consider: Any indication in your logs that does correlate closely to when this occurs? Or during the startup process (in console.log, system.log, or asl.log, I'd guess) — any evidence its driver isn't loading properly? Is it "seen" accurately in the <small>Hardware »» Firewire</small> section in System Profiler? Have you checked at the drive manufacturer's website to confirm that your driver software is current? Also, try selecting the appropriate driver(s) in <small>System Profiler »» Software »» Extensions</small>, and look at what's provided in the lower right-hand part of the window — if there's a problem, it may be indicated there.
—Dean