Description of problem: I find traceback in taskomatic log "SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder"." This error is reported when the org.slf4j.impl.StaticLoggerBinder class could not be loaded into memory. This happens when no appropriate SLF4J binding could be found on the class path. Placing one (and only one) of slf4j-nop.jar, slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar on the class path should solve the problem. since 1.6.0 As of SLF4J version 1.6, in the absence of a binding, SLF4J will default to a no-operation (NOP) logger implementation. http://www.slf4j.org/codes.html#StaticLoggerBinder Version-Release number of selected component (if applicable): spacewalk-base-2.4.2-1.fc22.noarch How reproducible: always Steps to Reproduce: 1. install spacewalk on Fedora 2. head /var/log/rhn/rhn_taskomatic_daemon.log Actual results: >> /var/log/rhn/rhn_taskomatic_daemon.log STATUS | wrapper | 2015/09/13 16:27:33 | --> Wrapper Started as Daemon STATUS | wrapper | 2015/09/13 16:27:34 | Launching a JVM... INFO | jvm 1 | 2015/09/13 16:27:34 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org INFO | jvm 1 | 2015/09/13 16:27:34 | Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. INFO | jvm 1 | 2015/09/13 16:27:34 | INFO | jvm 1 | 2015/09/13 16:27:37 | SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". INFO | jvm 1 | 2015/09/13 16:27:37 | SLF4J: Defaulting to no-operation (NOP) logger implementation Expected results: without error Failed to load class "org.slf4j.impl.StaticLoggerBinder"
I do not see this error on Spacewalk. I believe it has been fixed in the mean time as taskomatic works like expected. I'm switching this BZ to ON_QA.
Looking at SWnightly on F23 and F24: spacewalk-java-2.6.47-1.fc23.noarch java-1.8.0-openjdk-1.8.0.111-1.b16.fc23.x86_64 the issue is still there: # grep 'Failed to load' /var/log/rhn/rhn_taskomatic_daemon.log INFO | jvm 1 | 2016/11/11 00:10:11 | SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
This issue can't be reproduced in current Spacewalk 2.9 version. If you are still able to see it on your setup you are encouraged to update the reproducer and reopen it.