-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
Platform: All, OS: All
After an upgrade from 1.318 to 1.321, I get messages like these on the console
every 10 seconds:
Aug 25, 2009 2:06:32 PM hudson.triggers.SafeTimerTask run
SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@8905bd failed
java.lang.NoClassDefFoundError: Could not initialize class hudson.model.ComputerSet
at hudson.model.Hudson.getComputer(Hudson.java:1253)
at hudson.model.LoadStatistics$LoadStatisticsUpdater.doRun(LoadStatistics.java:204)
at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Aug 25, 2009 2:06:35 PM hudson.triggers.SafeTimerTask run
SEVERE: Timer task hudson.slaves.NodeProvisioner$NodeProvisionerInvoker@1b595f3
failed
java.lang.NoClassDefFoundError: Could not initialize class hudson.model.ComputerSet
at hudson.model.Hudson.getComputer(Hudson.java:1253)
at
hudson.model.OverallLoadStatistics.computeIdleExecutors(OverallLoadStatistics.java:54)
at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:157)
at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:52)
at
hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:213)
at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
[JENKINS-4306] SEVERE: Timer task {...} failed (Could not init class ComputerSet)
torbent
created issue -
torbent
made changes -
| Resolution | New: Cannot Reproduce [ 5 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
torbent
added a comment - Closing. Seems unlikely to be interesting anymore. torbent
made changes -
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
public_void
added a comment - I'm reopening because I was experiencing exactly the same symptoms but the
proposed fix wasn't applicable in my case. I didn't
even have the incriminated plugin (Promoted Builds) installed.
I'm using Hudson 1.324 on a Tomcat 5.5 container in a Ubuntu server.
It turned out that the problem was once again related to security.
First of all, I noticed that turning off TOMCAT_SECURITY immediately solves
the problem; but I couldn't afford such a risk, so I kept TOMCAT_SECURITY
on, and of course, added the following grant code in
/etc/tomcat5.5/policy.d/04webapps.policy :
grant codeBase "file:/var/lib/tomcat5.5/webapps/hudson/-" {
permission java.security.AllPermission;
};
... as explained in the wiki:
http://wiki.jenkins-ci.org/display/JENKINS/Tomcat#Tomcat-TomcatfromDebian
But actually this isn't enough in my configuration: as I pointed HUDSON_HOME
to /var/lib/hudson (which is one of the "recommended" locations), Hudson
started storing plugin jars in that directory. So I had to add the following
grant as well:
grant codeBase "file:/var/lib/hudson/-" {
permission java.security.AllPermission;
};
And now, finally, everyting got working like a charm.
Maybe someone with enough privileges could update the WIKI page with this
information, so that people on Ubuntu can finally get Hudson working WITH
security on?
Furthermore, what is really cumbersome is that nowhere in the logs is to be
found the slightest mention of any security issue preventing Hudson to run
normally. The only messages that appear periodically are the ones saying
"java.lang.NoClassDefFoundError: Could not initialize class
hudson.model.XXX". I don't know if this is a Hudson issue or a
Tomcat-logging problem, but maybe there is some work that could be done to
improve the logging of security-related exceptions within Hudson.
public_void
added a comment - I'm reopening because I was experiencing exactly the same symptoms but the
proposed fix wasn't applicable in my case. I didn't
even have the incriminated plugin (Promoted Builds) installed.
I'm using Hudson 1.324 on a Tomcat 5.5 container in a Ubuntu server.
It turned out that the problem was once again related to security.
First of all, I noticed that turning off TOMCAT_SECURITY immediately solves
the problem; but I couldn't afford such a risk, so I kept TOMCAT_SECURITY
on, and of course, added the following grant code in
/etc/tomcat5.5/policy.d/04webapps.policy :
grant codeBase "file:/var/lib/tomcat5.5/webapps/hudson/-" {
permission java.security.AllPermission;
};
... as explained in the wiki:
http://wiki.jenkins-ci.org/display/JENKINS/Tomcat#Tomcat-TomcatfromDebian
But actually this isn't enough in my configuration: as I pointed HUDSON_HOME
to /var/lib/hudson (which is one of the "recommended" locations), Hudson
started storing plugin jars in that directory. So I had to add the following
grant as well:
grant codeBase "file:/var/lib/hudson/-" {
permission java.security.AllPermission;
};
And now, finally, everyting got working like a charm.
Maybe someone with enough privileges could update the WIKI page with this
information, so that people on Ubuntu can finally get Hudson working WITH
security on?
Furthermore, what is really cumbersome is that nowhere in the logs is to be
found the slightest mention of any security issue preventing Hudson to run
normally. The only messages that appear periodically are the ones saying
"java.lang.NoClassDefFoundError: Could not initialize class
hudson.model.XXX". I don't know if this is a Hudson issue or a
Tomcat-logging problem, but maybe there is some work that could be done to
improve the logging of security-related exceptions within Hudson. public_void
made changes -
| Resolution | Original: Cannot Reproduce [ 5 ] | |
| Status | Original: Closed [ 6 ] | New: Reopened [ 4 ] |
torbent
made changes -
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: Reopened [ 4 ] | New: Closed [ 6 ] |
| Workflow | Original: JNJira [ 134379 ] | New: JNJira + In-Review [ 202807 ] |
Apparently, this was related to the problems with Promoted Builds plugin (see
issue 4181). When I upgraded to ver 1.5 of that plugin, both problems disappeared.
Strange, but true.
NB: There were messages from the plugin on the console as well, but not as
frequent as these – so I never suspected them to be linked.