[CRIU] [PATCH] LOG_DIR_FD_OFF -> WORK_DIR_FD_OFF
Andrew Vagin
avagin at parallels.com
Mon Nov 11 03:58:58 PST 2013
On Mon, Nov 11, 2013 at 03:36:59PM +0400, Pavel Emelyanov wrote:
> On 11/11/2013 07:25 PM, Ruslan Kuprieiev wrote:
> > On 11.11.2013 15:13, Andrew Vagin wrote:
> >> On Mon, Nov 11, 2013 at 03:01:07PM +0400, Cyrill Gorcunov wrote:
> >>> On Mon, Nov 11, 2013 at 02:53:02PM +0400, Pavel Emelyanov wrote:
> >>>> * service/page-server --daemon
> >>>> g
> >>>> - images : -D, don't start if absent
> >>>> - logs : $opt-filename, don't start if not absolute
> >>>> - pidfiles: $opt-filename, don't start if not absolute
> >>> Why can't the logs/pidfiles be a relative to -D directory here?
> >>> Do we really need to require absolute path?
> >> You think like me :)
> >>
> >> But after a discussion I agree that we can have image dir for images
> >> and work dir for other files like logs, pid, stat???, etc.
> >>
> >> I think we need to add an option to customize work dir too.
> > Maybe for server/service use -D as "work dir" path, and add optional
> > argument "where to chdir" to -d? For example, if i want server/service
> > go daemon, put his logs/pidfiles to DIR1 and chdir to DIR2 i will use:
> > criu service -o logfile --pidfile pidfile -D DIR1 -d DIR2
>
> Guys, let's leave -D option alone with "directory for images" meaning only, OK?
> Ruslan, plz, rework and resend the whole series _as_ _series_ with [PATCH 0/N]
> to obey the mentioned scheme. If we want the special option for work dir, we'll
> be able to add one later, but right now I don't see much point in it. All your
> scenarios can be achieved with the existing optionsi.
Don't forget:
* we need to initialize both IMG_FD_OFF and WORK_DIR_FD_OFF
* stats must be saved in WORK_DIR_FD_OFF
* -d is not only --daemon, it is --restore-detached
* check that zdtm.sh saves all test files in test/dump/tn/pid/
I think all checks about absolute paths are not needed. It's doesn't solve
the problem, because there may be more than these two type of files (e.g.
stat files).
>
> Thanks,
> Pavel
More information about the CRIU
mailing list