Status: 500 Internal Server Error

[everloop2]

• effects Builds: master | 0.3.0-rc1 | SAm0815/Hedy-alpha_olsr0903
• LEDE Vanilla Build tested > not effected
• first boot to FFWizard works, appears after FFWizard and later accessing: frei.funk (http://frei.funk/cgi-bin/luci) > "Status Page" ,even if no password is set
• accessing: http://frei.funk/cgi-bin/luci/admin > works and full usable
• everything else (VPN, Olsrd..) is workin > Box up and running (http://monitor.berlin.freifunk.net/host.php?h=cottbus-lausi36)

tried and did not work / already fixed: https://dev.openwrt.org/ticket/19752

• mkdir /etc/syslog-ng.d
• No need for 777, uhttpd just requires files to be world readable, so: chmod -R o+r /www
• chmod -R o+r /www
• chmod o+x /www/cgi-bin/luci
• add package Luci-Splash

Hostname: cottbus-lausi36 Model: Arcor 803 (Easybox803, https://wiki.openwrt.org/toh/astoria/arv752dpw22) Firmware Version: Freifunk Berlin Hedy 1.0.0-olsrd0903-alpha 9a4fd73 r3205-59508e3 / LuCI lede-17.01 branch (git-17.051.53299-a100738) Kernel Version: 4.4.50

Syslog: /usr/lib/lua/luci/dispatcher.lua:380: Failed to execute function dispatcher target for entry '/'. The called action terminated with an exception: /usr/lib/lua/luci/dispatcher.lua:380: Failed to execute function dispatcher target for entry '/freifunk'. The called action terminated with an exception: /usr/lib/lua/luci/dispatcher.lua:380: Failed to execute template dispatcher target for entry '/freifunk/index'. The called action terminated with an exception: /usr/lib/lua/luci/template.lua:55: Failed to execute template 'freifunk/index'. A runtime error occured: /usr/lib/lua/luci/template.lua:55: Failed to execute template 'header'. A runtime error occured: /usr/lib/lua/luci/template.lua:55: Failed to execute template 'themes/bootstrap/header'. A runtime error occured: [string "/usr/lib/lua/luci/view/themes/bootstrap/hea..."]:150: attempt to index local 'boardinfo' (a nil value) stack traceback: [C]: in function 'assert' /usr/lib/lua/luci/dispatcher.lua:380: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:109: in function </usr/lib/lua/luci/dispatcher.lua:108>

• also http://frei.funk/cgi-bin/luci/owm.json is not accessable

Syslog: /usr/lib/lua/luci/dispatcher.lua:380: Failed to execute call dispatcher target for entry '/owm.json'. The called action terminated with an exception: ?:0: attempt to index field 'iwdata' (a nil value) stack traceback: [C]: in function 'assert' /usr/lib/lua/luci/dispatcher.lua:380: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:109: in function </usr/lib/lua/luci/dispatcher.lua:108>

[everloop2]

Bug still there > tested branch: master Freifunk Berlin Hedy 0.3.0-alpha e7b8a36 r3205-59508e3 / LuCI lede-17.01 branch (git-17.051.53299-a100738)

feeds.conf

src-git packages https://github.com/openwrt/packages.git^ed90827282851ad93294e370860320f1af428bb2
src-git luci https://github.com/openwrt/luci.git^a100738163585ae1edc24d832ca9bef1f34beef0
src-git routing https://github.com/openwrt-routing/packages.git^dd36dd47bbd75defcb3c517cafe7a19ee425f0af
src-git packages_berlin https://github.com/freifunk-berlin/firmware-packages.git^3186386056cf52ebea3c7298b0a57fa8eafc851e

[SvenRoederer]

@everloop2 can you still see this issue?

[torte71]

I have the same behaviour as described in the 2nd syslog:

• A runtime error occured: [string "/usr/lib/lua/luci/view/themes/bootstrap/hea..."]:150: attempt to index local 'boardinfo' (a nil value)

LuCi will not open any page, but stop with "500 internal server error".

Happens for me on a PI3 with a self-compiled branch "SAm0815_Hedy-alpha" (checked out today, 2017-12-26 15:00) for TARGET=brcm2708-bcm2710).

As a quick workaround, changing the file

• /usr/lib/lua/luci/view/themes/bootstrap/header.htm

the line

• local boardinfo = util.ubus("system", "board") (https://github.com/openwrt/luci/blob/lede-17.01/themes/luci-theme-bootstrap/luasrc/view/themes/bootstrap/header.htm#L14)

to

• local boardinfo = { hostname = "dummy" }

makes LuCi accessible again.

Running "ubus call system board" from the commandline returns a nice looking set of values (including a non-empty entry for "hostname"), so I guess, there must be a problem with lua and the ubus library.

[SvenRoederer]

so it seems that this is a problem with the ubus-object for these boards util.ubus("system", "board") And is very likely upstream (LEDE) related

[SvenRoederer]

for reference on a TPlink WR1043 boardinfo looks like:

root@Ahof-frieden03:~# ubus call system board
{
        "kernel": "4.4.108",
        "hostname": "Ahof-frieden03",
        "system": "Qualcomm Atheros QCA9558 ver 1 rev 0",
        "model": "TP-Link TL-WR1043N\/ND v2",
        "board_name": "tl-wr1043nd-v2",
        "release": {
                "distribution": "Freifunk Berlin",
                "version": "1.0.0-rc1",
                "revision": "7f42122",
                "codename": "hedy",
                "target": "ar71xx\/generic",
                "description": "Freifunk Berlin Hedy 1.0.0-rc1 7f42122"
        }
}

[SvenRoederer]

also http://frei.funk/cgi-bin/luci/owm.json is not accessable Syslog: /usr/lib/lua/luci/dispatcher.lua:380: Failed to execute call dispatcher target for entry '/owm.json'. The called action terminated with an exception: ?:0: attempt to index field 'iwdata' (a nil value) stack traceback: [C]: in function 'assert' /usr/lib/lua/luci/dispatcher.lua:380: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:109: in function </usr/lib/lua/luci/dispatcher.lua:108>

think this might have been fixed by https://github.com/freifunk-berlin/firmware-packages/commit/d8a9c5eb271ef35f44d0e8d83a46ef400dc98816#diff-1190ed871db168151a64d3f9bd15b0ce

[torte71]

Looks quite similar on a RasPi:

root@kodi3kri:~# ubus call system board
{
        "kernel": "4.4.103",
        "hostname": "kodi3kri",
        "system": "ARMv7 Processor rev 4 (v7l)",
        "model": "Raspberry Pi 3 Model B Rev 1.2",
        "board_name": "rpi-3-b",
        "release": {
                "distribution": "Freifunk Berlin",
                "version": "1.0.0-alpha-SAm0815",
                "revision": "1f0e9de",
                "codename": "hedy",
                "target": "brcm2708\/bcm2710",
                "description": "Freifunk Berlin Hedy 1.0.0-alpha-SAm0815 1f0e9de"
        }
}

[torte71]

About the owm.lua issue: I just replaced "/usr/lib/lua/luci/owm.lua" with the file https://raw.githubusercontent.com/freifunk-berlin/firmware-packages/d8a9c5eb271ef35f44d0e8d83a46ef400dc98816/utils/luci-app-owm/luasrc/owm.lua but it seems not to fix it. Only, that the output now contains linenumbers and filenames:

root@torte-ar150:/usr/lib/lua/luci# owm.lua
/usr/bin/lua: /usr/lib/lua/luci/owm.lua:447: attempt to call field 'arptable' (a nil value)
stack traceback:
        /usr/lib/lua/luci/owm.lua:447: in function 'get'
        /usr/sbin/owm.lua:74: in main chunk
        [C]: ?

[SvenRoederer]

@torte71 @everloop2 if this problem still exists in 0.3.0 or 1.0.0(-rc1) there should be a separate issue for OWM. Having both issues here will not work out.

@torte71 putting this raw lua in place of the precompiled usr/lib/lua/owm.lua will give the linenumbers and exact postion in code, as you have found. And you can even debug there and this probably in interactive mode

[bobster-galore]

How do you manage to keep the lines separate?

You can use ``` as the introducing and outroducing signs, they have to stand alone in their line.

line
line

[ghost]

I didn't come across this issue building branches master, Hedy-1.0.0-rc1 and SAm0815_Hedy-alpha for rpi-3. Is there any particular way to reproduce?

[torte71]

@kehugter : It only shows up after you completed the wizard.

[ghost]

I did it several times without any issue. I filled only the mandatory information.

[torte71]

Weird... I'll do some builds next week, when I am back from journey - maybe this was indeed fixed in the meantime.

[torte71]

@kehugter : The wizard has to be completed (fill in ip range, etc.) until you get to the save&reboot button. After the reboot you'll see the error. Or to shorten it a bit: As soon as the file /etc/config/ffwizard contains the line "option runbefore 'true'" in the "settings" section, it shows up. (Checked with hedy-1.0.0-rc1, "default" and "vpn03")

[torte71]

Found it.

ubus requires its ACL-config files not being group-readable (see line 406): https://git.lede-project.org/?p=project/ubus.git;a=blob;f=ubusd_acl.c;h=4b72663d25aa983cb65b10fae8ba029b099c7c45;hb=HEAD#l406

In our image, the file "/usr/share/acl.d/luci-base.json" has 0664 mode, but needs 0644. You can check via "killall ubusd" - logread will show "Sun Jan 7 13:43:46 2018 daemon.err ubusd[7765]: /usr/share/acl.d/luci-base.json has wrong permissions" After correction permissions, restarting ubusd throws out a nicer "Sun Jan 7 13:44:31 2018 daemon.info ubusd[7793]: loading /usr/share/acl.d/luci-base.json"

And the 500-internal-server error is gone.

[SvenRoederer]

As I can see Kathleen-0.3.0 had ubus-2015-05-25. The code dealing with the permission-check was added to ubus on "Thu, 18 Jun 2015 18:01:17 +0100", so after Kathleen-0.3.0 release.

This check was adapted to LuCI (master and lede-17.01 branch) in https://github.com/openwrt/luci/commit/81e80c4b876e8e68bb8b022c39d0941e2c1ccb56. So who is changing these permissions?

thanks for finding this bug and its cause.

[SvenRoederer]

on my CPE210 (Freifunk Berlin Hedy 1.0.0-rc1 ffb48ca) I can't confirm this finding.

root@ff-tk-spare2:~# ls -l /usr/share/acl.d/luci-base.json -rw-r--r-- 1 root root 91 Dec 30 11:05 /usr/share/acl.d/luci-base.json

it seems to be "ar71xx-generic Build #582" ran on "buildslave02.berlin.freifunk.net". dmesg gives:

[ 0.000000] Linux version 4.4.108 (buildbot@ubuntu) (gcc version 5.4.0 (LEDE GCC 5.4.0 r2993+801-b9a408c) ) #0 Sat Dec 30 10:05:44 2017

can you check on your boxes?

[bobster-galore]

CPE 210 (Hedy 1.0.0-rc1 7f42122 ) is too like svens.

root@host:~# ls -l /usr/share/acl.d/luci-base.json
-rw-r--r--    1 root     root            91 Dec 30 11:05 /usr/share/acl.d/luci-base.json
# and
[    0.000000] Linux version 4.4.108 (buildbot@ubuntu) (gcc version 5.4.0 (LEDE GCC 5.4.0 r2993+801-b9a408c) ) #0 Sat Dec 30 10:05:44 2017

[SvenRoederer]

@bobster-galore

CPE 210 (Hedy 1.0.0-rc1 7f42122 )

0 Sat Dec 30 10:05:44 2017

makes me wonder ... 2 different builds at exact the same time, but with different revisions ????

[torte71]

In our luci-base package the installation is handled by "/openwrt/feeds/luci/luci.mk" (line 169..): https://github.com/openwrt/luci/blob/master/luci.mk#L169 This makefile handles many luci packages, it checks for certain directories in the package and if it finds them, creates them in the install/staging dir and simply copies their content, preserving their current access rights (cp -pR). But these rights have never been set since the checkout. (One of these directories is "root", which contains "usr/share/acl.d/luci-base.json (*1))

So the file mode depends on the default file mode of the build-machine - or is there a trick to get those filemodes via "git"?

[SvenRoederer]

@torte71 git will also take care of the permissions.

[bobster-galore]

notunnel CPE 210 (Hedy 1.0.0-rc1 7f42122 ), seems "ar71xx-generic Build #580" ran on "buildslave02.berlin.freifunk.net"

root@host2:~# ls -l /usr/share/acl.d/luci-base.json
-rw-r--r--    1 root     root            91 Dec 30 11:05 /usr/share/acl.d/luci-base.json
root@host2:~# dmesg | grep build
[    0.000000] Linux version 4.4.108 (buildbot@ubuntu) (gcc version 5.4.0 (LEDE GCC 5.4.0 r2993+801-
b9a408c) ) #0 Sat Dec 30 10:05:44 2017

same, same but different! interesting.

[torte71]

@SvenRoederer : Just checked out via "git clone git://github.com/openwrt/luci" (https as well), and "usr/share/acl.d/luci-base.json" has 0664 mode.

[SvenRoederer]

@torte71 different here:

sven@hypnosis:/tmp/luci/modules/luci-base/root/usr/share/acl.d$ git status Auf Branch master Ihr Branch ist auf dem selben Stand wie 'origin/master'. nichts zu committen, Arbeitsverzeichnis unverändert sven@hypnosis:/tmp/luci/modules/luci-base/root/usr/share/acl.d$ ls -l insgesamt 4 -rw-r--r-- 1 sven users 91 Jan 7 22:42 luci-base.json

[torte71]

gaga...

torte@Pluto:~/openwrt/hedy/y/luci/modules/luci-base/root/usr/share/acl.d$ git status
Auf Branch master
Ihr Branch ist auf dem selben Stand wie 'origin/master'.
nichts zu committen, Arbeitsverzeichnis unverändert
torte@Pluto:~/openwrt/hedy/y/luci/modules/luci-base/root/usr/share/acl.d$ ls -l
insgesamt 4
-rw-rw-r-- 1 torte torte 91 Jan  7 22:36 luci-base.json

[SvenRoederer]

• probably related to systems umask
• also see git config core.filemode (https://stackoverflow.com/a/2518917)

[torte71]

In fact: umask 0022 ; git clone git://github.com/openwrt/luci creates the file as 644

Update the build wiki, or change the makefile?

[SvenRoederer]

just another check: "ar71xx-generic Build #587"; 'Freifunk Berlin Hedy 1.0.0-rc1 5c1dc9d'; build on "wg1337"

Linux version 4.4.108 (pfleger@buildbot) (gcc version 5.4.0 (LEDE GCC 5.4.0 r2993+801-b9a408c) ) #0 Sat Dec 30 10:05:44 2017 root@Ahof-frieden03:~# ls -l /usr/share/acl.d/luci-base.json -rw-r--r-- 1 root root 91 Dec 30 11:05 /usr/share/acl.d/luci-base.json

[SvenRoederer]

@torte71 checking out after setting "umask 0002" results in wrong permissions of checkout:

sven@hypnosis:/tmp/luci_umask$ ls -l modules/luci-base/root/usr/share/acl.d/ insgesamt 4 -rw-rw-r-- 1 sven users 91 Jan 7 22:53 luci-base.json

[bobster-galore]

I checked all my routers unfortunately it's the same revision, same rights, same version.

[SvenRoederer]

I'd like to check with a build from buildslave1 before thinking of next steps.

[SvenRoederer]

As it seems to be intermittent (in some builds) and is very likely not caused by the firmware itself, I'll remove the "Hedy-1.0.0" Milestone.

[everloop2]

setting umask to 0022 before compiling helps

did a clean build for CPE210_v2 (SAm0815_experimental) -> @ luci got: Status: 500 Internal Server Error -> checked umask afterwards: showed 0002 -> set umask to 0022 & "git reset --hard" -> build again -> got some simlink already exist errors (deleted them, think due file permissions of previous build) -> got clean build without "Status: 500 Internal Server Error"

have seen this bug on every build i did after "Kathleen-0.3.0"

[bobster-galore]

Is this issue resolved? There were no more complaints. Can we close it?