Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status: 500 Internal Server Error #431

Closed
everloop2 opened this issue Mar 9, 2017 · 35 comments
Closed

Status: 500 Internal Server Error #431

everloop2 opened this issue Mar 9, 2017 · 35 comments

Comments

@everloop2
Copy link
Contributor

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>

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
Copy link
Contributor Author

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
Copy link
Contributor

@everloop2 can you still see this issue?

@torte71
Copy link
Member

torte71 commented Dec 26, 2017

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

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
Copy link
Contributor

SvenRoederer commented Jan 2, 2018

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
Copy link
Contributor

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
Copy link
Contributor

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 freifunk-berlin/firmware-packages@d8a9c5e#diff-1190ed871db168151a64d3f9bd15b0ce

@torte71
Copy link
Member

torte71 commented Jan 2, 2018

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
Copy link
Member

torte71 commented Jan 2, 2018

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link

ghost commented Jan 3, 2018

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
Copy link
Member

torte71 commented Jan 3, 2018

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

@ghost
Copy link

ghost commented Jan 3, 2018

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

@torte71
Copy link
Member

torte71 commented Jan 3, 2018

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

@torte71
Copy link
Member

torte71 commented Jan 6, 2018

@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
Copy link
Member

torte71 commented Jan 7, 2018

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
Copy link
Contributor

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 openwrt/luci@81e80c4. So who is changing these permissions?

thanks for finding this bug and its cause.

@SvenRoederer
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Member

torte71 commented Jan 7, 2018

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
Copy link
Contributor

@torte71 git will also take care of the permissions.

@bobster-galore
Copy link
Contributor

bobster-galore commented Jan 7, 2018

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
Copy link
Member

torte71 commented Jan 7, 2018

@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
Copy link
Contributor

@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
Copy link
Member

torte71 commented Jan 7, 2018

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
Copy link
Contributor

@torte71
Copy link
Member

torte71 commented Jan 7, 2018

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
Copy link
Contributor

SvenRoederer commented Jan 7, 2018

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
Copy link
Contributor

@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
Copy link
Contributor

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

@SvenRoederer
Copy link
Contributor

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

@SvenRoederer
Copy link
Contributor

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.

@SvenRoederer SvenRoederer modified the milestones: Hedy-1.0.0, Hedy-1.1.0 Jan 29, 2018
@everloop2
Copy link
Contributor Author

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"

torte71 added a commit to torte71/firmware that referenced this issue Mar 10, 2018
The openwrt files fetched via "git" already need the correct
permissions.

openwrt/luci#1521
freifunk-berlin#431
torte71 added a commit to torte71/firmware that referenced this issue Mar 14, 2018
If the openwrt files are fetched using "git" on systems with "umask 002",
they get checked out with group-writable permission. This finally leads
to a "500 internal server error" when accessing luci pages, because of
wrong permissions of /usr/share/acl.d/luci-base.json.

See OpenWrt: "Builds with umask != 022 are known to be broken":
openwrt/luci#1521 (comment)

Bugreport and details, how these wrong permissions end up in the image:
freifunk-berlin#431
@bobster-galore
Copy link
Contributor

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

SvenRoederer added a commit that referenced this issue Jan 22, 2019
db18699 batctl: Fix parsing of optional debug table command parameters
a1e1020 luci-app-bmx7: refactory, multiple fixes and add topology graph
a31ebca Merge pull request #429 from ecsv/batadv-2018.4
9345df9 luci-app-bmx7: update version, dependencies and maintainer
a7d7f4b luci-app-bmx7: fix bmx7-info script's indentation
3e259f8 luci-app-bmx7: fix bmx7-info script's "$info" call
3264d15 Merge pull request #431 from rogerpueyo/p4u/luci-app-bmx7/refactory
940d621 Merge branch 'p4u/luci-app-bmx7/refactory'
b6815d5 luci-app-bmx6: Fix URL of network topology JSON file
9bc518e Merge pull request #433 from rogerpueyo/bmx6-graph
2cc3c50 luci-app-bmx6: Fix corner case in bmx6-info?tunnels
a7c4479 Merge pull request #435 from rogerpueyo/bmx6-graph-tunnels
6c63383 luci-app-bmx6: Avoid race condition in bmx6json.lua get()
2c9f89c hnetd: add compatiblity with openssl 1.1.x
fce1287 luci-app-bmx7: show mDNS menu if available
f438333 Merge pull request #438 from cotequeiroz/hnetd_openssl-1.1
29d4160 Merge pull request #437 from rogerpueyo/luci-app-bmx6-graph-sys-exec
SvenRoederer pushed a commit that referenced this issue Apr 6, 2019
If the openwrt files are fetched using "git" on systems with "umask 002",
they get checked out with group-writable permission. This finally leads
to a "500 internal server error" when accessing luci pages, because of
wrong permissions of /usr/share/acl.d/luci-base.json.

See OpenWrt: "Builds with umask != 022 are known to be broken":
openwrt/luci#1521 (comment)

Bugreport and details, how these wrong permissions end up in the image:
#431
SvenRoederer pushed a commit that referenced this issue Apr 7, 2019
If the openwrt files are fetched using "git" on systems with "umask 002",
they get checked out with group-writable permission. This finally leads
to a "500 internal server error" when accessing luci pages, because of
wrong permissions of /usr/share/acl.d/luci-base.json.

See OpenWrt: "Builds with umask != 022 are known to be broken":
openwrt/luci#1521 (comment)

Bugreport and details, how these wrong permissions end up in the image:
#431

cherry-pick from master (47eedf5)
SvenRoederer pushed a commit that referenced this issue May 22, 2019
If the openwrt files are fetched using "git" on systems with "umask 002",
they get checked out with group-writable permission. This finally leads
to a "500 internal server error" when accessing luci pages, because of
wrong permissions of /usr/share/acl.d/luci-base.json.

See OpenWrt: "Builds with umask != 022 are known to be broken":
openwrt/luci#1521 (comment)

Bugreport and details, how these wrong permissions end up in the image:
#431

cherry-pick from master (47eedf5)
SvenRoederer pushed a commit that referenced this issue May 26, 2019
If the openwrt files are fetched using "git" on systems with "umask 002",
they get checked out with group-writable permission. This finally leads
to a "500 internal server error" when accessing luci pages, because of
wrong permissions of /usr/share/acl.d/luci-base.json.

See OpenWrt: "Builds with umask != 022 are known to be broken":
openwrt/luci#1521 (comment)

Bugreport and details, how these wrong permissions end up in the image:
#431

cherry-pick from master (47eedf5)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants