[Bug 1043158] New: zookeeper-server service silently fails while starting on FC20
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1043158
Bug ID: 1043158
Summary: zookeeper-server service silently fails while starting
on FC20
Product: Fedora
Version: 20
Component: zookeeper
Assignee: tstclair(a)redhat.com
Reporter: rudcy(a)broadbandninja.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
jeff(a)ocjtech.us, skottler(a)redhat.com,
tstclair(a)redhat.com
Description of problem:
zookeeper-server on fc20 silently fails to start after a fresh install
due to unit file precondition on missing file .
Version-Release number of selected component (if applicable):
zookeeper-server-3.4.5-12.fc20.noarch
Steps to Reproduce:
1. Fresh install of fc20
2. install zookeeper-server (and zookeeper?)
3. sudo cp /etc/zoo-sample.cfg /etc/zoo.cfg
4. sudo systemctl start zookeeper
5. journalctl -f shows:
```
Dec 14 14:18:32 localhost.localdomain systemd[1]: Started Apache ZooKeeper.
```
Actual results:
The service has aborted when trying to start, the errors it
reported are not logged to the journal nor /var/log/zookeeper/*
Expected results:
the service should be running, or log an error to the journal.
Additional info:
```
% cat /usr/lib/systemd/system/zookeeper.service
...
ConditionPathExists=/var/lib/zookeeper/data/myid
```
Creating /var/lib/zookeeper/data/myid and chowning it over to zookeeper makes
the next restart "stick" and zookeeper then logs to the journal (too verbosely,
btw).
I've found nothing on setting up zookeeper-server on fedora on google,
but I'm new here, I may have missed it.
So no docs on what is myid or what's it for, zookeeper runs fine without
it if it's launched manually.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ItjXVYdpch&a=cc_unsubscribe
8 years, 11 months
[Bug 1184269] New: groovy java.lang.LinkageError in groovy script using @Grab
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1184269
Bug ID: 1184269
Summary: groovy java.lang.LinkageError in groovy script using
@Grab
Product: Fedora
Version: rawhide
Component: groovy
Assignee: msrb(a)redhat.com
Reporter: pahan(a)hubbitus.info
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, msrb(a)redhat.com
Description of problem:
Fully up to date rawhide.
$ ./test.groovy
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
-Dsun.java2d.pmoffscreen=false -XX:+UseCompressedOops -XX:+DoEscapeAnalysis
-XX:+AggressiveOpts -XX:+EliminateLocks
Caught: java.lang.LinkageError: loader constraint violation in interface itable
initialization: when resolving method
"org.apache.xerces.dom.NodeImpl.getChildNodes()Lorg/w3c/dom/NodeList;" the
class loader (instance of org/codehaus/groovy/tools/RootLoader) of the current
class, org/apache/xerces/dom/NodeImpl, and the class loader (instance of
<bootloader>) for interface org/w3c/dom/Node have different Class objects for
the type org/w3c/dom/NodeList used in the signature
java.lang.LinkageError: loader constraint violation in interface itable
initialization: when resolving method
"org.apache.xerces.dom.NodeImpl.getChildNodes()Lorg/w3c/dom/NodeList;" the
class loader (instance of org/codehaus/groovy/tools/RootLoader) of the current
class, org/apache/xerces/dom/NodeImpl, and the class loader (instance of
<bootloader>) for interface org/w3c/dom/Node have different Class objects for
the type org/w3c/dom/NodeList used in the signature
at org.apache.xerces.parsers.AbstractDOMParser.startDocument(Unknown
Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown
Source)
at
org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at org.apache.ivy.util.XMLHelper.parseToDom(XMLHelper.java:208)
at org.apache.ivy.plugins.parser.m2.PomReader.<init>(PomReader.java:95)
at
org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:121)
at
org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:111)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:714)
at
org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:731)
at
org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:1193)
at
org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:536)
at
org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:271)
at
org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:512)
at
org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
at org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:169)
at org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:292)
at
org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:714)
at
org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:799)
at
org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:722)
at
org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:594)
at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:234)
at org.apache.ivy.Ivy.resolve(Ivy.java:517)
$ cat test.groovy
#!/usr/bin/groovy
@Grab(group='commons-cli', module='commons-cli', version='1.2')
def cli = new CliBuilder(/*usage: 'Usage:'*/)
println 'stared'
Version-Release number of selected component (if applicable):
$ rpm -qa groovy apache-ivy 'java*'
javapackages-tools-4.3.2-3.fc22.noarch
java-1.8.0-openjdk-headless-1.8.0.40-19.b12.fc22.x86_64
apache-ivy-2.3.0-17.fc22.noarch
java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.x86_64
java-1.8.0-openjdk-devel-1.8.0.40-19.b12.fc22.x86_64
groovy-2.3.7-2.fc22.noarch
javamail-1.5.1-4.fc22.noarch
How reproducible:
Always
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4aUdDxmiBL&a=cc_unsubscribe
8 years, 11 months
[Bug 1133789] New: CVE-2013-7397 async-http-client: SSL/TLS certificate verification is disabled under certain conditions [fedora-all]
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1133789
Bug ID: 1133789
Summary: CVE-2013-7397 async-http-client: SSL/TLS certificate
verification is disabled under certain conditions
[fedora-all]
Product: Fedora
Version: 20
Component: async-http-client
Keywords: Security, SecurityTracking
Severity: high
Priority: high
Assignee: mizdebsk(a)redhat.com
Reporter: djorm(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, msimacek(a)redhat.com,
msrb(a)redhat.com
Blocks: 1133769 (CVE-2013-7397)
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of Fedora.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time. If you need to fix the versions independent of each other,
you may clone this bug as appropriate.
[bug automatically created by: add-tracking-bugs]
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1133769
[Bug 1133769] CVE-2013-7397 async-http-client: SSL/TLS certificate
verification is disabled under certain conditions
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=corEJzycHn&a=cc_unsubscribe
9 years
[Bug 1076927] New: Solr - Hadoop missing support for ARM arch
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1076927
Bug ID: 1076927
Summary: Solr - Hadoop missing support for ARM arch
Product: Fedora
Version: rawhide
Component: solr
Assignee: puntogil(a)libero.it
Reporter: puntogil(a)libero.it
QA Contact: extras-qa(a)fedoraproject.org
CC: java-sig-commits(a)lists.fedoraproject.org,
puntogil(a)libero.it
solr has broken dependencies in the rawhide tree:
On armhfp:
solr-4.7.0-1.fc21.noarch requires mvn(org.apache.hadoop:hadoop-hdfs)
solr-4.7.0-1.fc21.noarch requires mvn(org.apache.hadoop:hadoop-common)
solr-4.7.0-1.fc21.noarch requires mvn(org.apache.hadoop:hadoop-auth)
solr-4.7.0-1.fc21.noarch requires mvn(org.apache.hadoop:hadoop-annotations)
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=snDZpFQcdi&a=cc_unsubscribe
9 years
[Bug 1207850] New: mvnDebug should be installed in /usr/bin/
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1207850
Bug ID: 1207850
Summary: mvnDebug should be installed in /usr/bin/
Product: Fedora
Version: 21
Component: maven
Assignee: mizdebsk(a)redhat.com
Reporter: thomas.mey(a)web.de
QA Contact: extras-qa(a)fedoraproject.org
CC: akurtako(a)redhat.com,
java-sig-commits(a)lists.fedoraproject.org,
mizdebsk(a)redhat.com, msimacek(a)redhat.com,
msrb(a)redhat.com
Description of problem:
mvn will be installed on the standard path /usr/bin/, but
mvnDebug not. mvnDebug will only be installed in /usr/share/maven/bin/mvnDebug.
To use it, every user needs to add this path to it's path list.
Please install mvnDebug also in /usr/bin/
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=MC2jKhT6Pk&a=cc_unsubscribe
9 years