1

It must be some kind of Linux update because all of a sudden, after years of ffmpeg usage with Debian, ffmpeg gets killed without a logic reason. The funny part is there is no trace of killings in log files inside /var/log. Nothing!

The killings are more or less random, sometimes it happens after 1 second, other times after 50 seconds.

While transcoding ffmpeg outputs "Killed" and after few rows it outputs:

Exiting normally, received signal 15.

The same behaviour happens with 4 different machines with Debian, kernel 3.16 and 4.9 with a lot of RAM, so memory is not the issue.

If have tried even with nice but no avail.

This problem is related to Debian only which kills all sort of CPU demanding processes, even GIT or wget.

When compiling h264 libraries I'm getting logged out from Debian. Things are getting worser. Still no log files.

Is there a kind of setting that limits CPU or some other devilry that is ruining my happiness? Is it possible that I'm the only person that has this problem with 4 different Debian systems?

Improve this question
6
  • Signal 15 is SIGTERM. Guess: You are using some incompatible libraries, and the CPU somehow ends up in the signal handler. Try to update all libraries involved, and see if the problem goes away.
    – dirkt
    Jul 3, 2017 at 15:03
  • You are right. I tried the same command on Ubuntu and everything works as expected. So it's an OS related issue.
    – Viktor Joras
    Jul 3, 2017 at 15:06
  • Don't know why it's doing that. Are you using the version from the repository (IIRC, it may be the old, dead, buggy, counterfeit "ffmpeg" from Libav)? You can try downloading a static build of ffmpeg and seeing if that works, and maybe it can help pinpoint the issue.
    – llogan
    Jul 3, 2017 at 22:16
  • I have compiled ffmpeg personally, plus I've tried the static build from johnvansickle.com/ffmpeg. I think it is not ffmpeg's fault it must be something with Debian, on Ubuntu it works fine. The fact is that I tried different Debian machines and versions, from 8.1 to 8.5 and the result is the same. So it must be a systematic Debian's problem.
    – Viktor Joras
    Jul 4, 2017 at 6:45
  • 1
    Is there a cpu time limit? See output of ulimit -a. Are you on a VM or shared hosting? I believe Debian 8 uses systemd, so perhaps view logs via journalctl.
    – llogan
    Jul 4, 2017 at 18:13

2 Answers 2

Reset to default
0

It's typical behavior for images larger than 4000p, if you got a NV GPU try building ffmpeg it from source

Improve this answer
-2

For error shown app recive the kiling signal . You can check log for which app or why app killed ffmpeg

For some app need run after killed we have reswpan setting . When app killed . It will be run again automatically

Improve this answer
3
  • There is no log nowhere. This is the problem. Debian does not log any error, ffmpeg does not log any error. It's the craziest thing I have even seen.
    – Viktor Joras
    Jul 3, 2017 at 14:21
  • You can get full dump of ffmpeq with -report switch
    – MohammadReza moeini
    Jul 3, 2017 at 16:30
  • It's not an ffmpeg error so it does not log anything unusual, it's Linux kernel sending signal 15 to ffmpeg, for unknown reasons. Ffmpeg can only prepare for shutdown and then quits.
    – Viktor Joras
    Jul 3, 2017 at 18:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .