Page MenuHomePhabricator

Webservice for tool 'persondata' does not terminate / does not start
Closed, ResolvedPublic


I got just a 502 Bad gateway (no content, just status) from the webserver at /var/run/lighttpd/persondata

I was started a few hours before (14:52 UTC) with "webservice --backend=kubernetes" start and did run fine

because of that 502 Bad gateway I decided to stop the webservice with "webservice stop"

tools.persondata@tools-sgebastion-07:~$ webservice stop
Stopping webservice

Then I started it again, this time without --backend=kubernetes:
tools.persondata@tools-sgebastion-07:~$ webservice start
Starting webservice.........

Still no success, but Status 503 Service Unavailable (but this time with a content, I shall contact the maintainer (which is me).

Looking at the error.log I see a line
2019-03-11 20:19:50: (configfile.c.1154) source: /var/run/lighttpd/persondata line: 631 pos: 1 parser failed somehow near here: (EOL)

No help, since /var/run/lighttpd/persondata does not exists or is not accessible from sgebastion
tools.persondata@tools-sgebastion-07:~$ ls -l /var/run/lighttpd/persondata
ls: cannot access '/var/run/lighttpd/persondata': No such file or directory

The only thing I see is this, and I see it still

tools.persondata@tools-sgebastion-07:~$ kubectl get pods
persondata-676273626-15020 1/1 Terminating 0 1d

Now, after one hour there is no change, kubectl get pods shows the same line.

tools.persondata@tools-sgebastion-07:~$ date
Mon Mar 11 21:06:52 UTC 2019

What else can I do to get a running webservice?

Event Timeline

Wurgl created this task.Mar 11 2019, 9:09 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 11 2019, 9:09 PM

tools.persondata@tools-sgebastion-07:~$ webservice --backend=kubernetes start
Looks like you already have another webservice running, with a gridengine backend
You should stop that webservice by issuing:

webservice --backend=gridengine stop

And then start it again with backend kubernetes by issuing:

webservice --backend=kubernetes start

Okay, I try …

tools.persondata@tools-sgebastion-07:~$ webservice --backend=gridengine stop
Your webservice is not running

No Idea what I can do

bd808 renamed this task from Webservice does not terminate / does not start to Webservice for tool 'persondata' does not terminate / does not start.Mar 11 2019, 10:47 PM
bd808 added a subscriber: bd808.Mar 11 2019, 10:52 PM
$ sudo become persondata
$ cat $HOME/.lighttpd.conf
# Redirects
url.rewrite-once += ( "/persondata/p/(.+)" => "/persondata/person.php?title=$1" )
url.rewrite-once += ( "/persondata/vorname/(.+)" => "/persondata/vorname.php?name=$1" )
url.rewrite-once += ( "/persondata/redirect/(.+)" => "/persondata/redirect.php?title=$1" )

# Directory Listings
$HTTP["url"] =~ "^/persondata/beacon($|/)" { dir-listing.activate = "enable" }

# Auth
server.modules += ( "mod_auth" )
auth.debug = 2
auth.backend = "htpasswd"
auth.backend.htpasswd.userfile = "/data/project/persondata/public_html/admin/.htusers"
auth.require = ( "/persondata/admin/" =>
   "method" => "basic",
   "realm" => "BEACON-Administration",
   "require" => "user=BEACON"

mimetype.assign += (
  ".txt" => "text/plain; charset=utf-8"

The problem is like the mimetype.assign stanza. This is the bug reported at T215683: Debian Stretch lighttpd does not allow overriding existing mimetype.assign values. The "fix" is to remove that section from your config file. The fix we applied in T178601: Add charset=utf-8 by default to lighttpd will take care of the issue that you probably added this for in the first place.

The other issue you seem to have stumbled into is documented at'webservice_stop'_says_service_is_not_running,_but_'webservice_start'_says_service_is_running.

So the full change need is something like:

  • become persondata
  • edit $HOME/.lighttpd.conf to remove the mimetype.assign section
  • webservice stop
  • rm $HOME/service.manifest
  • webservice --backend=kubernetes php7.2 start (or php5.6 if you prefer, but php7.2 will be a bit faster and supported longer)


I was not aware of this one. Worked fine on trusty :-(

Wurgl closed this task as Resolved.Mar 11 2019, 11:49 PM