Hello Pax Logging indeed is very fragile and from my own experience I had "lost logging" problems, but not when restarting Karaf. It happened when installing/uninstalling Karaf features which eventually lead to bundle refreshes (low level bundle operation), where current bundle revisions were getting new wirings.
At low level, loggers used by bundles (which should come from pax-logging-api) need to be wired to pax-logging-log4j2 bundle (which provides the implementation). Ideally I'd have to see a heapdump of your broken instance, but I know it may be problematic. Then maybe a list of bundles you have installed? (`la -l` Karaf command) You can also check the wiring state of your bundle using `tree-show <bundle id>` command. For example I see that eventually undertow-core uses pax-logging-api and pax-logging-log4j2 is wired correctly to pax-logging-api karaf@root()> tree-show 52 Bundle io.undertow.core [52] is currently ACTIVE io.undertow.core [52] +- org.jboss.xnio.api [56] | +- org.ops4j.pax.web.pax-web-undertow [63] | | +- org.ops4j.pax.web.pax-web-spi [61] | | | +- jakarta.servlet-api [55] | | | +- org.ops4j.pax.web.pax-web-api [58] | | | | +- jakarta.servlet-api [55] | | | | +- org.ops4j.pax.logging.pax-logging-api [7] | | | | +- org.apache.karaf.services.eventadmin [2] | | | | +- org.apache.felix.metatype [3] | | | | +- org.apache.felix.configadmin [12] | | | | +- org.apache.felix.coordinator [10] | | | +- org.ops4j.pax.logging.pax-logging-api [7] | | +- jakarta.servlet-api [55] | | +- org.ops4j.pax.web.pax-web-api [58] | | +- io.undertow.servlet [53] | | | +- jakarta.servlet-api [55] | | | +- jakarta.annotation-api [54] | | | +- org.ops4j.pax.logging.pax-logging-api [7] | | +- org.ops4j.pax.logging.pax-logging-api [7] | +- org.ops4j.pax.logging.pax-logging-api [7] +- org.ops4j.pax.logging.pax-logging-api [7] karaf@root()> tree-show 5 Bundle org.ops4j.pax.logging.pax-logging-log4j2 [5] is currently ACTIVE org.ops4j.pax.logging.pax-logging-log4j2 [5] +- org.apache.karaf.services.eventadmin [2] | +- org.apache.felix.metatype [3] | | +- org.ops4j.pax.logging.pax-logging-api [7] | +- org.apache.felix.configadmin [12] | | +- org.apache.felix.coordinator [10] | | | +- org.ops4j.pax.logging.pax-logging-api [7] | | +- org.ops4j.pax.logging.pax-logging-api [7] | +- org.ops4j.pax.logging.pax-logging-api [7] +- org.apache.felix.configadmin [12] +- org.ops4j.pax.logging.pax-logging-api [7] If nothing works, please create KARAF or pax.logging issue. regards Grzegorz Grzybek czw., 30 lis 2023 o 17:40 Daniel Krügler <[email protected]> napisał(a): > Hi, > > We are using karaf 4.4.3 with equinox 3.18.200.v20221116-1324 on Windows > 10 machines and we observe sometimes a very surprising effect of the > logging functionality on BundleActivator instances when restarting the > karaf server after a certain form of previous shut downs. > > How to reproduce: Initially we observed the issue after some VM reboots > when the karaf server restarted, but found out that especially VMs with > not too much memory and/or a smaller number of cores can provoke this > situation in nearly 100% of all cases. We also found that the same issue > can be provoked more easily (on Windows) when killing the karaf Java > process in the task manager, sometimes only after the second or third > attempt of such provoked crashes followed by a restart. > > How does it manifest: We found that under above described conditions > certain bundles that have registered a BundleActivator, don't show up > any more in the karaf logging. Interestingly an immediate declarative > OSGi service component in the same bundle (Which from a user point of > view has not much differences to a BundleActivator) did show logging, so > we could exclude the hypotheses, that the bundle was not started. In > fact, by triggering other observable side effects within > BundleActivator#start - such as creating a special marker file - we > could proof that the seemingly not executed BundleActivator#start *was* > in fact executed (The marker file was created), but no logging became > visible from the BundleActivator (as if logging would be disabled). We > found that all of org.slf4j.Logger, java.util.logging.Logger, and > org.osgi.service.log.Logger are affected by this, so we _assume_ that > the actual root may be related to a somewhat broken persisted state of > pax logging. But before we report that to the paxlogging project > directly, we would like to ask the karaf user group for possible hints > or ideas. > > I should point out that we investigated this situation only for our own > bundles that are started rather early, but certainly after pax logging > has been started (No system bundles, just normal bundles). > > I would appreciate any ideas or suggestions how to proceed. > > Thanks, > > - Daniel Krügler >
