Bug#1034015: exim4: exim paniclog on lenovo has non-zero size
On Mon, Oct 02, 2023 at 07:12:28PM +0200, Marc Haber wrote: > On Mon, Oct 02, 2023 at 04:55:40PM +0200, Peter Bex wrote: > > I have the same issue on my server. It seems to happen any time the > > exim4 daemon gets restarted. Logs indicate that the process is not shut > > down correctly, leaving a stale daemon listening on the old port, which > > causes the error on startup for the new daemon. > > If this is reproducible,it is probably unrelated to this bug report. > Does the last exim process eventually vanish if you wait a while? It > might stil be doing something, such as waiting for a timeout. I just waited for 15 minutes after "systemctl stop exim4", and the process is still alive. I can also still connect to port 25, exim is still actively listening on both ipv4 and ipv6 interfaces. Journalctl contains no errors, it just claims it stopped cleanly: Oct 03 09:23:29 scully.more-magic.net systemd[1]: Stopping exim4.service - LSB: exim Mail Transport Agent... Oct 03 09:23:29 scully.more-magic.net exim4[592530]: Stopping MTA:. Oct 03 09:23:29 scully.more-magic.net systemd[1]: exim4.service: Deactivated successfully. Oct 03 09:23:29 scully.more-magic.net systemd[1]: exim4.service: Unit process 575519 (exim4) remains running after unit stopped. Oct 03 09:23:29 scully.more-magic.net systemd[1]: Stopped exim4.service - LSB: exim Mail Transport Agent. Oct 03 09:23:29 scully.more-magic.net systemd[1]: exim4.service: Consumed 4.140s CPU time. It only complains about the left-over process when I start it again: Oct 03 09:38:40 scully.more-magic.net systemd[1]: exim4.service: Found left-over process 575519 (exim4) in control group while starting unit. Ignoring. Oct 03 09:38:40 scully.more-magic.net systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Oct 03 09:38:40 scully.more-magic.net systemd[1]: Starting exim4.service - LSB: exim Mail Transport Agent... Oct 03 09:38:40 scully.more-magic.net exim4[592898]: Starting MTA: exim4. Oct 03 09:38:40 scully.more-magic.net systemd[1]: Started exim4.service - LSB: exim Mail Transport Agent. This is also usually when exim itself notices and creates the paniclog entry. Strangely enough, it didn't do that this time... Cheers, Peter signature.asc Description: PGP signature
Bug#1034015: exim4: exim paniclog on lenovo has non-zero size
Dear maintainer, I have the same issue on my server. It seems to happen any time the exim4 daemon gets restarted. Logs indicate that the process is not shut down correctly, leaving a stale daemon listening on the old port, which causes the error on startup for the new daemon. After an update just now: Oct 02 16:46:37 scully.more-magic.net systemd[1]: Stopping exim4.service - LSB: exim Mail Transport Agent... Oct 02 16:46:37 scully.more-magic.net exim4[574161]: Stopping MTA:. Oct 02 16:46:37 scully.more-magic.net systemd[1]: exim4.service: Deactivated successfully. Oct 02 16:46:37 scully.more-magic.net systemd[1]: exim4.service: Unit process 701 (exim4) remains running after unit stopped. Oct 02 16:46:37 scully.more-magic.net systemd[1]: Stopped exim4.service - LSB: exim Mail Transport Agent. Oct 02 16:46:37 scully.more-magic.net systemd[1]: exim4.service: Consumed 2min 17.056s CPU time. Oct 02 16:46:40 scully.more-magic.net systemd[1]: exim4.service: Found left-over process 701 (exim4) in control group while starting unit. Ignoring. Oct 02 16:46:40 scully.more-magic.net systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Oct 02 16:46:40 scully.more-magic.net systemd[1]: Starting exim4.service - LSB: exim Mail Transport Agent... Oct 02 16:46:40 scully.more-magic.net exim4[574712]: Starting MTA: exim4. Oct 02 16:46:40 scully.more-magic.net systemd[1]: Started exim4.service - LSB: exim Mail Transport Agent. In /var/log/exim4/paniclog: 2023-10-02 16:51:10 socket bind() to port 25 for address (any IPv6) failed: Address already in use: daemon abandoned If I use systemctl to stop the daemon, it leaves an exim4 process running. Manually calling "pkill exim4" and then using systemctl to start exim4 resolves the issue (until the next restart). I thought it was ipv6-related, but if I see message #5 in this bug it seems that this is not necessarily the case. Perhaps it is caused by having exim listen on multiple interfaces (ipv4 and ipv6), or maybe it's a red herring? Anyway, I hope this helps debug the problem further! Regards, Peter Bex signature.asc Description: PGP signature
Bug#1039895: nsd refuses to start in chroot mode
I just figured out that the tilde applies to the entire list, not just the first entry. So if I get this right, that filter is a list of *disallowed* system calls. I've tested simply removing @mount from that list, and that is enough to make it work in chroot mode.
Bug#1039895: nsd refuses to start in chroot mode
Package: nsd Version: 4.3.5-1 Severity: important Dear Maintainer, When using the "chroot" option of nsd, the daemon refuses to start without any information in the logs about why. The only output is: × nsd.service - Name Server Daemon Loaded: loaded (/lib/systemd/system/nsd.service; enabled; preset: enabled) Drop-In: /etc/systemd/system/nsd.service.d └─capabilities.conf Active: failed (Result: signal) since Thu 2023-06-29 11:05:07 CEST; 735ms ago Duration: 38ms Docs: man:nsd(8) Process: 2480 ExecStart=/usr/sbin/nsd -d -P (code=killed, signal=SYS) Main PID: 2480 (code=killed, signal=SYS) CPU: 36ms Jun 29 11:05:07 x systemd[1]: nsd.service: Main process exited, code=kill> Jun 29 11:05:07 x systemd[1]: nsd.service: Failed with result 'signal'. Jun 29 11:05:07 x systemd[1]: nsd.service: Scheduled restart job, restart> Jun 29 11:05:07 x systemd[1]: Stopped nsd.service - Name Server Daemon. Jun 29 11:05:07 x systemd[1]: nsd.service: Start request repeated too qui> Jun 29 11:05:07 x systemd[1]: nsd.service: Failed with result 'signal'. Jun 29 11:05:07 x systemd[1]: Failed to start nsd.service - Name Server D> I created a bind mount for /dev/log into the chroot, but this did not help. Starting it by hand (by invoking /usr/sbin/nsd from the shell) works correctly without errors. Eventually, I managed to work around this by commenting out the SystemCallFilter line in the service file: #SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @resources I don't know what the correct system call set name would be to make chroot work. The systemd.exec(5) manual seems to imply that @mount should be sufficient, so perhaps it's not the chroot itself that's causing the problem, but something else that runs after chrooting. The upstream contributed systemd service file[1] doesn't use SystemCallFilter anymore. There used to be a more complex contrib file but it got removed because it was "too complicated and not useful"[2]. It looks like this old revision is the systemd file that Debian is still using. I ran into this again on the upgrade to Debian Bookworm, so this issue hasn't been fixed. -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-23-amd64 (SMP w/1 CPU thread) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) [1] https://github.com/NLnetLabs/nsd/blob/master/contrib/nsd.service [2] https://github.com/NLnetLabs/nsd/commit/c8eae0d3073fa48e70875bdb01aa9f6b27538e87
Bug#729144: libchicken-dev incorrectly depends on libpcre3-dev
Package: libchicken-dev Version: 4.7.0-1 Severity: minor Dear Maintainer, This is my first ever Debian bugreport, so please excuse any faux-pas. When installing libchicken-dev, I noticed apt-get wants to install libpcre3-dev. This seems to me to be an obsolete dependency which was never removed on the upgrade to CHICKEN 4.7.0, because starting with that release PCRE is no longer being used by CHICKEN. Instead, we ship a pure Scheme implementation of regular expressions called irregex. Therefore, I think the libpcre3-dev dependency should be removed from libchicken-dev. If you'd like to know more, just send me an e-mail, or ask on the chicken-users mailinglist. -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 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 libchicken-dev depends on: ii libchicken6 4.7.0-1 ii libpcre3-dev 1:8.30-5 libchicken-dev recommends no packages. libchicken-dev 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
