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.
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, smelrorAssignee: bugsquad => pkg-bugs
(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.
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.