Outils pour utilisateurs

Outils du site


blog

Pb SIGSEGV workrave

Même pb que https://bugs.archlinux.org/task/46621

$ workrave
Erreur de segmentation

$ echo $?
139

On peut faire un strace pour en savoir un peu plus

2025/03/24 15:06

Pb segfault - stack trace

Debugging Segfaults - (ProFTPd exemple)

If you see a message like the following in your logs:

golem.castaglia.org (127.0.0.1[127.0.0.1]) - ProFTPD terminating (signal 11)

then you have most likely encountered a segfault. This is a particular bad error, and can be hard to track down.

In version 1.3.1rc1, ProFTPD gained the ability to provide better logging to help track down these sorts of bugs. To enable this ability, you will need to configure proftpd with something like:

$ ./configure --enable-devel=stacktrace ...

and run your proftpd like normal. If a segfault occurs, the logs should show something like this:

golem.castaglia.org (127.0.0.1[127.0.0.1]) - ProFTPD terminating (signal 11)
golem.castaglia.org (127.0.0.1[127.0.0.1]) - FTP session closed.
golem.castaglia.org (127.0.0.1[127.0.0.1]) - -----BEGIN STACK TRACE-----
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [0] ./proftpd [0x809b1e1]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [1] ./proftpd(call_module+0x53) [0x8072c63]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [2] ./proftpd(strftime+0x14cf) [0x8051bef]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [3] ./proftpd(pr_cmd_dispatch+0x167) [0x8051f2f]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [4] ./proftpd(strftime+0x1fd3) [0x80526f3]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [5] ./proftpd [0x8053e12]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [6] ./proftpd [0x805484d]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [7] ./proftpd [0x8057975]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [8] ./proftpd(main+0x9d1) [0x8058625]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [9] /lib/i686/libc.so.6(__libc_start_main+0x93) [0x40076507]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - [10] ./proftpd(strcpy+0x31) [0x8051001]
golem.castaglia.org (127.0.0.1[127.0.0.1]) - -----END STACK TRACE-----

These stack symbols are generated automatically by glibc, and may or may not contain the function names.

The key here for tracking down the location of the segfault is that [0] frame, and the memory address: 0x809b1e1. Using that address and a very handy command called addr2line, you can determine the location of that address in the source code:

$ addr2line -e ./proftpd 0x809b1e1

In this example, I saw:

$ addr2line -e ./proftpd 0x809b1e1
/home/tj/proftpd/cvs/proftpd/modules/mod_auth.c:1723

which is the location of test code added to trigger the segfault.

This feature is specific to glibc systems, so keep that in mind. Other things to mention about this feature: it disables the changing of the process title that proftpd normally does. The obtaining of the stack symbols that glibc does uses the process title, and if this feature did not disable that process title changing, the output would be much less legible. Also, it does not work if the process which receives the SIGSEGV signal is chrooted. (Blame glibc for its bad handling of being chrooted.) To work around this, I would recommend using the mod_vroot module, just for a short period of time, in order to get a useful automatic stack trace.

2025/03/24 15:06

Pb rsync

protocol version mismatch

http://ss64.com/bash/rsync.html

# rsync -axP acme:/var/www/ ~/backup/www
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at compat.c(176) [Receiver=3.1.1]
ssh acme /bin/true > out.dat

Le fichier out.dat doit être vide. Si ce n'est pas le cas

Exemple :

J'ai dû modifié mon .bashrc (de Acme) comme suit : .bashrc

bin/start.sh

.bashrc

if [ $TERM == 'xterm' ]
then
        bin/start.sh
fi

A tester : --no-motd

Err - No space left on device - but work if remove

Voir :

find ./app?/L*/log/ -type f  -print0 | rsync -e \"ssh -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22 -i /home/app_a/.ssh/id_l_sync_hst1 \"  --bwlimit="5000" -c --itemize-changes --files-from=- --from0 "/home/app_a" "l_sync_hst1"@"192.168.1.44":"/home/l_sync_hst1/data/"
cd+++++++ app1/
cd+++++++ app1/L12/
cd+++++++ app1/L12/log/
<f+++++++ app1/L12/log/plop.csv
<f+++++++ app1/L12/log/out.0
<fcsT.... app1/L12/log/out.0
rsync: [receiver] write failed on "/home/l_sync_hst1/data/app1/L12/log/out.0": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(379) [receiver=3.2.5]
rsync: connection unexpectedly closed (29554 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(463) [sender=2.6.8]

Mais fonctionne si

sftp -o IdentityFile=/home/pcc/.ssh/id_l_sync_hst1 id_l_sync_hst1@192.168.1.10 <<EOF
rm data/app1/L12/log/out.0
EOF
Solution

Ajouter --inplace

find ./app?/L*/log/ -type f  -print0 | rsync -e \"ssh -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22 -i /home/app_a/.ssh/id_l_sync_hst1 \"  --bwlimit="5000" -c --inplace --itemize-changes --files-from=- --from0 "/home/app_a" "l_sync_hst1"@"192.168.1.10":"/home/l_sync_hst1/data/"
2025/03/24 15:06

Pb routage asymétrique pare-feux et routage unicast

Description du Pb

Suite à l'ajout d'une nouvelle interface réseaux en DHCP : plus de réseau depuis mon poste 172.20.18.23/24.
Enfin, perte de connexion de l'interface existante. La nouvelle répond depuis mon poste qui est dans le même VLAN.

Je cherche a garder la 1ere connexion fonctionnelle (depuis mon poste).

J'avais l'IP suivante :

  • 10.115.108.2/26 (default gw 10.115.108.60)

Maintenant j'ai :

  • 10.115.108.2/26 (default gw 10.115.108.60)
  • 172.20.18.19/24

Il y a pourtant bien DEFROUTE=no pour garder la passerelle par défaut de la 1ere interface.

Voyons cela de plus prés.

Nouvelle interface en DHCP

/etc/sysconfig/network-scripts/ifcfg-em3

TYPE=Ethernet
BOOTPROTO=dhcp
DEFROUTE=no
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
NAME=em3
UUID=da256961-5be0-44c7-8e60-1334d0cfc736
DEVICE=em3
ONBOOT=yes
DEFROUTE=no

Interface existante

/etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0
NAME=bond0
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.115.108.2
NETMASK=255.255.255.192
GATEWAY=10.115.108.60
BONDING_OPTS="mode=active-backup primary em1 primary_reselect=always miimon=100"
NM_CONTROLLED=no
ip r
 
#cat /etc/iproute2/rt_tables
#ip route show table local
#ip r show table all |egrep -v "^unreachable|^local|^broadcast"
default via 10.115.108.60 dev bond0
10.115.108.0/26 dev bond0  proto kernel  scope link  src 10.115.108.2
169.254.0.0/16 dev em3  scope link  metric 1004
169.254.0.0/16 dev bond0  scope link  metric 1008
172.20.18.0/24 dev em3  proto kernel  scope link  src 172.20.18.19
Eurêka !

En ajoutant la nouvelle interface (DHCP en 172.20.18.19/24) au serveur, il ne sort dorénavant plus par la passerelle par défaut (bond0 10.115.108.60/26) pour mon poste (172.20.18.23/24) mais par cette nouvelle interface.

Solution

Routage

Précaution au cas où

systemctl start atd
echo "systemctl restart network" | at now +2 min

La solution est d'ajouter une règle de routage que pour moi ! (unicast)

ip r add 172.20.18.23/32 via 10.115.108.60 dev bond0
ip r
default via 10.115.108.60 dev bond0
10.115.108.0/26 dev bond0  proto kernel  scope link  src 10.115.108.2
169.254.0.0/16 dev em3  scope link  metric 1004
169.254.0.0/16 dev bond0  scope link  metric 1008
172.20.18.0/24 dev em3  proto kernel  scope link  src 172.20.18.19
172.20.18.23 via 10.115.108.60 dev bond0

Pour rendre la règle permanente

/etc/sysconfig/network-scripts/route-em3

172.20.18.23/32 via 10.115.108.60 dev bond0
Config sysctl

Voir Why does Red Hat Enterprise Linux 6 and above invalidate / discard packets when the route for outbound traffic differs from the route of incoming traffic?

Autre solution dans le cas où le ping arrive sur une interface et doit repartir pour une autre.

echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter

Ne pas oublier de modifier le fichier /etc/sysctl.conf pour rendre la modif permanente.

2025/03/24 15:06

Pb réseau - ifup command not found

Contournement

sudo dnf install NetworkManager-initscripts-updown

Fichiers :

  • /usr/libexec/nm-ifdown
  • /usr/libexec/nm-ifup
  • /usr/sbin/ifdown
  • /usr/sbin/ifup

Alternative :

nmcli con down eth0
nmcli con up eth0
2025/03/24 15:06
blog.txt · Dernière modification : de 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki