Bug#1025220: passenger: Passenger startup fails with nodejs applications using node versions later than 14.x
Hi, On Tue, 13 Dec 2022 20:23:11 -0300 Antonio Terceiro wrote: > These binaries have the attached patch applied, please try them (I'm > assuming you are on amd64) and let me know. > > https://people.debian.org/~terceiro/tmp/passenger-bullseye/ Thank you for building the new packages. I've tested them with the debian nodejs package and the nodesource 14.x, 16.x, 18.x and 19.x repos, they all run the example nodejs application without any issues now.
Bug#1025220: passenger: Passenger startup fails with nodejs applications using node versions later than 14.x
Hello, On Tue, 13 Dec 2022 09:54:05 -0300 Antonio Terceiro wrote: > Please note that supporting nodejs from outside of the debian archive is > not a priority. That's entirely understandable. On Tue, 13 Dec 2022 09:54:05 -0300 Antonio Terceiro wrote: > I'm not making any promises, but if you can identify the fix yourself > and check whether it applies to the passenger version in stable (or do > the necessary backporting) in a way that doesn't break usage with nodejs > from stable, I could provide a stable update with that fix. I've made some quick and dirty docker containers to validate that replacing the "GLOBAL" with "global" is really all that is needed to fix the issue, and that it does not break for deployments using the nodejs version from the debian repos: https://git.insomnia247.nl/coolfire/passenger-tests As for actually writing the patch file needed for the package and how I would go about submitting that, a few pointers would be greatly appreciated if you can find the time.
Bug#1025220: passenger: Passenger startup fails with nodejs applications using node versions later than 14.x
Some additional digging findings; - Testing and Unstable packages are not affected as they are built from the upstream passenger 6.x branch, which already includes this fix. - Stable package is not affected when using the nodejs package from debian stable repo as this is still on the nodejs 12.x branch. - Stable package is affected when using newer stable release from upstream vendor repo (deb.nodesource.com). It would be superb if we could get the fix from passenger 6.x backported to the debian stable passenger package so we can deploy on modern nodejs versions.
Bug#1025220: passenger: Passenger startup fails with nodejs applications using node versions later than 14.x
Package: passenger Version: 5.0.30-1.2 Severity: important Dear Maintainer, Passenger errors out when starting a nodejs application when using a nodejs version later than 14.x. It throws the following error: /usr/share/passenger/helper-scripts/node-loader.js:41 GLOBAL.PhusionPassenger = exports.PhusionPassenger = new EventEmitter(); ^ ReferenceError: GLOBAL is not defined at Object. (/usr/share/passenger/helper-scripts/node-loader.js:41:1) at Module._compile (node:internal/modules/cjs/loader:1159:14) at Module._extensions..js (node:internal/modules/cjs/loader:1213:10) at Module.load (node:internal/modules/cjs/loader:1037:32) at Module._load (node:internal/modules/cjs/loader:878:12) at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) at node:internal/main/run_main_module:23:47 (Nodejs version: v18.12.1) It seems that after 14.x the "GLOBAL" alias to the "global" object was removed. Replacing the usage of "GLOBAL" with its lowercase variant in the node-loader.js file seems to be the way to fix this. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-17-amd64 (SMP w/24 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 passenger depends on: ii libc6 2.31-13+deb11u5 ii libcurl47.74.0-1.3+deb11u3 ii libgcc-s1 10.2.1-6 ii libruby2.7 2.7.4-1+deb11u1 ii libstdc++6 10.2.1-6 ii libuv1 1.40.0-2 ii ruby1:2.7+2 ii ruby-rack 2.1.4-3 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 passenger recommends no packages. Versions of packages passenger suggests: ii nodejs 18.12.1-deb-1nodesource1 pn passenger-doc ii python33.9.2-3 pn rails -- no debconf information
Bug#995961: libapache2-mpm-itk: Error "AH00052: child pid exit signal Segmentation fault" after update to apache 2.4.51-1~deb11u1
On Mon, 11 Oct 2021 20:54:38 +0200 "Steinar H. Gunderson" wrote: > It seems to me that this is only in bullseye-proposed-updates, not actually a > security update yet? If it breaks mpm-itk and nobody really knows why, > I would say that's a good reason to stop the proposal process of the package. It is already a security update: https://www.debian.org/security/2021/dsa-4982 For some reason it's not showing up in the listing on packages.debian.org, but that might be expected behavior. I don't know the packages site well enough to say for sure. Just to double-confirm I'm getting it from stable-security repos: $ apt list --upgradable Listing... Done apache2-bin/stable-security 2.4.51-1~deb11u1 amd64 [upgradable from: 2.4.48-3.1] apache2-data/stable-security 2.4.51-1~deb11u1 all [upgradable from: 2.4.48-3.1] apache2-utils/stable-security 2.4.51-1~deb11u1 amd64 [upgradable from: 2.4.48-3.1] apache2/stable-security 2.4.51-1~deb11u1 amd64 [upgradable from: 2.4.48-3.1]
Bug#995961: libapache2-mpm-itk: Error "AH00052: child pid exit signal Segmentation fault" after update to apache 2.4.51-1~deb11u1
Package: libapache2-mpm-itk Version: 2.4.7-04-1+b1 Severity: important Dear Maintainer, After installing the 2.4.51-1~deb11u1 security update the error log starts to get flilled with lines like: [core:notice] [pid 3115298] AH00052: child pid 3133160 exit signal Segmentation fault (11) Downgrading back to 2.4.48-3.1 made the errors disappear again. Disabling mpm_itk on 2.4.51-1~deb11u1 also stops the errors. The issue normally does not prevent pages from being loaded and they are still assigned the correct uid/gid. The problematic part lies in that it seems to cause issues with properly closing the connections. This lead to mod_qos limits being hit in my case, but I suspect it may also lead to hitting worker or thread pool limits in other cases. -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/24 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 libapache2-mpm-itk depends on: ii apache2-bin [apache2-api-20120211] 2.4.48-3.1 ii libc6 2.31-13 ii libcap2 1:2.44-1 libapache2-mpm-itk recommends no packages. libapache2-mpm-itk suggests no packages. -- no debconf information
Bug#932775: snmpd: Systemd service file also does not respect /etc/default/snmpd
Package: snmpd Version: 5.7.3+dfsg-5 Followup-For: Bug #932775 It seems the systemd service file (/lib/systemd/system/snmpd.service) also ignores the /etc/default/snmpd file. It does not even appear to attempt to read any configuration for there but rather has the defaults hardcoded into the service file's ExecStart parameter. -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/24 CPU cores) 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 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages snmpd depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libmariadb31:10.3.15-1 ii libsnmp-base 5.7.3+dfsg-5 ii libsnmp30 5.7.3+dfsg-5 ii libssl1.1 1.1.1c-1 ii lsb-base 10.2019051400 ii zlib1g 1:1.2.11.dfsg-1 snmpd recommends no packages. Versions of packages snmpd suggests: ii snmptrapd 5.7.3+dfsg-5 -- Configuration Files: /etc/default/snmpd changed: export MIBS= SNMPDRUN=yes SNMPDOPTS='-LS0-5d -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux -p /var/run/snmpd.pid' TRAPDRUN=no TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid' SNMPDCOMPAT=yes -- debconf information: snmpd/upgradefrom521:
