apr_proc_detach and chdir

[Javier Castillo II <ca...@tower1.castlecorporation.com>]

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?

It would appear to be an enhancement to leave it up to the developer 
using the function to chdir into the desired directory before or after 
apr_proc_detach() and not force them to chroot before the function call 
or require them to chdir afterwards.

It's only 3 lines of code, and should have a minimal impact on users of 
the function.

For software that parses configurations, then chroots into the required 
path, this would be alright, assuming you start the process with 
permission to chroot, and don't intend to reach out to other paths.

Otherwise, you are left to chdir back to the previous cwd.

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.

Re: apr_proc_detach and chdir

[sh...@e-z.net]

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.
>
>

Re: apr_proc_detach and chdir

[Stefan Fritsch <sf...@sfritsch.de>]

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.