Ramme install - Instagram Client - issue Segmentation Fault
Hi All, I had Ramme installed by Deb on Ubuntu 18.04LTS and it worked quite well with occasional flakiness, but no hanging the computer. I have upgraded to Ubuntu 20.4 LTS and now Ramme does not fire up. Starting it from the terminal I get only "Segmentation Fault". At least with Ramme, I was able to upload one image at a time to Instagram without having to bare my ass in Bourke St, I did not need to give IG access to my image folders. My trust of FB does not extend very far. Does anyone else use Ramme? What can I do now, I suspect that Ramme is unsupported, despite it being the best IG client in the Linux galaxy. Gratefully Andrew Greig
On Thursday, 14 January 2021 5:26:05 PM AEDT Andrew Greig via luv-main wrote:
I had Ramme installed by Deb on Ubuntu 18.04LTS and it worked quite well with occasional flakiness, but no hanging the computer. I have upgraded to Ubuntu 20.4 LTS and now Ramme does not fire up. Starting it from the terminal I get only "Segmentation Fault".
Does it say anything else? Have you run gdb on the core file to see where it crashed? Have you tried running strace on it to see what it was doing before it crashed? One thing you can do is use systemd-nspawn to create a chroot setup running an older version. On my workstations I have many old versions of Debian in chroots via systemd-nspawn. I have configured it to run sshd in the chroot and then I give each chroot a different address so I can ssh to any of them. A single sshd process takes hardly any resources so having a dozen chroots running at the same time is no big deal. Here's the systemd service file I use to start a wheezy chroot. If I wanted the home directory bind mounted (which you probably want) I'd add --bind=/home # cat /etc/systemd/system/wheezy.service [Unit] Description=wheezy [Service] ExecStart=/usr/bin/systemd-nspawn -D /chroot/wheezy -M wheezy --bind=/tmp / usr/local/sbin/run-sshd ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog KillMode=mixed Type=notify RestartForceExitStatus=133 SuccessExitStatus=133 [Install] WantedBy=multi-user.target Here's the script that is used to start sshd. # cat /chroot/wheezy/usr/local/sbin/run-sshd #!/bin/bash mkdir -p /var/run/sshd exec /usr/sbin/sshd -D -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 14/1/21 9:51 pm, Russell Coker wrote:
On Thursday, 14 January 2021 5:26:05 PM AEDT Andrew Greig via luv-main wrote:
I had Ramme installed by Deb on Ubuntu 18.04LTS and it worked quite well with occasional flakiness, but no hanging the computer. I have upgraded to Ubuntu 20.4 LTS and now Ramme does not fire up. Starting it from the terminal I get only "Segmentation Fault". Does it say anything else? Have you run gdb on the core file to see where it crashed? Have you tried running strace on it to see what it was doing before it crashed?
One thing you can do is use systemd-nspawn to create a chroot setup running an older version. On my workstations I have many old versions of Debian in chroots via systemd-nspawn. I have configured it to run sshd in the chroot and then I give each chroot a different address so I can ssh to any of them. A single sshd process takes hardly any resources so having a dozen chroots running at the same time is no big deal.
Here's the systemd service file I use to start a wheezy chroot. If I wanted the home directory bind mounted (which you probably want) I'd add --bind=/home
# cat /etc/systemd/system/wheezy.service [Unit] Description=wheezy
[Service] ExecStart=/usr/bin/systemd-nspawn -D /chroot/wheezy -M wheezy --bind=/tmp / usr/local/sbin/run-sshd ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog KillMode=mixed Type=notify RestartForceExitStatus=133 SuccessExitStatus=133
[Install] WantedBy=multi-user.target
Here's the script that is used to start sshd.
# cat /chroot/wheezy/usr/local/sbin/run-sshd #!/bin/bash
mkdir -p /var/run/sshd exec /usr/sbin/sshd -D
Thanks Russell, I took a guess on the syntax alg@andrewg:~$ sudo strace ramme -v And I got a mountain of output, the last few lines of which are here: madvise(0x37db42585000, 1048576, MADV_DONTNEED) = 0 madvise(0x37db42599000, 4096, MADV_DONTNEED) = 0 madvise(0x37db42599000, 4096, MADV_DONTNEED) = 0 futex(0x7f75956a2f38, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f75956a2f38, FUTEX_WAKE_PRIVATE, 2147483647) = 0 getrandom("\xef", 1, GRND_NONBLOCK) = 1 stat("/etc/gnutls/config", 0x7ffdb8f5b6d0) = -1 ENOENT (No such file or directory) statfs("/sys/fs/selinux", 0x7ffdb8f5b6c0) = -1 ENOENT (No such file or directory) statfs("/selinux", 0x7ffdb8f5b6c0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 read(3, "nodev\tsysfs\nnodev\ttmpfs\nnodev\tbd"..., 1024) = 367 read(3, "", 1024) = 0 close(3) = 0 access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or directory) --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0xe6e0c0} --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault If the whole output is needed I will output to a text file and stuff it in Google drive and send a link Many thanks Andrew
On Thursday, 14 January 2021 10:30:33 PM AEDT Andrew Greig via luv-main wrote:
I took a guess on the syntax alg@andrewg:~$ sudo strace ramme -v
Why did you use sudo? You run strace with the same privs as the program normally has, does ramme normally run as root?
And I got a mountain of output, the last few lines of which are here:
madvise(0x37db42585000, 1048576, MADV_DONTNEED) = 0 madvise(0x37db42599000, 4096, MADV_DONTNEED) = 0 madvise(0x37db42599000, 4096, MADV_DONTNEED) = 0 futex(0x7f75956a2f38, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f75956a2f38, FUTEX_WAKE_PRIVATE, 2147483647) = 0 getrandom("\xef", 1, GRND_NONBLOCK) = 1 stat("/etc/gnutls/config", 0x7ffdb8f5b6d0) = -1 ENOENT (No such file or directory) statfs("/sys/fs/selinux", 0x7ffdb8f5b6c0) = -1 ENOENT (No such file or directory) statfs("/selinux", 0x7ffdb8f5b6c0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 read(3, "nodev\tsysfs\nnodev\ttmpfs\nnodev\tbd"..., 1024) = 367 read(3, "", 1024) = 0 close(3) = 0 access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or directory) --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0xe6e0c0} --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault
If the whole output is needed I will output to a text file and stuff it in Google drive and send a link
That's strange. Please try gdb. # run gdb on the executable gdb /usr/bin/ramme # gdb run command with ramme parameters r -v -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (2)
-
Andrew Greig -
Russell Coker