<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2019 at 10:51 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 Fri, 12 Jul 2019 07:32:39 -0700, you wrote<br>
<br>
OK, I scanned that thread again and understand what you mean now.  <br></blockquote><div><br></div><div>Great</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>Regarding shutdown timer:<br>
>The evidence is that the standard shutdown timer is 90 seconds and I am<br>
>experiencing about 5 minutes for a shutdown. That suggests that there are<br>
>multiple things hung up and that they are being forced to shutdown in<br>
>series. I don't see a particular difference between forcing a hung program<br>
>to shutdown after 90 seconds or 4 seconds. The question then is there a<br>
>program that will shutdown gracefully and take more than 4 seconds to do<br>
>so.  The other evidence I have is that doing CTRL-ALT-BS restarts in less<br>
>than 4 seconds. That suggests that there is not a program that takes longer<br>
>than 4 seconds to gracefully shutdown and the 4 second timer should be fine.<br>
><br>
>Allen<br>
<br>
Shutdown and Ctrl-Alt-BS (restart X) are two completely different<br>
things.  Shutdown will have to stop all the background tasks that run<br>
on the system.  Restarting X will only affect the GUI programs run<br>
under X.  For shutdown, mythbackend and MySQL/MariaDB have to be shut<br>
down.  They are not affected by restarting X.  So Restarting X taking<br>
only 4 seconds has no bearing on how long shutdown should take.  With<br>
X, the GUI programs are normally running independently from each<br>
other, so they do not need to be shut down in any order.  Indeed, I<br>
have a feeling that shutting down X may kill them without prior<br>
notification, but I have never researched that.<br>
<br>
Shutting down all the background / daemon programs and the system<br>
itself has to be done in a specific and orderly way unless you want to<br>
corrupt things.  So systemd works out what is dependent on what, and<br>
the correct order to shut them down in.  If you have a look at your<br>
/lib/systemd/system/mythtv-backend.service file, you will find that it<br>
has this line:<br>
<br>
After=mysql.service network.target<br>
<br>
That means that at startup, the mythtv-backend.service will not be<br>
started until mysql.service has been started and network.target has<br>
been reached (the first network interface is up).  On shutdown,<br>
systemd reverses that.  It will shut down mythtv-backend.service, and<br>
will wait for that to happen before it will shut down either<br>
mysql.service or the network.  If mysql.service was to be shut down<br>
before mythtv-backend.service, mythbackend might still be trying to<br>
use the database while it was shutting down, and it would be unable to<br>
do that, and that might mean that the database would wind up having<br>
conflicting data in it ie it would be corrupt.  Similarly, if you<br>
force mythtv-backend.service to be shut down before the mythbackend<br>
program has properly shut down, you could be causing corrupt data in<br>
the database.<br>
<br>
When you set the DefaultTimeoutStopSec=4s globally, rather than as an<br>
option for one systemd unit, you are telling systemd that any unit<br>
that takes longer than 4 seconds to shut itself down is to be killed<br>
with a kill -9.  So if, for example, a program is waiting for a disk<br>
to spin up to speed so it can close some files it has on that disk, it<br>
may never be allowed to do that, and those files may be corrupted.<br>
Another example is a program that is waiting for a network connection<br>
to come up again so it can write over it.  This is usually the thing<br>
that causes the longest shutdown delays.  It is not a good idea to<br>
force such programs close with kill -9 unless you know that it is safe<br>
to do so.  And these things depend on exactly what is going on in the<br>
environment.  If you unplug the Ethernet cable to a PC, it will<br>
normally cause a slow shutdown as there will be things waiting for the<br>
network.  And something that is waiting for the network may also be<br>
waiting until after it has used the network to be able to write<br>
critical data to disk.  So under normal conditions, it will shut down<br>
virtually instantly, but being without the Ethernet cable will cause<br>
data corruption unless it is allowed to timeout its network connection<br>
and go on after that.  There is a reason that the<br>
DefaultTimeoutStopSec value defaults to a generous 90 seconds.  So<br>
when you have slow shutdowns, you need to diagnose the problem, work<br>
out which programs or systemd units are causing it, and fix each of<br>
those programs or units individually, to ensure you are not breaking<br>
something.<br>
<br>
If everything is working right, systemd shuts down everything it can<br>
in parallel.  So any unit that is not dependent on other units will be<br>
shut down immediately systemd is told to shut down.  It works its way<br>
back down the tree of dependencies shutting things down as soon as<br>
nothing else is dependent on them.  That setup of dependencies and how<br>
it works is one of the things that 18.04 has had optimised versus<br>
16.04, so 18.04 is capable of shutting down faster, and it also does<br>
not seem to do multiple waits for the same thing in the way 16.04<br>
seems to.<br>
<br>
One of the big culprits in slow shutdowns is mythbackend.  Systemd<br>
sends it only one kill -15 to request it to shut down.  It only partly<br>
shuts down, and then after the TimeoutStopSec timeout, systemd sends<br>
it a kill -9.  If mythbackend is given a second kill -15, like<br>
mythfrontend, it shuts down properly, and quickly.  Fortunately, in<br>
the case of mythbackend, the first kill -15 partial shutdown seems to<br>
be enough to ensure that nothing will be corrupted if systemd later<br>
does a kill -9.  So it appears to be safe to just let that happen, or<br>
to reduce the timeout before the kill -9 is done by overriding the<br>
DefaultTimeoutStopSec value with a TimeoutStopSec setting in the<br>
.service file.  But it is better to workaround the bug by giving<br>
mythbackend two kill -15 requests with a short time between them, as I<br>
posted the code for.  I tried giving two kill -15 signals with no<br>
delay between and that did not work, but it is entirely likely that a<br>
1 second delay between the kill 15 signals is overkill, so if you want<br>
to experiment, you may be able to find a smaller value that will<br>
always work safely.  The sleep command in Ubuntu takes a floating<br>
point number for seconds, so you can wait for a fraction of a second,<br>
but other Linux or Unix versions may not support non-integer values.<br>
<br>
Similarly, with your frozen mythfrontend, if it is not completely<br>
locked up and unkillable as you seem to have seen sometimes, it needs<br>
two kill -15 signals with a short delay between to get it to shut<br>
down.  I get the locked up but not completely frozen problem with<br>
mythfrontend fairly frequently when playing old .wmv files.  And I<br>
have had it once that I can recall when playing a damaged DVB-T<br>
recording file.  Each time, I have just gone to a command prompt,<br>
found the PID for mythfrontend.real and given it two kill -15 signals<br>
and it has shut down.  I am guessing that mythbackend and<br>
mythfrontend.real will have the same problem code that is causing<br>
this, and there is some evidence, from what is in the log files before<br>
and after the second kill -15, that it relates to how they set up<br>
their signal handling code.<br><br></blockquote><div><br></div><div>I am making several assumptions.  When Mythfrontend becomes non responsive and hangs it cannot be killed. CTRL-ALT-BS appeared to hang so I did a shutdown, which took 5 minutes. My assumption was that CTRL-ALT-BS, which I agree is a restart of X, might have timed out and worked if I gave it enough time. I also assumed the change in the timer limit would help CTRL-ALT-BS do it's thing faster. I shall see.</div><div><br></div><div>My system will run for years without shutting down under normal circumstances. With Mythbuntu 8.04 we did an occasional CTRL-ALT-BS when mythfrontend hung up or disappeared.</div><div><br></div><div>I did a test of how long it takes the system to shutdown and it is very difficult to see.  I can see that all the entries in syslog happen within one second. I do not know if things continue to happen past the last syslog entry and the power button takes a long time to go off so not sure my test is meaningful.</div><div><br></div><div>Interestingly, doing CTR-ALT-BS seems to end mythfrontend with a seg fault so I find that strange.</div><div><br></div><div>My plan is to leave the 4 second timer in and see if CTRL-ALT-BS is responsive next time that the system hangs.</div><div><br></div><div>This is where I got the idea <a href="https://askubuntu.com/questions/972460/my-pc-doesnt-shut-down-with-ubuntu-17-10">https://askubuntu.com/questions/972460/my-pc-doesnt-shut-down-with-ubuntu-17-10</a></div><div><br></div><div>Allen</div><div><br></div><div> </div></div></div>