Re: open fails in daemon

• Subject: Re: open fails in daemon
• From: Chris Kane <email@hidden>
• Date: Tue, 22 Jul 2003 13:38:00 -0700

email@hidden writes:

Well, daemon() does a fork() for you. So, it still could be a
fork()-related issue. Does your code not call daemon() when launched
as a startupitem?

Yes, it does. But from what you've said, at that point, it's called
within the startup context.

Why shouldn't a process call daemon() if it's using the higher-level frameworks? It seems like an odd restriction. Does this also apply to processes that do similar things to the daemon() function (e.g. detach themselves from the terminal and fork() into the background)?

The restriction applies to any use of fork() which is not soon followed by an exec*(), not just daemon()'s use of fork(). You cannot reliably use higher-level API after a fork(), before the exec*() either.

The issue stems from the fact that fork() does not replicate all a parent's state (such as some kernel resources) into the child, but it does replicate the memory and some resources. Thus (1) libraries in the new process have not gone through their ordinary initialization steps in the new process, and (2) libraries' cached state or opened resources have now gone silently invalid underneath them, due to the fork() (for those things not replicated by fork()). For example, calls to library functions may produce errors now where they weren't before the fork(), or crash, or silently misbehave, or whatever.

I believe there is a Tech Note on this. You need to exec*() after a fork() if you want to use APIs above the BSD/POSIX layer. And POSIX itself, I believe I've been told, specifies only a small list of things that are guaranteed safe after fork(). [But in practice...]

• Prev by Date: Re: open fails in daemon
• Next by Date: zero filling pages
• Previous by thread: Re: open fails in daemon
• Next by thread: Re: open fails in daemon
• Index(es):
  • Date
  • Thread