Bug 714430
Summary: | Provide native systemd unit file for postgrey | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
Component: | postgrey | Assignee: | Matthias Saou <matthias> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 15 | CC: | gwync, matthias, mjc, tcallawa |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | postgrey-1.34-3.fc17 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-04-12 02:02:39 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 713562 |
Description
Harald Reindl
2011-06-19 09:25:39 UTC
Mattias, any objection to my making this change? Ping? here the unit-file written the same day as my bugreport and in production since many months - laughable how many package maintainers are acting with systemd-transition [root@mail:~]$ cat /lib/systemd/system/postgrey.service [Unit] Description=Postfix Greylisting Service Before=postfix.service [Service] Type=simple ExecStart=/usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket Restart=always RestartSec=1 [Install] WantedBy=multi-user.target Thanks, Harald, I'll use that if Mattias OKs it. Does it matter that the "-d" flag is not in the ExecStart line? The old init script had it. I couldn't make this service file work on F16. Postfix couldn't find postgrey without the -d flag, but systemd didn't report a successful start with the -d flag in. Not sure what it all means. I'm back to the init file method. Personally, I'd also add "--delay=60". The default 5 minute delay (300 sec) is a bit excessive. no idea what you are speaking about see log at the bottom [root@testserver:~]$ rpm -q postgrey postgrey-1.34-4.fc16.20120311.rh.noarch [root@testserver:~]$ uname -r 3.2.10-1.fc16.x86_64 [root@testserver:~]$ systemctl status postgrey.service postgrey.service - Postfix Greylisting Service Loaded: loaded (/lib/systemd/system/postgrey.service; enabled) Active: active (running) since Thu, 15 Mar 2012 21:39:31 +0100; 1min 40s ago Main PID: 15350 (/usr/sbin/postg) CGroup: name=systemd:/system/postgrey.service └ 15350 /usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket [root@testserver:~]$ cat /lib/systemd/system/postgrey.service [Unit] Description=Postfix Greylisting Service Before=postfix.service [Service] Type=simple ExecStart=/usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket Restart=always RestartSec=1 [Install] WantedBy=multi-user.target [root@testserver:~]$ cat maillog Mar 15 21:40:27 testserver postfix/smtpd[15374]: connect from local.rhsoft.net[84.113.45.179] Mar 15 21:40:27 testserver postfix/smtpd[15374]: Anonymous TLS connection established from local.rhsoft.net[84.113.45.179]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Mar 15 21:40:27 testserver postfix/smtpd[15374]: NOQUEUE: reject: RCPT from local.rhsoft.net[84.113.45.179]: 450 4.2.0 <test.net>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testserver.rhsoft.net.html; from=<harry.net> to=<test.net> proto=ESMTP helo=<srv-rhsoft.rhsoft.net> Mar 15 21:40:28 testserver postfix/smtpd[15374]: disconnect from local.rhsoft.net[84.113.45.179] Your maillog is only showing entries from "postfix/smtpd". My system shows "postfix/smtpd" entries AND "postgrey" entries, like this: Mar 15 17:31:54 server2 postgrey[846]: action=greylist, reason=new, client_name=unknown, client_address=41.200.83.15, sender=importunityseu636, recipient=info Mar 15 17:31:54 server2 postfix/smtpd[5640]: NOQUEUE: reject: RCPT from unknown[41.200.83.15]: 450 4.2.0 <info>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/avtechpulse.com.html; from=<importunityseu636> to=<info> proto=ESMTP helo=<dsldevice.lan> Your service file does not launch postgrey with the -d (or --daemonize) flag, so logging is disabled. From /usr/sbin/postgrey: log_file => $opt{daemonize} ? 'Sys::Syslog' : undef The init script uses: start() { [ -x $exec ] || exit 5 echo -n $"Starting $prog: " daemon $exec -d $options retval=$? echo [ $retval -eq 0 ] && touch $lockfile return $retval } Note the "-d". Maybe, but it is working and all relevant things are in maillog, teh rest in /var/log/messages -> However it would be the job of the package-maintainer since a year to patch whatever si needed and provide native systemd-units, not mine Mar 15 21:38:56 testserver postgrey[15317]: 2012/03/15-21:38:56 postgrey (type Net::Server::Multiplex) starting! pid(15317) Mar 15 21:38:56 testserver postgrey[15317]: Binding to UNIX socket file /var/spool/postfix/postgrey/socket using SOCK_STREAM Mar 15 21:38:56 testserver postgrey[15317]: Setting gid to "482 482" Mar 15 21:38:56 testserver postgrey[15317]: Setting uid to "488" Mar 15 21:39:18 testserver postgrey[15317]: 2012/03/15-21:39:18 Server closing! Mar 15 21:39:31 testserver postgrey[15350]: 2012/03/15-21:39:31 postgrey (type Net::Server::Multiplex) starting! pid(15350) Mar 15 21:39:31 testserver postgrey[15350]: Binding to UNIX socket file /var/spool/postfix/postgrey/socket using SOCK_STREAM Mar 15 21:39:31 testserver postgrey[15350]: Setting gid to "482 482" Mar 15 21:39:31 testserver postgrey[15350]: Setting uid to "488" Mar 15 21:40:27 testserver postgrey[15350]: action=greylist, reason=new, client_name=local.rhsoft.net, client_address=84.113.45.179, sender=harry.net, recipient=test.net Mar 15 21:55:33 testserver postgrey[15350]: action=pass, reason=triplet found, delay=906, client_name=local.rhsoft.net, client_address=84.113.45.179, sender=harry.net, recipient=test.net Also, we can add delay config in a /etc/sysconfig/postgrey file, which the unit file can source. -d Shouldn't be necessary, as systemd should handle daemonization. Maybe Type should be Forking rather than Simple? Here's a more robust postgrey.service file, I think. Can you test it, Harald? [Unit] Description=Postfix Greylisting Service Before=postfix.service [Service] Type=forking EnvironmentFile=-/etc/sysconfig/postgrey ExecStartPre=-/bin/rm -f /var/run/postgrey.pid PIDFile=/var/run/postgrey.pid ExecStart=/usr/sbin/postgrey \ --unix=/var/spool/postfix/postgrey/socket \ --pidfile=/var/run/postgrey.pid \ --daemonize \ $POSTGREY_OPTS Restart=always RestartSec=1 [Install] WantedBy=multi-user.target My /etc/sysconfig/postgrey contains one line: POSTGREY_OPTS="--delay=60" Anyway... the service file in comment 10 seems to work well. In fact, it works better than the current init script, which does not cleanly kill postgrey for some reason on my system. Can someone push this into a testing release? It would be nice to have a service file for F17. - Mike I'll do this today. Committed. Will build once rawhide builds recover from the deltarpm/rpm issue. Done, thanks all. I'll send an update for f17. postgrey-1.34-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/postgrey-1.34-3.fc17 Package postgrey-1.34-3.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing postgrey-1.34-3.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4360/postgrey-1.34-3.fc17 then log in and leave karma (feedback). remove this whole PID-crap systemd doe snot need it, postgrey does not need it if you are not froce to create it you have no troubles after a crash because it was not deleted with "--daemonize" and "forking" it logs in /var/log/maillog and that was it [Unit] Description=Postfix Greylisting Service Before=postfix.service [Service] Type=forking ExecStart=/usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --daemonize Restart=always RestartSec=1 [Install] WantedBy=multi-user.target The service file in comment 17 is too minimal. It has no support for EnvironmentFile, which is not good. Also, "man systemd.service" says: "If set to forking ...<snip>... If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon." The ExecStartPre line removes leftover pid files before launch, in the event of a crash. I believe the existing service file is more correct. The env-file si your, i haveno need for it with the pid-file you are TOTALLY wrong look gagain at my systemd-unit postgrey itself is started without pid-file, there is no one and so there is nothing to remove and nothing block the next start, that it is a ppor bug in postgrey refuse starting because a orphaned pid-file exists is another story and the root-cause of the whole problem your reference to systemd manual is nice but completly wrong interpretaed for a service wiht only a single process and why it is really wrong is: i saw manually created htttp-services for special instances of apache which did not start as all as long PIDFile was set, removing the line and all was fine systemd does NOT need this line, make a request on the system-devel list i am tired after many months with a lot of REALLY forking services aithout PID lines in production to get educated here - where were you when i had to upgrade to F15 and there was no postgrey.service? Harald, the env file provides a mechanism for providing a reasonable default, editable by the admin. You don't have to use it. postgrey is not httpd, simply because something works for one does not mean it's needed or appropriate for the other. postgrey's behaviour may be buggy, but this unit file works for it as it is. If the maintainer wishes to patch the buggy behaviour and submit it upstream, that's fine. If you wish to do so and submit a patch for him or someone else to apply and send upstream, that's also fine. again: postgey works completly without an PID-file please try it out, so the bug remove orphaned on start is not a topic the pid-file was more needed for sysv-scripts it is obsolete this appears in /var/log/messages for nearly ALL services with the "PIDFile" line, after remove it from the unit-file all works fine believe it or not systemd[1]: PID file /var/run/pure-ftpd.pid not readable (yet?) after start. postgrey-1.34-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |