It appears that postinst is calling /lib/functions.sh:default_postinst which hangs due to existing (by root locks). There is no reason to call /lib/functions.sh:default_postinst
What I would like is:
a) has this behavior been seen and corrected before (i'm at r50108, slowly migrating to trunk)
b) An explanation for the logic behind this behavior and, if it is normal
c) What, if anything I can do in the Makefile to avoid calling /lib/functions.sh:default_postinst or, change postinst to #!/bin/sh, exit 0
Then the problem is likely with the interaction of nginx and LuCI. Since nginx does not natively support CGI I assume you use some kind of wrapper which might or might not be the culprit. Maybe something leaks FDs across forks, leading to the observed behaviour.
To answer your actual questions
There's been various issues with nginx that required workarounds in LuCI, so maybe it is addressed now.
So; the best / pragmatic approach was to create custom package.mk and opkg.mk for inclusion in the problematic Makefile. This creates a postinst script that just returns, eliminating the lock problem.
My reasons are
a) none of the luci/nginx packages have any reported issues that seem pertinent
b) not enuf info to debug. Additional problems may show up, allowing insight
c) My working revision (r50108) is throwaway, a stepping stone to trunk (I have many custom packages such as xorg and vmware workstation)
d) Allow time for trunk to catch up to this bug
To add a bit more context for the above... the default_postinst() is supposed to be always called, whether or not a package-specific script exits, since it performs key functions. In bypassing it, you also skip running any uci-defaults, enabling and starting the service. Hacking around it is OK to make other progress, but the root cause is what seems worrisome.
Can you emulate the "much larger sequence of install commands" you mentioned before, to determine what earlier package install is taking the locks? Does ps tell you the parent process of the one holding the first lock (i.e. PID 20230 in your first post)?
I already put a wrapper around /bin/lock which dumps the parent process and command line to a logfile to determine just that. The first two (root) locks came from ash, not sure exactly where in the command sequence.
When I revisit, I will make /bin/lock (wrapper) stall to answer the question.
Thanks for the explanation and pointing out that default_postinst is the norm and, the REAL problem is the pre-existing locks.
This seems to be the sort of thing to easily suck up a huge amount of someone else's troubleshooting time , so perhaps also raise an issue/PR in the package repo and see what the maintainer thinks about your suggestion?