# The form data below was edited by tom_tyler
# Perforce Workshop Jobs
#
#  Job:           The job name. 'new' generates a sequenced job number.
#
#  Status:        Job status; required field.  There is no enforced or
#                 promoted workflow for transition of jobs from one
#                 status to another, just a set of job status values
#                 for users to apply as they see fit.  Possible values:
#
#                 open - Issue is available to be worked on.
#
#                 inprogress - Active development is in progress.
#
#                 blocked - Issue cannot be implemented for some reason.
#
#                 fixed - Fixed, optional status to use before closed.
#                 
#                 closed - Issue has been dealt with definitively.
#
#                 punted - Decision made not to address the issue,
#                    possibly not ever.
#
#                 suspended - Decision made not to address the issue
#                    in the immediate future, but noting that it may
#                    have some merit and may be revisited later.
#
#                 duplicate - Duplicate of another issue that.
#
#                 obsolete - The need behind the request has become
#                    overcome by events.
#
#  Project:       The project this job is for. Required.
#
#  Severity:      [A/B/C] (A is highest)  Required.
#
#  ReportedBy     The user who created the job. Can be changed.
#
#  ReportedDate:  The date the job was created.  Automatic.
#
#  ModifiedBy:    The user who last modified this job. Automatic.
#
#  ModifiedDate:  The date this job was last modified. Automatic.
#
#  OwnedBy:       The owner, responsible for doing the job. Optional.
#
#  Description:   Description of the job.  Required.
#
#  DevNotes:      Developer's comments.  Optional.  Can be used to
#                 explain a status, e.g. for blocked, punted,
#                 obsolete or duplicate jobs.  May also provide
#                 additional information such as the earliest release
#                 in which a bug is known to exist.
#
# Component:      Projects may use this optional field to indicate
#                 which component of the project a givenjob is associated
#                 with.
#
#                 For the SDP, the list of components is defined in:
#                 //guest/perforce_software/sdp/tools/components.txt
#
#  Type:          Type of job [Bug/Feature].  Required.
#
#  Release:       Release in which job is intended to be fixed.

Job:	SDP-575

Status:	closed

Project:	perforce-software-sdp

Severity:	C

ReportedBy:	roadkills_r_us

ReportedDate:	2020/12/15 12:49:25

ModifiedBy:	tom_tyler

ModifiedDate:	2020/12/30 19:05:28

OwnedBy:	tom_tyler

Description:
	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.

DevNotes:
	Fixing this may require that p4d_base exit codes be reviewed.

Component:	core-unix

Type:	Bug