SDP-575

roadkills_r_us
Closed
The stop_p4d() function reports 'missing server.pid' error with systemd.

On systems on which systemd is used, there is some healthily paranoid
logic in the stop_p4d() function in backup_functions.sh. On systems
that use systemd, stop_p4d first stops the server using the systemd
method.  That sets the systemd status correctly if the service was
running and systemd was able to shut it down.

However, if the service was not started with systemd, then then the
systemd status mechanism will not be aware that e p4d service is
running.  Worse, if systemd is asked to stop a service, and it
doesn't know it was running due to the faulty status indication, it
will not attempt to call the underlying init script to stop the
service, and thus the service will be left running. This could
contribute to database and/or journal corruption in a simple
reboot situation.

Because systemd is thus not terribly reliable at shutting down
services, the SDP script calls the underlying p4d init script
directly after trying it the systemd way, to be darn sure p4d is
well and truly stopped and thus prevent any bad outcomes.

It is this second call that generates the error about the missing
server.pid file, since p4d might already down at that point (but
only if the systemd call succeeded).

So, while the SDP init mechanism will stop p4d reliably, it
generates scary error messages that show up in log files, which
can be disconcerting, and hence this is a bug.

The desired behavior would be to preserve the assurance that p4d
is stopped reliably (regardless of whether the systemd or SysV init
mechanism is used), but avoid generating scary error messages in
the log when the shutdown occurs normally.
Status
Closed
Project
perforce-software-sdp
Severity
C
Reported By
roadkills_r_us
Reported Date
Modified By
tom_tyler
Modified Date
Owned By
tom_tyler
Dev Notes
Fixing this may require that p4d_base exit codes be reviewed.
Component
core-unix
Type
Bug