The following options are valid on POSIX based platforms.

--pidfile[=pidfile]
    Causes a file (by default, .pid) to be created indicating the PID of the running process. If the pidfile argument is not specified, or if it does not begin with /, then it is created in @RUNDIR@.

    If --pidfile is not specified, no pidfile is created.

--overwrite-pidfile
    By default, when --pidfile is specified and the specified pidfile already exists and is locked by a running process, refuses to start. Specify --overwrite-pidfile to cause it to instead overwrite the pidfile.

    When --pidfile is not specified, this option has no effect.

--detach
    Runs as a background process. The process forks, and in the child it starts a new session, closes the standard file descriptors (which has the side effect of disabling logging to the console), and changes its current directory to the root (unless --no-chdir is specified). After the child completes its initialization, the parent exits.

--monitor
    Creates an additional process to monitor the daemon. If the daemon dies due to a signal that indicates a programming error (SIGABRT, SIGALRM, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGXCPU, or SIGXFSZ) then the monitor process starts a new copy of it. If the daemon dies or exits for another reason, the monitor process exits.

    This option is normally used with --detach, but it also functions without it.

--no-chdir
    By default, when --detach is specified, changes its current working directory to the root directory after it detaches. Otherwise, invoking from a carelessly chosen directory would prevent the administrator from unmounting the file system that holds that directory.

    Specifying --no-chdir suppresses this behavior, preventing from changing its current working directory. This may be useful for collecting core files, since it is common behavior to write core dumps into the current working directory and the root directory is not a good directory to use.

    This option has no effect when --detach is not specified.

--no-self-confinement
    By default daemon will try to self-confine itself to work with files under well-known directories determined during build. It is better to stick with this default behavior and not to use this flag unless some other Access Control is used to confine daemon. Note that in contrast to other access control implementations that are typically enforced from kernel-space (e.g. DAC or MAC), self-confinement is imposed from the user-space daemon itself and hence should not be considered as a full confinement strategy, but instead should be viewed as an additional layer of security.

--user
    Causes to run as a different user specified in "user:group", thus dropping most of the root privileges. Short forms "user" and ":group" are also allowed, with current user or group are assumed respectively. Only daemons started by the root user accepts this argument.

    On Linux, daemons will be granted CAP_IPC_LOCK and CAP_NET_BIND_SERVICES before dropping root privileges. Daemons that interact with a datapath, such as ovs-vswitchd, will be granted three additional capabilities, namely CAP_NET_ADMIN, CAP_NET_BROADCAST and CAP_NET_RAW. The capability change will apply even if the new user is root.

    On Windows, this option is not currently supported. For security reasons, specifying this option will cause the daemon process not to start.