Re: rcs configure hang
Hi Paul,
With kill -14 91418, I don't see any output add to tr.
% ps -elf | grep strace
0 S kellythw480 1 0 80 0 - 58957 - Nov05 ?00:00:00
strace -o tr ./a.out
0 S kellythw 3760 1 0 80 0 - 58957 - Nov05 ?00:00:00
strace -o tr ./a.out
0 S kellythw 15709 1 0 80 0 - 58957 - Nov05 ?00:00:00
strace -o tr ./a.out
0 S kellythw 93336 91418 0 80 0 - 58957 - 08:14 pts/900:00:00
strace -o tr ./a.out
% tail tr
chdir("confdir3") = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3") = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3") = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3") = 0
mkdir("confdir3", 0700) = 0
chdir("confdir3") = 0
mkdir("confdir3", 0700
Is server issue? should I change to other rhel8 server and try the same?
Thanks,
Kelly
If you need support for DevX Tools: http://devxsupport.cisco.com/
Specifically, for NXOS, see -
https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools
On 11/5/20, 2:52 PM, "Paul Eggert" wrote:
On 11/5/20 2:28 PM, Kelly Wang (kellythw) wrote:
> When strace hang, I do 'ps -elf | grep strace' from other terminal and do
kill -9
> kill -s INT $(ps -o pid= -C a.out) looks like not working from my server.
Assuming you're using the Linux kernel signal numbers, you should be able
to get
a process ID (say, 4729) and use this:
kill -2 4729
instead of the fancier 'kill' command I suggested. Also, try this in
another
session:
kill -14 4729
which sends the ALRM signal instead of the INT signal. Either way, see what
'tr'
says.
Re: rcs configure hang
On 11/6/20 8:20 AM, Kelly Wang (kellythw) wrote: Is server issue? should I change to other rhel8 server and try the same? It does sound like some sort of server or filesystem problem, yes. The mkdir syscall does not finish and refuses to be interrupted. I don't see any way to modify Gnulib to work around the problem automatically. However, you should be able to sidestep the problem with something either like this: ./configure gl_cv_func_getcwd_path_max=no or like this: ./configure gl_cv_func_getcwd_path_max=yes It's not clear to me which of these workarounds would be better for your system. Didn't we have this same conversation a year ago, with GNU tar, which uses the same Gnulib module? Are you building now on the same system you used a year ago? https://lists.gnu.org/r/bug-tar/2019-10/msg1.html https://lists.gnu.org/r/bug-tar/2019-10/msg2.html https://lists.gnu.org/r/bug-tar/2019-10/msg3.html Reviewing that earlier conversation prompts me to ask: are you building on a Samba filesystem? There seems to be a problem in this area that is reportedly fixed by upgrading to a newer version of Samba, or by fiddling with Samba settings (not clear). See: https://www.cs.rug.nl/~jurjen/ApprenticesNotes/tstcg_tar.html which is part of: https://www.cs.rug.nl/~jurjen/ApprenticesNotes/testing_samba_to_compilation_grade.html
Re: rcs configure hang
Hi Paul, With ./configure gl_cv_func_getcwd_path_max=no, the step passed without hanging. I was able to get rcs configure, make and installed. Just need to verify if 5.10.0 fix ci/co problem among our team. I don't think we have conversation for GNU tar before and the rhel8 server that I am building rcs base on is a new system. Thanks so much for all your help! Thanks, Kelly If you need support for DevX Tools: http://devxsupport.cisco.com/ Specifically, for NXOS, see - https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools On 11/6/20, 9:41 AM, "Paul Eggert" wrote: On 11/6/20 8:20 AM, Kelly Wang (kellythw) wrote: > Is server issue? should I change to other rhel8 server and try the same? It does sound like some sort of server or filesystem problem, yes. The mkdir syscall does not finish and refuses to be interrupted. I don't see any way to modify Gnulib to work around the problem automatically. However, you should be able to sidestep the problem with something either like this: ./configure gl_cv_func_getcwd_path_max=no or like this: ./configure gl_cv_func_getcwd_path_max=yes It's not clear to me which of these workarounds would be better for your system. Didn't we have this same conversation a year ago, with GNU tar, which uses the same Gnulib module? Are you building now on the same system you used a year ago? https://lists.gnu.org/r/bug-tar/2019-10/msg1.html https://lists.gnu.org/r/bug-tar/2019-10/msg2.html https://lists.gnu.org/r/bug-tar/2019-10/msg3.html Reviewing that earlier conversation prompts me to ask: are you building on a Samba filesystem? There seems to be a problem in this area that is reportedly fixed by upgrading to a newer version of Samba, or by fiddling with Samba settings (not clear). See: https://www.cs.rug.nl/~jurjen/ApprenticesNotes/tstcg_tar.html which is part of: https://www.cs.rug.nl/~jurjen/ApprenticesNotes/testing_samba_to_compilation_grade.html
