[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: apr_proc_detach and chdir
From:       shathawa () e-z ! net
Date:       2013-01-25 5:22:18
Message-ID: 49260.67.150.169.139.1359091338.squirrel () webmail ! iinet ! com
[Download RAW message or body]

Stefan,
I agree with your review.  UNIX system daemon writing is well documented
in other manuals that startup in '/' is good programming practice for
the reason of dismounting file systems.  This is especially true of
initrd systems, temporary file systems, shared network maps, et. al.

Sincerely,
Steven J. Hathaway

> On Friday 18 January 2013, Javier Castillo II wrote:
>> Looking into the code for apr_proc_detach(int daemonize), it
>> appears that chdir("/") is being run unconditionally.
>>
>> Was there a specific reason that "/" is chosen?
>>
>> I guess it's not much of a big deal, because you can chdir into the
>> directory it should be in after you detach, however, why is this
>> forced into the function to begin with?
>
> I guess that this is to avoid troubles when unmounting file systems.
> If the daemon would not change its working directory explicitly, the
> file system where it was started could not be unmounted until the
> daemon is killed. The assumption is probably that "/" will not need to
> be unmounted. And it is guaranteed to exist.
>
>> At the moment, I am fine with using getcwd and chdir to get back to
>> where I started, however it does seem counter-intuitive.
>>
>> So, I am guessing that this is the expected practice when calling
>> this function, correct? Any insight would be great and any other
>> methods to use with this function to get around it would be
>> appreciated.
>
> Many daemons don't need a specific working directory, so it would seem
> quite likely that many daemon authors would not consider the
> unmounting problem and forget doing a chdir(). Therefore it makes
> sense to do it automatically.
>
>


[prev in list] [next in list] [prev in thread] [next in thread]