Bug#980046: iproute2: Upgrade from 5.10.0-1 to 5.10.0-2 breaks ip vrf exec
Package: iproute2 Version: 5.10.0-2 Severity: important Dear Maintainer, Upgrading from 5.10.0-1 to 5.10.0-2 breaks ip vrf exec. Before package upgrade: root@gateway:~# ip vrf exec mgmt bash root@gateway:mgmt:~# Now with version 5.10.0-2: root@gateway:~# ip vrf exec mgmt bash Failed to load BPF prog: 'Invalid argument' Kernel compiled with CGROUP_BPF enabled? root@gateway:~# -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iproute2 depends on: ii debconf [debconf-2.0] 1.5.74 ii libbpf0 1:0.3-1 ii libbsd0 0.10.0-1 ii libc6 2.31-9 ii libcap2 1:2.44-1 ii libcap2-bin 1:2.44-1 ii libdb5.3 5.3.28+dfsg1-0.6 ii libelf1 0.182-3 ii libmnl0 1.0.4-3 ii libselinux1 3.1-2+b2 ii libxtables12 1.8.6-1 Versions of packages iproute2 recommends: pn libatm1 Versions of packages iproute2 suggests: pn iproute2-doc -- debconf information: iproute2/setcaps: false
Bug#917128: udev 240 breaks network interface naming
Hello, It looks like, I have the same problem and it is still present in 240-4. For more detail : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917128#40 Regards, -- Emmanuel DECAEN
Bug#917128: udev 240 breaks network interface naming
Hello, I've tried with 240-4, the VLAN problem is still present. File /etc/systemd/network/00-xgbe1.link : [Match] MACAddress=00:50:56:96:0d:d7 [Link] Name=xgbe1 File /etc/network/interfaces : iface xgbe1.40 inet static address 192.168.40.218/24 $ sudo ifup xgbe1.40 Cannot find device "xgbe1.40" ifup: failed to bring up xgbe1.40 $ sudo dmesg [...] [ 56.261847] vmxnet3 :13:00.0 xgbe1: intr type 3, mode 0, 3 vectors allocated [ 56.263559] vmxnet3 :13:00.0 xgbe1: NIC Link is Up 1 Mbps [ 56.446638] 8021q: 802.1Q VLAN Support v1.8 [ 56.446861] 8021q: adding VLAN 0 to HW filter on device xgbe1 [ 56.449675] rename5: renamed from xgbe1.40 $ ip link 3: xgbe1: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:50:56:96:0d:d7 brd ff:ff:ff:ff:ff:ff 5: rename5@xgbe1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:96:0d:d7 brd ff:ff:ff:ff:ff:ff The device xgbe1.40 is created and renamed during ifup to "rename5@xgbe1". If you think the problem is not the same as mentioned earlier, I can open a new bug report. Best regards. -- * *Emmanuel DECAEN
Bug#863797: Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp
Le 01/06/2017 à 07:21, Sebastiaan Couwenberg a écrit : > notfound 863797 nagios-nrpe/3.0.1-3 > thanks > > On 05/31/2017 11:05 PM, Emmanuel DECAEN wrote: >>> And what does nagios-nrpe-server log on the system where the check_disk >>> command you claim fails? >> May 31 22:46:45 server nrpe[31037]: Running command: >> /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql >> May 31 22:46:45 server nrpe[31037]: Command completed with return code 2 >> and output: DISK CRITICAL - /var/tmp/mysql is not accessible: No such >> file or directory >> May 31 22:46:45 server nrpe[31037]: Return Code: 2, Output: DISK >> CRITICAL - /var/tmp/mysql is not accessible: No such file or directory >> >> I think the problem is related to this "private" mount in >> nagios-nrpe-server (extract from /proc/xx/mountinfo): >> 121 113 8:5 >> /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-MbLbk1/tmp >> /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 rw,data=ordered > The systemd configuration uses PrivateTmp=true, you can override it by > adding a snippet: > > /etc/systemd/system/nagios-nrpe-server.service.d/local.conf > > With the following content: > > [Service] > PrivateTmp=false > > See systemd.exec(5) for details about PrivateTmp. Thanks for the details. > > You have a non-standard setup, hence you need to customize the > configuration. This is not a bug in nagios-nrpe, so I'm closing this issue. I disagree. Having a configuration using standard check_disk on any directory can't be considered as "a non-standard setup" (and especially when it was working correctly in Debian 8) Maybe, I'm missing something but there was no "PrivateTmp=true" in Debian 8 nagios-nrpe-server. >From what I see, using "PrivateTmp=true" in nagios-nrpe-server is a *change in behavior from Debian 8 to Debian 9*. I think, you can't indicate "not found" on this bug report as it can be easily reproduced, with a standard check_disk configuration. Don't you think the package upgrade should warn user about this change when migrating from Debian 8 to Debian 9 ? Regards, -- *Emmanuel DECAEN*
Bug#863797: Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp
Le 31/05/2017 à 18:50, Sebastiaan Couwenberg a écrit : > On 05/31/2017 06:11 PM, Emmanuel DECAEN wrote: >> Le 31/05/2017 à 17:04, Bas Couwenberg a écrit : >>> On 2017-05-31 16:52, Jan Wagner wrote: >>>> Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN: >>>>> In nrpe, system wide /var/tmp is no more reachable >>>>> $ grep "/var/tmp" /proc/11489/mountinfo >>>>> 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65 >>>>> master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota >>>>> 121 113 8:5 >>>>> /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp >>>>> >>>>> /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 >>>>> rw,data=ordered >>>> As you traced the problem yourself to nrpe, you might want to reassign >>>> the bug to nagios-nrpe-plugin with appropriate version? >>> If NRPE cannot execute the checkcommand that implies that the nagios >>> user doesn't have the required permissions. >> Command run as nagios user: >> nagios@server:~$ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p >> /var/tmp/mysql >> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);| >> /var/tmp/mysql=42MB;8184;9207;0;10230 > This is what NRPE executes, so this is not a problem in NRPE. > >>> The given checkcommand is not part of the default configuration: >>> >>> /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql >>> >>> Which suggests that this is a configuration issue to be resolved by >>> the administrator of the system. (e.g use sudo to execute the plugin >>> as a users with the required permissions). >> (It was working before upgrade) >> >> Using sudo : >> $ sudo -u nagios /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p >> /var/tmp/mysql >> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);| >> /var/tmp/mysql=42MB;8184;9207;0;10230 > What is the output of the check_nrpe command when you execute it (as the > nagios user) from the monitoring host? nagios@mon:~$ /usr/lib/nagios/plugins/check_nrpe -n -H server -c check_tmpsqldisk DISK CRITICAL - /var/tmp/mysql is not accessible: No such file or directory > And what does nagios-nrpe-server log on the system where the check_disk > command you claim fails? May 31 22:46:45 server nrpe[31037]: Running command: /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql May 31 22:46:45 server nrpe[31037]: Command completed with return code 2 and output: DISK CRITICAL - /var/tmp/mysql is not accessible: No such file or directory May 31 22:46:45 server nrpe[31037]: Return Code: 2, Output: DISK CRITICAL - /var/tmp/mysql is not accessible: No such file or directory I think the problem is related to this "private" mount in nagios-nrpe-server (extract from /proc/xx/mountinfo): 121 113 8:5 /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-MbLbk1/tmp /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 rw,data=ordered Best Regards, -- *Emmanuel DECAEN*
Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp
reassign 863797 nagios-nrpe-server 3.0.1-3 Le 31/05/2017 à 16:52, Jan Wagner a écrit : > Hi Emmanuel, > > thanks for bringing this to our attention. > > Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN: >> Package: monitoring-plugins-basic >> Version: 2.2-3 > [...] >> After upgrade, check_disk on /var/tmp/mysql is broken. >> >> Status using nrpe (wrong): >> DISK CRITICAL - /var/tmp/mysql is not accessible: No such file or directory >> >> Status using bash (works correctly): >> $ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql >> DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);| >> /var/tmp/mysql=42MB;8184;9207;0;10230 > Which is a strong indication that check_disk itself works as expected. > >> In nrpe, system wide /var/tmp is no more reachable >> $ grep "/var/tmp" /proc/11489/mountinfo >> 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65 >> master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota >> 121 113 8:5 >> /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp >> /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 rw,data=ordered > As you traced the problem yourself to nrpe, you might want to reassign > the bug to nagios-nrpe-plugin with appropriate version? I agree to reassign the bug to the package containing /usr/sbin/nrpe. Best regards, -- *Emmanuel DECAEN*
Bug#863797: Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp
Le 31/05/2017 à 17:04, Bas Couwenberg a écrit : > On 2017-05-31 16:52, Jan Wagner wrote: >> Am 31.05.17 um 12:06 schrieb Emmanuel DECAEN: >>> In nrpe, system wide /var/tmp is no more reachable >>> $ grep "/var/tmp" /proc/11489/mountinfo >>> 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65 >>> master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota >>> 121 113 8:5 >>> /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp >>> >>> /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 >>> rw,data=ordered >> As you traced the problem yourself to nrpe, you might want to reassign >> the bug to nagios-nrpe-plugin with appropriate version? > > If NRPE cannot execute the checkcommand that implies that the nagios > user doesn't have the required permissions. Command run as nagios user: nagios@server:~$ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);| /var/tmp/mysql=42MB;8184;9207;0;10230 > > The given checkcommand is not part of the default configuration: > > /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql > > Which suggests that this is a configuration issue to be resolved by > the administrator of the system. (e.g use sudo to execute the plugin > as a users with the required permissions). (It was working before upgrade) Using sudo : $ sudo -u nagios /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);| /var/tmp/mysql=42MB;8184;9207;0;10230 Best Regards -- *Emmanuel DECAEN*
Bug#863797: monitoring-plugins-basic: unable to use check_disk inside /var/tmp
Package: monitoring-plugins-basic Version: 2.2-3 Severity: important Dear Maintainer, After upgrade, check_disk on /var/tmp/mysql is broken. Status using nrpe (wrong): DISK CRITICAL - /var/tmp/mysql is not accessible: No such file or directory Status using bash (works correctly): $ /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /var/tmp/mysql DISK OK - free space: /var/tmp/mysql 10187 MB (99% inode=99%);| /var/tmp/mysql=42MB;8184;9207;0;10230 In nrpe, system wide /var/tmp is no more reachable $ grep "/var/tmp" /proc/11489/mountinfo 115 113 254:2 / /var/tmp/mysql rw,noatime,nodiratime shared:65 master:32- xfs /dev/mapper/v1-tmp rw,attr2,inode64,noquota 121 113 8:5 /tmp/systemd-private-b35c254c031041979d3126e02a0c5c51-nagios-nrpe-server.service-7xjqpw/tmp /var/tmp rw,relatime shared:66 master:28 - ext4 /dev/sda5 rw,data=ordered -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages monitoring-plugins-basic depends on: ii iputils-ping 3:20161105-1 ii libc6 2.24-10 ii libssl1.1 1.1.0e-2 ii monitoring-plugins-common 2.2-3 ii procps 2:3.3.12-3 ii ucf3.0036 Versions of packages monitoring-plugins-basic recommends: ii libcap2-bin 1:2.25-1 Versions of packages monitoring-plugins-basic suggests: pn icinga | icinga2 -- Emmanuel DECAEN
Bug#856590: systemd: Unspecified problems mounting /usr partition
Hi, Le 31/03/2017 à 10:21, Michael Biebl a écrit : The udevadm info dump you attached shows that TAGS=:systemd: is missing for all your partitions, thus systemd doesn't consider them ready. The flag is no more missing, and the boot problem is still present. udevadm info /dev/sda6 P: /devices/pci:00/:00:16.1/:0c:00.0/host2/target2:0:0/2:0:0:0/block/sda/sda6 N: sda6 S: disk/by-partuuid/000586b9-06 S: disk/by-path/pci-:0c:00.0-scsi-0:0:0:0-part6 S: disk/by-uuid/08511bfb-ef79-432c-b792-c455ec64679e E: DEVLINKS=/dev/disk/by-partuuid/000586b9-06 /dev/disk/by-path/pci-:0c:00.0-scsi-0:0:0:0-part6 /dev/disk/by-uuid/08511bfb-ef79-432c-b792-c455ec64679e E: DEVNAME=/dev/sda6 E: DEVPATH=/devices/pci:00/:00:16.1/:0c:00.0/host2/target2:0:0/2:0:0:0/block/sda/sda6 E: DEVTYPE=partition E: ID_BUS=scsi E: ID_FS_TYPE=ext3 E: ID_FS_USAGE=filesystem E: ID_FS_UUID=08511bfb-ef79-432c-b792-c455ec64679e E: ID_FS_UUID_ENC=08511bfb-ef79-432c-b792-c455ec64679e E: ID_FS_VERSION=1.0 E: ID_MODEL=Virtual_disk E: ID_MODEL_ENC=Virtual\x20disk\x20\x20\x20\x20 E: ID_PART_ENTRY_DISK=8:0 E: ID_PART_ENTRY_NUMBER=6 E: ID_PART_ENTRY_OFFSET=46874624 E: ID_PART_ENTRY_SCHEME=dos E: ID_PART_ENTRY_SIZE=7811072 E: ID_PART_ENTRY_TYPE=0x83 E: ID_PART_ENTRY_UUID=000586b9-06 E: ID_PART_TABLE_TYPE=dos E: ID_PART_TABLE_UUID=000586b9 E: ID_PATH=pci-:0c:00.0-scsi-0:0:0:0 E: ID_PATH_TAG=pci-_0c_00_0-scsi-0_0_0_0 E: ID_REVISION=1.0 E: ID_SCSI=1 E: ID_TYPE=disk E: ID_VENDOR=VMware E: ID_VENDOR_ENC=VMware\x20\x20 E: MAJOR=8 E: MINOR=6 E: PARTN=6 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=2997221 That tag is set in /lib/udev/rules.d/99-systemd.rules. Is that file missing? This file is present. Do you have any custom udev rules in /etc/udev/rules.d ? ls -l /etc/udev/rules.d/ -rw-r--r-- 1 root root 789 Mar 6 2012 70-persistent-cd.rules Another (probably unrelated) observation is, that your /etc/fstab uses type ext4 while the udev info shows ID_FS_TYPE=ext3 Oups, this morning, i'm converting ext3 to ext4, you should consider the following /etc/fstab: # proc/proc procdefaults0 0 # / was on /dev/sda1 during installation UUID=0ab4af79-6e21-4c58-8514-2cf849d53ae1 / ext3 errors=remount-ro 0 1 # /home was on /dev/sda7 during installation UUID=60dac49d-8399-4a6f-9ded-7adc952fc33e /home ext4 defaults 0 2 # /tmp was on /dev/sda6 during installation UUID=08511bfb-ef79-432c-b792-c455ec64679e /tmp ext3 defaults 0 2 # /var was on /dev/sda5 during installation UUID=66610011-7694-4574-ba2f-7ab34169b037 /var ext3 defaults 0 2 # swap was on /dev/sda2 during installation UUID=840f5b96-d8ce-4ad5-9750-330cb69bf691 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/sda7 is now converted: udevadm info /dev/sda7 [...] S: disk/by-uuid/60dac49d-8399-4a6f-9ded-7adc952fc33e E: DEVLINKS=/dev/disk/by-path/pci-:0c:00.0-scsi-0:0:0:0-part7 /dev/disk/by-p artuuid/000586b9-07 /dev/disk/by-uuid/60dac49d-8399-4a6f-9ded-7adc952fc33e E: DEVNAME=/dev/sda7 [...] E: ID_FS_TYPE=ext4 E: ID_FS_USAGE=filesystem [...] The problem is still present with this /etc/fstab configuration. In any case, we shouldn't hijack this bug report. It's probably not the same issue. If you think it's not related, I can open a new bug report. Thanks -- *Emmanuel DECAEN*
Bug#856590: systemd: Unspecified problems mounting /usr partition
Hi, The system boots correctly using sysV grub option, but randomly fails during boot using systemd (grub default). /etc/fstab: # proc/proc procdefaults0 0 # / was on /dev/sda1 during installation UUID=0ab4af79-6e21-4c58-8514-2cf849d53ae1 / ext4 errors=remount-ro 0 1 # /home was on /dev/sda7 during installation UUID=60dac49d-8399-4a6f-9ded-7adc952fc33e /home ext4 defaults 0 2 # /tmp was on /dev/sda6 during installation UUID=08511bfb-ef79-432c-b792-c455ec64679e /tmp ext4 defaults 0 2 # /var was on /dev/sda5 during installation UUID=66610011-7694-4574-ba2f-7ab34169b037 /var ext4 defaults 0 2 # swap was on /dev/sda2 during installation UUID=840f5b96-d8ce-4ad5-9750-330cb69bf691 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 Regards, -- *Emmanuel DECAEN*
Bug#520417: Remove /etc/network/*.d/vlan
Hello, Maybe I'm wrong, but it looks like the /etc/network/*.d/vlan conflicts with normal behaviour of ifup/ifdown in wheezy. The script ifup/ifdown already use ip link to configure and create vlan. Configuration file /etc/network/interfaces auto bond2.341 iface bond2.341 inet static address 192.168.1.1 netmask 255.255.255.0 With VLAN package installed: # ifconfig bond2.341 bond2.341: error fetching interface information: Device not found # ifup bond2.341 Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config ERROR: trying to add VLAN #341 to IF -:bond2:- error: File exists # ifconfig bond2.341 bond2.341 Link encap:Ethernet HWaddr 00:10:18:f0:88:b8 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::210:18ff:fef0:88b8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:398 (398.0 B) # ifdown bond2.341 Removed VLAN -:bond2.341:- Cannot find device bond2.341 # ifconfig bond2.341 bond2.341: error fetching interface information: Device not found Without VLAN package: # dpkg -P vlan Removing vlan ... Purging configuration files for vlan ... # ifup bond2.341 # ifconfig bond2.341 bond2.341 Link encap:Ethernet HWaddr 00:10:18:f0:88:b8 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::210:18ff:fef0:88b8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:398 (398.0 B) # ifdown bond2.341 # ifconfig bond2.341 bond2.341: error fetching interface information: Device not found The scripts /etc/network/*.d/vlan should be modified or removed ? On the web site of the author http://www.candelatech.com/~greear/vlan.html http://www.candelatech.com/%7Egreear/vlan.html it's written : 802.1Q VLAN code is now part of the official kernel, and has been for years and years. MAC-VLAN code has been added since around 2.6.29. It is very unlikely that you need to download anything from this site, the packages are left here for posterity's sake. Thanks. -- *Emmanuel DECAEN*
Bug#650981: Re: Memory leak on Quagga 0.99.20
Hello, Yes, it has long been fixed in Quagga 0.99.21... But, current Debian Stable release contains Quagga 0.99.20. I you plan to close this bug, could you please solve the bug before. Regards -- Emmanuel DECAEN Le 06/01/2013 17:11, Christian Hammers a écrit : Hello This has long been fixed in Quagga 0.99.21. bye, -christian- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650981: quagga: Memory leak on Quagga 0.99.20
Package: quagga Version: 0.99.20-3 Severity: important Tags: patch Hello, BGP part of Quagga in 0.99.20 use a lot more memory than before. On the same gateway: - Using Quagga 0.99.17, memory used 323 MB - Using Quagga 0.99.20, memory used 769 MB It looks like this is due to a memory leak, this patch should solve the problem: http://patchwork.diac24.net/patch/402/ Best Regards -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages quagga depends on: ii adduser3.113 ii debconf [debconf-2.0] 1.5.41 ii iproute2017-1 ii libc6 2.13-21 ii libcap21:2.22-1 ii libpam0g 1.1.3-6 ii libreadline6 6.2-8 ii libtinfo5 5.9-4 ii logrotate 3.7.8-6 quagga recommends no packages. Versions of packages quagga suggests: ii snmpd 5.4.3~dfsg-2.3+b1 -- debconf information: * quagga/really_stop: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#332229: raidutils: raideng Segmentation fault (solution ?)
Hello, Barak A. Pearlmutter a écrit : I think the patch you mention is included in the current Debian version, 0.0.6-3. It seems to works fine for me, but I'm not doing anything fancy with it. Could I trouble you to check for the problem in this bug? Yes, if I can help :-) The package should compile fine under sarge, albeit with an newer debhelper installed from sarge-backports. If you'd like I can send you a binary .deb built for your environment; just let me know. I'm running Etch, I got raidutils debian version 0.6.6-3. If you want me to test another .deb binary, I will try it and tell you the result. Thanks. -- Emmanuel DECAEN XSALTO - www.xsalto.com - [EMAIL PROTECTED] Tél : 0820 208 408 - Fax : 04 92 36 19 75
Bug#332229: raidutils: raideng Segmentation fault (solution ?)
Followup-For: Bug #332229 Package: raidutils Version: 0.0.6-3 *** Please type your report below this line *** I had the same problem and this is now solved. The solution (for me) : - got the package from http://i2o.shadowconnect.com/raidutils/raidutils-0.0.6.tar.bz2 - got the debian-patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356366 - cd /usr/src - tar -xvjf raidutils-0.0.6.tar.bz2 - cd raidutils-0.0.6 - patch -p0 debian-patch - ./configure - make - (under root) mv raideng/raideng /usr/local/bin/ And now, raidutils works correctly. -- Emmanuel DECAEN - XSALTO - www.xsalto.com -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages raidutils depends on: ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 raidutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388027: Auto reconnect to DB when connection dropped?
Hi Kern, Kern Sibbald wrote : It seems to me that there are a few issues here: 1. If you shutdown or upgrade a database while Bacula is running a Job, then Bacula will fail. The solution is: don't do that. Bacula has no explicit code to reconnect to a database after the database is successfully opened, and we don't plan to add any such code as it would render the data less secure. No shutdown or upgrade when the problem occurs. 2. It is possible that the network (if that is what you setup) connection between Bacula and the database server could be broken. In that case, since it is the database's client libraries that established the connection, it is their responsibility to manage the connection and reconnect if it is possible. If the database API supplies a call or flag that requests the client libraries to reconnect, we will (and in the case of MySQL where this exists do) use the API/flag. However, this still leaves it to the client libraries to manage the interface. The Mysql Server and Bacula Director are on the same server. Catalogs use nearly 48 GB (over 100 GB dedicated now) Backups use nearly 6 067 GB. 3. With most databases, you can set them up to use sockets rather than TCP/IP providing the database and the Director run on the same machine. This might reduce any disconnects that would occur via TCP/IP. We use tcp/ip, we can try unix socket, if it helps. 4. Bacula has a connection to the database open only when it is actually running a job, so if this error occurs, and the client library cannot reconnect by itself, Bacula will take the conservative point of view and fail the job. Ok 5. There was one case of MySQL recently releasing a new version where they changed the API/flag that requests reconnect. This unfortunately resulted in a few dropped connections until we modified the Bacula code to correspond to the new MySQL coding. This should no longer be an issue if you are running any version of 1.38.11. The only (debian) version with this problem is bacula-xxx-1.38.11-5. bacula-xxx-1.38.11-1 and bacula-xxx-1.38.11-7 don't have this problem. 6. Some of the test results reported indicate that there may be a bug with specific versions of MySQL. Works correctly during 2 weeks : - bacula 1.38.11-1 and mysql 5.0.22-4 - bacula 1.38.11-1 and mysql 5.0.24a - bacula 1.38.11-7 and mysql 5.0.27 Fails after few days : - bacula 1.38.11-5 and mysql 5.0.22-4 - bacula 1.38.11-5 and mysql 5.0.24a Providing there are no Debian specific modifications to the cats directory source code, I recommend closing this bug report as there is no planned change to Bacula and no known bug in version 1.38.11 or greater. I agree to close this bug report, current version of Bacula doesn't seem to have anymore the described problem. I do have wishes, but this bug report is not the correct place for them ;-) Bacula is a really good product, you've done a great job ! Thanks. -- Emmanuel DECAEN XSALTO - www.xsalto.com - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388027: director-mysql fatal error
Hi, I had no problem with bacula 1.38.11-1 and 5.0.24a since 2 weeks. If I sum up : Works correctly during 2 weeks : - bacula 1.38.11-1 and mysql 5.0.22-4 - bacula 1.38.11-1 and mysql 5.0.24a Fails after few days : - bacula 1.38.11-5 and mysql 5.0.22-4 - bacula 1.38.11-5 and mysql 5.0.24a The only difference between them, is the version of Bacula, the problem appears only in bacula 1.38.11-5. If this is the same bacula version (1.38.11), it looks like a Debian problem. Thanks. -- Emmanuel DECAEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388027: director-mysql fatal error
Hi,
As I said before :
I've reproduced the problem on bacula 1.38.11-5, last week with mysql
5.0.24a and yesterday with mysql 5.0.22-4.
20-Sep 00:14 backup01-dir: Bak_x_mail.2006-09-20_00.14.09 Fatal error:
sql_create.c:87 Create DB Job record INSERT INTO Job
(Job,Name,Type,Level,JobStatus,SchedTime,JobTDate) VALUES
('Bak_x_mail.2006-09-20_00.14.09','Bak_x_mail','B','I','C','2006-09-20
00:14:08',1158704048) failed. ERR=MySQL server has gone away
I will try with older Debian version of bacula 1.38.11-1 and mysql 5.0.22-4.
I had no problem with bacula 1.38.11-1 and mysql 5.0.22-4 since 3 weeks.
Now, I will try with bacula 1.38.11-1 and mysql 5.0.24a-9.
If I sum up :
- bacula 1.38.11-5 and mysql 5.0.24a : fails after few days
- bacula 1.38.11-5 and mysql 5.0.22-4 : fails after few days
- bacula 1.38.11-1 and mysql 5.0.22-4 : works correctly since 3 weeks
- bacula 1.38.11-1 and mysql 5.0.24a-9 : test in progress
Thanks.
--
Emmanuel DECAEN
XSALTO - www.xsalto.com - [EMAIL PROTECTED]
Tél : 0820 208 408 - Fax : 04 92 36 19 75
Je serais en congés du 28 Septembre au 17 Octobre 2006
Bug#388027: Acknowledgement (bacula-director-mysql fails after restart of MySQL)
Hello,
I've reproduced the problem on bacula 1.38.11-5, last week with mysql
5.0.24a and yesterday with mysql 5.0.22-4.
20-Sep 00:14 backup01-dir: Bak_x_mail.2006-09-20_00.14.09 Fatal error:
sql_create.c:87 Create DB Job record INSERT INTO Job
(Job,Name,Type,Level,JobStatus,SchedTime,JobTDate) VALUES
('Bak_x_mail.2006-09-20_00.14.09','Bak_x_mail','B','I','C','2006-09-20
00:14:08',1158704048) failed. ERR=MySQL server has gone away
I will try with older Debian version of bacula 1.38.11-1 and mysql 5.0.22-4.
Thanks.
--
Emmanuel DECAEN
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388027: Acknowledgement (bacula-director-mysql fails after restart of MySQL)
Hi,
John Goerzen wrote :
On Sun, Sep 24, 2006 at 12:58:10PM +0200, Emmanuel DECAEN wrote:
I've reproduced the problem on bacula 1.38.11-5, last week with mysql
5.0.24a and yesterday with mysql 5.0.22-4.
20-Sep 00:14 backup01-dir: Bak_x_mail.2006-09-20_00.14.09 Fatal error:
sql_create.c:87 Create DB Job record INSERT INTO Job
(Job,Name,Type,Level,JobStatus,SchedTime,JobTDate) VALUES
('Bak_x_mail.2006-09-20_00.14.09','Bak_x_mail','B','I','C','2006-09-20
00:14:08',1158704048) failed. ERR=MySQL server has gone away
This would be a MySQL issue -- the MySQL server has gone away means
that the system couldn't maintain a working connection to MySQL.
Perhaps your disk is full?
I've created a 40 GB dedicated space for catalogs (mysql) and only 15 GB
are used.
And the problem has occured only for this catalog over 14 catalogs.
As a result, the backups of this catalog were in ERROR, but all the
others (from others catalogs) were OK.
If it can help, Bacula is used to backup, every day, 60 servers on a 5.5
TB dedicated backup system.
This is the result of a mysqlcheck on catalog cat_x :
$ mysqlcheck -p cat_x
cat_x.BaseFiles OK
cat_x.CDImages OK
cat_x.ClientOK
cat_x.Counters OK
cat_x.DeviceOK
cat_x.File OK
cat_x.FileSet OK
cat_x.Filename OK
cat_x.Job OK
cat_x.JobMedia OK
cat_x.Media OK
cat_x.MediaType OK
cat_x.Path OK
cat_x.Pool OK
cat_x.StatusOK
cat_x.Storage OK
cat_x.UnsavedFiles OK
cat_x.Version OK
Bacula-director and mysql-server are on the same server.
Thanks.
--
Emmanuel DECAEN
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388027: bacula-director-mysql fails after restart of MySQL
Hello, You don't need to restard mysql-server to exhibit this problem. We have this problem randomly with the new version of mysql-server (5.0.24). In order to solve this problem, we had to downgrade to 5.0.22 version of mysql-server and libmysqlclient15off. Best regards. -- Emmanuel DECAEN -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366278: imp4: Action Purge deleted disappeared.
Hello, If you want to have the Purge deleted action displayed, you can enable it by changing the value of vinbox_id in /etc/horde/imp4/prefs.php : $ diff -u /etc/horde/imp4/prefs.php.old /etc/horde/imp4/prefs.php --- /etc/horde/imp4/prefs.php.old 2006-06-30 17:06:34.0 +0200 +++ /etc/horde/imp4/prefs.php 2006-06-30 17:06:48.0 +0200 @@ -1209,7 +1209,7 @@ // virtual inbox identifier $_prefs['vinbox_id'] = array( -'value' = '', +'value' = '0', 'locked' = false, 'shared' = false, 'type' = 'implicit'); This is not the solution, but it's a way to have this Purge deleted back ;-) -- Emmanuel DECAEN XSALTO - www.xsalto.com - [EMAIL PROTECTED] Tél : 0820 208 408 - Fax : 04 92 36 19 75
Bug#364917: vrrpd: Need new ioctl for -m (monitoring)
Package: vrrpd
Version: 1.0-1
Severity: normal
The monitoring option of vrrpd (-m) does not support the new ioctl for MII
for example :
# vrrpd -m eth1
SIOCGMIIPHY on eth1 failed: Operation not supported
This problem can be corrected with the following patch :
diff -u vrrpd-old.c vrrpd.c
--- vrrpd-old.c 2006-04-26 18:10:37.0 +0200
+++ vrrpd.c 2006-04-26 18:11:46.0 +0200
@@ -113,6 +113,7 @@
intskfd[MAXINTS]; /* AF_INET socket for ioctl() calls. */
struct ifreq ifr[MAXINTS];
char *ifname[MAXINTS];
+int new_ioctl_nums;
/
NAME : print_buffer 01/05/23 12:26:27
@@ -1784,7 +1785,7 @@
data[0] = phy_id;
data[1] = location;
- if ( ioctl( skfd[i], SIOCGMIIREG, ifr[i] ) 0 ) {
+ if ( ioctl( skfd[i], new_ioctl_nums ? 0x8948 : SIOCGMIIREG, ifr[i] ) 0 ) {
fprintf( stderr, SIOCGMIIREG on %s failed: %s\n, ifr[i].ifr_name,
strerror( errno ));
return -1;
@@ -1806,12 +1807,18 @@
}
/* Get the vitals from the interface. */
strncpy( ifr[i].ifr_name, ifname[i], IFNAMSIZ );
- if ( ioctl( skfd[i], SIOCGMIIPHY, ifr[i]) 0 ) {
+ if (ioctl(skfd[i], 0x8947, ifr[i]) = 0) {
+new_ioctl_nums=1;
+ }
+ else if ( ioctl( skfd[i], SIOCGMIIPHY, ifr[i]) = 0 ) {
+new_ioctl_nums=0;
+ } else
+ {
fprintf( stderr, SIOCGMIIPHY on %s failed: %s\n, ifname[i],
strerror( errno ));
(void) close( skfd[i] );
exit( -1 );
- }
+ }
}
/
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages vrrpd depends on:
ii libc6 2.3.6-7GNU C Library: Shared libraries
vrrpd recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
