Bug#1057466: htop: CPU limit Regression in htop 3.2.2 caused by patch in deb package (?)
> > The processors shown were not necessarily the ones running the load, > easily seen by not matching temp and speed measurements. > Oh yes, I agree, that's annoying. More annoying than seeing the unused CPUs actually. However the situation of the OP in issue https://github.com/htop-dev/htop/issues/1195, which has "caused" the patch, is slightly different. OP seems to be using LXD with just a CPU limit set but with random threads and no fixed CPU assignment. In my situation I have assigned a specific set of cpu's (e.g. 6-7) to the LXC container. Here htop represents the correct CPU usage. Compared CPU usage on host and inside container with htop 3.2.2 (source) and htop 3.2.2 (deb) and they show the same values (with some millisecond diffs of course). You can find both htop 3.2.2 from source and from deb package running in parallel inside the same container: https://www.claudiokuenzler.com/media/htop-3.2.2-comparison.png Now the question is whether or not this situation is somehow detectable. Is there some "knowledge" inside the container that there are fixed cpu threads assigned to the container or are these randomly assigned threads? But this is a discussion which is out of scope of Debian and should be discussed in htop upstream. Maybe also include Stephane Graber or someone from the LXC maintainers in the discussion. I let you close this Debian bug now, as I agree, in a situation with random cpu threads the htop cpu usage can be wrong and this is worse than seeing all cpu threads from the host.
Bug#1057466: htop: CPU limit Regression in htop 3.2.2 caused by patch in deb package (?)
On Tue, Dec 5, 2023 at 4:56 PM Daniel Lange wrote: > The rationale is given on top of the patch that you found > (001_remove_lxc_special_handling.patch) and the matching commit > > < > https://github.com/htop-dev/htop/commit/11318b5ef6de6b2f80186a888cd5477e0ff167bb > > > > We don't have any better LXC handling, so I opted for showing the > reality (visible CPUs that the container cannot schedule load on) over > the bugs we had otherwise. > Thank you, Daniel, for your quick response. Probably depends on the view point, but the reality for me is that this container is able to use two cpus. The fact that all physical cores are showing up is misleading - especially as htop is often used for a "quick view" on resource usage. > You created upstream #1332 but did not try the latest htop main branch, > did you? I suspect it will be the same but would be nice to confirm. > NB: There has been some improvements in the cgroup name handling for LXC > since the 3.2.2 release. > The current main branch shows the same behaviour: All physical cores are showing up. Here is a comparison. htop 3.2.1 shows 2 cpus, 31 tasks, 66 threads. htop uses roughly 0.7% CPU htop 3.2.2 shows 2 cpus, 31 tasks, 66 threads. htop uses roughly 1.3% CPU htop 3.2.2 with that patch shows 16 cpus, 31 tasks, 66 threads. htop uses between 5.3% and 10.6% CPU htop current main branch shows 16 cpus, 31 tasks, 66 threads. htop uses between 5.3% and 10.6% CPU I guess I fail to see the reason why this patch (removing LXC handling) was implemented. What was the bug being the reason to apply this patch? Let me know If I can help with some additional tests in my environments.
Bug#1057466: htop: CPU limit Regression in htop 3.2.2 caused by patch in deb package (?)
Package: htop Version: 3.2.2-2 Severity: normal Dear Maintainer, It seems that htop 3.2.2 for Debian 12/Bookworm contains a patch which removes LXC specific code to identify cgroup limited cpu cores. Due to that patch, which removes that cgroup limit lookup, htop shows all physical cores inside a LXC container. The container in question has a cpu limit set to 2 CPUs. htop should show two CPUs at the top of the ncurses UI - however on Debian 12 all physical cores are showing up. Manually compiling and running htop 3.2.2 from source shows the correct number of cgroup limited CPUs inside a LXC container. To me it looks as if the patch, added in the deb package, is a regression. Was there a specific reason to add this patch? I cant see what is supposed to be broken without that patch. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.deb10.16-amd64 (SMP w/16 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/bash Init: systemd (via /run/systemd/system) Versions of packages htop depends on: ii libc6 2.36-9+deb12u3 ii libncursesw6 6.4-4 ii libnl-3-200 3.7.0-0.2+b1 ii libnl-genl-3-200 3.7.0-0.2+b1 ii libtinfo6 6.4-4 htop recommends no packages. Versions of packages htop suggests: pn lm-sensors ii lsof4.95.0-1 pn strace -- no debconf information
Bug#898336: hpwdt NMI kernel crash on shutdown/reboot
Just FYI, this bug still happens on the new Debian 12 Bookworm Alpha2, currently Debian Testing. Solution is the same as previously stated: Disable (blacklsit) hpwdt Kernel module.
Bug#1009351: systemd: Static IP addressing (from config) in LXC containers not working anymore
Possibly related: https://github.com/lxc/lxc-ci/pull/487
Bug#1009351: systemd: Static IP addressing (from config) in LXC containers not working anymore
> Can you attach the output of > systemctl status systemd-networkd.service > journalctl -ulb systemd-networkd.service > > for both containers. > Older 11.2 container: root@11-2:~# systemctl status systemd-networkd.service Warning: The unit file, source configuration file or drop-ins of systemd-networkd.service changed on disk. Run 'systemctl daemon-reload' to reload units. ● systemd-networkd.service Loaded: masked (Reason: Unit systemd-networkd.service is masked.) Drop-In: /run/systemd/system/service.d └─zzz-lxc-service.conf Active: inactive (dead) root@11-2:~# journalctl -ulb systemd-networkd.service Failed to add match 'systemd-networkd.service': Invalid argument Newly created 11.3 container (11test2): root@11test2:~# systemctl status systemd-networkd.service ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled) Drop-In: /run/systemd/system/service.d └─zzz-lxc-service.conf Active: active (running) since Tue 2022-04-12 13:56:00 UTC; 34s ago TriggeredBy: ● systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 85 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 619000) Memory: 4.0M CPU: 38ms CGroup: /system.slice/systemd-networkd.service └─85 /lib/systemd/systemd-networkd Apr 12 13:55:59 11test2 systemd[1]: Starting Network Service... Apr 12 13:56:00 11test2 systemd-networkd[85]: eth0: Gained IPv6LL Apr 12 13:56:00 11test2 systemd-networkd[85]: Enumeration completed Apr 12 13:56:00 11test2 systemd[1]: Started Network Service. root@11test2:~# journalctl -ulb systemd-networkd.service Failed to add match 'systemd-networkd.service': Invalid argument There's the following diff in the zzz-lxc-service.conf: root@11test2:~# diff /run/systemd/system/service.d/zzz-lxc-service.conf /tmp/zzz-lxc-service-11.2.conf 2d1 < ProcSubset=all So the reason for the previously working case seems to be because the systemd-networkd service was actually masked before. Where and why the mask did come from? No idea... > > If systemd-networkd wasn't running in your old, 11.2 based container, it > couldn't interfere with your custom network setup. > > This is btw I recommended to disable systemd-networkd as the correct > solution for your issue. > Yes, that's fine for me. I'll adjust our template for that case. In Ubuntu we need to do the same with Netplan.
Bug#1009351: systemd: Static IP addressing (from config) in LXC containers not working anymore
On Tue, Apr 12, 2022 at 11:33 AM Michael Biebl wrote:
>
> Hm, works fine here, i.e. I can't reproduce your problem.
> I'm running LXC on a Debian sid host though.
> Maybe it's something related to your LXC configuration/installation?
>
Hi Michael
LXC host runs on Debian Bullseye.
ck@host:~$ dpkg -l|egrep "(systemd|lxc)" | awk '{print $2" "$3}'
dbus-user-session 1.12.20-2
liblxc1:amd64 1:4.0.6-2
libnss-systemd:amd64 247.3-6
libpam-systemd:amd64 247.3-6
libsystemd0:amd64 247.3-6
libvirt-daemon-system-systemd 7.0.0-3
lxc 1:4.0.6-2
lxcfs 4.0.7-1
systemd 247.3-6
systemd-container 247.3-6
systemd-sysv 247.3-6
systemd-timesyncd 247.3-6
I actually see a major difference when comparing a Debian 11.2 vs. a 11.3
container.
---
Inside 11.2 LXC:
root@112:~# cat /etc/debian_version
11.2
ck@112:~$ systemctl list-units|grep network
networking.service loaded active exitedRaise network
interfaces
network-online.target loaded active activeNetwork is
Online
network.target loaded active activeNetwork
Inside 11.3 LXC:
root@113test:~# cat /etc/debian_version
11.3
root@11test:~# systemctl list-units|grep network
systemd-networkd.serviceloaded active running Network
Service
systemd-networkd.socket loaded active running Network
Service Netlink Socket
network.target loaded active activeNetwork
---
Note the different network units.
Both LXC containers have been setup with the same lxc-download template.
Actually a locally modified lxc-download template for our infra so there
was definitely no change inside the template.
Not sure where this change comes from though.
Bug#962807: binfmt-support from Debian stable reports errors/warnings within lxc guests
This situation causes a problem whenever trying to remove an old Python version within an LXC container/guest. E.g. after a dist-upgrade from Debian 10 to 11, running apt autoremove: Removing python3.7 (3.7.3-2+deb10u3) ... Removing libpython3.7-stdlib:amd64 (3.7.3-2+deb10u3) ... Removing python3.7-minimal (3.7.3-2+deb10u3) ... update-binfmts: warning: unable to open /proc/sys/fs/binfmt_misc/python3.7 for writing: Permission denied update-binfmts: warning: unable to disable binary format python3.7 update-binfmts: exiting due to previous errors dpkg: error processing package python3.7-minimal (--remove): installed python3.7-minimal package pre-removal script subprocess returned error exit status 2 dpkg: too many errors, stopping Errors were encountered while processing: python3.7-minimal Processing was halted because there were too many errors. E:Sub-process /usr/bin/dpkg returned an error code (1) See also https://bugs.launchpad.net/ubuntu/+source/binfmt-support/+bug/1862347 According to Stéphane Graber (one of the maintainers of LXC/LXD): > that update-binfmts shouldn't be fatal https://github.com/lxc/lxc/issues/388#issuecomment-71416534
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
The fact that a later Kernel versions work fine _could_ be because of a hpwdt commit after 5.10: https://github.com/torvalds/linux/commit/acc195bd2cc48445ea35d00036d8c0afcc4fcc9c#diff-994ee4b010b5c6222ad7a20e160f733401f46894b36fa3e1fb6ffbb48bedb817 I have not tested sid or a newer Kernel on our HP machines though. If you've compiled your own Kernel and this one works (did your do a multiple reboot test?), maybe there's a difference in the Kernel "config"? What happens if you disable the hpwdt module as mentioned in the other bug reports? Does Bullseye with 5.10 and experimental with 5.14 work in this case?
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
Also look at the following links and compare. Might be related or even the same as you are seeing: https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995773 On Thu, Oct 21, 2021 at 10:42 AM Yunqiang Su wrote: > On Fri, 10 Sep 2021 09:40:41 +0800 YunQiang Su wrote: > > Yunqiang Su 于2021年9月9日周四 上午11:11写道： > > > > > > > > > On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su > wrote: > > > > Package: src:linux > > > > Version: 5.10 > > > > > > > > After upgrade to bullseyes' kernel, the system always hang after > about 10 min > > > > with an error from IML log > > > > > > > > An Unrecoverable System Error (NMI) has occurred (Service > Information: > > > > 0x0008, 0x8948) > > > > > > > > Kernel 5.14 from experimental also has this problem. > > > > Kernel 4.19 works fine. > > > > Fedora 34 seems to be working well. > > > > > > This is the output of dmesg and lspci from both Fedora 34 and Debian > bullseye. > > > Wish they are useful. > > > > > > > Finally, we find the problem: > > > > > https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8 > > > https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf > > > > In the first patch: > >They thought `err' is not used at all, and removed it. > > In the second patch: > >They add it back and a wrong value "-EINVAL" is given. > > > > Better KPI got. > > > > The NICs can be detected now, while the machine continue to hang… > 4.19.y works fine, while 5.10, 5.14 cannot. > > I think that we need more dig. > > > > > > > > > -- > > > > YunQiang Su > > > > > > > > > > > > > > > > -- > > YunQiang Su > > > > > >
Bug#995773: linux-image-5.10.0-8-amd64: NMI panic on HP ProLiant DL380G6 and DL360G7
I've seen this too and documented my findings here: https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380 (reason is the hpwdt module) This bug is most likely a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336 where the same NMI's are reported with Kernel 4.16 but with Kernel 5.10 the boot issues/crashes seem to be even worse. Maintainers, please consider disabling (blacklisting) the hpwdt module by default (same as Ubuntu). If anyone REALLY needs it, it can be manually enabled.
Bug#898336: hpwdt NMI kernel crash on shutdown/reboot 4.16.5-1~bpo9+1
I can confirm (somewhat) similar issues with the newest Debian 11 (Bullseye) and Kernel 5.10 on HP Proliant DL380 G7 servers. Boot does sometimes work, then it doesn't work (with a freeze caused by NMI), leading to a very unstable OS. After disabling hpwdt (module blacklist), the problems were gone. I documented the troubleshooting and solution on my blog: https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380 Ubuntu seems to have disabled/blacklisted the hpwdt module since 2015 already: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1432837 Maybe something Debian should also consider?
Bug#990428: ifenslave: Bonding not working on bullseye (using bond-slaves config)
> In your case you could simply remove the stanzas for enp4s0f0 and enp4s0f1 > which would leave you with just the stanza for bond1: > iface bond1 inet static > bond-slaves enp4s0f0 enp4s0f1 Thank you Oleander. It works with this hint (the physical interfaces were left out of the config). Working config: = ck@bullseye:~$ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback auto bond0 iface bond0 inet static address 192.168.12.4/24 gateway 192.168.12.1 bond-slaves enp3s0f0 enp3s0f1 bond-mode 802.3ad bond-miimon 100 bond-lacp-rate 1 = > That should work but it is still a regression as it breaks configuration > which worked before. Yes, agree. Do you know if your patch (I have not tested) will be included in the next point release? > https://serverfault.com/a/1075192/267378 > > Best regards, > Arunas You mention both bond-master of the physical devices and blond-slaves on the bond interface. This causes networking service to hiccup in my case: Sep 01 15:58:23 irczsrvp09 systemd[1]: Starting Raise network interfaces... Sep 01 15:58:23 irczsrvp09 ifup[1251]: No iface stanza found for master bond0 Sep 01 15:58:23 irczsrvp09 ifup[1249]: run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 1 Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp3s0f0 Sep 01 15:58:23 irczsrvp09 ifup[1256]: No iface stanza found for master bond0 Sep 01 15:58:23 irczsrvp09 ifup[1254]: run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 1 Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp3s0f1 Sep 01 15:58:23 irczsrvp09 ifup[1261]: No iface stanza found for master bond1 Sep 01 15:58:23 irczsrvp09 ifup[1259]: run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 1 Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp4s0f0 Sep 01 15:58:23 irczsrvp09 ifup[1266]: No iface stanza found for master bond1 Sep 01 15:58:23 irczsrvp09 ifup[1264]: run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 1 Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp4s0f1 Although the bonding interface seems to work with your workaround, the Systemd service (networking) is stuck at failed state. So for now the "proper" way to fix this seems to be to remove the physical device stanzas and only use the bonding interfaces - until this bug is fixed.
Bug#990428: Additional information
Non-working bonding config in /etc/network/interfaces: auto enp4s0f0 iface enp4s0f0 inet manual auto enp4s0f1 iface enp4s0f1 inet manual auto bond1 iface bond1 inet static address 192.168.12.4/24 gateway 192.168.12.1 slaves enp4s0f0 enp4s0f1 bond-mode 802.3ad bond-miimon 100 bond-downdelay 200 bond-updelay 200 (also mentioned in https://wiki.debian.org/Bonding) Working config: auto enp4s0f0 iface enp4s0f0 inet manual bond-master bond1 auto enp4s0f1 iface enp4s0f1 inet manual bond-master bond1 auto bond1 iface bond1 inet static address 192.168.12.4/24 gateway 192.168.12.1 bond-slaves none bond-mode 802.3ad bond-miimon 100 bond-downdelay 200 bond-updelay 200
Bug#990428: ifenslave: Bonding not working on bullseye (using bond-slaves config)
Package: ifenslave
Version: 2.12
Severity: important
Dear Maintainer,
Bonding on Debian 11 Bullseye is not working, when using "bond-slaves int1
int2" syntax on the bonding interface.
However it seems to work, when defining bonding the other way around using
"bond-master bond1" on the interfaces which make up the bonding interface.
I came across bug #968368 and modified the ifenslave pre-up.d script, hence the
changes below.
The same config (using bond-slaves) was working fine in Debian Buster. In
Bullseye the bond interface stays DOWN and /proc/net/bonding/bond* also shows
mii-status down.
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-7-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 ifenslave depends on:
ii ifupdown 0.8.36
ii iproute2 5.10.0-4
Versions of packages ifenslave recommends:
ii net-tools 1.60+git20181103.0eebece-1
ifenslave suggests no packages.
-- Configuration Files:
/etc/network/if-pre-up.d/ifenslave changed:
[ "$VERBOSITY" = 1 ] && set -x
[ "$ADDRFAM" = meta ] && exit 0
add_master()
{
# Return if $IFACE is already a bonding interface.
[ -f "/sys/class/net/$IFACE/bonding/slaves" ] && return
ip link add dev "$IFACE" type bond
}
sysfs_change_down()
{
# Called with :
# $1 = basename of the file in bonding/ to write to.
# $2 = value to write. Won't write if $2 is empty.
if [ -n "$2" ] ; then
# If the value we plan to write is different from the current
one...
if ! grep -sq "\\<$2\\>"
"/sys/class/net/$BOND_MASTER/bonding/$1" ; then
# ...and the master is up...
if ip link show "$BOND_MASTER" | grep -sq '[<,]UP[,>]'
; then
# ...bring the master down.
ip link set dev "$BOND_MASTER" down
fi
fi
sysfs "$1" "$2"
fi
}
sysfs()
{
# Called with :
# $1 = basename of the file in bonding/ to write to.
# $2 = value to write. Won't write if $2 is empty.
if [ -n "$2" ] ; then
echo "$2" > "/sys/class/net/$BOND_MASTER/bonding/$1"
return $?
fi
return 0
}
sysfs_add()
{
#??Called with :
# $1 = target filename.
# $2 = values to write.
for value in $2; do
# Do not add $2 to $1 if already present.
if ! grep -sq "\\<$value\\>"
"/sys/class/net/$BOND_MASTER/bonding/$1"
then
sysfs "$1" "+$value"
fi
done
}
early_setup_master()
{
# Warning: the order in which we write into the sysfs files is
important.
# Double check in drivers/net/bonding/bond_sysfs.c in the Linux kernel
source tree
# before changing anything here.
# fail_over_mac must be set before enslavement of any slaves.
sysfs fail_over_mac "$IF_BOND_FAIL_OVER_MAC"
}
enslave_slaves()
{
case "$BOND_SLAVES" in
none)
BOND_SLAVES=""
;;
all)
BOND_SLAVES=$(sed -ne 's/ *\(eth[^:]*\):.*/\1/p'
/proc/net/dev)
;;
esac
[ "$VERBOSITY" = 1 ] && v=-v
for slave in $BOND_SLAVES ; do
export IFENSLAVE_ENV_NAME="IFUPDOWN_$slave"
IFUPDOWN_IFACE="$(printenv "$IFENSLAVE_ENV_NAME")"
unset IFENSLAVE_ENV_NAME
#if ifquery --state "$slave" 2>/dev/null || [ -n
"$IFUPDOWN_IFACE" ] ; then
if ifquery --state "$slave" 2>/dev/null ; then
# Skipping interface that's already up or being
configured
continue
else
# Ensure $slave is down.
ip link set "$slave" down 2>/dev/null
if ! sysfs_add slaves "$slave" 2>/dev/null ; then
echo "Failed to enslave $slave to $BOND_MASTER.
Is $BOND_MASTER ready and a bonding interface ?" >&2
else
# Bring up slave if it is the target of an
allow-bondX stanza.
# This is useful to bring up slaves that need
extra setup.
ifup $v --allow "$BOND_MASTER" "$slave"
fi
fi
done
}
setup_master()
{
# Warning: the order in which we write into the sysfs files is
important.
# Double check in drivers/net/bonding/bond_s
Bug#974922: libapache2-mod-perl2: "mod_perl interferes with mod_php locales, unable to use gettext translations"
The same bug can also be reproduced in the current unstable (bullseye) by the way. apache2 2.4.46-2 libapache2-mod-perl2 2.0.11-2+b1 libapache2-mod-php7.4 7.4.11-1 perl 5.32.0-5 As there is another bug in Mageia Linux (see https://bugs.mageia.org/show_bug.cgi?id=25411) which points to (probably) the same issue, it would seem an upstream bug of mod_perl.
Bug#974922: libapache2-mod-perl2: "mod_perl interferes with mod_php locales, unable to use gettext translations"
Hi Damyan, Thanks for your follow-up! > It would be nice if you could share the translate.php contents (or > a minimal version) so that the issue can be reproduced and any > prospective fixes/workarounds be tested. > As a matter of fact, I was right in the middle of reproducing this on another Debian 10 machine. It can be reproduced easily. Just use a standard Apache installation with libapache2-mod-php7.3, place the translate.php in the document root and create the locale structure in the same path as translate.php: ./locale/de_CH.UTF-8/LC_MESSAGES/ Inside LC_MESSAGES place a homepage.po file, here's an example: --- cut --- # Sample translation. # Copyright (C) 2020 Infiniroot. # Infiniroot LLC , 2020. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Infiniroot 1.0\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2020-11-16 10:00+0100\n" "PO-Revision-Date: 2020-11-16 10:00+0100\n" "Last-Translator: Infiniroot \n" "Language-Team: Infiniroot \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Language: de\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" # Home page msgid "Dedicated Hosting Description" msgstr "Mein deutscher Text" --- cut --- Then use msgfmt command (from the gettext package) to create a binary mo file: cd locale/de_CH.UTF-8/LC_MESSAGES/; msgfmt homepage.po --output-file=homepage.mo -v When you now launch the translate.php file through Apache (you can use curl), it should translate and show the German translation. $ curl localhost/translate.php Mein deutscher Text Then install and enable the libapache2-mod-perl2 module and restart Apache. The translation stops working. $ curl localhost/translate.php Original English was returned. Something wrong I published a blog article about this behaviour yesterday: https://www.claudiokuenzler.com/blog/1023/php-gettext-translations-not-working-apache-mod_php-cli-works. The sample translate.php is included in the article. Hope this helps. Am available for debugging this together if you want.
Bug#974922: libapache2-mod-perl2: "mod_perl interferes with mod_php locales, unable to use gettext translations"
Package: libapache2-mod-perl2 Version: 2.0.10-3 Severity: important Tags: l10n Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: -8<-- Start Bug Report 8<-- 1. Problem Description: When using mod_perl and mod_php at the same time, mod_perl somehow interferes with PHPs ability to translate texts using gettext. The PHP translation works fine using CLI but not via Apache web server. $ curl localhost/translate.php My original English text (not translated) As soon as mod_perl is disabled, the translations work: # a2dismod perl # systemctl restart apache2 $ curl localhost/translate.php Mein deutscher Text (translated) This happened on Debian 10. Language in the PHP script was set to de_CH.UTF-8. mod_php is 7.3.19. 2. Used Components and their Configuration: *** mod_perl version 2.10 *** using /usr/lib/x86_64-linux-gnu/perl5/5.28/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_CONFIG => /usr/bin/apr-config MP_APR_LIB => aprext MP_APXS=> /usr/bin/apxs MP_CCOPTS => -g -O2 -fdebug-prefix-map=/build/libapache2-mod-perl2-1OJ3cA/libapache2-mod-perl2-2.0.10=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fgnu89-inline MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_TRACE => 0 MP_USE_DSO => 1 MP_USE_STATIC => 0 *** The httpd binary was not found *** (apr|apu)-config linking info (apr|apu)-config scripts were not found *** /usr/bin/perl -V Summary of my perl5 (revision 5 version 28 subversion 1) configuration: Platform: osname=linux osvers=4.9.0 archname=x86_64-linux-gnu-thread-multi uname='linux localhost 4.9.0 #1 smp debian 4.9.0 x86_64 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dcc=x86_64-linux-gnu-gcc -Dcpp=x86_64-linux-gnu-cpp -Dld=x86_64-linux-gnu-gcc -Dccflags=-DDEBIAN -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/perl-5WfRyb/perl-5.28.1=. -fstack-protector-strong -Wformat -Werror=format-security -Dldflags= -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.28 -Darchlib=/usr/lib/x86_64-linux-gnu/perl/5.28 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/x86_64-linux-gnu/perl5/5.28 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.28.1 -Dsitearch=/usr/local/lib/x86_64-linux-gnu/perl/5.28.1 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -Ui_xlocale -Uversiononly -DDEBUGGING=-g -Doptimize=-O2 -dEs -Duseshrplib -Dlibperl=libperl.so.5.28.1' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='x86_64-linux-gnu-gcc' ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' optimize='-O2 -g' cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='' gccversion='8.3.0' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='x86_64-linux-gnu-gcc' ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=libc-2.28.so so=so useshrplib=true libperl=libperl.so.5.28 gnulibc_version='2.28' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,-E' cccdlflags='-fPIC' lddlflags='-shared -L/usr/local/lib -fstack-protector-strong' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS
Bug#865409: nagios-nrpe: Unable to build nagios-nrpe on Debian Stretch
Source: nagios-nrpe Version: 3.0.1-3 Severity: important Tags: upstream Dear Maintainer, With the current version, it is impossible to build nagios-nrpe on Debian Stretch using openssl 1.1.x. This applies to both the Debian source package nagios-nrpe and the upstream source code. The problem was also reported on https://github.com/NagiosEnterprises/nrpe/issues/93. Currently the workaround is to add "--with-need-dh=no" to the configure options. In order to support this new configure options, the source package needs to be updated from upstream (3.1.1) Please update nagios-nrpe source to 3.1.1 and add the configure workaround, too. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? -> Trying to rebuild the Debian source package fails during "make all" due to incompatibility with openssl 1.1.x. * What was the outcome of this action? -> Build failed, unable to compile (see https://github.com/NagiosEnterprises/nrpe/issues/93) * What outcome did you expect instead? -> Able to build/compile the package. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 UTF-8), LANGUAGE=en_US:en.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#818573: rsnapshot fails to do remote backups when using ssh_args in config file
Package: rsnapshot Version: 1.3.1-4 Severity: normal Tags: newcomer The bug was already discussed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721043 but the problem on Jessie (current stable) remains. Please backport the fixed version (1.4.0-1) to Jessie as well. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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: sysvinit (via /sbin/init) Versions of packages rsnapshot depends on: ii liblchown-perl 1.01-2+b1 ii logrotate 3.8.7-1+b1 ii perl5.20.2-3+deb8u4 ii rsync 3.1.1-3 Versions of packages rsnapshot recommends: ii openssh-client [ssh-client] 1:6.7p1-5+deb8u1 rsnapshot suggests no packages. -- Configuration Files: /etc/rsnapshot.conf changed [not included] -- no debconf information
Bug#758642: nginx-naxsi: naxsi not compiled as first module
Package: nginx-naxsi Version: 1.2.1-2.2+wheezy2 Severity: important Dear Maintainer, When using naxsi installed through nginx-naxsi package, and by activating it in the config files, certain web-applications were affected and could not be loaded, even when Naxsi was set to be in LearningMode. The effects of the web-application where that sometimes the css files were not loaded, after another refresh the website seemed correct, another refresh and the logo was not loaded, etc. Random load issues of elements to describe it best. In the naxsi wiki it is mentioned, that naxsi should be compiled as FIRST nginx module. This is not the case when naxsi is installed with the package nginx-naxsi. We have manually re-compiled nginx from the nginx sources (installed Debian source package for nginx) together with the current release of naxsi sources. After re-activation of naxsi in the config files, the above mentioned web-application is now working fine. So there are two things to do: 1) Please redo the nginx-naxsi package with another order of compiled modules (naxsi first!) - necessary 2) Please compile nginx with the newest source of naxsi - many rules have changed since the naxsi release with Wheezy - optional Thank you =) -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/24 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nginx-naxsi depends on: ii libc6 2.13-38+deb7u3 ii libpcre3 1:8.30-5 ii libssl1.0.0 1.0.1e-2+deb7u12 ii nginx-common 1.2.1-2.2+wheezy2 ii zlib1g1:1.2.7.dfsg-13 nginx-naxsi recommends no packages. nginx-naxsi suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697592: grub-update does not update device.map when hdd was replaced
Package: grub Version: 0.97-64 Severity: important Tags: squeeze The command "update-grub" should update /boot/grub/device.map if there was a change of hdd (e.g. replacement). I had two servers where I recently replaced a defect hdd but even after running update-grub the device.map was not updated with the new path to the new disk. This has caused a big problem during the last boot cycle as the machine could not boot anymore (was stuck at grub boot screen). IMO update-grub should check for validity of /boot/grub/device.map and replace a non-existant entry with the new hdd name. A workaround is to remove /boot/grub/device.map and then run update-grub. The file will then be created with the correct hdd paths/names. -- System Information: Debian Release: 6.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 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 grub depends on: ii debconf [debco 1.5.36.1 Debian configuration management sy ii grub-pc1.98+20100804-14+squeeze1 GRand Unified Bootloader, version grub recommends no packages. grub suggests no packages. -- debconf information: * grub/migrate_from_legacy: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
