[CRIU] [PATCH 1/3] [v3] crtools: close a signal descriptor after passing a preparation stage

Pavel Emelyanov xemul at virtuozzo.com
Mon Dec 5 00:56:41 PST 2016


On 12/01/2016 12:05 AM, Andrei Vagin wrote:
> On Wed, Nov 30, 2016 at 11:47:02AM +0300, Pavel Emelyanov wrote:
>> On 11/29/2016 12:34 AM, Andrei Vagin wrote:
>>> On Wed, Nov 23, 2016 at 11:24:07AM +0300, Pavel Emelyanov wrote:
>>>> On 11/18/2016 10:33 AM, Andrei Vagin wrote:
>>>>> From: Andrei Vagin <avagin at virtuozzo.com>
>>>>>
>>>>> This patch adds the --siganl-fd FD option to specify a file descriptor.
>>>>> CRIU will write '\0' to this descriptor and close it after passing
>>>>> a preparation stage.
>>>>>
>>>>> It is alternative way to demonizing a criu process after a preparation
>>>>> stage. It's imposiable to get exit code, if a process has daemonized.
>>>>>
>>>>> The introduced way allows to wait a preparation stage and to get an exit
>>>>> code. It can be easy used from shell and other script languages.
>>>>
>>>> Wait a second, if the whole effort is to get error from __preparation__
>>>> stage, then it should be fixed the other way -- once preparation stage
>>>> fails the call to cr_daemon() shouldn't happen and "criu <whatever>"
>>>> should just exit with an error. Doesn't it work like this now, btw?
>>>
>>> It works, but this patch set is about the final exit code, when a work
>>> is done.
>>
>> Done? The close_status_fd() is called right after cr_daemon() in all the
>> daemons we have. Also, the patch comment says: "CRIU will write '\0' to 
>> this descriptor and close it after passing a _preparation_ stage."
> 
> status_fd is used to wait a preparation stage. The "final" exit code is
> a code which service returns when it exits.
> 
> When a service is deamonized, it is detached from a parent process, so
> we can't call waitpid() for it, so we can't git its exit code.
> 
> With the introduced way the service becomes a child process for the
> caller, so the caller can call waitpid() and get its exist status.
> 
> Here is a sequence of actions how it can be used:
> * open a pipe
> * run a service with the pipe[1] as status_fd
> * read(pipe[0]) to wait a moment when the service will be ready to
>   accept connections
> * do a work which requires the service
> * wait the service process to gets its exit status to be sure that
>   everything okey

OK, now it's clear. Can we have some ... explanation of the fact that --status-fd
and --daemon are somewhat doing the same thing? Either in man-page or add a
warning in sources?

Incremental patch is OK.

-- Pavel




More information about the CRIU mailing list