Table des matières
3 billet(s) pour janvier 2026
| Notes rsh rcp | 2026/01/21 18:08 | Jean-Baptiste |
| Git - Duplication d'un dépôt | 2026/01/19 10:22 | Jean-Baptiste |
| Exemple simple de conf Nagios | 2026/01/14 10:07 | Jean-Baptiste |
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
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.
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/"
Pb routage asymétrique pare-feux et routage unicast
Voir :
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
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.
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
