Yesterday evening my RSSOwl install stopped working. I got an error something
about unable to connect to localhost porto 8000-something, and after that no
feeds would load whatsoever. This is the error that now appears in the .log
file each time I start RSSOwl:
This is on a Debian Testing system. It is possible that something was updated
on the system between when RSSOwl worked and when it stopped working, but I
don't think there was anything related to java. I tried wiping out my .rssowl2
configuration directory and starting from scratch, and the error persisted. I
also tried reverting to an older version of RSSOwl (v2.0), and it did the same
thing. I also tried rebooting my computer as well as setting the Network
Connection setting to use a proxy and then back to direct connection (as it
had been set before).
I am out of ideas for things to try now and would welcome any suggestions for
how to diagnose and resolve this problem.
Thank you,
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-12-31
You run a Firewall that blocks localhost connections?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the same problem. I also run debian testing. After my software update
of 26 Dec. 2009 rssowl can no longer connect to localhost:8795. I believe that
it is not due to my firewall, because I do not see dropped packets for this
port in the log files. My network analyser reports a connection between ports
3646 (xxs-srv-port) -> 8795: SYN; RST,ACK. netstat does not report a listening
port 8795, nor a listening program rssowl. I get the impression that since the
debian testing update the listening part of rssowl is not able to run. I have
no idea which debian component is causing this. It could be a permissions
problem, but I see no log messages to that effect. I have no idea about the
components of rssowl, so I do not know where to look for causes.
I also get crash reports of SIGSEGV from java. I have the impression that that
happens when rssowl exits. I get similar SIGSEGV reports for eclipse, so that
that problem seems to be due to eclipse. I now believe that the crashes are
not related to the connection problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I might add that I run rssowl 2.0.2, and that I run it as a standalone
application, not in eclipse.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-01-02
Please ensure that you install RSSOwl from packages.rssowl.org as it includes
a fix for the recent issue introduced by an update to GTK (see http://www.rss
owl.org/help#item_6aa).
Could it be that another application is using this port and rssowl fails to
use it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-01-02
Btw also suggest to update to latest Java if possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not wish to have the additional recommended dependencies, i.ei. avahi , etc. "Will RSSOwl still work without them" ?
I previously had open-java6-jdk , open-java6-jre install 'before' installing RSSOwl , "Do I have to remove all open java6 because RSSOwl wishes to use Sun's java instead" ?
Can I remove all Sun Java and force RSSOwl to use Open Java6 jre ?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have rssowl installed from the Linux zip file and launch it from a script
that sets the environment variables and some command-line options for me.
The FAQ that you referenced includes a command-line option -Dlocalhost=<IP>
that "will use the provided IP to display the content of news". What does that
mean? Would that be a way to change the port the RSSOwl uses to communicate
with itself?
My Java version is as follows:
$ java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I played around with the -Dlocalhost option a bit and was able to get past the
java.net.SocketException by specifying -Dlocalhost=::1 (the IPv6 format for
localhost). I wonder if something is went screwy with IPv6 somewhere? With
that option, I now show a listening port 8795. All attempts to load feeds
still show "Network is unreachable" errors in the log.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
I used a common -data folder, updated RssOwl in Fedora, rebooted into Debian
Testing and could read all articles with the built-in browser. Still can't
update any feeds in Debian.
Very frustrating.
Any ideas?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-01-03
Pleae post to for questions related to the Ubuntu/Debian packages.
The investigation towards using -Dlocalhost seems to indicate that something
is seriously going wrong on your systems with regards to how the Java VM
handles "127.0.0.1" as ServerSocket. RSSOwl is using this value to create a
loopback connection for displaying news. With -Dlocalhost this can be changed.
It seems, the port itself is not the problem but the syntax of the loopback
adress. Nothing changed for RSSOwl in this area for a while. The issue that no
feed is loading indicates that there seems to be a general issue with how the
Java VM can connect to the internet on Linux Debian Testing. Could it be that
permissions on Debian Testing block the entire Java VM from connecting via
Sockets? This would explain the issue. Or, could it be that only IPv6 is
supported, given that it seems to work on localhost in the IPv6 form?
I would greatly appreciate any of you asking this on the related Debian
Testing forums. I can only tell that nothing changed in RSSOwl in this area
for months now.
I found that the difference is in booting kernel 2.6.30-2-686. When I reboot
and boot to the previous kernel version (2.6.30-1-686), RSSOwl works fine. I
don't know what might have made the difference, but since there are others
looking at this, I thought it might be a good tip. At least we can get RSSOwl
working again until the root problem is found.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-01-03
Thanks, thats good to know. I am quite sure that RSSOwl will not be the only
application that is bitten by this. How much unstable is this kernel version?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since RssOwl (bin or .rpm) is working perfectly using the same openjdk java in
Fedora 12 64bit but not in Debian Testing 64bit, would building RssOwl from
source possibly solve the java mystery problem ?
Thanks
Senseah
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-01-05
I can not see how building RSSOwl would change anything. There should be no
difference building RSSOwl on any VM or any OS, given the compiler used is
Eclipse (and not the VM). The only interesting aspect is the Java Runtime, and
thats something that has an impact on the binary form of RSSOwl.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is indeed a problem with Debian testing (and probably unstable). See Debian
bug report 560044 (http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=560044#4). A setting breaks networking in java, and
any traffic will always result in a "java.net.SocketException: Network is
unreachable". The value of
net.ipv6.bindv6only
in
/etc/sysctl.d/bindv6only.conf
should be changed from 1 to 0, and the networking settings must be restarted
as:
sudo invoke-rc.d procps restart
. I can now update my feeds again.
The comment in the settings file is interesting for developers:
This sysctl sets the default value of the IPV6_V6ONLY socket option.
When disabled, IPv6 sockets will also be able to send and receive IPv4
traffic with addresses in the form ::ffff:192.0.2.1 and daemons listening
on IPv6 sockets will also accept IPv4 connections.
When IPV6_V6ONLY is enabled, daemons interested in both IPv4 and IPv6
connections must open two listening sockets.
This is the default behaviour of almost all modern operating systems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I could locate the relevant bug report with Debian due to the error message in
message #1, esp. the exception type java.net.SocketException. The confusion
was made larger because RSSOwl does not provide good error messages. It
happily swallows the java.net.SocketException, and the fact that creation of
its server socket fails. Its first error message occurs when the front end
cannot connect to the server, but at that moment there is no information about
the cause. I suggest you check your catch blocks, and at least write exception
messages to System.err. Failure to create the server should result in an error
message to the user; it is quite fatal.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-01-07
I could not agree more and thereby fixed this () a few days ago for upcoming
RSSOwl 2.0.3
I have the same problem and OS. I tried diffrent versions of jre (open 1.6,
sun 1.6, oracle 1.7) - problem still exist. I don't have such file
(bindv6only.conf), but I created it and nothing changed. Can anybody help me?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yesterday evening my RSSOwl install stopped working. I got an error something
about unable to connect to localhost porto 8000-something, and after that no
feeds would load whatsoever. This is the error that now appears in the .log
file each time I start RSSOwl:
!SESSION 2009-12-30 20:52:26.196
eclipse.buildId=unknown
java.version=1.6.0_16
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
Command-line arguments: -os linux -ws gtk -arch x86
!ENTRY org.rssowl.ui 4 4 2009-12-30
20:52:31.167 !MESSAGE Invalid argument
!STACK 0 java.net.SocketException:
Invalid argument
at java.net.PlainSocketImpl.socketBind(NativeMethod)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.<init>(ServerSocket.java:185)
at org.rssowl.ui.internal.ApplicationServer.createServerSocket(ApplicationServ
er.java:228)
at
org.rssowl.ui.internal.ApplicationServer.startup(ApplicationServer.java:179)
at org.rssowl.ui.internal.Activator.startServer(Activator.java:246)
at org.rssowl.ui.internal.Activator.access$0(Activator.java:243)
at org.rssowl.ui.internal.Activator$1.run(Activator.java:104)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.rssowl.ui.internal.Activator.start(Activator.java:102)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleCont
extImpl.java:1009)
at java.security.AccessController.doPrivileged(NativeMethod)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(B
undleContextImpl.java:1003)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleCont
extImpl.java:984)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.
java:346)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundl
e.java:265)
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalC
lass(EclipseLazyStarter.java:111)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(Classpa
thManager.java:427)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(Def
aultClassLoader.java:193)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(Bundle
Loader.java:370)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(Bun
dleLoader.java:446)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoade
r.java:399)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoade
r.java:387)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultC
lassLoader.java:87)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoade
r.java:315)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.ja
va:227)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractB
undle.java:1274)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutab
leExtension(RegistryStrategyOSGI.java:160)
at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtens
ion(ExtensionRegistry.java:867)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExt
ension(ConfigurationElement.java:243)
at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecuta
bleExtension(ConfigurationElementHandle.java:51)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java
:188)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication
(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseA
ppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
Then there are numerous entries like this:
!ENTRY org.rssowl.core 2 4 2009-12-30 20:52:43.840
!MESSAGE Error loading 'Shonn's Blog'
Problem: Network is unreachable
Link: http://shonnkeels.blogspot.com/feeds/posts/default/
This is on a Debian Testing system. It is possible that something was updated
on the system between when RSSOwl worked and when it stopped working, but I
don't think there was anything related to java. I tried wiping out my .rssowl2
configuration directory and starting from scratch, and the error persisted. I
also tried reverting to an older version of RSSOwl (v2.0), and it did the same
thing. I also tried rebooting my computer as well as setting the Network
Connection setting to use a proxy and then back to direct connection (as it
had been set before).
I am out of ideas for things to try now and would welcome any suggestions for
how to diagnose and resolve this problem.
Thank you,
Paul
You run a Firewall that blocks localhost connections?
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.047 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.033 ms
I don't think that the firewall will restrict any traffic to or from localhost
--or anywhere else for that matter.
Here is a new error that has started (since RSSOwl stopped working) appearing
when I close RSSOwl:
!ENTRY org.rssowl.ui 4 2 2010-01-01 08:13:02.569
!MESSAGE Problems occurred when invoking code from plug-in: "org.rssowl.ui".
!STACK 0
java.lang.NullPointerException
at
org.rssowl.ui.internal.ApplicationServer.shutdown(ApplicationServer.java:186)
at org.rssowl.ui.internal.Controller.shutdown(Controller.java:1060)
at org.rssowl.ui.internal.Activator$7.run(Activator.java:346)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.rssowl.ui.internal.Activator.stop(Activator.java:344)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$3.run(BundleCont
extImpl.java:1050)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleConte
xtImpl.java:1046)
at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.j
ava:457)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBun
dle.java:531)
at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.
java:1104)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLev
elManager.java:655)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(
StartLevelManager.java:312)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLe
velManager.java:257)
at org.eclipse.osgi.framework.internal.core.SystemBundle.suspend(SystemBundle.
java:236)
at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:
678)
at
org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:576)
at org.eclipse.osgi.framework.internal.core.OSGi.close(OSGi.java:41)
at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.jav
a:424)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:200)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
I have the same problem. I also run debian testing. After my software update
of 26 Dec. 2009 rssowl can no longer connect to localhost:8795. I believe that
it is not due to my firewall, because I do not see dropped packets for this
port in the log files. My network analyser reports a connection between ports
3646 (xxs-srv-port) -> 8795: SYN; RST,ACK. netstat does not report a listening
port 8795, nor a listening program rssowl. I get the impression that since the
debian testing update the listening part of rssowl is not able to run. I have
no idea which debian component is causing this. It could be a permissions
problem, but I see no log messages to that effect. I have no idea about the
components of rssowl, so I do not know where to look for causes.
I also get crash reports of SIGSEGV from java. I have the impression that that
happens when rssowl exits. I get similar SIGSEGV reports for eclipse, so that
that problem seems to be due to eclipse. I now believe that the crashes are
not related to the connection problem.
I might add that I run rssowl 2.0.2, and that I run it as a standalone
application, not in eclipse.
Please ensure that you install RSSOwl from packages.rssowl.org as it includes
a fix for the recent issue introduced by an update to GTK (see http://www.rss
owl.org/help#item_6aa).
Could it be that another application is using this port and rssowl fails to
use it?
Btw also suggest to update to latest Java if possible.
I love RSSOwl and also am having trouble with Debian Testing 64bit, previously
working flawlessly. I have performed;
added to /etc/apt/sources.list ...
deb http://packages.rssowl.org/debian
lenny main
sudo apt-get update
Questions;
Thank you.
I have rssowl installed from the Linux zip file and launch it from a script
that sets the environment variables and some command-line options for me.
The FAQ that you referenced includes a command-line option -Dlocalhost=<IP>
that "will use the provided IP to display the content of news". What does that
mean? Would that be a way to change the port the RSSOwl uses to communicate
with itself?
My Java version is as follows:
$ java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
I played around with the -Dlocalhost option a bit and was able to get past the
java.net.SocketException by specifying -Dlocalhost=::1 (the IPv6 format for
localhost). I wonder if something is went screwy with IPv6 somewhere? With
that option, I now show a listening port 8795. All attempts to load feeds
still show "Network is unreachable" errors in the log.
RssOwl 2.0.2 (binary 64bit .zip) works well on;
I used a common -data folder, updated RssOwl in Fedora, rebooted into Debian
Testing and could read all articles with the built-in browser. Still can't
update any feeds in Debian.
Very frustrating.
Any ideas?
Thank you.
Pleae post to for questions related to the Ubuntu/Debian packages.
The investigation towards using -Dlocalhost seems to indicate that something
is seriously going wrong on your systems with regards to how the Java VM
handles "127.0.0.1" as ServerSocket. RSSOwl is using this value to create a
loopback connection for displaying news. With -Dlocalhost this can be changed.
It seems, the port itself is not the problem but the syntax of the loopback
adress. Nothing changed for RSSOwl in this area for a while. The issue that no
feed is loading indicates that there seems to be a general issue with how the
Java VM can connect to the internet on Linux Debian Testing. Could it be that
permissions on Debian Testing block the entire Java VM from connecting via
Sockets? This would explain the issue. Or, could it be that only IPv6 is
supported, given that it seems to work on localhost in the IPv6 form?
I would greatly appreciate any of you asking this on the related Debian
Testing forums. I can only tell that nothing changed in RSSOwl in this area
for months now.
http://dev.rssowl.org/show_bug.cgi?id=789
I found that the difference is in booting kernel 2.6.30-2-686. When I reboot
and boot to the previous kernel version (2.6.30-1-686), RSSOwl works fine. I
don't know what might have made the difference, but since there are others
looking at this, I thought it might be a good tip. At least we can get RSSOwl
working again until the root problem is found.
Thanks, thats good to know. I am quite sure that RSSOwl will not be the only
application that is bitten by this. How much unstable is this kernel version?
Since RssOwl (bin or .rpm) is working perfectly using the same openjdk java in
Fedora 12 64bit but not in Debian Testing 64bit, would building RssOwl from
source possibly solve the java mystery problem ?
Thanks
Senseah
I can not see how building RSSOwl would change anything. There should be no
difference building RSSOwl on any VM or any OS, given the compiler used is
Eclipse (and not the VM). The only interesting aspect is the Java Runtime, and
thats something that has an impact on the binary form of RSSOwl.
It is indeed a problem with Debian testing (and probably unstable). See Debian
bug report 560044 (http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=560044#4). A setting breaks networking in java, and
any traffic will always result in a "java.net.SocketException: Network is
unreachable". The value of
in
should be changed from 1 to 0, and the networking settings must be restarted
as:
. I can now update my feeds again.
The comment in the settings file is interesting for developers:
This sysctl sets the default value of the IPV6_V6ONLY socket option.
When disabled, IPv6 sockets will also be able to send and receive IPv4
traffic with addresses in the form ::ffff:192.0.2.1 and daemons listening
on IPv6 sockets will also accept IPv4 connections.
When IPV6_V6ONLY is enabled, daemons interested in both IPv4 and IPv6
connections must open two listening sockets.
This is the default behaviour of almost all modern operating systems.
Thanks a lot. I can confirm this fix solves the issue on debian unstable.
Thanks for the update, good to know!
I could locate the relevant bug report with Debian due to the error message in
message #1, esp. the exception type java.net.SocketException. The confusion
was made larger because RSSOwl does not provide good error messages. It
happily swallows the java.net.SocketException, and the fact that creation of
its server socket fails. Its first error message occurs when the front end
cannot connect to the server, but at that moment there is no information about
the cause. I suggest you check your catch blocks, and at least write exception
messages to System.err. Failure to create the server should result in an error
message to the user; it is quite fatal.
I could not agree more and thereby fixed this () a few days ago for upcoming
RSSOwl 2.0.3
http://dev.rssowl.org/show_bug.cgi?id=1323
I have the same problem and OS. I tried diffrent versions of jre (open 1.6,
sun 1.6, oracle 1.7) - problem still exist. I don't have such file
(bindv6only.conf), but I created it and nothing changed. Can anybody help me?
Which version of RSSOwl? Can you please export your log file from
http://www.rssowl.org/help#item_5
I use latest (2.1.2) version. Logs
here.
Hi