Project

General

Profile

Actions

Bug #16126

closed

Webapp on 6.0 on Ubutun16 doesn't start/is stuck

Added by Nicolas CHARLES about 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
N/A
Category:
Packaging
Target version:
Severity:
Minor - inconvenience | misleading | easy workaround
UX impact:
User visibility:
Getting started - demo | first install | Technique editor and level 1 Techniques
Effort required:
Very Small
Priority:
79
Name check:
To do
Fix check:
To do
Regression:

Description

With openjdk-9-jdk-headless:amd64 9~b114-0ubuntu1 , one CPU, the webapp get stuck at start

=> workaround: use 2 CPU for rudder, as specified in doc https://docs.rudder.io/reference/5.0/installation/requirements.html#_cpu

Rudder-jetty init script states that it doesn't start.
Last log is

file:/var/rudder/tmp/jetty/jetty-rudder.war.dir/webapp/WEB-INF/lib/unboundid-ldapsdk-4.0.7.jar
file:/var/rudder/tmp/jetty/jetty-rudder.war.dir/webapp/WEB-INF/lib/lift-common_2.12-3.3.0.jar
[2019-11-05 23:24:18+0100] INFO  org.reflections.Reflections - Reflections took 132 ms to scan 110 urls, producing 0 keys and 0 values 
INFO Configure inventory processing with parallelism of '1' and queue size of '50'
[2019-11-05 23:24:18+0100] INFO  inventory-processing - Incoming inventory watcher started - process existing inventories
[2019-11-05 23:24:24+0100] DEBUG com.normation.rudder.services.reports.NodeChangesServiceImpl - Get all changes on all rules
[2019-11-05 23:24:24+0100] DEBUG com.normation.rudder.repository.jdbc.ReportsJdbcRepository - Fetching all changes for intervals 2019-11-02T18:00:00.000+01:00/2019-11-03T00:00:00.000+01:00,2019-11-03T00:00:00.000+01:00/2019-11-03T06:00:00.000+01:00,2019-11-03T06:00:00.000+01:00/2019-11-03T12:00:00.000+01:00,2019-11-03T12:00:00.000+01:00/2019-11-03T18:00:00.000+01:00,2019-11-03T18:00:00.000+01:00/2019-11-04T00:00:00.000+01:00,2019-11-04T00:00:00.000+01:00/2019-11-04T06:00:00.000+01:00,2019-11-04T06:00:00.000+01:00/2019-11-04T12:00:00.000+01:00,2019-11-04T12:00:00.000+01:00/2019-11-04T18:00:00.000+01:00,2019-11-04T18:00:00.000+01:00/2019-11-05T00:00:00.000+01:00,2019-11-05T00:00:00.000+01:00/2019-11-05T06:00:00.000+01:00,2019-11-05T06:00:00.000+01:00/2019-11-05T12:00:00.000+01:00,2019-11-05T12:00:00.000+01:00/2019-11-05T18:00:00.000+01:00,2019-11-05T18:00:00.000+01:00/2019-11-06T00:00:00.000+01:00

May be related to https://issues.rudder.io/issues/16004


Files

ubuntu.log (68.7 KB) ubuntu.log Nicolas CHARLES, 2019-11-05 23:14
ubuntu3.log (77.9 KB) ubuntu3.log Nicolas CHARLES, 2019-11-05 23:33

Related issues 1 (0 open1 closed)

Is duplicate of Rudder - Bug #16291: Deadlock when application startsReleasedNicolas CHARLESActions
Actions #1

Updated by Nicolas CHARLES about 5 years ago

jstack output isn't much helpful

Actions #2

Updated by Nicolas CHARLES about 5 years ago

  • Subject changed from Webapp on 6.0 on Ubutun16 is stuck to Webapp on 6.0 on Ubutun16 doesn't start/is stuck
Actions #3

Updated by Nicolas CHARLES about 5 years ago

  • Description updated (diff)
Actions #5

Updated by François ARMAND about 5 years ago

  • Description updated (diff)
  • Assignee set to François ARMAND
  • Severity changed from Critical - prevents main use of Rudder | no workaround | data loss | security to Minor - inconvenience | misleading | easy workaround
  • User visibility changed from First impressions of Rudder to Getting started - demo | first install | Technique editor and level 1 Techniques
  • Effort required set to Very Small
  • Priority changed from 124 to 79

Need to be reproduced (effort is for that, and it should be quite quick to see what blocks afterward).

I'm decreasing the severity a lot, because doc asks for 2 CPU even in the smallest test env.

Actions #6

Updated by Vincent MEMBRÉ about 5 years ago

  • Target version changed from 6.0.0~beta1 to 6.0.0
Actions #7

Updated by François ARMAND almost 5 years ago

  • Is duplicate of Bug #16291: Deadlock when application starts added
Actions #8

Updated by François ARMAND almost 5 years ago

  • Status changed from New to Resolved

It was due to #16291, now corrected

Actions

Also available in: Atom PDF