Daemonize should have a configurable working path

[jamesmunns]

What is the problem your feature solves, or the need it fulfills?

Currently, when pingora is configured to daemonize, it uses Daemonize::new() as the base configuration:

pingora/pingora-core/src/server/daemon.rs

Lines 56 to 114 in 42a847d

	/// Start a server instance as a daemon.
	pub fn daemonize(conf: &ServerConf) {
	// TODO: customize working dir
	let daemonize = Daemonize::new()
	.umask(0o007) // allow same group to access files but not everyone else
	.pid_file(&conf.pid_file);
	let daemonize = if let Some(error_log) = conf.error_log.as_ref() {
	let err = OpenOptions::new()
	.append(true)
	.create(true)
	// open read() in case there are no readers
	// available otherwise we will panic with
	// an ENXIO since O_NONBLOCK is set
	.read(true)
	.custom_flags(libc::O_NONBLOCK)
	.open(error_log)
	.unwrap();
	daemonize.stderr(err)
	} else {
	daemonize
	};
	let daemonize = match conf.user.as_ref() {
	Some(user) => {
	let user_cstr = CString::new(user.as_str()).unwrap();
	#[cfg(target_os = "macos")]
	let group_id = unsafe { gid_for_username(&user_cstr).map(|gid| gid as i32) };
	#[cfg(target_os = "freebsd")]
	let group_id = unsafe { gid_for_username(&user_cstr).map(|gid| gid as u32) };
	#[cfg(target_os = "linux")]
	let group_id = unsafe { gid_for_username(&user_cstr) };
	daemonize
	.privileged_action(move || {
	if let Some(gid) = group_id {
	// Set the supplemental group privileges for the child process.
	unsafe {
	libc::initgroups(user_cstr.as_ptr() as *const libc::c_char, gid);
	}
	}
	})
	.user(user.as_str())
	.chown_pid_file(true)
	}
	None => daemonize,
	};
	let daemonize = match conf.group.as_ref() {
	Some(group) => daemonize.group(group.as_str()),
	None => daemonize,
	};
	move_old_pid(&conf.pid_file);
	daemonize.start().unwrap(); // hard crash when fail
	}

However, this selects the system root, e.g. /, as the new working path for the daemonized process:

https://github.com/knsd/daemonize/blob/c270c91354524b6d750dc3cecfbf3d21dcec508c/daemonize/src/lib.rs#L259-L275

This means that if the pidfile is specifed as a relative path, e.g. ./river.pidfile, it will try to create the pidfile in the system root, e.g. /river.pidfile. This will often fail, and was confusing to me until I used strace to figure out what it was actually trying to do:

56466 statx(AT_FDCWD</mnt/share/vmshare/contracts/isrg/river/source/river>, "./testdir/river.pidfile", AT_STATX_SYNC_AS_STAT, STATX_ALL,  <unfinished ...>
56467 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=10000000},  <unfinished ...>
56466 <... statx resumed>0xffffd704c260) = -1 ENOENT (No such file or directory)
56466 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xffffa66810f0) = 56468
56468 set_robust_list(0xffffa6681100, 24 <unfinished ...>
56466 wait4(56468,  <unfinished ...>
56468 <... set_robust_list resumed>)    = 0
56468 chdir("/")                        = 0
56468 setsid()                          = 56468
56468 umask(007)                        = 022
56468 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD <unfinished ...>
56469 set_robust_list(0xffffa6681100, 24 <unfinished ...>
56468 <... clone resumed>, child_tidptr=0xffffa66810f0) = 56469
56469 <... set_robust_list resumed>)    = 0
56468 sigaltstack({ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=16384},  <unfinished ...>
56469 openat(AT_FDCWD</>, "./testdir/river.pidfile", O_WRONLY|O_CREAT, 0666 <unfinished ...>
56468 <... sigaltstack resumed>NULL)    = 0
56469 <... openat resumed>)             = -1 ENOENT (No such file or directory)

The relevant lines are:

# the parent process changes to the root directory
56468 chdir("/")                        = 0
# the child process attempts to open the pidfile at that root path
56469 openat(AT_FDCWD</>, "./testdir/river.pidfile", O_WRONLY|O_CREAT, 0666 <unfinished ...>

We can see the current working directory is /, and the path to open is ./testdir/river.pidfile.

This might also affect the upgrade socket path in addition to the pidfile.

Describe the solution you'd like

We should likely do one or both of two things:

1. Allow the configuration of the working directory of the daemonized process, having a configuration that perhaps defaults to the host process' current working directory if not otherwise set
2. Canonicalize the paths prior to forking, turning them into absolute paths relative to the working directory of the host process

Describe alternatives you've considered

We could also refuse to accept relative paths at all for both of these configuration values, but this may impact other configuration paths in the future.

Additional Context

CC memorysafety/river#50