SDP-804
Open
p4state.sh on case-insensitive servers doesn't find p4d processes to run strace/lsof on.
Reproduction steps:
Rev. SDP/MultiArch/2021.2/28649 (2022/03/03).
The verify_sdp.sh doesn't seem to complain about any misconfiguration:
Verified: Target for P4D= in /p4/1/bin/p4d_1 is correct (/p4/common/bin/p4d_1_bin).
and the running p4d processes show up in 'ps' as /p4/common/bin/p4d_1_bin:
$ ps -ef | grep p4d_1
perforce 16396 1 0 Jun07 ? 00:00:00 /p4/common/bin/p4d_1_bin -C1 -p 1666
perforce 17238 16396 0 12:58 ? 00:00:00 /p4/common/bin/p4d_1_bin -C1 -p 1666
perforce 28203 19552 0 13:31 pts/0 00:00:00 grep --color=auto p4d_1
which p4dstate.sh doesn't find because p4dstate.sh uses p4_vars to set up the environment to run p4dstate in:
/p4/common/bin/p4_vars $SDP_INSTANCE
which sets P4DBIN incorrectly; p4dstate uses P4DBIN to find the p4d processes to lsof/strace:
getpids()
{
printf "ps -e | grep '%s$'" `echo $P4DBIN | sed 's/.*\/\([^\/]*\)$/\1/'` \
| sh \
| sed 's/^[^0-9]*\([0-9]*\)[^0-9]*.*/\1/'
}
so you end up getting no strace/lsof data because the running p4d processes for a -C1 server in SDP use a different binary name, p4d_1_bin:
and not what p4_vars sets for P4DBIN which is p4d_1 (P4DBIN=/p4/1/bin/p4d_1) and is subsequently used in getpids().
I've worked around this locally by manually setting P4DBIN in p4dstate.sh after p4_vars runs:
P4DBIN=/p4/common/bin/p4d_1_bin
which then results in subsequent p4dstate.sh runs finding the p4d processes and running strace/lsof on them,.
We seem to be the ones setting P4D to /p4/common/bin/p4d_1_bin when -C1 is in use:
$ cat /p4/1/bin/p4d_1
#!/bin/bash
P4D=/p4/common/bin/p4d_1_bin
exec $P4D -C1 "$@"
Reproduction steps:
Rev. SDP/MultiArch/2021.2/28649 (2022/03/03).
The verify_sdp.sh doesn't seem to complain about any misconfiguration:
Verified: Target for P4D= in /p4/1/bin/p4d_1 is correct (/p4/common/bin/p4d_1_bin).
and the running p4d processes show up in 'ps' as /p4/common/bin/p4d_1_bin:
$ ps -ef | grep p4d_1
perforce 16396 1 0 Jun07 ? 00:00:00 /p4/common/bin/p4d_1_bin -C1 -p 1666
perforce 17238 16396 0 12:58 ? 00:00:00 /p4/common/bin/p4d_1_bin -C1 -p 1666
perforce 28203 19552 0 13:31 pts/0 00:00:00 grep --color=auto p4d_1
which p4dstate.sh doesn't find because p4dstate.sh uses p4_vars to set up the environment to run p4dstate in:
/p4/common/bin/p4_vars $SDP_INSTANCE
which sets P4DBIN incorrectly; p4dstate uses P4DBIN to find the p4d processes to lsof/strace:
getpids()
{
printf "ps -e | grep '%s$'" `echo $P4DBIN | sed 's/.*\/\([^\/]*\)$/\1/'` \
| sh \
| sed 's/^[^0-9]*\([0-9]*\)[^0-9]*.*/\1/'
}
so you end up getting no strace/lsof data because the running p4d processes for a -C1 server in SDP use a different binary name, p4d_1_bin:
and not what p4_vars sets for P4DBIN which is p4d_1 (P4DBIN=/p4/1/bin/p4d_1) and is subsequently used in getpids().
I've worked around this locally by manually setting P4DBIN in p4dstate.sh after p4_vars runs:
P4DBIN=/p4/common/bin/p4d_1_bin
which then results in subsequent p4dstate.sh runs finding the p4d processes and running strace/lsof on them,.
We seem to be the ones setting P4D to /p4/common/bin/p4d_1_bin when -C1 is in use:
$ cat /p4/1/bin/p4d_1
#!/bin/bash
P4D=/p4/common/bin/p4d_1_bin
exec $P4D -C1 "$@"
- Status
- Open
- Project
- perforce-software-sdp
- Severity
- B
- Reported By
- sgcommon
- Reported Date
- 3 years ago
- Modified By
- C. Thomas Tyler
- Modified Date
- 3 years ago
- Owned By
- sgcommon
- Component
- core-unix
- Type
- Bug
FYI I intend to address this by making an update to p4dstate.sh such that it is SDP-aware but not SDP-dependent.