MB process restarts when SB starts recording

[Yianni Vidalis <yiannividalis@…>]

I had noticed the restarts (under systemd the process is set to restart on fail) but that was before I realised they were occuring as the SB was starting recording (the MB is not used for recordings). I tried to run mythbackend under gdb as the normal user but it got "problematic", i.e. I couldn't even access it through mythweb. So I continued running it normally via systemd (which still runs it as a normal user) and then I noticed in the system logs when it was restarting. Sorry for the monologue...

I am enclosing the relevant syslog entry from a restart. "al2kpro" is the name of the SB. If this doesn't help, please let me know and I will try to run the master mythbackend as root to see if it's more responsive.

Master backend system log:

Dec  4 12:40:00 storage mythbackend[7024]: 2012-12-04 12:40:00.057913 E  MythSocket(21b0bb0:63): Got MythEvent on non-event socket
Dec  4 12:40:00 storage mythbackend[7024]: 2012-12-04 12:40:00.057921 E  PlaybackSock::SendReceiveStringList(): No response.
Dec  4 12:40:00 storage mythbackend[7024]: 2012-12-04 12:40:00.061787 E  MythSocket(21b0bb0:63): Got MythEvent on non-event socket
Dec  4 12:40:00 storage mythbackend[7024]: 2012-12-04 12:40:00.061793 E  PlaybackSock::SendReceiveStringList(): No response.
Dec  4 12:40:00 storage mythbackend[7024]: 2012-12-04 12:40:00.061985 C  Received Σ�άλμα κα�ά�μη�η� (segmentation fault): Code 128, PID 0, UID 0, Value 0x3000000002
Dec  4 12:40:00 storage mythbackend[7024]: 2012-12-04 12:40:00.065015 E  Unknown command: al2kpro
Dec  4 12:40:00 storage mythbackend[7024]: 2012-12-04 12:40:00.135154 E  Unknown command: -10
Dec  4 12:40:01 storage systemd[1]: mythbackend.service: main process exited, code=killed, status=11
Dec  4 12:41:31 storage systemd[1]: mythbackend.service stopping timed out. Killing.
Dec  4 12:41:31 storage systemd[1]: mythbackend.service holdoff time over, scheduling restart.
Dec  4 12:41:31 storage systemd[1]: Unit mythbackend.service entered failed state.
Dec  4 12:41:31 storage mythbackend[7264]: 2012-12-04 12:41:31.418891 C  mythbackend version: master [v0.27-pre2-271-gcf5189f-dirty] www.mythtv.org
Dec  4 12:41:31 storage mythbackend[7264]: 2012-12-04 12:41:31.418916 C  Qt version: compile: 4.8.3, runtime: 4.8.3
Dec  4 12:41:31 storage mythbackend[7264]: 2012-12-04 12:41:31.418920 N  Enabled verbose msgs:  general
Dec  4 12:41:31 storage mythbackend[7264]: 2012-12-04 12:41:31.532327 E  No locale defaults file for el_GR, skipping
Dec  4 12:41:32 storage mythbackend[7264]: 2012-12-04 12:41:32.183857 W  Scheduler: Listings source 'HotbirdSat' is defined, but is not attached to a card input.
Dec  4 12:41:32 storage mythbackend[7264]: 2012-12-04 12:41:32.184097 W  Scheduler: Listings source 'AstraSat' is defined, but is not attached to a card input.

MB:

MythTV Version : v0.27-pre2-271-gcf5189f-dirty
MythTV Branch : master
Network Protocol : 76
Library API : 0.27.20121128-1
QT Version : 4.8.3
Options compiled in:
 linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_frontend using_ceton using_hdpvr using_libcrypto using_libfftw3 using_libxml2 using_libudf using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_mheg using_libxml2 using_libudf

SB:

MythTV Version : v0.27-pre2-271-gcf5189f-dirty
MythTV Branch : master
Network Protocol : 76
Library API : 0.27.20121128-1
QT Version : 4.8.1
Options compiled in:
 linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_frontend using_ceton using_hdpvr using_ivtv using_libcrypto using_libfftw3 using_libxml2 using_libudf using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_mheg using_libxml2 using_libudf

If these are not enough and you want gdb logs, what log options should I enter (i.e. network,socket. etc)

Best regards,

Yianni.

[Yianni Vidalis <yiannividalis@…>]

gdb trace.

[Yianni Vidalis <yiannividalis@…>]

mythbackend log with -v database,network,socket

[Yianni Vidalis <yiannividalis@…>]

this time mythtv is compiled as debug type

[yiannividalis@…]

The only four available dvb-t channels in my area are back on the air, and I tested recording using the MB. It doesn't restart when it uses its own cards. Only when the remote SB records something the problem occurs. I'd appreciate if someone took a look in this ticket - if they have any time - because even watching movies stops on the SB when the MB restarts and the kids start looking at me in a funny way!!

Could it be the difference between the Qt versions (4.8.1 vs 4.8.3)?

TIA,

Yianni.

[stuartm]

Potentially related to the mythsocket branch merger.

[Yianni Vidalis <yiannividalis@…>]

The problem seems to have been corrected by applying the second patch of ticket #11316.

Multiple & sequencial 2 min recordings didn't cause the MB proccess to restart. I'll keep testing, though.

[yiannividalis@…]

2 days later and having recorded numerous programs, not a single segfault. The 2nd patch from #11316 has corrected the problem for me.

[yiannividalis@…]

Until today, I still have to patch mythtv to stop the MB process from restarting. Today I tried to run it without the patch to see if things got corrected by one of the other fixed tickets (11318) and I'm afraid it's still broken.

I've got mythtv compiled as debug and I schedule 2 minute long recordings from the inputs on the SB (analogue & hdpvr) and if the MBE is compiled without the patch, it will always restart when I enter the recorded programs screen in mythweb to check if the shows were recorded. I cannot trigger the segfault with the patch I use.

With the imminent 0.27 release, I'm wondering if this problem is not only local to my setup, and I'd appreciate if it got looked at, to avoid problems to those that upgrade to the new release.

I will enclose the backend logs and the gdb.txt from three failures that I tested today. During the tests, I once left the SB unpatched and patched only the MB. It didn't crash.

[stuartm]

Duplicate of #11316