Re: [RFC] [PATCH 00/13] Introduce task_pid api

[ebiederm@xmission.com (Eric W. Biederman)]

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> Quoting Pavel Machek (pavel@ucw.cz):
>> Hi!
>> 
>> > > Hmm... it is hard to judge a patch without context. Anyway, can't we
>> > > get process snasphot/resume without virtualizing pids? Could we switch
>> > > to 128-bits so that pids are never reused or something like that?
>> > 
>> > That might work fine for a managed cluster, but it wouldn't be a good
>> > fit if you ever wanted to support something like a laptop in
>> > disconnected operation, or if you ever want to restore the same snapshot
>> > more than once.  There may also be some practical userspace issues
>> > making pids that large.
>> > 
>> > I also hate bloating types and making them sparse just for the hell of
>> > it.  It is seriously demoralizing to do a ps and see
>> > 7011827128432950176177290 staring back at you. :)
>> 
>> Well, doing cat /var/something/foo.pid, and seeing pid of unrelated process
>> is wrong, too... especially if you try to kill it....
>
> Good point.  However the foo.pid scheme is incompatible with
> checkpoint/restart and migration regardless.

Well if you look at the other uses vserver and bsd style jail
mechanisms the concept is not nearly so ridiculous.

The funny thing though is that this is a trivial thing to continue
to make be sensible.  Run the process in a chroot or a private
namespace and the /var/something/foo.pid works fine.

>
> So if you wanted to checkpoint and restart/migrate a process with a
> foo.pid type of file, you might need to start it with a private
> tmpfs in a private namespace.  That part is trivial to do as part
> of the management tools, though checkpointing a whole tmpfs per process
> could be unfortunate.

The way you describe it I bet that tmpfs will likely be a small
fraction of the size of the processes that you are thinking
about checkpointing.

Eric