Ah, never mind, I see the use of daemon_is_ready() later in main.cc now.
So anyway, I have then encountered a bug in that the parent process
never returns (on Centos 6, while trying to build RPMs from
lp:pkg-drizzle/drizzle7-dev.rpm). It's a bit weird. I can see with
gdb/poormansprofiler the following:
10
pthread_cond_wait@@GLIBC_2.3.2,os_cond_wait,reset_sig_count=<value,os_aio_simulated_handle,fil_aio_wait,io_handler_thread,start_thread,clone
1 sigwait,signal_hand,thread_proxy,start_thread,clone
1
sem_wait,v8::internal::LinuxSemaphore::Wait(),v8::internal::RuntimeProfiler::WaitForSomeIsolateToEnterJS(),v8::internal::SignalSender::Run(),??,start_thread,clone
1 select,os_thread_sleep,srv_LRU_dump_restore_thread,start_thread,clone
1
pthread_cond_wait@@GLIBC_2.3.2,os_cond_wait,reset_sig_count=<value,srv_purge_thread,start_thread,clone
1
pthread_cond_wait@@GLIBC_2.3.2,os_cond_wait,reset_sig_count=<value,srv_master_thread,start_thread,clone
1
pthread_cond_timedwait@@GLIBC_2.3.2,os_cond_wait_timed,time_in_usec=<value,srv_monitor_thread,start_thread,clone
1
pthread_cond_timedwait@@GLIBC_2.3.2,os_cond_wait_timed,time_in_usec=<value,srv_lock_timeout_thread,start_thread,clone
1
pthread_cond_timedwait@@GLIBC_2.3.2,os_cond_wait_timed,time_in_usec=<value,srv_error_monitor_thread,start_thread,clone
1 poll,drizzled::plugin::Listen::getClient,main
1 epoll_wait,??,event_base_loop,thread_proxy,start_thread,clone
The line "poll,drizzled::plugin::Listen::getClient,main" indicates
I've already progressed past the daemon_is_ready() call, yet the
parent process is still there and refuses to return. Parent process
unsurprisingly says:
1 waitpid,drizzled::daemonize,main
Does --daemon work correctly for others?
henrik
On Mon, Jan 2, 2012 at 1:05 AM, Henrik Ingo <[email protected]> wrote:
> Hi
>
> Brian, bzr tells me this code is from you:
> http://bazaar.launchpad.net/~drizzle-trunk/drizzle/development/revision/2399
>
> drizzled/daemon.cc
>
> bool daemonize()
> {
> pid_t child= -1;
> parent_pid= getpid();
> signal(SIGUSR1, sigusr1_handler);
> child= fork();
> switch (child)
> {
> case -1:
> return true;
> case 0:
> break;
> default:
> {
> /* parent */
> int exit_code= -1;
> int status;
> while (waitpid(child, &status, 0) != child)
> { }
> ...
> _exit(exit_code);
>
>
> Why do you leave the parent process to wait for the child to
> terminate? Now when I do
>
> /usr/sbin/drizzled --daemon
>
> ...it means I'm left hanging in the terminal. This also means our rpm
> (and probably deb) init script seems to hang too:
>
> # /etc/init.d/drizzled start
> Starting Drizzle:
>
> ...since the main process never returns.
>
> Granted, I don't really know much about this stuff, but in all
> examples I looked at the parent simply returns immediately after
> successful fork (including memcached, it seems), which is the point of
> daemonizing.
>
> I volunteer to remove above code if you ok it / if there is no good
> reason it is there.
>
> In other news, it seems we don't test for --daemon to work
> consistently :-) (cc Crews)
>
> henrik
> PS: It's also weird to return true on failure and false on success,
> even if the calling code uses those correctly (ie freak out on
> true...). If I fix the above, do you mind if I swap true/false the
> other way around, and then add a "!" (not) to the calling code?
>
> --
> [email protected]
> +358-40-8211286 skype: henrik.ingo irc: hingo
> www.openlife.cc
>
> My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559
--
[email protected]
+358-40-8211286 skype: henrik.ingo irc: hingo
www.openlife.cc
My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
