SDP-541
Closed
Make 'p4d' rather than 'p4d_N' safe to run.
The SDP supports having multiple instances running on the same
server machine, and thus the admin must always be aware of which
instance they are using.
SDP docs advise using 'p4d_N', where N is the instance name, rather
than simply calling 'p4d'. That ensures you get the correct p4d
version for that instance, and also applies the '-C1' if required
for a given instance.
However, because calling 'p4d_N' rather than simply 'p4d' is at odds
with Core docs, KB articles, and Support recommendations, it can
cause confusion and contribute to where the wrong 'p4d' version is
inadvertantly called.
=== Proposed New Behavior ===
1. The file /p4/common/bin/p4d, which is currently the latest p4d
binary staged for the next planned upgrade of any instance, will be
replaced with a wrapper script. If the $SDP_INSTANCE environment
variable is defined as N, the 'p4d' script will call /p4/N/bin/p4d_N,
thus making SDP operations more consistent with core docs and a
plethora of KB articles. If $SDP_INSTANCE is undefined, it will
exit with a useful error message.
2. The 'verify_sdp.sh' will find *any and all* 'p4d' binaries in the
path, and report them as errors. This will include /p4/common/bin/p4d,
and also any other errant ones, e.g. in /usr/local/bin, /usr/bin,
/usr/sbin/, /opt/perforce/bin, etc. Any binary name 'p4d' will be
deemed an error if found on the path.
3. The 'mdkirs.sh' and 'upgrade.sh' scripts, as well as the Helix
Installer, will be updated accordingly.
4. SDP docs will be updated accordingly.
5. The 'upgrade_sdp.sh' script (not yet in the SDP) will fix this
when upgrading SDP.
The SDP supports having multiple instances running on the same
server machine, and thus the admin must always be aware of which
instance they are using.
SDP docs advise using 'p4d_N', where N is the instance name, rather
than simply calling 'p4d'. That ensures you get the correct p4d
version for that instance, and also applies the '-C1' if required
for a given instance.
However, because calling 'p4d_N' rather than simply 'p4d' is at odds
with Core docs, KB articles, and Support recommendations, it can
cause confusion and contribute to where the wrong 'p4d' version is
inadvertantly called.
=== Proposed New Behavior ===
1. The file /p4/common/bin/p4d, which is currently the latest p4d
binary staged for the next planned upgrade of any instance, will be
replaced with a wrapper script. If the $SDP_INSTANCE environment
variable is defined as N, the 'p4d' script will call /p4/N/bin/p4d_N,
thus making SDP operations more consistent with core docs and a
plethora of KB articles. If $SDP_INSTANCE is undefined, it will
exit with a useful error message.
2. The 'verify_sdp.sh' will find *any and all* 'p4d' binaries in the
path, and report them as errors. This will include /p4/common/bin/p4d,
and also any other errant ones, e.g. in /usr/local/bin, /usr/bin,
/usr/sbin/, /opt/perforce/bin, etc. Any binary name 'p4d' will be
deemed an error if found on the path.
3. The 'mdkirs.sh' and 'upgrade.sh' scripts, as well as the Helix
Installer, will be updated accordingly.
4. SDP docs will be updated accordingly.
5. The 'upgrade_sdp.sh' script (not yet in the SDP) will fix this
when upgrading SDP.
- Status
- Closed
- Project
- perforce-software-sdp
- Severity
- C
- Reported By
- C. Thomas Tyler
- Reported Date
- Modified By
- C. Thomas Tyler
- Modified Date
- Owned By
- tom_tyler
- Component
- core-unix
- Type
- Feature