Bug 1471424 - strace 4.18 causes program execution to become stale
strace 4.18 causes program execution to become stale
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: strace (Show other bugs)
26
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dmitry V. Levin
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-15 17:14 EDT by Ali Akcaagac
Modified: 2017-08-09 04:58 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-09 04:58:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ali Akcaagac 2017-07-15 17:14:46 EDT
We're having some scripts here that basicly does this:

;--------------
TRACE="stat" # or stat64
STRACE1="strace -f -qq -e trace=${TRACE} -o ${HOME}/gedanken${VR3}.txt"
${STRACE1} sh "${PDIR}/gedanken${VR3}.sh"
;--------------

or in short:

strace -f -qq -e trace=stat -o somelog.txt sh gedanken.sh
(or stat64)

where gedanken.sh contains some "yum" executions like

yum group install
or
yum download
or
some other stuff that "unfortunately" only yum is capable of.

But coming back to the point...

This stuff above used to work for years...

With todays update we received strace 4.18 and ran into issues that yum became stale after a short while... it's not even possible to sent ctrl+c to break the scripts and thus breaking yum... We had to find all PIDs by issuing ps aux and then kill one stale process after another...

It took us a while to figure out that this is related to the update of strace 4.18 which appeared in testing... we had to downgrade to 4.17 to have our stuff to normally operate again.

I would urgently ask for investigation of the changes within strace because we rely on our framework to operate (as it used to operate before).

We use strace to capture the output for further processing and rely on exactly that output...
Comment 1 Ali Akcaagac 2017-07-15 17:16:57 EDT
Btw: We repeatly tested this issue with upgrading and downgrading strace and are able to reproduce this issue instantly every time... After short operation the straced processes are becoming stale and needs to be shot down via a kill -9 PID instruction (including the childprocesses)... strace 4.17 behaves normally and operates normally...
Comment 2 Dmitry V. Levin 2017-07-15 18:58:40 EDT
yum invocation can do anything depending on its configuration.
Could you provide details, please?  strace output, for example?
Comment 3 Eugene Syromyatnikov 2017-07-25 11:13:05 EDT
(In reply to Ali Akcaagac from comment #0)
> TRACE="stat" # or stat64
On an unrelated note, strace 4.17+ accepts %stat for capturing different variants of the stat syscall.
Comment 4 Ali Akcaagac 2017-08-09 04:57:03 EDT
After further investigation - that's a sorry for the late answer :) - we figured out that the issues have been resolved through further package updates. We initially were able to track down the issues to strace... But it looks like some underlaying libraries may have caused the issue which strace unintendedly triggered... After some weeks of further usage, the issues have never shown up again. So please close the bugreport as NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.