remote core file analysis with eclipse - c++

I want to use eclipse IDE as front-end GUI to debug a core file of another OS that is docker'ed in my host. With 'gdbserver' in the docker i can only debug a running process. But i need post-mortem debugging of core files.
I tried some /home/me/bin/remote_gdb wrapper that uses
docker exec -it $DOCKER_CONTAINER bash -c "gdb /usr/bin/executable /opt/crash/executable.core
This works using in a shell. But it fails using in 'eclipse' because of
Could not determine GDB version using command: remote_gdb --version
even though 'remote_gdb --version' prints out exactly the same as the original 'gdb --version'.
I could make something work with 'ddd' as a front-end - let me exercise:
> cd $HOME/SRC
> ls -l
total 4
-rw-rw-r-- 1 frank frank 96 Aug 24 18:04 test.c
> cat test.c
#include <stdio.h>
int main(int argc, char** argv)
{
printf("hello, world!\n");
return 0;
}
> docker run -v $HOME/SRC:/SRC -t fedora /bin/bash
// IN DOCKER NOW:
>> yum install gcc
[...]
>> yum install gdb
[...]
>> cd /SRC
>> gcc -g3 -O0 -o test test.c
>> ls -l
total 40
-rwxr-xr-x 1 root root 34864 Aug 24 16:26 test
-rw-rw-r-- 1 1000 1000 96 Aug 24 16:04 test.c
Back in Host:
> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e501d8384060 fedora "/bin/bash" 4 minutes ago Up 4 minutes stupefied_murdock
> cat $HOME/bin/remote_gdb
#!/bin/bash
docker exec -it e501d8384060 gdb /SRC/test
> remote_gdb # $HOME/bin/ is in $PATH
GNU gdb (GDB) Fedora 8.0-20.fc26
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /SRC/test...done.
(gdb) list
1 #include <stdio.h>
2
3 int main(int argc, char** argv)
4 {
5 printf("hello, world!\n");
6 return 0;
7 }
8
(gdb)
Switching back to the shell, where i am in the docker - see 'gdb' is running:
>> yum install procps-ng
[...]
>> ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 16:22 ? 00:00:00 /bin/bash
root 16 0 0 16:23 ? 00:00:00 bash
root 116 0 0 16:28 ? 00:00:00 gdb /SRC/test
root 131 16 0 16:30 ? 00:00:00 ps -ef
Back again on the host shell (after quit gdb session in docker):
> ddd --debugger remote_gdb
The 'ddd' plays nicely with gdb started in docker.
And it also works with core-files (add a "sleep(100);" and kill the process).
But 'ddd' doesn't have a really good GUI.
So what's the way to make such work with 'eclipse'?
I also couldn't make it work with other options: 'qtcreator', 'kdevelop', 'nemiver', 'kdbg', etc
Addendum:
It also doesn't work with 'ssh' into container.
But when i execute the same 'remote_gdb' wrapper script as 'External Tool' it can be executed(?!)

I partially could solve the issue.
The main problem was: my docker command does not provide a tty to eclipse.
As a workaround i switched over to 'ssh' into the docker image.
Moreover i had to align the file locations (executable, core-file and source-files) between host and docker image. Because using a 'gdb' wrapper script, 'eclipse' is not aware that i am debugging remotely and verifies all files for local availability.
This works for post-mortem debugging (core file analysis) and attaching a running process in docker (in general on the remote system).
However, it does not work for starting up a process in gdb via eclipse.
So used 'strace' to check for the activities between 'eclipse' and 'gdb' and found out, that for starting up a new process in 'gdb', 'eclipse' tries to apply some '--interpreter mi2 -nx' command:
inferior-tty-set --thread-group i1 /dev/pts/27
Does it mean it tries to bind a local tty to gdb?
That of course does not work remotely.
What is the reason to use "inferior-tty-set" by 'eclipse'?
It doesn't use this command for doing post-mortem debugging or attaching a running process - while for both i even have a gdb console operable in 'eclipse'
?

Related

How to debug Fiware-Orion

I'm new to this field.
I've installed Fiware-orion via source on my VM (centOS), by following the link below:
https://fiware-orion.readthedocs.io/en/master/admin/build_source/index.html.
Currently I'm working on a Fiware-Orion issue, but I don't know how to debug Fiware-Orion. I've searched on google and Official documentation of Fiware-Orion but I don't find any relative documentation/material related to Fiware-Orion debugging.
I've find some commands related to Orion debugging (but I don't know whether these commands are correct or not) and I'm following these commands:
-> First installed orion from source and mongoDB then,
make di
./BUILD_DEBUG/src/app/contextBroker/contextBroker -port 1026
curl localhost:1026/version
gdb ./BUILD_DEBUG/src/app/contextBroker/contextBroker -tui
b (lineNo)
run
[root#localhost fiware-orion]# gdb ./BUILD_DEBUG/src/app/contextBroker/contextBroker
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/workingDir/fiware-orion/BUILD_DEBUG/src/app/contextBroker/contextBroker...done.
(gdb) b 101
Breakpoint 1 at 0x6033c9: file /root/workingDir/fiware-orion/src/app/contextBroker/contextBroker.cpp, line 101.
(gdb) run
Starting program: /root/workingDir/fiware-orion/./BUILD_DEBUG/src/app/contextBroker/contextBroker
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, fileExists (path=0xbfc380 <pidPath> "/tmp/contextBroker.pid")
at /root/workingDir/fiware-orion/src/app/contextBroker/contextBroker.cpp:371
371 if (access(path, F_OK) == 0)
Missing separate debuginfos, use: debuginfo-install boost-filesystem-1.53.0-27.el7.x86_64 boost-regex-1.53.0-27.el7.x86_64 boost-system-1.53.0-27.el7.x86_64 boost-thread-1.53.0-27.el7.x86_64 cyrus-sasl-lib-2.1.26-23.el7.x86_64 glibc-2.17-292.el7.x86_64 gmp-6.0.0-15.el7.x86_64 gnutls-3.3.29-9.el7_6.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-37.el7_7.2.x86_64 libcom_err-1.42.9-16.el7.x86_64 libcurl-7.29.0-54.el7_7.1.x86_64 libffi-3.0.13-18.el7.x86_64 libgcc-4.8.5-39.el7.x86_64 libgcrypt-1.5.3-14.el7.x86_64 libgpg-error-1.12-3.el7.x86_64 libicu-50.1.2-15.el7.x86_64 libidn-1.28-4.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 libssh2-1.8.0-3.el7.x86_64 libstdc++-4.8.5-39.el7.x86_64 libtasn1-4.10-1.el7.x86_64 libuuid-2.23.2-61.el7_7.1.x86_64 nettle-2.7.1-8.el7.x86_64 nspr-4.21.0-1.el7.x86_64 nss-3.44.0-7.el7_7.x86_64 nss-softokn-freebl-3.44.0-8.el7_7.x86_64 nss-util-3.44.0-4.el7_7.x86_64 openldap-2.4.44-5.el7.x86_64 openssl-libs-1.0.2k-19.el7.x86_64 p11-kit-0.23.5-3.el7.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) list
366 *
367 * fileExists -
368 */
369 static bool fileExists(char* path)
370 {
371 if (access(path, F_OK) == 0)
372 {
373 return true;
374 }
375
(gdb) n
376 return false;
(gdb) n
377 }
(gdb) n
pidFile (justCheck=true) at /root/workingDir/fiware-orion/src/app/contextBroker/contextBroker.cpp:397
397 if (justCheck == true)
(gdb) print justCheck
$1 = true
(gdb) list
876 {
877 LM_X(1, ("Fatal Error (when option '-https' is used, option '-cert' is mandatory)"));
878 }
879 }
880
881 notificationModeParse(notificationMode, &notificationQueueSize, &notificationThreadNum); // This should be called before contextBrokerInit()
882 LM_T(LmtNotifier, ("notification mode: '%s', queue size: %d, num threads %d", notificationMode, notificationQueueSize, notificationThreadNum));
883 LM_I(("Orion Context Broker is running"));
884
885 if (fg == false)
(gdb) n
882 LM_T(LmtNotifier, ("notification mode: '%s', queue size: %d, num threads %d", notificationMode, notificationQueueSize, notificationThreadNum));
(gdb) step
883 LM_I(("Orion Context Broker is running"));
(gdb)
While I'm using skip(i.e. 's') command to enter into the function but it moves to the next line. I don't know where I'm making mistakes.
Actually I wanted to debug the files present inside https://github.com/telefonicaid/fiware-orion/blob/master/src/lib/ folders but I'm not able to reach there. Even, I'm not able to move out of fiware-orion/src/app/contextBroker/contextBroker.cpp class.
Can anyone suggest me correct commands for debugging Fiware-Orion, or tell me where I'm making mistakes, please.
Is there any proper documentation available regarding to debugging the Fiware-Orion?
To debug Orion you would need it compiled in DEBUG mode. The release that you have installed is not. To get a debuggable Orion, you'll have to build it from source, and compile it for debugging.
To build Orion from sources, check out the documentation here: https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/admin/build_source.md.
Build Orion using the make target "di", which stands for "debug install".
Good luck!
If you simply want to increase the debug level of Orion itself, the command line arguments are simply:
orion -logLevel DEBUG -t 0-255 -noCache -logForHumans
For example, when using a Dockerized Orion, the following docker-compose could be used:
orion:
image: fiware/orion:${ORION_VERSION}
hostname: orion
container_name: fiware-orion
depends_on:
- mongo-db
networks:
- default
expose:
- "${ORION_PORT}"
ports:
- "${ORION_PORT}:${ORION_PORT}" # localhost:1026
command: -dbhost mongo-db -logLevel DEBUG -noCache -logForHumans
healthcheck:
test: curl --fail -s http://orion:${ORION_PORT}/version || exit 1
In my case, I use QtCreator as IDE (in particular, version 3.5.1, a bit old but it works :). QtCreator integrates nicely with gdb, so it is easy to run Orion in debug mode, set breakpoints in the graphical code editor, then stimulate Orion with requests and see how it goes (breakpoint reached, etc.).

How to debug custom kernel with GDB and QEMU [duplicate]

I'm new to kernel development and I would like to know how to run/debug the linux kernel using QEMU and gdb. I'm actually reading Robert Love's book but unfortunately it doesn't help the reader on how to install proper tools to run or debug the kernel... So what I did was to follow this tutorial http://opensourceforu.efytimes.com/2011/02/kernel-development-debugging-using-eclipse/. I'm using eclipse as an IDE to develop on the kernel but I wanted first to get it work under QEMU/gdb. So what I did so far was:
1) To compile the kernel with:
make defconfig (then setting the CONFIG_DEBUG_INFO=y in the .config)
make -j4
2) Once the compilation is over I run Qemu using:
qemu-system-x86_64 -s -S /dev/zero -kernel /arch/x86/boot/bzImage
which launch the kernel in "stopped" state
3) Thus I have to use gdb, I try the following command:
gdb ./vmlinux
which run it correctly but... Now I don't know what to do... I know that I have to use remote debugging on the port 1234 (default port used by Qemu), using the vmlinux as the symbol table file for debugging.
So my question is: What should I do to run the kernel on Qemu, attach my debugger to it and thus, get them work together to make my life easier with kernel development.
I'd try:
(gdb) target remote localhost:1234
(gdb) continue
Using the '-s' option makes qemu listen on port tcp::1234, which you can connect to as localhost:1234 if you are on the same machine. Qemu's '-S' option makes Qemu stop execution until you give the continue command.
Best thing would probably be to have a look at a decent GDB tutorial to get along with what you are doing. This one looks quite nice.
Step-by-step procedure tested on Ubuntu 16.10 host
To get started from scratch quickly I've made a minimal fully automated QEMU + Buildroot example at: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/c7bbc6029af7f4fab0a23a380d1607df0b2a3701/gdb-step-debugging.md Major steps are covered below.
First get a root filesystem rootfs.cpio.gz. If you need one, consider:
a minimal init-only executable image: https://unix.stackexchange.com/questions/122717/custom-linux-distro-that-runs-just-one-program-nothing-else/238579#238579
a Busybox interactive system: https://unix.stackexchange.com/questions/2692/what-is-the-smallest-possible-linux-implementation/203902#203902
Then on the Linux kernel:
git checkout v4.15
make mrproper
make x86_64_defconfig
cat <<EOF >.config-fragment
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_GDB_SCRIPTS=y
EOF
./scripts/kconfig/merge_config.sh .config .config-fragment
make -j"$(nproc)"
qemu-system-x86_64 -kernel arch/x86/boot/bzImage \
-initrd rootfs.cpio.gz -S -s \
-append nokaslr
On another terminal, from inside the Linux kernel tree, supposing you want to start debugging from start_kernel:
gdb \
-ex "add-auto-load-safe-path $(pwd)" \
-ex "file vmlinux" \
-ex 'set arch i386:x86-64:intel' \
-ex 'target remote localhost:1234' \
-ex 'break start_kernel' \
-ex 'continue' \
-ex 'disconnect' \
-ex 'set arch i386:x86-64' \
-ex 'target remote localhost:1234'
and we are done!!
For kernel modules see: How to debug Linux kernel modules with QEMU?
For Ubuntu 14.04, GDB 7.7.1, hbreak was needed, break software breakpoints were ignored. Not the case anymore in 16.10. See also: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/901944
The messy disconnect and what come after it are to work around the error:
Remote 'g' packet reply is too long: 000000000000000017d11000008ef4810120008000000000fdfb8b07000000000d352828000000004040010000000000903fe081ffffffff883fe081ffffffff00000000000e0000ffffffffffe0ffffffffffff07ffffffffffffffff9fffff17d11000008ef4810000000000800000fffffffff8ffffffffff0000ffffffff2ddbf481ffffffff4600000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000
Related threads:
https://sourceware.org/bugzilla/show_bug.cgi?id=13984 might be a GDB bug
Remote 'g' packet reply is too long
http://wiki.osdev.org/QEMU_and_GDB_in_long_mode osdev.org is as usual an awesome source for these problems
https://lists.nongnu.org/archive/html/qemu-discuss/2014-10/msg00069.html
nokaslr: https://unix.stackexchange.com/questions/397939/turning-off-kaslr-to-debug-linux-kernel-using-qemu-and-gdb/421287#421287
Known limitations:
the Linux kernel does not support (and does not even compile without patches) with -O0: How to de-optimize the Linux kernel to and compile it with -O0?
GDB 7.11 will blow your memory on some types of tab completion, even after the max-completions fix: Tab completion interrupt for large binaries Likely some corner case which was not covered in that patch. So an ulimit -Sv 500000 is a wise action before debugging. Blew up specifically when I tab completed file<tab> for the filename argument of sys_execve as in: https://stackoverflow.com/a/42290593/895245
See also:
https://github.com/torvalds/linux/blob/v4.9/Documentation/dev-tools/gdb-kernel-debugging.rst official Linux kernel "documentation"
Linux kernel live debugging, how it's done and what tools are used?
When you try to start vmlinux exe using gdb, then first thing on gdb is to issue cmds:
(gdb) target remote localhost:1234
(gdb) break start_kernel
(continue)
This will break the kernel at start_kernel.
BjoernID's answer did not really work for me. After the first continuation, no breakpoint is reached and on interrupt, I would see lines such as:
0x0000000000000000 in ?? ()
(gdb) break rapl_pmu_init
Breakpoint 1 at 0xffffffff816631e7
(gdb) c
Continuing.
^CRemote 'g' packet reply is too long: 08793000000000002988d582000000002019[..]
I guess this has something to do with different CPU modes (real mode in BIOS vs. long mode when Linux has booted). Anyway, the solution is to run QEMU first without waiting (i.e. without -S):
qemu-system-x86_64 -enable-kvm -kernel arch/x86/boot/bzImage -cpu SandyBridge -s
In my case, I needed to break at something during boot, so after some deciseconds, I ran the gdb command. If you have more time (e.g. you need to debug a module that is loaded manually), then the timing doesn't really matter.
gdb allows you to specify commands that should be run when started. This makes automation a bit easier. To connect to QEMU (which should now already be started), break on a function and continue execution, use:
gdb -ex 'target remote localhost:1234' -ex 'break rapl_pmu_init' -ex c ./vmlinux
As for me the best solution for debugging the kernel - is to use gdb from Eclipse environment. You should just set appropriate port for gdb (must be the same with one you specified in qemu launch string) in remote debugging section. Here is the manual:
http://www.sw-at.com/blog/2011/02/11/linux-kernel-development-and-debugging-using-eclipse-cdt/
On Linux systems, vmlinux is a statically linked executable file that contains
the Linux kernel in one of the object file formats supported by Linux, which
includes ELF, COFF and a.out. The vmlinux file might be required for kernel
debugging, symbol table generation or other operations, but must be made
bootable before being used as an operating system kernel by adding a multiboot
header, bootsector and setup routines.
An image of this initial root file system must be stored somewhere accessible
by the Linux bootloader to the boot firmware of the computer. This can be the
root file system itself, a boot image on an optical disc, a small partition on
a local disk (a boot paratition, usually using ext4 or FAT file systems), or a
TFTP server (on systems that can boot from Ethernet).
Compile linux kernel
Build the kernel with this series applied, enabling CONFIG_DEBUG_INFO (but leave CONFIG_DEBUG_INFO_REDUCED off)
https://www.kernel.org/doc/html/latest/admin-guide/README.html
https://wiki.archlinux.org/index.php/Kernel/Traditional_compilation
https://lwn.net/Articles/533552/
Install GDB and Qemu
sudo pacman -S gdb qemu
Create initramfs
#!/bin/bash
# Os : Arch Linux
# Kernel : 5.0.3
INIT_DIR=$(pwd)
BBOX_URL="https://busybox.net/downloads/busybox-1.30.1.tar.bz2"
BBOX_FILENAME=$(basename ${BBOX_URL})
BBOX_DIRNAME=$(basename ${BBOX_FILENAME} ".tar.bz2")
RAM_FILENAME="${INIT_DIR}/initramfs.cpio.gz"
function download_busybox {
wget -c ${BBOX_URL} 2>/dev/null
}
function compile_busybox {
tar xvf ${BBOX_FILENAME} && cd "${INIT_DIR}/${BBOX_DIRNAME}/"
echo "[*] Settings > Build options > Build static binary (no shared libs)"
echo "[!] Please enter to continue"
read tmpvar
make menuconfig && make -j2 && make install
}
function config_busybox {
cd "${INIT_DIR}/${BBOX_DIRNAME}/"
rm -rf initramfs/ && cp -rf _install/ initramfs/
rm -f initramfs/linuxrc
mkdir -p initramfs/{dev,proc,sys}
sudo cp -a /dev/{null,console,tty,tty1,tty2,tty3,tty4} initramfs/dev/
cat > "${INIT_DIR}/${BBOX_DIRNAME}/initramfs/init" << EOF
#!/bin/busybox sh
mount -t proc none /proc
mount -t sysfs none /sys
exec /sbin/init
EOF
chmod a+x initramfs/init
cd "${INIT_DIR}/${BBOX_DIRNAME}/initramfs/"
find . -print0 | cpio --null -ov --format=newc | gzip -9 > "${RAM_FILENAME}"
echo "[*] output: ${RAM_FILENAME}"
}
download_busybox
compile_busybox
config_busybox
Boot Linux Kernel With Qemu
#!/bin/bash
KER_FILENAME="/home/debug/Projects/kernelbuild/linux-5.0.3/arch/x86/boot/bzImage"
RAM_FILENAME="/home/debug/Projects/kerneldebug/initramfs.cpio.gz"
qemu-system-x86_64 -s -kernel "${KER_FILENAME}" -initrd "${RAM_FILENAME}" -nographic -append "console=ttyS0"
$ ./qemuboot_vmlinux.sh
SeaBIOS (version 1.12.0-20181126_142135-anatol)
iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+07F92120+07EF2120 C980
Booting from ROM...
Probing EDD (edd=off to disable)... o
[ 0.019814] Spectre V2 : Spectre mitigation: LFENCE not serializing, switching to generic retpoline
can't run '/etc/init.d/rcS': No such file or directory
Please press Enter to activate this console.
/ # uname -a
Linux archlinux 5.0.3 #2 SMP PREEMPT Mon Mar 25 10:27:13 CST 2019 x86_64 GNU/Linux
/ #
Debug Linux Kernel With GDB
~/Projects/kernelbuild/linux-5.0.3 ➭ gdb vmlinux
...
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0xffffffff89a4b852 in ?? ()
(gdb) break start_kernel
Breakpoint 1 at 0xffffffff826ccc08
(gdb)
Display all 190 possibilities? (y or n)
(gdb) info functions
All defined functions:
Non-debugging symbols:
0xffffffff81000000 _stext
0xffffffff81000000 _text
0xffffffff81000000 startup_64
0xffffffff81000030 secondary_startup_64
0xffffffff810000e0 verify_cpu
0xffffffff810001e0 start_cpu0
0xffffffff810001f0 __startup_64
0xffffffff81000410 pvh_start_xen
0xffffffff81001000 hypercall_page
0xffffffff81001000 xen_hypercall_set_trap_table
0xffffffff81001020 xen_hypercall_mmu_update
0xffffffff81001040 xen_hypercall_set_gdt
0xffffffff81001060 xen_hypercall_stack_switch
0xffffffff81001080 xen_hypercall_set_callbacks
0xffffffff810010a0 xen_hypercall_fpu_taskswitch
0xffffffff810010c0 xen_hypercall_sched_op_compat
0xffffffff810010e0 xen_hypercall_platform_op

Can't download a file via os.system('scp (...)') whithin a python script launched via a init script

I'm trying to download a remote file using the scp command called by os.system() in a Python script (scp.py) started as a service by a procd init script.
This script is running on OpenWrt 15.05.1 (which uses BusyBox to implement the shell environment). SCP itself is handled by dropbear SSH (https://matt.ucc.asn.au/dropbear/dropbear.html)
The code is quite simple :
import os
import logging
logging.basicConfig(level=logging.DEBUG, filename='/usr/local/www/log/scp_test.log', filemode = 'w')
rc = os.system('scp -i /root/.ssh/id_rsa root#vps500141.ovh.net:/root/simon/test /tmp/hello')
error_code, signal = rc >> 8, rc & 0xFF
logging.debug('error_code -> {}'.format(error_code))
logging.debug('signal -> {}'.format(signal))
When launched in the terminal using the command "python scp.py", the program's behave well. The download is successful and produces the following output :
root#S096C08:/usr/local/bin# python scp.py
test 100% 24 0.0KB/s 00:00
root#S096C08:/usr/local/bin# cat /usr/local/www/log/scp_test.log
DEBUG:root:error_code -> 0
DEBUG:root:signal -> 0
But this program fails to download anything when launched as a service using the command /etc/init.d/scp_test start
root#S096C08:/usr/local/bin# /etc/init.d/scp_test start
root#S096C08:/usr/local/bin# cat /usr/local/www/log/scp_test.log
DEBUG:root:error_code -> 1
DEBUG:root:signal -> 0
Furthermore, a quick investigation of the syslogs using the logread command shows this :
Wed May 15 10:24:58 2019 daemon.err python[3156]: Host 'vps500141.ovh.net' is not in the trusted hosts file.
Wed May 15 10:24:58 2019 daemon.err python[3156]: (ssh-rsa fingerprint md5 41:aa:2b:57:48:be:01:81:48:a3:d0:ac:b6:56:16:34)
Wed May 15 10:24:58 2019 daemon.err python[3156]: Do you want to continue connecting? (y/n)
Wed May 15 10:24:58 2019 daemon.err python[3156]: /usr/bin/dbclient: Connection to root#vps500141.ovh.net:22 exited: Didn't validate host key
vps500141.ovh.net already have an entry in /root/.ssh/known_hosts so this is quite surprising that it is not found when the script is running.
I've also tried to add the "-o StrictHostKeyChecking=no" option to the scp command but it doesn't seems to work either.
NB : this is the content of the init script /etc/init.d/scp_test
#!/bin/sh /etc/rc.common
# Copyright (C) 2015 CZ.NIC z.s.p.o. (http://www.nic.cz/)
START=99
STOP=0
USE_PROCD=1
SCRIPT="/usr/local/bin/scp.py"
start_service() {
procd_open_instance
procd_set_param user root
procd_set_param command python "$SCRIPT"
procd_set_param stderr 1
procd_close_instance
}
Problem resolved after moving /root/.ssh/known_hosts to /.ssh/known_hosts

gdb fails on mountain lion

I tried to compile a 7.x Version of gdb without any luck.
I codesigned the executable(http://sourceware.org/gdb/wiki/BuildingOnDarwin).
With following version there were these problems.
7.5,7.4,git clone: unknown load command 0x2a (and others) for my application and different system libraries when starting gbd. When trying to print a vector for example i always get:
Could not find the frame base for "main(int, char**)"
7.3 (macports and from gdb-website): on starting the application it fails to set the breakpoint and continues to run.
(gdb) start
Temporary breakpoint 1 at 0x100000950: file ../src/main.cpp, line 15.
Starting program: [...]
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x2a
BFD: unable to read unknown load command 0x26
Error in re-setting breakpoint 1: Cannot access memory at address 0x100000950
[application continues]
I used the system llvm-gcc, gcc4.7 and svn-gcc4.8 to compile.
Has anybody succeeded in installing gdb on Mountain Lion?
i installed gdb 7.5 on mountain lion without problems...
those steps might help you: ./configure --prefix=/usr/local
--enable-targets=x86_64-apple-darwin10 --enable-64-bit-bfd --disable-werror --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
then make install gdb.
create your own certificate like discribed here and sign the gdb
http://sourceware.org/gdb/wiki/BuildingOnDarwin
you have to explicitly state: codesign -s gdb-cert /usr/local/gdb
before you sign the gdb make sure you already set your certificate
to trusted. also close the keychain before signing your gdb.
hope this also works for your
I resolved this issue by following the steps tried here: http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2012-09/msg00305.html
Steps
sudo chgrp procmod /usr/local/bin/gdb
sudo chmod g+s /usr/local/bin/gdb
Edit /System/Library/LaunchDaemons/com.apple.taskgated.plist and add +p argument to taskgated process
Force kill taskgated process (it will restart)
Try again
Other links:
https://blogs.oracle.com/dns/entry/understanding_the_authorization_framework_on
it doesn't seem to work for me... same issue as with the default homebrew settings
v1:src zeph$ brew install gdb
==> Downloading http://ftpmirror.gnu.org/gdb/gdb-7.5.tar.bz2
Already downloaded: /Library/Caches/Homebrew/gdb-7.5.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/gdb/7.5 --with-python=/usr --with-system-readline --enable-targets=x86_64-apple-darwin10 --enable-64-bit-bfd --disable-werror --build=x86_64-apple-darwin10 --hos
==> make
==> make install
==> Caveats
gdb requires special privileges to access Mach ports.
You will need to codesign the binary. For instructions, see:
http://sourceware.org/gdb/wiki/BuildingOnDarwin
==> Summary
/usr/local/Cellar/gdb/7.5: 62 files, 9.3M, built in 119 seconds
v1:src zeph$ codesign -s gdb-cert /usr/local/Cellar/gdb/7.5/bin/gdb
v1:src zeph$ /usr/local/Cellar/gdb/7.5/bin/gdb --args /Users/zeph/tmp/CouchBase/src/install/bin/memcached -d -u root -P /tmp/0libmemcached_memc.pid -t 1 -p 11221 -U 11221 -m 128
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BFD: /Users/zeph/tmp/CouchBase/src/install/bin/memcached: unknown load command 0x29
BFD: /Users/zeph/tmp/CouchBase/src/install/bin/memcached: unknown load command 0x29
Reading symbols from /Users/zeph/tmp/CouchBase/src/install/bin/memcached...done.
(gdb) run
Starting program: /Users/zeph/tmp/CouchBase/src/install/bin/memcached -d -u root -P /tmp/0libmemcached_memc.pid -t 1 -p 11221 -U 11221 -m 128
Unable to find Mach task port for process-id 28755: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb)
k, I had to re-sign it after having TRUSTED the certificate all across the board
codesign -fs gdb-cert /usr/local/Cellar/gdb/7.5/bin/gdb
There were two issues in the OP's question. The one regarding signing the executable or modifying taskgated and using setgid procmod has been covered. The second issue is the warnings about unknown load commands. I too ran into this and after a bunch of searching came across the following patches, that fix it:
https://gist.github.com/davidbalbert/4197567

How to debug a running C++ program in Linux?

I have a question about debugging a running C++ program in Linux. If a programming is already running and can't be interrupted, how to do that.
I can find three ways, but I don't know too much about details, I am grateful if any one can elaborate it deeper.
1) we can use GDB by specifying the process ID
gdb -p PID
In this case, what's the difference between this and attach PID?
2) We can use pstat, however, I am using Ubuntu, no pstat, but only mpstat
it seems that mpstat does not provide too much information, and not so many options.
3) check the details information under directory ./proc
In this case, just go to the directory with the PID. However, should this be done mannually?
I can't find -p option in gdb man or their documentation, but it does work! I've tried it many times with older versions on RedHat and 7.0.1 on Debian.
I'm not sure how exactly it finds the exe by PID (maybe /proc/<PID>/exe), but it does. Since it's not described in their documentation, perhaps it not the most recommended way, but I haven't had any problems with it.
There's no noticeable difference between gdb -p <PID> and running gdb and in the their shell typing attach <PID>.
I personally prefer ps xa| grep myprogram for getting the PID
In regards to technique 1, there is no -p flag and you still need the name of the program:
gdb prog PID
There is no difference between doing that vs running gdb prog and then telling gdb attach pid.
Use ps -ef | grep <your program> to get the PID. Then run gdb <your program> <PID>.
pstat is not a standard command. I've only used it with Solaris.
e.g.
gayan#gayan:~/FE/bin> ./fe&
[1] 5866
gayan#gayan:~/FE/bin> ps -ef | grep fe
gayan 5866 5836 2 10:19 pts/3 00:00:00 ./fe
gayan 5871 5836 0 10:19 pts/3 00:00:00 grep fe
gayan#gayan:~/FE/bin> gdb fe 5866
GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>...
Attaching to program: /home/gayan/FE/bin/fe, process 5866
The above was run on openSuse but should work on Ubuntu.