<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 4, 2019 at 2:58 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 3 Jul 2019 22:33:43 -0700, you wrote:<br>
<br>
>On Wed, Jul 3, 2019 at 9:27 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>><br>
>wrote:<br>
><br>
>> On Wed, 3 Jul 2019 17:44:59 -0700, you wrote:<br>
>><br>
>> >Twice now the frontend has frozen. If that were not bad enough, I am<br>
>> unable<br>
>> >to kill it. I have remotely tried to kill it and what I find is a status<br>
>> >message on the main screen saying the program has become unresponsive and<br>
>> >do I want to shut it down.  But with no visible cursor I cannot click on<br>
>> >"Yes" and it does not respond to "Y" from the keyboard. I did a "sudo<br>
>> >shutdown now -r" from the remote and the link was immediately cut but the<br>
>> >myth computer did not shut down. It is as if mythfrontend was blocking all<br>
>> >attempts to close it. I finally held the power button down long enough to<br>
>> >turn the computer off and when I restarted it, all was fine. There is just<br>
>> >a short section in the frontend log between when my wife started watching<br>
>> >her show and the freeze. No log entries after the freeze until the<br>
>> restart.<br>
>> ><br>
>> >Jul  3 07:33:33 NewMyth mythfrontend.real: mythfrontend[1555]: I<br>
>> >CoreContext tv_play.cpp:2532 (HandleStateChange) TV::HandleStateChange():<br>
>> >Changing from None to WatchingRecording<br>
>> >Jul  3 07:33:34 NewMyth mythfrontend.real: mythfrontend[1555]: I<br>
>> >CoreContext tv_play.cpp:2638 (HandleStateChange) TV::HandleStateChange():<br>
>> >Main UI disabled.<br>
>> >Jul  3 07:33:34 NewMyth mythfrontend.real: mythfrontend[1555]: I<br>
>> >CoreContext tv_play.cpp:424 (StartTV) TV::StartTV(): Entering main<br>
>> playback<br>
>> >loop.<br>
>> >Jul  3 07:33:34 NewMyth mythfrontend.real: mythfrontend[1555]: N<br>
>> >CoreContext mythplayer.cpp:2231 (PrebufferEnoughFrames) Player(f): Waited<br>
>> >101ms for video buffers AAAAAAAAAAAAAA<br>
>> >Jul  3 07:33:34 NewMyth mythfrontend.real: mythfrontend[1555]: N<br>
>> >CoreContext mythplayer.cpp:2231 (PrebufferEnoughFrames) Player(f): Waited<br>
>> >203ms for video buffers AAAAAAAAAAAAAA<br>
>> >Jul  3 07:33:34 NewMyth mythfrontend.real: mythfrontend[1555]: N<br>
>> >CoreContext mythplayer.cpp:2231 (PrebufferEnoughFrames) Player(f): Waited<br>
>> >305ms for video buffers LAAAAAAAAAAAAA<br>
>> >Jul  3 07:33:34 NewMyth mythfrontend.real: mythfrontend[1555]: I<br>
>> >CoreContext mythrender_vdpau.cpp:615 (CheckOutputSurfaces) VDPAU: Added 2<br>
>> >output surfaces (total 4, max 4)<br>
>> >Jul  3 07:33:34 NewMyth mythfrontend.real: mythfrontend[1555]: N<br>
>> >CoreContext mythplayer.cpp:2231 (PrebufferEnoughFrames) Player(f): Waited<br>
>> >102ms for video buffers dLAAAAAAAAAAAA<br>
>> >Jul  3 07:35:29 NewMyth mythfrontend.real: mythfrontend[1555]: E Decoder<br>
>> >mythplayer.cpp:3504 (DecoderGetFrame) Player(f): Decoder timed out waiting<br>
>> >for free video buffers.<br>
>> ><br>
>> >Nothing here that means anything to me that tells me what happened or what<br>
>> >to do.<br>
>> ><br>
>> >Ideally someone can help figure out what is causing the freezes but short<br>
>> >of that, how can I shutdown the system?<br>
>> ><br>
>> > What I tried:<br>
>> >sudo kill 1555<br>
>> >sudo kill -9 1555<br>
>> > sudo killall  <a href="http://mythfrontend.re" rel="noreferrer" target="_blank">mythfrontend.re</a><br>
>> > sudo shutdown now -r<br>
>> ><br>
>> >Nothing  above would kill the frontend.<br>
>> ><br>
>> >Allen<br>
>><br>
>> That sounds like something else other than mythfrontend was locked up,<br>
>> like the kernel.  Check syslog.   When that happens, you can get a<br>
>> complete lockup, or it can just make the system very slow, where it<br>
>> takes an hour or two to shutdown.  The latter usually happens when one<br>
>> or more cores of your CPU are locked up or "stalled" by the software<br>
>> running on them.<br>
>><br>
>> What distro is it?  If it is Ubuntu, some of the "magic" keys are<br>
>> enabled, so that in such a situation, you may be able to get the<br>
>> filesystem shut down safely and force a reboot.  Try holding down the<br>
>> Alt key, and the SysReq key (PrintScrn if there is no marked SysReq<br>
>> key), and then with both those keys down, hit and release all these<br>
>> keys in sequence, slowly, with a second or two between keys: REISUB.<br>
>><br>
>> See this page for what all those keys do:<br>
>><br>
>><br>
>> <a href="http://www.ubuntugeek.com/how-to-use-magic-system-request-keys-in-ubuntu-linux.html" rel="noreferrer" target="_blank">http://www.ubuntugeek.com/how-to-use-magic-system-request-keys-in-ubuntu-linux.html</a><br>
>><br>
>> Note that the information on that page is for a very old version of<br>
>> Ubuntu.  The O key (shutdown) does not work for some reason in modern<br>
>> Ubuntus, so you need to use B and have it reboot, and then you can<br>
>> shut it down when the BIOS display comes up if that is what you want.<br>
>><br>
>> You did manage a remote login - did that take longer than usual to<br>
>> work?  Was it slow to respond to commands?<br>
>><br>
>> Another option is to enable the systemd debug console:<br>
>><br>
>> systemctl enable debug-shell.service<br>
>><br>
>> That creates a logged-in root shell on Ctrl-Alt-F9 that comes up early<br>
>> in the boot process and does not go away until as late as possible on<br>
>> shutdown.  It allows you to use Ctrl-Alt-F9 to see what is preventing<br>
>> a shutdown by using "systemctl status" or "systemctl list-units", or<br>
>> any other commands.  However, it is a big security hole as it allows<br>
>> anyone who knows about it to use Ctrl-Alt-F9 to get root access while<br>
>> it is enabled.<br>
>><br>
>> And remember that if you did not get the filesystem shut down properly<br>
>> before you powered off or rebooted the PC, you must do a full<br>
>> filesystem check (fsck -C -f) on all partitions that were mounted at<br>
>> the time.  The easiest way to do that is to have a separate small boot<br>
>> partition on the PC to do it from, so that you do not have the root<br>
>> partition locked.  Or you can use a compatible live DVD or USB stick<br>
>> to boot from - one that has the same or better level of filesystem<br>
>> drivers.  Keep repeating the fsck -C -f command for each partition<br>
>> until there are no more errors reported.<br>
>> _______________________________________________<br>
>><br>
><br>
>Thanks for the reply. I looked at the syslog and other than I am no expert<br>
>on what is normal and what is not the best I can tell the system was<br>
>running just fine except mythfrontend was locked. When I logged in remotely<br>
>it seemed normal. I ran "top" and was able to see normal sort of readouts<br>
>which is how I found the PID of mythfrontend. I ran the sudo kill 1555 and<br>
>it did nothing.  PID 1555 was still running.  The UI on the local display<br>
>(I have two displays, a TV and a LCD display) looked to be working normally<br>
>except there was no cursor. But I could more the invisible cursor over to<br>
>the menu area and click and get drop downs and such. From syslog it looks<br>
>like the system ran a daily cron job after mythfrontend crashed. It seemed<br>
>to terminate normally.I can see my remote login in syslog and I can see<br>
>when that ended, which was when I did the shutdown.<br>
<br>
So you were able to do all the normal things you want on the PC with<br>
no sign of slowdown.  Only mythfrontend seemed to be locked up.<br>
Mythfrontend, like a number of full screen programs, suppresses the<br>
mouse cursor when over its window, so that is normal.<br>
<br>
When killing mythfrontend with a normal kill (no -9), you have to do<br>
it twice.  That seems to be a result of the multithreading of<br>
mythfrontend and is probably a bug, but it has been like that for a<br>
long time.  The normal kill command (kill -15 or kill -SIGTERM) is<br>
only a request to a program for it to terminate itself.  If it has<br>
installed a handler for that signal (which mythfrontend does), the<br>
program can ignore or change what a SIGTERM does.  So next time<br>
mythfrontend locks up, try running the same normal kill <pid> command<br>
twice.<br>
<br>
However, kill -9 should always work.  A kill -9 or kill -SIGKILL is<br>
done by the operating system from outside the program.  The program<br>
has no control of it.  The only time it does not work is if the<br>
program is waiting on some external condition (say in a driver) and<br>
that is not able to be undone by a SIGKILL for some reason.  Then you<br>
can wind up with a dead program that does not exit.  I consider this<br>
to be a bug in the kernel that this can happen, but it is possible. It<br>
can result in the system taking a very long time to shut down if you<br>
try that.  But normally, after one or more long timeouts, the shutdown<br>
should succeed.  Using a Ctrl-Alt-F9 debug console you should be able<br>
to tell it this is what is happening.<br>
<br>
It is possible that your having done only one kill -SIGTERM and that<br>
having left mythfrontend only partially shut down made kill -9 fail<br>
and caused the shutdown problems.  I have never tried that to find<br>
out.<br>
<br>
>I find this set of entries odd.  It starts with the stopping of my remote<br>
>session (dad) and there is nothing of the same sime sequence above that one<br>
>(well there is one).  What is odd is that the time stamp on the second to<br>
>last one before the start is out of time sequence.<br>
><br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopped Stop ureadahead data collection<br>
>45s after completed startup.<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopping Session c1 of user dad.<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopping ACPI event daemon...<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopping RealtimeKit Scheduling Policy<br>
>Service...<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopped target Timers.<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopped Daily Cleanup of Temporary<br>
>Directories.<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopping Session 596 of user dad.<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopping Disk Manager...<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopped target Sound Card.<br>
>Jul  3 07:51:36 NewMyth systemd[1]: Stopping User Manager for UID 1000...<br>
>Jul  3 07:35:06 NewMyth rsyslogd: message repeated 8 times: [ [origin<br>
>software="rsyslogd" swVersion="8.16.0" x-pid="777" x-info="<br>
><a href="http://www.rsyslog.com" rel="noreferrer" target="_blank">http://www.rsyslog.com</a>"] rsyslogd was HU<br>
>Ped]<br>
>Jul  3 07:51:38 NewMyth rsyslogd: [origin software="rsyslogd"<br>
>swVersion="8.16.0" x-pid="777" x-info="<a href="http://www.rsyslog.com" rel="noreferrer" target="_blank">http://www.rsyslog.com</a>"] exiting on<br>
>signal 15.<br>
>Jul  3 07:55:21 NewMyth rsyslogd: [origin software="rsyslogd"<br>
>swVersion="8.16.0" x-pid="821" x-info="<a href="http://www.rsyslog.com" rel="noreferrer" target="_blank">http://www.rsyslog.com</a>"] start<br>
<br>
I agree that this looks odd, but I think it is an artifact of how<br>
rsyslogd handles repeats of the same message.  I would have to dig<br>
into the rsyslog documentation to be sure and it is not worth that as<br>
I am pretty sure it is irrelevant.<br>
<br>
>I am running the latest Mythbuntu<br>
>Ubuntu 16.04.1 LTS<br>
<br>
It is worth upgrading to Ubuntu 18.04 as the updates to systemd and<br>
how startup and shutdown work have made it quite a bit faster and have<br>
also got rid of a number of problems with shutdown that made 16.04<br>
much more likely to lockup while shutting down.  And it is much faster<br>
shutting down if it has a locked up dead program.<br>
_______________________________________________<br><br></blockquote><div>Here is what I did:</div><div>top (to find the PID)</div><div>sudo kill 1555</div><div>top (still running)</div><div>sudo kill 1555</div><div>top (still running)</div><div>sudo kill -9 1555</div><div>ps aux | grep mythfrontend (still running) <br></div>sudo killall  <a href="http://mythfrontend.re">mythfrontend.re</a><br></div><div class="gmail_quote">ps aux | grep mythfrontend (still running)<br></div><div class="gmail_quote">I believe it was at this point I went downstairs and found the popup asking if I really wanted to kill the program but with no cursor I was unable to randomly land on the "Yes" area and it did not respond to a "Y" from the keyboard. The UI was still interactive and I did a right click on the mythfrontend tack on the taskbar and said close. The computer was still acting normally at this time except no cursor. I then went back upstairs to my remote session.</div><div class="gmail_quote">sudo shutdown now -r</div><div class="gmail_quote">Then I went downstairs to the computer and pressed the power button, which normally does a graceful shutdown. Nothing happened so then I held the power button down and the computer turned off.</div><div class="gmail_quote"><br></div><div class="gmail_quote">So as you can see, I did kill PID twice.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I was under the impression that Ubuntu 18.04 would break my LIRC code and become another project to get the system working again. I ran Mythbuntu 8.04 until just this year and never had the problems I have had with the latest install. I thought I had it all fixed but then these two lock ups happened. Very frustrating.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Allen</div></div>