| 3 years agosgcommon created SDP-804 forp4state.sh on case-insensitive servers doesn't find p4d processes to run strace/lsof on.
Reproduction steps:
Rev. SDP/MultiArch/2...021.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 "$@" « | |
| 6 years agosgcommon committed change 24922 into Add readme to my guest branch | |
| 7 years agosgcommon updated description of review 24619 forCorrect usage and rpc tracking values.
Per the schema for the process table, the values were being written in
the wrong order. They are now written... in the correct order making queries
return the exepcted results for usage and rpc track values.
Test data updated accordingly. « | |
| 7 years agosgcommon updated description of review 24619 forCorrect usage and rpc tracking values.
Per the schema for the process table, the values were being written in the wrong order. They are now written i...n the correct order making queuries return the exepcted results for usage and rpc track values.
Test data updated accordingly. « | |
| 7 years agosgcommon updated files in review 24619 forCorrect usage and rpc tracking values.
Per the schema for the process table, the values were being written
in the wrong order. They are now written... in the correct order making
queuries return the exepcted results for usage and rpc track values. « | |
| 7 years agosgcommon updated files in review 24619 forCorrect usage and rpc tracking values.
Per the schema for the process table, the values were being written
in the wrong order. They are now written... in the correct order making
queuries return the exepcted results for usage and rpc track values. « | |
| 7 years agosgcommon updated description of review 24619 forCorrect usage and rpc tracking values.
Per the schema for the process table, the values were being written
in the wrong order. They are now written... in the correct order making
queuries return the exepcted results for usage and rpc track values. « | |
| 7 years agosgcommon updated description of review 24619 forCorrect usage and rpc tracking values.
Per the schema for the process table, the values were being written
in the wrong order. They are now written... in the correct order making
queuries return the exepcted results for usage and rcp track values. « | |
| 7 years agosgcommon edited reviewers on review 24619 for | |
| 7 years agosgcommon edited reviewers on review 24619 for | |
| 7 years agosgcommon requested review 24619 for Correct usage and rpc tracking values. | |
