36 replies to this topic

[s3n0]

Hi.

 

The enigma2.sh script does not start when booting the set-top box. After booting I only see the OpenPLi wallpaper. But FTP and SSH works. I can to connect via SSH and run the /usr/bin/enigma2.sh shell script manually and then OpenPLi starts and works normally (everything seems to be fine).

 

Does anyone know where the problem may be ? I don't want to do the new OpenPLi 7.3 reflash and configuration .

 

I use the open-multiboot plugin (OpenATV 6.4 is used as the main enigma). Could there be an open-multiboot problem ?

 

What should I check as first ?

 

Thanks.

[WanWizard]

Quite possible.

 

It is started from /etc/inittab, when in runlevel 3.

[s3n0]

Thanks.

 

After booting, the system is in runlevel-3:

root@vusolose:~# runlevel
N 3

But this enigma2.sh script probably won't run. I have to run it "manually" via SSH.

[betacentauri]

You could add something like
echo “test” > /tmp/start.txt
at the start(2. line) of the enigma2.sh. After boot check whether /tmp/start.txt is present.

Maybe e2 crashes at start. Do you see the spinner?
You could try to add a
sleep 10
to enigma2.sh. Maybe network is not up and running or something else.

[Dimitrij]

telnet:

init 4
ENIGMA_DEBUG_LVL=4 enigma2

 

[s3n0]

Thx guys.

 

The init 4 or init 3 commands have no effect because the enigma2 process is not running.

 

I added to the "enigma2.sh" as well as to the "enigma2_pre_start.sh" scripts, new line at the beginning of the scripts:

#!/bin/sh
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Shell script enigma2.sh was started" >> /tmp/e2_startup.log

However, no response. These two scripts do not run at all when booting the system (no record and no file "/tmp/e2_startup.log" was created).

 

It is unnecessary to test the functionality of the "enigma2.sh" script itself, which ensures the start of the enigma2 process / binary. This script still works and also starts Enigma - but only if I start it manually via SSH or Telnet connection. I wrote in the query that this "enigma2.sh" script after boot is not started, so why do you advise me to check if it starts at all ?

 

The error will be deeper somewhere - I think it's a system error. This error could have occurred (I only assume), for example, by interfering with the OpenMultiboot plugin in the Linux boot process. I really don't know where the real cause might be.

 

EDIT:

 

If I start Enigma via SSH with ENIGMA_DEBUG_LVL=4 and then stop the Enigma (CTRL + C shortcut), then the init 3 and init 4 commands have meaning and stop / start the whole Enigma. However, immediately after booting the set-top box, the init 3 and 4 commands have no effect because the enigma2 process is not running yet.

Edited by s3n0, 3 September 2020 - 09:00.

[betacentauri]

Does the file /etc/inittab exists? Please post the content of file.

[s3n0]

# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.
id:3:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin

gui:3:respawn:/usr/bin/enigma2.sh 

 

[s3n0]

I mentioned one important piece of information incorrectly above. Sorry. My fault.

 

After rebooting the set-top box, the command set: init 4; sleep 5; init 3 successfully starts the enigma (script /usr/bin/enigma2.sh).

 

This means that if I try to use init 3 command after booting the set-top box, nothing happens and the runlevel status is reported by the system as "N 3". However, if before that init 3 command, I first switch the system to runlevel-4 (init 4) and then back to runlevel-3 (init 3), then Enigma will start successfully.

 

So now it looks different. It looks like the system will not switch to runlevel-3 after booting the set-top box. After booting, the runlevel status is "N 3", but it should be the correct status "4 3". Or am I wrong ? Uhm ...

Edited by s3n0, 3 September 2020 - 10:34.

[betacentauri]

Looks ok.

I'm no expert, but afaik all scripts in /etc/init.d/rcS and then all scripts for runlevel /etc/rc3.d are executed. Wait means that all scripts have to finish execution before next line (gui:3:respawn:....enigma2.sh) for the runlevel is executed.

 

So either a script in /etc/rc3.d runs infinite or a scripts returns an error code.

Check "ps -w" whether a script is still running. Remove all own scripts if you have some.

[betacentauri]

So now it looks different. It looks like the system will not switch to runlevel-3 after booting the set-top box. After booting, the runlevel status is "N 3", but it should be the correct status "4 3". Or am I wrong ? Uhm ...

N 3 is ok
 

 

runlevel reads the system UTMP file, which defaults to /var/run/utmp when no alternate filename is given, to locate the most recent runlevel record.

The previous and current runlevel from that record are output separated by a single space. If there is no previous runlevel in the record, the letter N will be substituted.

[s3n0]

OK, thank you for your help.

The "ps -w" command showed among the "/etc/rc3.d" scripts that the "/etc/init.d/ntpdate" script is still running.

So that also helped me.

root@vusolose:~# ls -l /etc/rc3.d
lrwxrwxrwx    1 root     root            20 Sep  2 22:47 S01networking -> ../init.d/networking
lrwxrwxrwx    1 root     root            16 Sep  2 22:47 S02dbus-1 -> ../init.d/dbus-1
lrwxrwxrwx    1 root     root            18 Sep  2 22:47 S10dropbear -> ../init.d/dropbear
lrwxrwxrwx    1 root     root            17 Sep  2 22:47 S12rpcbind -> ../init.d/rpcbind
lrwxrwxrwx    1 root     root            21 Jul  5 09:09 S15mountnfs.sh -> ../init.d/mountnfs.sh
lrwxrwxrwx    1 root     root            19 Sep  2 22:47 S19nfscommon -> ../init.d/nfscommon
lrwxrwxrwx    1 root     root            16 Sep  2 22:47 S20autofs -> ../init.d/autofs
lrwxrwxrwx    1 root     root            22 Sep  2 22:48 S20busybox-cron -> ../init.d/busybox-cron
lrwxrwxrwx    1 root     root            23 Sep  2 22:47 S20inetd.busybox -> ../init.d/inetd.busybox
lrwxrwxrwx    1 root     root            19 Sep  2 22:47 S20nfsserver -> ../init.d/nfsserver
lrwxrwxrwx    1 root     root            18 Sep  2 22:47 S20samba.sh -> ../init.d/samba.sh
lrwxrwxrwx    1 root     root            16 Sep  2 22:47 S20syslog -> ../init.d/syslog
lrwxrwxrwx    1 root     root            22 Sep  2 22:47 S21avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx    1 root     root            24 Sep  2 22:48 S30streamproxy.sh -> ../init.d/streamproxy.sh
lrwxrwxrwx    1 root     root            17 Jan  1  1970 S50softcam -> ../init.d/softcam
lrwxrwxrwx    1 root     root            17 Feb  4  2020 S50udpxy -> /etc/init.d/udpxy
lrwxrwxrwx    1 root     root            17 Jan  1  1970 S99ntpdate -> ../init.d/ntpdate
lrwxrwxrwx    1 root     root            22 Jul  5 09:09 S99rmnologin.sh -> ../init.d/rmnologin.sh
lrwxrwxrwx    1 root     root            23 Jul  5 09:19 S99stop-bootlogd -> ../init.d/stop-bootlogd

So the reason for the stopped runlevel-3 was the following script (sym-link):

lrwxrwxrwx    1 root     root            17 Jan  1  1970 S99ntpdate -> ../init.d/ntpdate

The contents of the script from the init.d folder to which the symlink refers are as follows:

#!/bin/sh

sleep 0

[ -x /usr/sbin/ntpdate ] && /usr/sbin/ntpdate -s -u pool.ntp.org

exit 0

I don't know how it got there .

 

Is it possible to BUG in OpenPLi ? Maybe I installed something to update the time (via NTP). And I also don't remember if it's part of OpenPLi or an external package. Or is it really an OpenPLi BUG ? I really don't know.

 

Anyway. So far, I have deleted the sym-link "/etc/rc3.d/S99ntpdate". Now the runlevel-3 system is working and Enigma will start correctly without getting stuck. Thanks again for helping.

Edited by s3n0, 3 September 2020 - 11:21.

[WanWizard]

That is created by the SystemTime plugin.

 

It won't do anything when ntpdate doesn't exist and ntpdate should timeout if the time server can not be reached?

[s3n0]

If I run the command "/usr/sbin/ntpdate -s -u pool.ntp.org" especially after booting the set-top box, via the linux-shell, the time synchronization will not work correctly. Sync will be stuck. But if I interrupt the process (via the terminal with ^C, i.e. keyboard shortcut CTRL+C), and start the synchronization again, then it will run correctly:

root@vusolose:~# /usr/sbin/ntpdate -v -u pool.ntp.org
 3 Sep 12:49:50 ntpdate[659]: ntpdate 4.2.8p10@1.3728-o Sun Jul  5 07:34:42 UTC 2020 (2)
^C
root@vusolose:~# /usr/sbin/ntpdate -v -u pool.ntp.org
 3 Sep 12:50:21 ntpdate[660]: ntpdate 4.2.8p10@1.3728-o Sun Jul  5 07:34:42 UTC 2020 (2)
 3 Sep 12:50:33 ntpdate[660]: step time server 92.240.244.202 offset 5.017976 sec
root@vusolose:~#

(NOTE: the argument "-v" is only for testing purpose, of course I also tried those arguments that are in the init.d script)

 

The error will definitely have something to do with running processes during boot (runlevel-3 startup), when this "ntpdate" synchronization wants to run at the same time. For example, if the network interface or the internet is not already working. Or it could be related to the endless problems of IPv6 in many Enigma distributions. Or anything else ... I don't just want to guess here .

Edited by s3n0, 3 September 2020 - 11:57.

[Dimitrij]

#!/bin/sh

sleep 0

[ -x /usr/sbin/ntpdate ] && /usr/sbin/ntpdate -s -u pool.ntp.org &

exit 0

 

[s3n0]

@Dimitrij thanks, however, running the 'ntpdate' process in the background will not help because it will still get stuck in the background. :-/

 

Why isn't 'ntpd' actually used but 'ntpdate' for time synchronization ? Uhm...

[s3n0]

OK.

 

I uninstalled the "ntpdate" package and installed the "ntpd" package. All done. Everything works as it should :-).

 

Although this "ntpdate" stuck boot issue is not solved by this my solution (using the "ntpd" instead of "ntpdate").

 

It is difficult to assess where the "ntpdate" stuck problem could be. There is probably a bug in the 'ntpdate' binary or its incompatibility with the OpenPLi image (in the library versions used ?). I don't know why just during boot, "ntpdate" stays stuck. Grrrr...

[WanWizard]

Instead of working around it, it might be better to fix it. That begins with the question "why" it gets stuck.

 

Because (virtually) all of my boxes use it, for many years, and I've never seen this issue.

[ccs]

FWIW my ViX boxes are running ntpdate (4.2.8p12-r0.5)

[WanWizard]

ntpdate is build from source in OpenPLi, the version depends on the OE version used. Which in 7.3-release is quite a dated one.

 

However, if this was a common problem in 7.3-release, I guess the forums would have been flooded with "Box doesn't start up" complaints. So for the moment, I rule out the binary in the feed.