# The form data below was edited by super-tom_tyler
# Perforce Workshop Jobs
#
# Job: The job name. 'new' generates a sequenced job number.
# Status: Job status; [open/closed/suspended]. Required
# 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.
# Type: Type of job; [Bug/Feature]. Required.
Job: SDP-63
Status: closed
Project: perforce-software-sdp
Severity: C
ReportedBy: UnstoppableDrew
ReportedDate: 2017/04/02 17:25:41
ModifiedBy: super-tom_tyler
ModifiedDate: 2017/04/02 17:25:42
OwnedBy: UnstoppableDrew
Description:
p4master_run operates incorrectly as root.
Hey Tom, I was rebuilding my test server today and I ran into an issue
with the SDP scripts. I’m using the released version from April 8th, and
I discovered if you run p4master_run as root, it fails with a usage message.
After some investigating I was able to find the problem, and I was wondering
if I should offer up a fix on the main branch or the dev branch?
The problem is you grab the instance from $1 then do a shift. Later in the
script, you test if the person running the script is UID 0, and if so, it does:
exec su - $OSUSER –c "$0 $@"
This results in the usage message from p4master_run, and your intended command
doesn't get run. The reason is '$@' no longer contains the instance that was
the first argument, because it got shifted out. I hit this because the crontab
file has the following line at the end:
*/5 * * * * [ -e /p4/common/bin ] && /p4/common/bin/p4master_run ${INSTANCE} /p4/common/bin/p4review.py ${INSTANCE}
If you run p4master_run with "bash –x" you'll see it happen:
+ exec su - p4admin -c '/p4/common/bin/p4master_run /p4/common/bin/p4review.py' 1
It would be even worse if you used the '-c' argument, there's a block that
checks for '-c', makes sure there is something after it, sets a variable CRON
(which is never used), and does another shift, removing the '-c' from $@.
I also noticed all the shell scripts in the crontab file no longer use p4master_run,
and source p4_vars themselves, however, the comment block at the top still says you
need run call the script from p4master_run.
DevNotes:
This job, SDP-63, was originally named job000543.
Type: Bug