With the haproxy init script we've noticed an inversion in the openrc logic that is usually invisible: "" + ebegin 'Stopping haproxy_1' * Stopping haproxy_1 ... + start-stop-daemon --stop --exec /usr/sbin/haproxy --pidfile /run/haproxy_1.pid * start-stop-daemon: no matching processes found + eend 0 'Failed to stop haproxy_1' [ ok ] + for _pid in '$(cat ${pidfile})' + echo 20177 + pidfile=/tmp/tmp.TnWKoXqLzp + default_stop + local func=ssd_stop + case "$supervisor" in + ssd_stop + local _progress= ++ service_get_value command + local startcommand=/usr/sbin/haproxy ++ service_get_value chroot + local startchroot= ++ service_get_value pidfile + local startpidfile=/run/haproxy_1.pid ++ service_get_value procname + local startprocname= + command=/usr/sbin/haproxy + chroot= + pidfile=/run/haproxy_1.pid + procname= + '[' -n /usr/sbin/haproxy -o -n '' -o -n /run/haproxy_1.pid ']' + yesno '' + '[' -z '' ']' + return 1 + ebegin 'Stopping haproxy_1' * Stopping haproxy_1 ... "" notice how pidfile is set to a unique file in temp, and then overwritten a little bit later with the value of startpidfile. The root cause is in rc/sh/start-stop-daemon.sh: "" ssd_stop() { local _progress= local startcommand="$(service_get_value "command")" local startchroot="$(service_get_value "chroot")" local startpidfile="$(service_get_value "pidfile")" [...] pidfile="${startpidfile:-$pidfile}" [...] "" This sets the value unconditionally to the value of startpidfile, but in this case the haproxy init script wants to override it by setting pidfile explicitly.
ssd_start() saves the pidfile setting then ssd_stop() reloads it. If we didn't do this, upgrades of services wouldn't work properly because the upgrade could change the location of the pid file out from under us. Let me know if I can help with the haproxy service script, but I don't thinnk this is an OpenRC issue.
