MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
It's definitely not seeing the process finish.
Why this is so is a riddle ,wrapped in a mystery, inside an enigma - otherwise known as somewhere in C++ code.
Lots of tracking still to do, I'm afraid.
EDIT. I forgot to add that I can produce a successful eConsole run by doing a screen grab, so at least I can trace a working one at will.
Last edited by birdman; 09-09-21 at 18:12.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
topchippyles (09-09-21),Willo3092 (09-09-21)
It gets weirder....
The install command is fired off with a sync command to follow. I was running a test just now and when it hung I started to look at the log. Sometime later, when I looked back up, the install screen had cleared and I was back at the package list!
For some reason the code had finally read/seen the end of the opkg install and run the sync. No idea yet what is holding it up.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
(some) PROGRESS!!!!
The problem is caused by the fact that when opkg installs the terminal plugin it also fires off a shellinaboxd process (via the postinst script).
Somehow that process is what holds things up.
If you stop it then the "hung" enigma2 immediately drops back to the plugin list.
So, now I just need to figure out how a supposedly separate process group can affect the one which fired it off. But at least I know what I'm looking for now....
Suspicion is that shellinabox still has the pipes open from enigma2.
And yes, that's the problem!
Code:[et8000]: ls -l exe fd lrwxrwxrwx 1 root root 0 Sep 10 23:18 exe -> /usr/bin/shellinaboxd fd: lr-x------ 1 root root 64 Sep 10 23:17 0 -> pipe:[5484] l-wx------ 1 root root 64 Sep 10 23:17 1 -> pipe:[5483] l-wx------ 1 root root 64 Sep 10 23:17 2 -> pipe:[5485] l-wx------ 1 root root 64 Sep 10 23:17 3 -> /run/opkg.lock (de leted) lrwx------ 1 root root 64 Sep 10 23:17 4 -> socket:[4563] lrwx------ 1 root root 64 Sep 10 23:17 5 -> socket:[4565]Code:[et8000]: ls -l exe fd/7{0,4,5} lrwxrwxrwx 1 root root 0 Sep 10 23:15 exe -> /usr/bin/enigma2 lr-x------ 1 root root 64 Sep 10 23:17 fd/70 -> pipe:[5483] l-wx------ 1 root root 64 Sep 10 23:17 fd/74 -> pipe:[5484] lr-x------ 1 root root 64 Sep 10 23:17 fd/75 -> pipe:[5485]
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
abu baniaz (11-09-21),topchippyles (11-09-21),Willo3092 (11-09-21)
Having thought it through the fault lies in shellinabox.
It's the thing which knows it is daemonizing, so should close all file-units as it does so. Indeed, I already have code from a utility I wrote years ago (to daemonize any program - like nohup, but lets you say whether you want a log, and where) that will do it - it's not difficult.
I can't show that this will fix the problem, as I'd need to get the "fixed" package file into the feed for opkg to download, but I can produce a fixed executable and check that it still runs OK.
So I'll get that done...then submit a PR and explanation as to why it is required.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
abu baniaz (11-09-21),Willo3092 (11-09-21)
Built and tested a fix.
Just as well I tested it, as it turns out that something in the rest of the code is decidedly unhappy about units 0, 1, and 2 being closed. Presumably something else gets opened on one (or more) of them (such as the pid file?) and it then has a problem setting up the tty for the terminal (which has to use 0, 1 and 2). (A lack of imagination in the coding?).
So the fix for that is to open /dev/null on them before closing the rest of the units. This will ensure that any pipes onto the original tty (the problem here) get shut and so the other end gets told about it.
EDIT:
Code:https://github.com/oe-mirrors/shellinabox/pull/1
Last edited by birdman; 11-09-21 at 18:29.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
abu baniaz (11-09-21),Willo3092 (14-09-21)
Not sure how likely this PR is to be activated.
It's against a fork in oe-mirrors that is just a copy of another repository (no changes).
So I've submitted the PR to that original repository as well.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
Willo3092 (14-09-21)
I'm not surprised, but the second PR is being ignored as well.
I'm now looking at the possibility of putting in a patch to apply the fix as OpenVix is built.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
Willo3092 (20-09-21)
Despite poking both PRs I've still heard nothing back.
But, I have worked out how to apply the patch from an OpenVix-specific part of oe-alliance-core.
In meta-oe-alliance/meta-oe/recipes-distros/openvix I created a shellinabox-fix directory. This contains shellinabox.bbappend (which adds the patch to SRC_URI and prepends this location to the file search with FILESEXTRAPATHS - spent some time tracking down that this needed to be done, and how to do it...) and a shellinabox sub-dir containing the patch.
If I submit this as a PR for oe-alliance-core is it likely to get accepted?
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
Even I have made some changes to the OpenViX distro - so Yes it is possible.
Gigablue Quad 4K & UE 4K
.........FBC Tuners:
------------------> GT-Sat unicable LNB to 1.5M dish(28.2E)
------------------> Gigablue unicable LNB to 80 cm dish(19.2E)
.......................
Vu+ Uno4KSE, Dreambox dm900
AX HD61, Edision Osmio 4K+, Zgemma H9Combo, Octagon SF8008 , gbtrio4k, h9se using unicable ports
Zgemma H9 C/S into Giga4K
Last edited by birdman; 21-09-21 at 18:27.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
Changes to the OpenVix enigma2 aren't the issue.
This is a change to the build configuration, so needs to go into oe-alliance-core. Given that oe-mirrors is ignoring the change, why would oe-alliance-core do anything, when all they actually need to do now is sync the mirror?
Then there is also the issue of whether this should be in an OpenVix-specific location within oe-alliance-core (it's self-contained, so can go anywhere that a *.bb file could go) or in a generic location.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
I have posted Schimmelreiter asking him to also update mirror
Gigablue Quad 4K & UE 4K
.........FBC Tuners:
------------------> GT-Sat unicable LNB to 1.5M dish(28.2E)
------------------> Gigablue unicable LNB to 80 cm dish(19.2E)
.......................
Vu+ Uno4KSE, Dreambox dm900
AX HD61, Edision Osmio 4K+, Zgemma H9Combo, Octagon SF8008 , gbtrio4k, h9se using unicable ports
Zgemma H9 C/S into Giga4K
birdman (22-09-21)