So there are 2 issues actually. First one - the /run/burp directory does not exists after fresh emerge (it won't be created automatically until reboot). I did a bit of digging into the ebuild and noticed it uses newtmpfiles function to install appropriate entry, however it never actually creates the directory. This should be easy to fix by adding "tmpfiles_process burp.conf" to pkg_postinst(). The second issue - apparently burp uses pidfile to make sure that no other instance is running and will try to create it even if running in foreground. The problem is that both burp and start-stop-daemon tries to create the same file, in my case it ends badly for burp: Jun 03 23:54:12 [burp] Could not open lock file /run/burp/burp.server.pid: Permission denied_ Jun 03 23:54:12 [burp] Could not get lockfile._ Jun 03 23:54:12 [burp] Maybe you do not have permissions to write to /run/burp/burp.server.pid._ The easiest way to solve it is to patch the config file and rename pidfile to e.g. burp.server.lock but perhaps it would be better to just let the burp handle the pidfile in the first place (and let in run in background) ?
Thank you for your very detailed bug report! Both issues have been fixed - the ebuilds now invoke tmpfiles_process, and the OpenRC init script now only reads the PID file (which, incidentally, makes its behaviour in this respect consistent with that of the systemd unit). I'll think some more about removing the -F flag from the OpenRC init script to make sure it doesn't break anything.
