Re: Clusterwide pids

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Chris Wright writes:
> * Albert D. Cahalan (acahalan@cs.uml.edu) wrote:
>> Lars Marowsky-Br\351e writes:
>>>    "Albert D. Cahalan" <acahalan@cs.uml.edu> said:
>> 
>>>>> This leaves us with the chicken and egg problem - how do you
>>>>> boot a node which is - at the time of boot - unable to contact
>>>>> the cluster?
>>>>
>>>> You don't. It is a mistake to design for this perversion.
>>>
>>> Uh. A node not being able to join the cluster is a perfectly
>>> reasonable exception, and you want it to boot so that you can
>>> fix it over the network. It makes sense not to start any cluster
>>> services, that is true.
>> 
>> 1. boot the single node without joining the cluster
>> 2. fix the node
>> 3. reboot to join the cluster
> 
> sounds like a windows soultion ;-)  seriously though, if you can boot
> and run processes that are local only (no cluster yet, as you haven't
> been able to join for whatever reason), how does this cause problems when
> you join the cluster?

Conflicting PIDs are bad.

>>> init is almost guaranteed to be a "local" process, and thus
>>> not visible to other nodes.
>> 
>> Eeew.
>> 
>> Share, or do not share.
> 
> are you suggesting that it is not legitimate to have local-only
> processes? i would expect some processes to be necessarily tied
> to a node.  like those repsonsible for reporting the state of
> the node...

Being tied to a node is fine. Just do it with a unique PID.
On an SMP system, one may support the ability to lock a process
onto a processor. This doesn't mean you should allow that PID
to be used for a different process on a different CPU.

> it seems useful to me to be able to distinguish local from cluster
> processing.  for ps, perhaps you could use different flags as
> mentioned earlier, and scan /proc/cluster/ for cluster processes.

If you're going to do that, then "do not share" is your answer.
Just run a regular cluster and forget about a shared PID space.

Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/