Re: [vserver] Getting a real pid 1 init in a container

From: Grzegorz Nosek <grzegorz.nosek_at_gmail.com>
Date: Wed 21 Mar 2012 - 13:56:59 GMT
Message-ID: <4F69DE2B.7010408@gmail.com>

W dniu 21.03.2012 14:10, Grzegorz Nosek pisze:
> Given that I have seen the call to vx_set_reaper and it looked fine, any
> further things I can check before putting a printk everywhere I can?

Talking to myself again, how do the vservers even set the reaper?

I looked through the patch and all this reaper stuff ends up modifying
vx_info->reaper, which AFAICS is not used anywhere. I downloaded the 3.3
patch[1] and it looks the same. The relevant function seems to be
find_new_reaper() from kernel/exit.c as of 2.6.27.y:

/*
  * When we die, we re-parent all our children.
  * Try to give them to another thread in our thread
  * group, and if no such member exists, give it to
  * the child reaper process (ie "init") in our pid
  * space.
  */
static struct task_struct *find_new_reaper(struct task_struct *father)
{
     struct pid_namespace *pid_ns = task_active_pid_ns(father);
     struct task_struct *thread;

     thread = father;
     while_each_thread(father, thread) {
         if (thread->flags & PF_EXITING)
             continue;
         if (unlikely(pid_ns->child_reaper == father))
             pid_ns->child_reaper = thread;
         return thread;
     }

     if (unlikely(pid_ns->child_reaper == father)) {
         write_unlock_irq(&tasklist_lock);
         if (unlikely(pid_ns == &init_pid_ns))
             panic("Attempted to kill init!");

         zap_pid_ns_processes(pid_ns);
         write_lock_irq(&tasklist_lock);
         /*
          * We can not clear ->child_reaper or leave it alone.
          * There may by stealth EXIT_DEAD tasks on ->children,
          * forget_original_parent() must move them somewhere.
          */
         pid_ns->child_reaper = init_pid_ns.child_reaper;
     }

     return pid_ns->child_reaper;
}

I'd expect a reference to father->vx_info->reaper somewhere in there. Or
rather simply using the pid namespaces already present in the kernel.

Daniel, what exactly did you mean by pid namespaces not being supported?
What would have to happen for Linux-VServer to use pidns, apart from
fixing the pid=2 issue I noticed?

Best regards,
  Grzegorz Nosek

1. http://vserver.13thfloor.at/Experimental/patch-3.3-vs2.3.3.1.diff
Received on Wed Mar 21 13:57:11 2012

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 21 Mar 2012 - 13:57:11 GMT by hypermail 2.1.8