# 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