Recherche avancée

Sur d’autres sites (17834)

• fate.sh : Allow setting other make flags for running tests

  21 mai 2013, par Martin Storsjö

  fate.sh : Allow setting other make flags for running tests
  If makeopts_fate is set, these makeopts are used for running the
  
  tests instead of the normal makeopts. If it isn’t set, the normal
  
  makeopts variable is used as before.
  This is useful if remote testing on a lesser machine where a large
  
  number of parallel jobs might be undesireable, while wanting to speed
  
  up the build with many parallel processes.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] doc/fate.texi
  • [DBH] tests/fate.sh

• Long-running AWS Linux process suddenly freezes once in a while

  12 décembre 2022, par Incredi Blame

  I am running a non-stop process on Ubuntu LTS AWS t2.micro instance. Process is ffmpeg downloading network stream from a CCTV. It crashes every 10 min cause of network errors, so I run it in a cycle script like this :

  


  while true
do
    ~command~
done


  


  The cycler-script itself never crashes.

  


  Everything works fine for hours (I check with ssh from time to time). But then sometimes ffmpeg process just freezes. I checked logs, it is writing the stream and it literally freezes mid-way through the stream, no error messages, nothing, as if it is still waiting for the next packet. Just stops working and never wakes up. Usually if the stream goes down ffmpeg complains, spits errors out and crashes. But on this occasion there is nothing and no crash either.

  


  Another mystery is that I run several of such ffmpeg processes and they all freeze at the same time.

  


  The issue with that freezing is the cycler can't restart ffmpegs, as they haven't crashed. When I check frozen processes with ps -aux they are shown as SL, which doesn't tell much, as they are always marked this way. top -i doesn't display them at all as active. When they work as normal it does. If I kill those frozen processes the cycler restarts them and everything works again as it should.

  


  I can always kill those ffmpegs once in a while on some schedule and let cycler restart them. Or check if they froze by timestamps they output and kill them then, so theoretically the problem is solvable. But I just want to know what causes it.

  


  I haven't figured out yet if this freezing happens at the same time of the day, trying to track that now. I don't think it could be related to free space shortage, as I have a cleaner cron job and free space is always available.

  


  So I have the following questions :

  


  

  1. Is there anything on AWS itself which could cause this freezing ? Like some kind of regular maintenance job that messes with running processes ?

  


  2. Could it be caused by Linux freezing long-running processes ? Probably not, as they all freeze at the same time while current running time is different for each.

  


  3. Last one, my cron job that cleans space also cleans out logs that ffmpeg is appending to. The script goes like this :

  


  


  tail "ffmpeg.log" -n 10000 > "tmp.log" && \
    cat "tmp.log" > "ffmpeg.log" && \
    rm "tmp.log"


  


  The logs now are already full and are never fully cleared. Cron job just preserves the last 10000 lines. It runs every 2 min and runs fine for hours. Could it be responsible for this sudden freezing due to some coincidental timing ?

  


  If none of the above is responsible for freezing it must be some streaming issue on the server side, which I have no access to. In that case I would have to rely on detecting freezing and restarting ffmpegs.

  


• qpeg : Add checks for running out of rows in qpeg_decode_inter

  19 septembre 2013, par Martin Storsjö

  qpeg : Add checks for running out of rows in qpeg_decode_inter
  Reported-by : Mateusz "j00ru" Jurczyk and Gynvael Coldwind
  
  CC : libav-stable@libav.org
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavcodec/qpeg.c