gluu server failing to restart after service gluu-server-3.1.1 stop

By: Chris Tomlinson user 15 Jan 2018 at 5:17 p.m. CST

6 Responses
Chris Tomlinson gravatar
New to gluu. Debian 8 Jessie on AWS (ami-b14ba7a7). Following /installation-guide/install/ instructions an initial login seems to work fine. Logout and then: service gluu-server-3.1.1 stop then following /operation/backup/ simple tar of /opt/gluu-server-3.1.1/ and then: service gluu-server-3.1.1 start but now after some time can not login with 503 Service Unavailable. Examining the /opt/gluu-server-3.1.1/opt/gluu/jetty/identity/log/2018_01_15.stderrout.log I see that the slapd is not (yet) available and connection pool can not be established because of connection refused on 1636. I notice that the first time that gluu is started after the apt-get, that slapd appears to start first (based on PIDs) followed by identity, etc. The second time I see that identity, oxauth, oxauth-rp, start and then slapd so it makes sense that identity can't connect to slapd initially. I tried 3.0.2 with similar results: "Failed to load configuration from LDAP". So I conclude I'm doing something wrong consistently. I've followed the preparing guide for the Debian install and tried several times restarting the gluu server and and to a complete uninstall and fresh install and so on. I hope I've given enough info to identify what I'm doing wrong Thanks, Chris
Debian 8.0
closed

Answers

By Michael Schwartz Account Admin 15 Jan 2018 at 6:19 p.m. CST

Copy
Michael Schwartz gravatar
What is the RAM and CPU for this server?

By Chris Tomlinson user 15 Jan 2018 at 6:25 p.m. CST

Copy
Chris Tomlinson gravatar
2 cpus 8 GB - it's a dedicated m4.large with 64GB ebs

By Aliaksandr Samuseu staff 16 Jan 2018 at 3:41 p.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Chris. I suspect you encountered a known issue of 3.1.1. There is a simple test to verify whether it's the case. If next sequence of commands (within container) resolves it until the next restart - that's it: ``` # service gluu-server-3.1.1 login # cd /etc/init.d # ./identity stop # ./oxauth stop # ./idp stop # ./solserver stop # ./solserver start # ./oxauth start # ./identity start # ./idp start ``` In that case the cause of it is messed up services' start up order. Please provide output of next command as well: `# ll /etc/rc3.d/`

By Aliaksandr Samuseu staff 16 Jan 2018 at 3:53 p.m. CST

Copy
Aliaksandr Samuseu gravatar
Had to correct my initial post, the report that was linked was about just IDP not starting properly because its (and only its) service was not provided correct start up priority. I confused it with other case reported by another user before, which they encountered in Xenial package. There is no report for it as its cause is unknown, the only clue is that they'd run `apt-get upgrade` before it happened. It still resulted in rearranged start up priorities for mentioned services, which I believe is issue in your case as well. Had you done any system updates before that happened, Chris?

By Chris Tomlinson user 16 Jan 2018 at 4:04 p.m. CST

Copy
Chris Tomlinson gravatar
I have switched over to Ubuntu 16.04, ami-41e0b93b, and it appears to work in that I can stop, tar backup, and start. I haven't gotten further than that yet. My next step is to install proper certs and go from there. If I get time I'll try the Debian 8 again and send the info you've requested, but as I reported the start order was pretty clearly wrong. In fact it appeared to be alphabetical. When I watch the startup order on Ubuntu, I see oxauth-rp, node, slapd, oxauth, and identity, which makes a lot more sense.

By Aliaksandr Samuseu staff 19 Jan 2018 at 2:11 p.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Chris. Thank you for reporting it, the issue is confirmed and will be fixed at the next release. In case you'll encounter it again prior to that, restarting `oxauth`, `identity` and other core services inside container fixes it till the next restart of the main Gluu service (the cause of it are those services starting before LDAP server is available). I'm closing the ticket, but you can track its status [on Github](https://github.com/GluuFederation/community-edition-setup/issues/400). Sorry for all the trouble.

Post an answer