<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 3:58 AM Jo-Philipp Wich <<a href="mailto:jo@mein.io">jo@mein.io</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">Hi,<br>
<br>
> <br>
>     That loop-kill-all thing should be a kind of last resort really, what's<br>
>     actually needed is some kind of "init 1" procd equivalent which shuts down all<br>
>     services in a more or less clean manner.<br>
> <br>
> <br>
> Oddly enough, the /lib/upgrade/stage2 script has some aspect of this. It<br>
> explicitly shuts down (kill -9) telnet, dropbear, and ash before looping with<br>
> sigTERM, and then again with sigKILL.<br>
> <br>
> I find it very odd that it's explicitly singling out telnet, dropbear, and<br>
> ash. My OpenWRT build doesn't have any of these installed in the first place.<br>
> E.g. I have OpenSSH, and it's jumping straight to kill -9 instead of sending<br>
> sigTERM first like it should.<br>
<br>
These are (in the case of telnet, were) the default services offering shell<br>
access in standard images the sysupgrade script was tailored for.<br>
<br>
The intention is to kill all user shell sessions to prevent interference with<br>
the subsequent upgrade process. An openssh case simply hasn't been added since<br>
it is uncommon, especially on lower end devices.<br>
<br>
The subsequent TERM / KILL loops are a poor mans attempt to cleanly shut down<br>
services. It obviously won't work for things having expensive teardown<br>
procedures (databases, squid proxy, etc.) - those really should be handled<br>
manually by the user before invoking sysupgrade. I mean obviously one can<br>
extend the grace period, but I guess there will always be unhandled cases.<br>
<br></blockquote><div><br></div><div>I merely meant that i thought it odd that instead of using sigTERM on the user-interactable processes, we jump straight to sigKILL.</div><div><br></div><div>I don't really see why singling out the user interactable processes does any good, if they'd be sigTERM and then sigKILL-ed like everything else.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Uhm, yeah sure, we could try writing the image again I guess. But eventually<br>
you have to give up if the storage device simply cannot be written cleanly.<br>
<br></blockquote><div><br></div><div>Of course. Eventually we know it won't succeed, but a flaky storage doesn't necessarily mean a second attempt won't succeed. Or an attempt to write the data in smaller pieces.</div><div><br></div><div>My concern is that one error and giving up will lead to more soft-bricks than two errors and giving up. </div><div><br></div><div>We could bikeshed on this forever though. I merely meant that one retry isn't unreasonable. 50 probably is.</div><div><br></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">
Stuff like umounting external disks, fsync / swapoff etc. come to mind as well<br>
which should be doable at this point.<br>
<br><br></blockquote><div><br></div><div>Right, that's also feasible.</div><div><br></div><div>In fact I don't see any code at all for unmounting existing filesystem mounts. Thanks for pointing that out.</div></div></div>