On Thu, Apr 28, 2011 at 2:29 PM, Tommi Virtanen
<tommi.virtanen@xxxxxxxxxxxxx> wrote:
> NSS, the crypto library Red Hat likes to use, cannot tolerate
> forks. NSS_NoDB_Init must be called after daemonization, and there
> seems to be no way around it; for example, calling it again is
> explicitly forbidden.
>
> The code in branch wip-nss-vs-fork adds a common_init_daemonized
> function, that things that (potentially) daemonize must call, after
> the point where they'd daemonize. Non-daemons are handled in
> common_preinit and need nothing special.
>
> Users of libceph/librados cannot fork, and expect to keep using the
> library :(
We already are in a situation where the child process after a fork
can't use librados or libceph. The reason is because the child process
will not have any threads besides the main one.
The question we need to answer is really whether forking somehow
destroys the state of the parent process, even if the child thread
never runs any libNSS code. If the answer is no, which is very likely,
then essentially our situation is unchanged.
>
> The "remove this" comment on libceph_initialized cannot be blindly
> acted on; similar logic could be pushed down into ceph::crypto::init,
> though.
>
> This is ugly, but it's the best I could do. Please go through the code
> and let me know if you have any ideas on how to make it less painful.
Daemonization should be done in common_init. Obviously, only daemons will do it!
Daemonization has nothing to do with the messenger logically, so it
will be good to get that stuff out of there.
Colin.
>
> In the meanwhile, if you need NSS to work, you can always run in
> non-daemonizing mode, with -f.
>
>
> P.S. Please use Crypto++. For my sanity.
>
> --
> :(){ :|:&};:
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
