Hi, Ehem... While writing this, I realized that ps is not even piped to mawk...
Here is the code I was running with more detail: MAIN SCRIPT: #!/bin/bash
...
/bin/bash -c -- "
source SCRIPT_LIB monitor_pid || exit -1;
" 2>&1 \
| /usr/bin/gawk "/Rotated/ {next} {print \$0; fflush(\"\")}" 2>&1 \
| /usr/bin/mawk -W Interactive -v "MYNAME=$( /usr/bin/basename
"$FALLBACK" )" -f "$FALLBACK" 2>&1 \
| /usr/bin/tee -a "$fallback" 1>&2 &
... SCRIPT_LIB:monitor_pid { while :
do
while [[ "$( /bin/ls -l --block-size=M "$logfile_basename" |
/usr/bin/tr -s ' ' | /usr/bin/cut -d' ' -f5 | /usr/bin/tr -d
'M' )" -le $max_file_size_MB ]]
do# !!!!PS IS HERE!!!!
local line="$( /bin/ps aux | /bin/grep '^[^ ]\+
\+'"$pid"' \+' | /usr/bin/tr -s ' ' | /usr/bin/cut -d'
' -f3,4,5,6,8,10,11- )"
if [[ -z "$line" ]]
then
return
else
echo "$( get_date_time ) $( echo "$line" | /bin/sed "s,
${cmd_pattern}$,," )"
/bin/sleep "$interval_sec"
fi
done >>"$logfile_basename"
# logfile size is over the limit, rotate
/usr/bin/savelog -t -n -j -c $max_num_keep_file "$logfile_basename"
done
} NOTE1: There are other occurences of ps and mawk in may script, but their
output is saved in separate logfiles, so I am sure that the error logs were
produced these 2 processes. NOTE2: There were 2 instances of this code running
parallel, and BOTH of them produced the same error log (into different
logfiles). So there seems to be a real connection between memory issues, mawk
and ps. I have been running the script for a few months (there were patches
and restarts on the way, though) and I had this problem only once so far. I
have no idea, what causes it. Since the error log says "Cannot allocate memory"
(for the mawk), I suppose, it is connected to the ps error. Before realizing
that ps is not piped to mawk, I had another idea for explanation. It is
probably not a valid train of thoughts, anymore, but I leave it here, maybe it
helps. My other guess was that since the ps output is piped to mawk (I
thought), if mawk fails due to memory issues, ps may hold a freed virtual
memory address, where ps is trying to write, which causes the segfault. I have
observed similar behavior in another test, which more reliably produces the
segfault, but without a call to ps:
https://stackoverflow.com/questions/47012675/bash-trap-and-process-substitution
see: TEST SETUPS:TEST SETUP 1 (1 cat):
Results:... for the segfault. I think, this is all, what I have on this error.
This error report should probably better be treated as a reference, if anyone
else experiences this issue. I do keep track of this, but until it surfaces
again, I'm afraid, I cannot give more details... Best regards,Zoltan
Craig Small <csm...@debian.org> írta:
>Hi, Are you sure it's just a lack of memory causing this problem?It's
>going to be a bit tricky to fix with just a crash message. - Craig
>>
>--Craig Small https://dropbear.xyz/ csmall at :
>enc.com.auDebian GNU/Linux https://www.debian.org/ csmall at :
>debian.orgMastodon: @smalls...@social.dropbear.xyz Twitter:
>@smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B
>DF50 FEA5
