| Summary: | postfix won't start | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Marc Krämer <mageia> |
| Component: | RPM Packages | Assignee: | All Packagers <pkg-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | basesystem, fri, smelror |
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 32832 | ||
additional info: it fails since glibc-6:2.36-52.mga9.x86_64 update. During this update it was reloaded and fails since. Only one machine get this issue. But still, we should get better error messages, I really don't see at the moment why it won't start and where it hangs. CC registered maintainer of postfix CC:
(none) =>
fri, luis.daniel.lucio (In reply to Morgan Leijström from comment #2) > CC registered maintainer of postfix dlucio is not with us since a very long time; unCC'ing him. We have a more recent version 3.8.5 in Cauldron, but this does not look like a Postfix problem. Stig normally updates Postfix, but assigning this globally because the problem looks deeper. CC'ing basesytem. @Marc: has this always happened, or recently - like a glibc update? CC:
luis.daniel.lucio =>
basesystem, smelror (In reply to Lewis Smith from comment #3) > dlucio is not with us since a very long time; unCC'ing him. Ah. He is listed for several packages according to madb. Who can unassingn him from all? This is strange. I've a server running MGA9 that I updated today and rebooted.
$ sudo systemctl status postfix
● postfix.service - LSB: Starts the postfix daemons
Loaded: loaded (/etc/rc.d/init.d/postfix; generated)
Active: active (running) since Fri 2024-02-09 17:25:43 CET; 4h 28min ago
Docs: man:systemd-sysv-generator(8)
Process: 8213 ExecStart=/etc/rc.d/init.d/postfix start (code=exited, status=0/SUCCESS)
Main PID: 9027 (master)
Tasks: 3 (limit: 38373)
Memory: 45.4M
CPU: 1.991s
CGroup: /system.slice/postfix.service
├─ 9027 /usr/libexec/postfix/master -w
├─ 9033 qmgr -l -t unix -u -c
└─59273 pickup -l -t unix -u -c -o content_filter= -o receive_override_options=
--
glibc-2.36-52.mga9
postfix-3.8.4-1.mga9
--
$ uname -a
Linux phoenix 6.6.14-server-2.mga9 #1 SMP PREEMPT_DYNAMIC Tue Jan 30 16:12:58 UTC 2024 x86_64 GNU/Linux
--
I'm not an expert in systemd, so any help in porting the rc-style init scripts would be very much appreciated.
> @Marc: has this always happened, or recently - like a glibc update? it was running just before the glibc update, the restart after the update was not successfull. I did not had the time to restart the machine. It is just one machine out of 6. As I told, I find the scripts calling themselves (with hooked systemd hard to read) > I'm not an expert in systemd, so any help in porting the rc-style init scripts would be very much appreciated. @Stig: doesn't postfix ship anything with the sources? What does fedora do? Did the migrate - and how? Writing an systemd file just calling the old scripts, would be easy, but I gues it will not help much. I've written a few systemd files, but none creating a chroot env. But the most problematic part is understanding the old scripts, not to miss things which will not work afterwards. In most cases systemd simplifies the old init scripts. @Stig: I've looked a bit into fedora's spec: https://koji.fedoraproject.org/koji/buildinfo?buildID=2396664 they've created a service file which looks quite simple and they use a few (shiped) scripts. I did not look deeper into it, but I guess we could use this and make a few adaptions and have, finally, a real service.
Marc Krämer
2024-02-14 16:19:31 CET
Blocks:
(none) =>
32832 Found a strange solution: - deactivated chroot in /etc/sysconfig/postfix CHROOT=0 - started postfix via systemctl start postfix - activated chroot - run /usr/sbin/postfix-chroot.sh check_update - restarted postfix it works again... My guess: a special file is lying around, which prevents the chroot-sync. Still - we should move to plain systemd files. |
I got one system where postfix won't start: systemctl start postfix Job for postfix.service failed because a timeout was exceeded. See "systemctl status postfix.service" and "journalctl -xeu postfix.service" for details. while it is "starting" I see this: ps aux|grep post root 2109235 0.0 0.0 37664 7104 pts/1 S+ 08:37 0:00 systemctl start postfix root 2109237 0.0 0.0 25944 3264 ? Ss 08:37 0:00 /usr/bin/sh /etc/rc.d/init.d/postfix start root 2109247 0.0 0.0 25680 3072 ? S 08:37 0:00 /usr/bin/sh /usr/sbin/postfix-chroot.sh -q check_update root 2109266 0.0 0.0 25812 3264 ? S 08:37 0:00 /usr/bin/bash /sbin/service postfix reload root 2109275 0.0 0.0 25944 3264 ? S 08:37 0:00 /usr/bin/sh /etc/init.d/postfix reload root 2109290 0.0 0.0 37664 7104 ? S 08:37 0:00 /bin/systemctl reload postfix.service root 2109298 0.0 0.0 25224 2112 pts/0 S+ 08:37 0:00 grep --color post running postfix via command line "/usr/sbin/postfix start" works as expected. I tried to run "/usr/sbin/postfix-chroot.sh check_update" which gave me this: Reloading postfix configuration (via systemctl): postfix.service is not active, cannot reload. [FAILED] Is this some kind of loop? It does not start because it is not running?? This script really looks wired. Is this file (2003) really up-to-date? I really think we should migrate the old rc.d script to a modern systemd file. I guess it will simplify many things done in old scripts and (hopefully) give more information what and why it fails.