search

lu-zero / bmdtools

Basic capture and play programs for Blackmagic Design Decklink
Boost Software License 1.0
198 stars 74 forks source link

bmdcapture doesn't register any signal handler #77

Closed advera68 closed 8 years ago

advera68 commented 8 years ago

Dear Friend,

We have realized that 'bmdcapture' process does not register any signal handler, for example, suposse bmdcapture process has PID = 15372

cat /proc/15372/status

.... SigCgt: 0000000180000000 ......

What in binary means 110000000000000000000000000000000 , i.e, no handler ofr any signal.

Do you think this issue could be the reason of what I told you some weeks ago ?

https://github.com/lu-zero/bmdtools/issues/76#issuecomment-239407932

I have modified my scripts using "/home/tv/Blackmagic_DeckLink_SDK_10.6.5/Linux/Samples/bin/x86_64/Capture" instead "bmdcapture", only to test, and I have realized no "oops kernel state" occurs using Capture instead "bmdcapture"

As we have realized Capture process does have handler for several signals, we have thought this could be the reason for the different behaviour.

What do you think?

Regards.

lu-zero commented 8 years ago

Strange, set_signal() should be called so at least those signals should be registered..

advera68 commented 8 years ago

Interessting .... could you check it in one Ubuntu server ?

I have three servers with the same behavior, all of them are Ubuntu, Ubuntu 16.04 LTS or Ubuntu 14.04.1 LTS.

As a matter on fact, this issue hasn't been discovered by me, but by developer@blackmagicdesign.com . When I reported this issue with the sporadic kernel Oops they suggested to me trying with "Capture" and they were who really realized about the difference between signal handlers.

If you have something new, please, let me know.

Best regards.

lu-zero commented 8 years ago

If you comment out set_signal does anything change?

On Mon, Sep 12, 2016 at 2:46 PM, advera68 notifications@github.com wrote:

Interessting .... could you check it in one Ubuntu server ?

I have three servers with the same behavior, all of them are Ubuntu, Ubuntu 16.04 LTS or Ubuntu 14.04.1 LTS.

As a matter on fact, this issue hasn't been discovered by me, but by developer@blackmagicdesign.com . When I reported this issue with the sporadic kernel Oops they suggested to me trying with "Capture" and they were who really realized about the difference between signal handlers.

If you have something new, please, let me know.

Best regards.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lu-zero/bmdtools/issues/77#issuecomment-246335965, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOlpNxQFuvsJRdSidufSZiGfsbof4I9ks5qpUmUgaJpZM4J6gVx .

advera68 commented 8 years ago

Yes, it does, but if I'm allowed I'm going to explain what I have in the two environments that I have.

On the other hand I observed Capture process registers 0000000180004003 , i.e SIGHUP, SIGINT, and SIGTERM.

I used to stop bmdcapture with kill -9, ... I don't know it it has anything to do but I assure doing like this it turned the system in Oops state in one week or one week and a half.

As it seems to be this state doesn't occur using Capture and the treatment of the signal is different, I have decide to add signal(SIGHUP , exit_handler); to set_signal() in order to have the same behaviour than Capture, and stop 'bmdcapture' process using kill -15 instead of kill -9.

We can keep in touch, if you want.

Best Regards.

lu-zero commented 8 years ago

I'll have a look soon about sighup and what they did in capture soon.

On Sep 13, 2016 1:24 PM, "advera68" notifications@github.com wrote:

Yes, it does, but if I'm allowed I'm going to explain what I have in the two environments that I have.

-

2 production SERVERS with Ubuntu 14.04.1 , SDK 10.3.1, bmdcapture.cpp doe not have set_signal() function. /proc/.../status -> SigCgt: 0000000180000000 (i.e, no signal)

1 test SERVER with Ubuntu 16.04 LT, SDK 10.6.5, bmdcapture.cpp has got set_signal() function. /proc/.../status -> SigCgt: 0000000180004002 (i,e signal(SIGINT , exit_handler); signal(SIGTERM, exit_handler); what is written in bmdcapture.cpp ) , by the way, if I comment out set_signal() then /proc/.../status informs SigCgt: 0000000180000000 (i.e, no signal). So, it works properly.

On the other hand I observed Capture process registers 0000000180004003 , i.e SIGHUP, SIGINT, and SIGTERM.

I used to stop bmdcapture with kill -9, ... I don't know it it has anything to do but I assure doing like this it turned the system in Oops state in one week or one week and a half.

As it seems to be this state doesn't occur using Capture and the treatment of the signal is different, I have decide to add signal(SIGHUP , exit_handler); to set_signal() in order to have the same behaviour than Capture, and stop 'bmdcapture' process using kill -15 instead of kill -9.

We can keep in touch, if you want.

Best Regards.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lu-zero/bmdtools/issues/77#issuecomment-246651626, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOlpON_jIgUm8NfeUyS8uxJFoY-3czcks5qpofugaJpZM4J6gVx .

advera68 commented 8 years ago

Hi Luca, just to tell you I think the modifications done to 'bmdcapture' have fixed the problem which turned the kernel in Oops state. As I told you in the previous post I added SIGHUP to set_signal() and I stop 'bmdcapture' which 'kill -15'.

My server has been working like this for more than one month and never entered in Oops state, capturing video continuously and stopping as events were written in Marina AsrunLog, so, if you don't mind I will close this issue.

Thanks a lot.

Best Regards.

lu-zero commented 8 years ago

I'll add the HUP handler to cleanly exit as well. Sorry for the delay.