Ticketed the log4cxx message here: https://code.ros.org/trac/ros/ticket/3375 - Ken On Sun, Feb 27, 2011 at 9:27 AM, Michael Ferguson wrote: > Just an extra point -- I'm seeing the log4cxx error when closing rviz or > rosbag on my RC3 install on 10.04. > > -Mike > > On Sun, Feb 27, 2011 at 4:32 AM, Patrick Bouffard > wrote: >> >> Another possible clue: Killing nodes that are running on this new >> machine with Ctrl+C, I get errors like the following: >> >> log4cxx: No appender could be found for logger (ros.flyer_est). >> log4cxx: Please initialize the log4cxx system properly. >> >> log4cxx: No appender could be found for logger (ros.vicon_mocap). >> log4cxx: Please initialize the log4cxx system properly. >> >> .. which I'm pretty sure I've never seen before. >> >> Pat >> >> >> On Sun, Feb 27, 2011 at 1:08 AM, Patrick Bouffard >> wrote: >> > Just one thing to add: Running roscore on another machine (on the >> > 10.32.43.x subnet), and another node locally that points to that >> > roscore, does seem to work. >> > >> > Pat >> > >> > On Sun, Feb 27, 2011 at 12:59 AM, Patrick Bouffard >> > wrote: >> >> Hi, I've just setup a new Ubuntu 10.10 box that will be running some >> >> ROS nodes, occasionally including roscore. I installed diamondback >> >> from debs this evening. This particular machine has a more complex >> >> networking setup than others I've setup before and I suspect that is >> >> giving me issues with running ROS. >> >> >> >> I'm pretty sure everything is setup as it ought to be in terms of my >> >> .bashrc (just source /opt/ros/diamondback/setup.bash). But when I run >> >> roscore it just hangs. After waiting awhile, after pressing Ctrl+C >> >> once, the following is output: >> >> >> >> {{{ >> >> ^C... logging to >> >> >> >> /home/bouffard/.ros/log/ea02b894-424c-11e0-a499-00226bbd5586/roslaunch-lynx-3561.log >> >> Checking log directory for disk usage. This may take awhile. >> >> Press Ctrl-C to interrupt >> >> Done checking log file disk usage. Usage is <1GB. >> >> >> >> started roslaunch server http://lynx:52141/ >> >> ros_comm version 1.4.4 >> >> >> >> SUMMARY >> >> ======== >> >> >> >> PARAMETERS >> >>  * /rosversion >> >>  * /rosdistro >> >> >> >> NODES >> >> >> >> auto-starting new master >> >> process[master]: started with pid [3576] >> >> ROS_MASTER_URI=http://lynx:11311/ >> >> >> >> setting /run_id to ea02b894-424c-11e0-a499-00226bbd5586 >> >> process[rosout-1]: started with pid [3589] >> >> started core service [/rosout] >> >> }}} >> >> >> >> At this point things seem to be working; roswtf returns no errors or >> >> warnings, I can run, e.g., rxconsole, rostopic list outputs /rosout >> >> and /rosout_agg, etc. But having to hit Ctrl+C is not so great. >> >> >> >> Also, without roscore running, if I run roswtf it also hangs after >> >> displaying: >> >> >> >> {{{ >> >> bouffard@lynx:~$ roswtf >> >> Loaded plugin tf.tfwtf >> >> No package or stack in context >> >> >> >> ================================================================================ >> >> Static checks summary: >> >> >> >> No errors or warnings >> >> >> >> ================================================================================ >> >> }}} >> >> >> >> If I then hit Ctrl+C I get the following traceback: >> >> >> >> {{{ >> >> ^CTraceback (most recent call last): >> >>  File "/opt/ros/diamondback/ros/bin/roswtf", line 35, in >> >>    roswtf.roswtf_main() >> >>  File >> >> "/opt/ros/diamondback/stacks/ros_comm/utilities/roswtf/src/roswtf/__init__.py", >> >> line 93, in roswtf_main >> >>    _roswtf_main() >> >>  File >> >> "/opt/ros/diamondback/stacks/ros_comm/utilities/roswtf/src/roswtf/__init__.py", >> >> line 208, in _roswtf_main >> >>    master = master_online() >> >>  File >> >> "/opt/ros/diamondback/stacks/ros_comm/utilities/roswtf/src/roswtf/__init__.py", >> >> line 100, in master_online >> >>    master.getPid('/roswtf') >> >>  File "/usr/lib/python2.6/xmlrpclib.py", line 1199, in __call__ >> >>    return self.__send(self.__name, args) >> >>  File "/usr/lib/python2.6/xmlrpclib.py", line 1489, in __request >> >>    verbose=self.__verbose >> >>  File "/usr/lib/python2.6/xmlrpclib.py", line 1235, in request >> >>    self.send_content(h, request_body) >> >>  File "/usr/lib/python2.6/xmlrpclib.py", line 1349, in send_content >> >>    connection.endheaders() >> >>  File "/usr/lib/python2.6/httplib.py", line 908, in endheaders >> >>    self._send_output() >> >>  File "/usr/lib/python2.6/httplib.py", line 780, in _send_output >> >>    self.send(msg) >> >>  File "/usr/lib/python2.6/httplib.py", line 739, in send >> >>    self.connect() >> >>  File "/usr/lib/python2.6/httplib.py", line 720, in connect >> >>    self.timeout) >> >>  File "/usr/lib/python2.6/socket.py", line 554, in create_connection >> >>    sock.connect(sa) >> >>  File "", line 1, in connect >> >> KeyboardInterrupt >> >> bouffard@lynx:~$ >> >> }}} >> >> >> >> Just to check that it wasn't something in the latest diamondback >> >> release candidate, I dist-upgrade'd and tried these same commands on >> >> another couple machines (that have been running some version of ROS >> >> for awhile and are similarly configured, Ubuntu 10.0, diamondback >> >> debs) with no problems. >> >> >> >> Based on the roswtf traceback and the main weirdness of the current >> >> box being its network config (it has three wired network interfaces), >> >> I'm suspecting it has something to do with that. However, I still see >> >> the same behaviour if I sudo ifdown all the interfaces besides lo. >> >> >> >> I'm not a networking expert but I noticed on the EnvironmentVariables >> >> wiki page: ".. ROS components bind to all available network >> >> interfaces.". Could this have something to do with my issues? >> >> >> >> Here's the output of ifconfig -a in case that helps: >> >> >> >> {{{ >> >> bouffard@lynx:~$ ifconfig -a >> >> eth1      Link encap:Ethernet  HWaddr xx:xx;xx:xx:xx:xx >> >>          inet addr:128.32.43.208  Bcast:128.32.43.255 >> >>  Mask:255.255.255.0 >> >>          inet6 addr: fe80::218:8bff:fe74:766d/64 Scope:Link >> >>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 >> >>          RX packets:1066 errors:0 dropped:0 overruns:0 frame:0 >> >>          TX packets:504 errors:0 dropped:0 overruns:0 carrier:0 >> >>          collisions:0 txqueuelen:1000 >> >>          RX bytes:329324 (329.3 KB)  TX bytes:116257 (116.2 KB) >> >>          Interrupt:17 >> >> >> >> eth2      Link encap:Ethernet  HWaddr xx:xx;xx:xx:xx:xx >> >>          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0 >> >>          inet6 addr: fe80::e291:f5ff:fe94:cc3/64 Scope:Link >> >>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 >> >>          RX packets:1264 errors:0 dropped:0 overruns:0 frame:0 >> >>          TX packets:1342 errors:0 dropped:0 overruns:0 carrier:0 >> >>          collisions:0 txqueuelen:1000 >> >>          RX bytes:78005 (78.0 KB)  TX bytes:67277 (67.2 KB) >> >>          Interrupt:17 Base address:0xef00 >> >> >> >> eth3      Link encap:Ethernet  HWaddr xx:xx;xx:xx:xx:xx >> >>          inet addr:10.32.43.1  Bcast:10.32.43.255  Mask:255.255.255.0 >> >>          inet6 addr: fe80::222:6bff:febd:5586/64 Scope:Link >> >>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 >> >>          RX packets:235591 errors:0 dropped:0 overruns:0 frame:0 >> >>          TX packets:451507 errors:0 dropped:0 overruns:0 carrier:0 >> >>          collisions:0 txqueuelen:1000 >> >>          RX bytes:17233068 (17.2 MB)  TX bytes:629352191 (629.3 MB) >> >>          Interrupt:16 Base address:0x2e00 >> >> >> >> lo        Link encap:Local Loopback >> >>          inet addr:127.0.0.1  Mask:255.0.0.0 >> >>          inet6 addr: ::1/128 Scope:Host >> >>          UP LOOPBACK RUNNING  MTU:16436  Metric:1 >> >>          RX packets:8526 errors:0 dropped:0 overruns:0 frame:0 >> >>          TX packets:8526 errors:0 dropped:0 overruns:0 carrier:0 >> >>          collisions:0 txqueuelen:0 >> >>          RX bytes:817773 (817.7 KB)  TX bytes:817773 (817.7 KB) >> >> }}} >> >> >> >> eth1 is the connection to the internet, eth2 is a crossover cable to >> >> another machine, and eth3 connected to a private subnet. Iptables is >> >> configured to allow machines on the 10.32.43.x subnet to access the >> >> internet via eth1. It's possible something I did in setting that up >> >> had the side-effect of messing with ROS, as I said I'm no networking >> >> expert. Hopefully one of you is! :) >> >> >> >> Thanks, >> >> Pat >> >> >> > >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >