Starting postfix

[Christian Roessner]

Hi,

I am currently preparing an upstart script for Ubuntu. I tried several ways do 
use /usr/sbin/postfix, but I never would get the master PID. So I looked at the 
postfix.c code.

Is it a problem to start /usr/lib/postfix/master -c /etc/postfix from the init 
system? I believe I have seen in upstarts man page that they close stdin, 
stdout and stderr before starting a job.

Would the upstart script lack of some functionality or do have other problems?

My systems currently run with this upstart script and yet I don't see any 
differences.

Thanks
Christian


---
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com



PGP.sig
Description: Signierter Teil der Nachricht

Re: Starting postfix

[Wietse Venema]

Christian Roessner:
> 
> I am currently preparing an upstart script for Ubuntu. I tried several way
>-s do use /usr/sbin/postfix, but I never would get the master PID. So I looke
>-d at the postfix.c code.

The only supported way to start Postfix is "postfix start", using
the commands provided with /etc/postfix/postfix-script. 

DO NOT TINKER WITH THIS. 

SUSE people discovered years ago that their home-grown approach to
stop Postfix would terminate a lot more processes than just Postfix.

Wietse

Re: Starting postfix

[Christian Roessner]

Hi,

> The only supported way to start Postfix is "postfix start", using
> the commands provided with /etc/postfix/postfix-script. 
> 
> DO NOT TINKER WITH THIS. 
> 
> SUSE people discovered years ago that their home-grown approach to
> stop Postfix would terminate a lot more processes than just Postfix.

I take your warning really serious. That is the reason I wrote here to the 
list. But it brings me to a conflict that I do not know, how to solve else.

The problem with using /usr/sbin/postfix is that it starts master and upstart 
never will have control over that process, which in my opinion it must have.

Can you tell me what postfix does differently while starting master, than an 
exec call from upstart would do? Maybe if I understand more from the "behind 
the scenes" I can find a solution.

Maybe at the end I will accept that it might be impossible to use upstart and 
that a classical sysvinit might be the only way. But I do not want to give up 
so early ;-)

Regards
Christian

PGP.sig
Description: Signierter Teil der Nachricht

Re: Starting postfix

[Wietse Venema]

Christian Roessner:
> Hi,
> 
> > The only supported way to start Postfix is "postfix start", using
> > the commands provided with /etc/postfix/postfix-script. 
> > 
> > DO NOT TINKER WITH THIS. 
> > 
> > SUSE people discovered years ago that their home-grown approach to
> > stop Postfix would terminate a lot more processes than just Postfix.
> 
> I take your warning really serious. That is the reason I wrote here to the
>- list. But it brings me to a conflict that I do not know, how to solve else.
> 
> The problem with using /usr/sbin/postfix is that it starts master and upst
>-art never will have control over that process, which in my opinion it must h
>-ave.

No, that would be a mistake. For example that would break Postfix
multi-instance support, among many things.

To start Postfix, use "postfix start".

To stop Postfix, use "postfix stop".

> Can you tell me what postfix does differently while starting master, than 
>-an exec call from upstart would do? Maybe if I understand more from the "beh
>-ind the scenes" I can find a solution.

Sorry, this is an internal Postfix interface. TINKERING WITH INTERNAL
INTERFACES IS NOT SUPPORTED.

If you must persist along this path then I request that you stop
distributing Postfix. I will get all the complaints about the things
that you break, and I will have to deal with the consequences for
Postfix's reputation.

Wietse

Re: Starting postfix

[Christian Roessner]

> If you must persist along this path then I request that you stop
> distributing Postfix. I will get all the complaints about the things
> that you break, and I will have to deal with the consequences for
> Postfix's reputation.

Don't fear it. I am not going to do something that breaks postfix. That is the 
reason why I ask here/you to learn and to understand and in this case: to find 
another solution.

Thanks
Christian


---
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com



PGP.sig
Description: Signierter Teil der Nachricht

Re: Starting postfix

[Wietse Venema]

Christian Roessner:
> > If you must persist along this path then I request that you stop
> > distributing Postfix. I will get all the complaints about the things
> > that you break, and I will have to deal with the consequences for
> > Postfix's reputation.
> 
> Don't fear it. I am not going to do something that breaks postfix. That is
>- the reason why I ask here/you to learn and to understand and in this case: 
>-to find another solution.

The solution is to respect the documented interfaces. You may
negotiate an interface change, but you may not rely on unsupported
implementation details under the documented interface.

Doing so leads to silently breaking things like multi-instance 
support.

This is elementary software engineering practice. We should not
have to waste time arguing about such things.

Wietse

Re: Starting postfix

[Victor Duchovni]

On Fri, Feb 25, 2011 at 12:58:22AM +0100, Christian Roessner wrote:

> I am currently preparing an upstart script for Ubuntu. I tried several
> ways do use /usr/sbin/postfix, but I never would get the master PID. So
> I looked at the postfix.c code.

There is a no single "master pid". A fully-general Postfix MTA may run
multiple master instances.

Postfix startup is not just a fork/exec of master(8), queue files that
got renamed (perhaps restored) have to be recovered via "postsuper -s".
Required "missing" directories have to be created. Basic security checks
performed, all this for multiple instances.

Don't run Postfix on laptops, something much simpler that drains a disk
queue to a fixed SMTP smart-host is likely best for consumer machines.

Do run Postfix on servers, but be prepared to not break advanced
configurations, and let Postfix do its own startup and shutdown.

Attempts to monitor the status of a complex multi-component Postfix MTA---as
though it were a monolithic system that is either entirely up or entirely
down---based on observations of a single process are likely to fail.
It would be better to not monitor at all than to do it badly.

I monitor Postfix by sending messages and observing their arrival
or non-arrival at a monitoring sink. Automated re-start is not that
interesting, the master service never crashes (not once in the last 10
years of running multiple hosts doing 2,000,000 messages a day). Automated
re-start of the Postfix master(8) service is a non-problem.

-- 
Viktor.

Re: Starting postfix

[lst_hoe02]

Zitat von Victor Duchovni :


On Fri, Feb 25, 2011 at 12:58:22AM +0100, Christian Roessner wrote:


I am currently preparing an upstart script for Ubuntu. I tried several
ways do use /usr/sbin/postfix, but I never would get the master PID. So
I looked at the postfix.c code.


There is a no single "master pid". A fully-general Postfix MTA may run
multiple master instances.

Postfix startup is not just a fork/exec of master(8), queue files that
got renamed (perhaps restored) have to be recovered via "postsuper -s".
Required "missing" directories have to be created. Basic security checks
performed, all this for multiple instances.

Don't run Postfix on laptops, something much simpler that drains a disk
queue to a fixed SMTP smart-host is likely best for consumer machines.

Do run Postfix on servers, but be prepared to not break advanced
configurations, and let Postfix do its own startup and shutdown.

Attempts to monitor the status of a complex multi-component Postfix MTA---as
though it were a monolithic system that is either entirely up or entirely
down---based on observations of a single process are likely to fail.
It would be better to not monitor at all than to do it badly.

I monitor Postfix by sending messages and observing their arrival
or non-arrival at a monitoring sink. Automated re-start is not that
interesting, the master service never crashes (not once in the last 10
years of running multiple hosts doing 2,000,000 messages a day). Automated
re-start of the Postfix master(8) service is a non-problem.


The "problem" is more of that distribution like Ubuntu and Redhat are  
moving to "upstart" for boot and starting services/daemons. The main  
difference for the started services is that upstart need the program  
to *not* daemonize or terminate itself because status is checked  
directly to do respawn and other things if necessary and not by  
monitoring a PID like it was with sys-v. So basically to get Postfix  
upstart compatibel a "postfix-start-stop" helper would be needed which  
is always running and only does dispatching of start/stop requests to  
the master(s) according to Postfix needs.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Starting postfix

[Christian Roessner]

Hi, 

> The "problem" is more of that distribution like Ubuntu and Redhat are  
> moving to "upstart" for boot and starting services/daemons. The main  
> difference for the started services is that upstart need the program  
> to *not* daemonize or terminate itself because status is checked  
> directly to do respawn and other things if necessary and not by  
> monitoring a PID like it was with sys-v. So basically to get Postfix  
> upstart compatibel a "postfix-start-stop" helper would be needed which  
> is always running and only does dispatching of start/stop requests to  
> the master(s) according to Postfix needs.

I was thinking the whole night how to solve it for upstart. I wrote a
python wrapper:

#
import os, sys
import time

program = "/usr/sbin/postfix"

# First start postfix and wait for the return code
try:
pid = os.fork()
except OSError, e:
Log.error("First fork failed")
print >>sys.stderr, ("Fork failed: (%d) %s" % (e.errno, e.strerror))
sys.exit(1)

if not pid:
try:
os.execvp(program, (program, "start"))
except OSError, e:
print >>sys.stderr, ("Exec failed: (%d) %s" % (e.errno,
e.strerror))
os._exit(1)

if os.wait()[1] != 0:
sys.exit(1)

# wait until we get killed
while True:
time.sleep(10)
#

This can be called with exec in upstart and doing a stop is easy, too,
because I simply call /usr/sbin/postfix stop in a post-stop script
block.

So if this is okay, I would use it. It is some kind of silly, but I
tested it here on my workstation and it does the job. But I also want to
ask the Ubuntu guys, if that is a working mechanism.

Thanks
Christian
-- 
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com

Re: Starting postfix

[Wietse Venema]

lst_ho...@kwsoft.de:
> The "problem" is more of that distribution like Ubuntu and Redhat are  
> moving to "upstart" for boot and starting services/daemons. The main  
> difference for the started services is that upstart need the program  
> to *not* daemonize or terminate itself because status is checked  
> directly to do respawn and other things if necessary and not by  
> monitoring a PID like it was with sys-v. So basically to get Postfix  
> upstart compatibel a "postfix-start-stop" helper would be needed which  
> is always running and only does dispatching of start/stop requests to  
> the master(s) according to Postfix needs.

The problem with this approach is that Postfix is not one program,
like named, apache, etc., and that simply starting one master daemon
is insufficient as it skips all the start-up repair and sanity checks.

Wietse

Re: Starting postfix

[lst_hoe02]

Zitat von Wietse Venema :


lst_ho...@kwsoft.de:

The "problem" is more of that distribution like Ubuntu and Redhat are
moving to "upstart" for boot and starting services/daemons. The main
difference for the started services is that upstart need the program
to *not* daemonize or terminate itself because status is checked
directly to do respawn and other things if necessary and not by
monitoring a PID like it was with sys-v. So basically to get Postfix
upstart compatibel a "postfix-start-stop" helper would be needed which
is always running and only does dispatching of start/stop requests to
the master(s) according to Postfix needs.


The problem with this approach is that Postfix is not one program,
like named, apache, etc., and that simply starting one master daemon
is insufficient as it skips all the start-up repair and sanity checks.


That's why i said it may be useful to have a simple  
"dispatcher/wrapper" which only is started to call "postfix start" and  
keeps running to keep upstart happy and calls "postfix stop/restart"  
when advised to do so by upstart. With this the supported way of  
starting/stopping is possible *and* upstart could be used without  
problems. The only problem to solve is the non-terminating behaviour  
required by upstart, all other startup work can be done as usual  
behind the scene.


Regards

Andreas





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Starting postfix

[Christian Roessner]

Hi,

> That's why i said it may be useful to have a simple  
> "dispatcher/wrapper" which only is started to call "postfix start" and  
> keeps running to keep upstart happy and calls "postfix stop/restart"  
> when advised to do so by upstart. With this the supported way of  
> starting/stopping is possible *and* upstart could be used without  
> problems. The only problem to solve is the non-terminating behaviour  
> required by upstart, all other startup work can be done as usual  
> behind the scene.

my upstart-postfix python script works. It does call "/usr/sbin/postfix
start" and loops. So this is a very simple form of making upstart happy
and also starting/stopping postfix as expected.

That postfix must not be started directly by calling master should also
be documented in the master man page, as people like me (and my idea was
based on Apple's practise, like they DO START postfix with launchctl on
Mac OS X Server edition).

Anyways. If someone likes to help me doing further coding on the python
code, he/she is welcome.

@Andreas: Du bist doch aus Deutschland? Kannst mich gerne mal
anschreiben; vielleicht finden wir beide eine gute Lösung. Danke

Best wishes
Christian

-- 
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com

Re: Starting postfix

[Wietse Venema]

lst_ho...@kwsoft.de:
> Zitat von Wietse Venema :
> 
> > lst_ho...@kwsoft.de:
> >> The "problem" is more of that distribution like Ubuntu and Redhat are
> >> moving to "upstart" for boot and starting services/daemons. The main
> >> difference for the started services is that upstart need the program
> >> to *not* daemonize or terminate itself because status is checked
> >> directly to do respawn and other things if necessary and not by
> >> monitoring a PID like it was with sys-v. So basically to get Postfix
> >> upstart compatibel a "postfix-start-stop" helper would be needed which
> >> is always running and only does dispatching of start/stop requests to
> >> the master(s) according to Postfix needs.
> >
> > The problem with this approach is that Postfix is not one program,
> > like named, apache, etc., and that simply starting one master daemon
> > is insufficient as it skips all the start-up repair and sanity checks.
> 
> That's why i said it may be useful to have a simple  
> "dispatcher/wrapper" which only is started to call "postfix start" and  
> keeps running to keep upstart happy and calls "postfix stop/restart"  
> when advised to do so by upstart. With this the supported way of  
> starting/stopping is possible *and* upstart could be used without  
> problems. The only problem to solve is the non-terminating behaviour  
> required by upstart, all other startup work can be done as usual  
> behind the scene.

I suppose you mean something like this:

postfix upstart

Run in "upstart pacifier" mode, and do not terminate.
Execute the equivalents of "postfix start" and "postfix
stop" as appropriate, and do nothing in the mean time.

Just using up an idle process slot to keep upstart happy.

Wietse

Wietse

Re: Starting postfix

[Wietse Venema]

Wietse Venema:
> lst_ho...@kwsoft.de:
> > Zitat von Wietse Venema :
> > 
> > > lst_ho...@kwsoft.de:
> > >> The "problem" is more of that distribution like Ubuntu and Redhat are
> > >> moving to "upstart" for boot and starting services/daemons. The main
> > >> difference for the started services is that upstart need the program

Is there any reason they can't do this:

Postfix "job" script:

  pre-start exec postfix start
  post-stop exec postfix stop

With this, the system will do the work for them, and everything
uses stable documented interfaces.

Wietse

Re: Starting postfix

[lst_hoe02]

Zitat von Wietse Venema :


Wietse Venema:

lst_ho...@kwsoft.de:
> Zitat von Wietse Venema :
>
> > lst_ho...@kwsoft.de:
> >> The "problem" is more of that distribution like Ubuntu and Redhat are
> >> moving to "upstart" for boot and starting services/daemons. The main
> >> difference for the started services is that upstart need the program


Is there any reason they can't do this:

Postfix "job" script:

  pre-start exec postfix start
  post-stop exec postfix stop

With this, the system will do the work for them, and everything
uses stable documented interfaces.



I'm just on the way learning the new concepts of upstart...
As far as i understand the common way is to not detach as it is done  
in the common way but run in foreground to keep contact with upstart  
(init) so status can be easily collected. It should be possible to  
fire only a startup script and terminate but with this the daemon  
listing (initctl list) would show status "waiting" instead of "running".

A simple startup config for sshd taken from Ubuntu 10.04 is for example:


# ssh - OpenBSD Secure Shell server
#
# The OpenSSH server provides secure shell access to the system.

description "OpenSSH server"

start on filesystem
stop on runlevel S

respawn
respawn limit 10 5
umask 022
# replaces SSHD_OOM_ADJUST in /etc/default/ssh
oom never

pre-start script
test -x /usr/sbin/sshd || { stop; exit 0; }
test -e /etc/ssh/sshd_not_to_be_run && { stop; exit 0; }
test -c /dev/null || { stop; exit 0; }

mkdir -p -m0755 /var/run/sshd
end script

# if you used to set SSHD_OPTS in /etc/default/ssh, you can change the
# 'exec' line here instead
exec /usr/sbin/sshd -D


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Starting postfix

[Gábor Lénárt]

On Fri, Feb 25, 2011 at 03:08:51PM +0100, lst_ho...@kwsoft.de wrote:
[...]
> >Is there any reason they can't do this:
> >
> >Postfix "job" script:
> >
> >  pre-start exec postfix start
> >  post-stop exec postfix stop
> >
> >With this, the system will do the work for them, and everything
> >uses stable documented interfaces.
> 
> 
> I'm just on the way learning the new concepts of upstart...
> As far as i understand the common way is to not detach as it is done
> in the common way but run in foreground to keep contact with upstart
> (init) so status can be easily collected. It should be possible to
> fire only a startup script and terminate but with this the daemon
> listing (initctl list) would show status "waiting" instead of
> "running".

I'm just thinking how Solaris 10's SMF can solve this. As far as I noticed,
it somehow keeps track on children too, so if the "start method" only does
something then exits, it still knows that the service is running since there
is child(ren) process(es) of the start method in the system. I am not sure
however, but as far as I remember/experienced. Upstart may does not have
this feature however ...

-- Gábor

Re: Starting postfix

[Daniel Bromberg]

On 2/25/2011 8:16 AM, Wietse Venema wrote:

The problem with this approach is that Postfix is not one program,
like named, apache, etc., and that simply starting one master daemon
is insufficient as it skips all the start-up repair and sanity checks.

That's why i said it may be useful to have a simple
"dispatcher/wrapper" which only is started to call "postfix start" and
keeps running to keep upstart happy and calls "postfix stop/restart"
when advised to do so by upstart. With this the supported way of
starting/stopping is possible *and* upstart could be used without
problems. The only problem to solve is the non-terminating behaviour
required by upstart, all other startup work can be done as usual
behind the scene.

I suppose you mean something like this:

 postfix upstart

Run in "upstart pacifier" mode, and do not terminate.
Execute the equivalents of "postfix start" and "postfix
stop" as appropriate, and do nothing in the mean time.

Just using up an idle process slot to keep upstart happy.

Wietse

Wietse


Since Upstart is new to me I decided to read about it: "[The 
shortcomings of sysvinit] leaves it unable to handle various tasks on a 
moderndesktop computer 
elegantly, including: The 
addition or removal ofUSB pen drives 
and other portable storage / 
network devices while the machine is running..." (Wikipedia) 'As the 
primary focus of this specification is dealing with modern hardware and 
its "coming and going" nature' (Ubuntu)


So the meta-issue appears to be a collision in design between typical 
desktop and server design models. Sort of. Desktops still have long 
running services too that should never "go awry" (wording from Fedora 
upstart doc page).


The (*flame retardant leggings put on*) Windows service model seems much 
better, wherein each service must implement a defined start/stop 
interface. Any service management tool doesn't need a tight grip on a 
collection of child processes, just uses this simple interface. Breaking 
the daemonization model is just odd to me.


In any case the upstart page makes it clear that it will be 
backward-compatible with sysv for a while during this transition, so 
there doesn't seem to be any rush. Perhaps someone can advocate for a 
true service model in the meantime for things that *don't* change and 
*should definitely* happen right at boot?


-Daniel

Re: Starting postfix

[Wietse Venema]

lst_ho...@kwsoft.de:
> Zitat von Wietse Venema :
> 
> > Wietse Venema:
> >> lst_ho...@kwsoft.de:
> >> > Zitat von Wietse Venema :
> >> >
> >> > > lst_ho...@kwsoft.de:
> >> > >> The "problem" is more of that distribution like Ubuntu and Redhat are
> >> > >> moving to "upstart" for boot and starting services/daemons. The main
> >> > >> difference for the started services is that upstart need the program
> >
> > Is there any reason they can't do this:
> >
> > Postfix "job" script:
> >
> >   pre-start exec postfix start
> >   post-stop exec postfix stop
> >
> > With this, the system will do the work for them, and everything
> > uses stable documented interfaces.
> 
> 
> I'm just on the way learning the new concepts of upstart...
> As far as i understand the common way is to not detach as it is done  
> in the common way but run in foreground to keep contact with upstart  
> (init) so status can be easily collected. It should be possible to  

I'll repeat, this does not work with Postfix multi-instance support,
which requires multiple master daemons.

They can use this:

   pre-start exec postfix start
   pre-stop exec postfix stop

Or they can use a "postfix upstart" pacifier which does "postfix
start" then does nothing until shutdown:

exec postfix upstart
pre-stop exec postfix stop

They should not start and stop the master directly.  Among other
things, that does not work with multi-instance support.

Wietse

Re: Starting postfix

[Christian Roessner]

Hi,

> > > Postfix "job" script:
> > >
> > >   pre-start exec postfix start
> > >   post-stop exec postfix stop
> > >
> > > With this, the system will do the work for them, and everything
> > > uses stable documented interfaces.

sorry Wietse, if it really would have been so easy, I never had contaced
the list for such trivial solutions ;-)

In fact your code snipped would start, that is true, but upstart would
catch a wrong pid and you could never stop postfix with upstart again.

But we really can close this thread, as I already have shown a script
that does the job.

Thanks
Christian
-- 
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com

Re: Starting postfix

[Wietse Venema]

Christian Roessner:
> Hi,
> 
> > > > Postfix "job" script:
> > > >
> > > >   pre-start exec postfix start
> > > >   post-stop exec postfix stop
> > > >
> > > > With this, the system will do the work for them, and everything
> > > > uses stable documented interfaces.
> 
> sorry Wietse, if it really would have been so easy, I never had contaced
> the list for such trivial solutions ;-)
> 
> In fact your code snipped would start, that is true, but upstart would
> catch a wrong pid and you could never stop postfix with upstart again.

Sorry, with the above, there is no PID, since all the work is done
in the pre-start and pre-start actions.

This approach is valid. It is used for example to turn on/off networking,
where there is no single PID.

> But we really can close this thread, as I already have shown a script
> that does the job.

I disagree. We need a solution that is based on proper understanding
of how upstart works, and I will provide one that has no kludges.

Wietse

Re: Starting postfix

[lst_hoe02]

Zitat von Wietse Venema :


lst_ho...@kwsoft.de:

Zitat von Wietse Venema :

> Wietse Venema:
>> lst_ho...@kwsoft.de:
>> > Zitat von Wietse Venema :
>> >
>> > > lst_ho...@kwsoft.de:
>> > >> The "problem" is more of that distribution like Ubuntu and  
Redhat are

>> > >> moving to "upstart" for boot and starting services/daemons. The main
>> > >> difference for the started services is that upstart need the program
>
> Is there any reason they can't do this:
>
> Postfix "job" script:
>
>   pre-start exec postfix start
>   post-stop exec postfix stop
>
> With this, the system will do the work for them, and everything
> uses stable documented interfaces.


I'm just on the way learning the new concepts of upstart...
As far as i understand the common way is to not detach as it is done
in the common way but run in foreground to keep contact with upstart
(init) so status can be easily collected. It should be possible to


I'll repeat, this does not work with Postfix multi-instance support,
which requires multiple master daemons.


Agreed and understanded.


They can use this:

   pre-start exec postfix start
   pre-stop exec postfix stop


This has the drawback that "postfix start" terminates after Postfix is  
started so as said upstart will report Postfix as "waiting" (for the  
next event) instead of "running".



Or they can use a "postfix upstart" pacifier which does "postfix
start" then does nothing until shutdown:

exec postfix upstart
pre-stop exec postfix stop


That was the construct i tried to explain. A wrapper/pacifier whatever  
is needed which does not terminate but does nothing until a "stop" or  
some other event arrives.



They should not start and stop the master directly.  Among other
things, that does not work with multi-instance support.


Agreed and understanded.

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Starting postfix

[Christian Roessner]

Hi, 

> That was the construct i tried to explain. A wrapper/pacifier whatever  
> is needed which does not terminate but does nothing until a "stop" or  
> some other event arrives.
> 
> > They should not start and stop the master directly.  Among other
> > things, that does not work with multi-instance support.
> 
> Agreed and understanded.

may I ask, why postfix should find a solution? I explain my question:
before I came here and started that thread, I took many hours of reading
about upstart and doing many local tests here to figure out how I could
get the job done. I also called strace start postfix and could see that
there is some kind of message communication. Yet I did not find out,
which destination receives upstart information. But at least I think,
there could be more applications out there that have issues like this
here. So wouldn't it make sense to ask upstart developers, if they can
extend their upstart interfaces?

Or if we really can find out, where upstart is comminicating to, maybe
extend postfix' capabilities to send information to this place.

Just thoughts and I only try to sort some ideas. If I am allowed to
summarize, from what I learned here these days:

Postfix does:
- have a really stable master process that did not die in more than 10
years (Victor)
- does not need a respawn feature

upstart does:
- start
- stop
- status
- restart
- what else?

start, stop and status use the pid that a process had after starting it.
So now I try to combine this:

Some piece of software, call it dispatcher, call it wrapper, whatever,
needs to call postfix start to not break any interfaces or anything else
postfix related. Right?

The wrapper that I showed here does this job. You can start and stop
postfix cleanly. If I understood right, simply testing a status of
postfix is not so easy, so Victor does the monitoring differently. So we
can not simply check the status and the result may be a bogus result.

This is, what I learned. So now my question: what do you have in mind
Wietse, if you say, you may provide something? Do not get me wrong
please. I really like to learn and even when you got me totally wrong at
the beginning of this thread, I never had something bad in mind. Just
coming here and trying to find a solution. Is that ok so far?

Is there anything that I can do to help?

Best wishes
Christian
-- 
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com

Re: Starting postfix

[Wietse Venema]

Christian Roessner:
> This is, what I learned. So now my question: what do you have in mind
> Wietse, if you say, you may provide something? Do not get me wrong

I have written a "postfix upstart" command as described below.

This can automatically respawn Postfix in single instance mode
(even if I have never seen Postfix die in 14 years of development).
It automatically handles the SIGHUP signal from upstart.

In the case of "multi instance mode" Postfix it just becomes an
idle persistent process. Here, I still need to add code that executes
"postfix reload" when it receives the SIGHUP signal from upstart.

Some details are still in flux, for example I may decide to merge
"postfix check" functionality under "postfix upstart".

Wietse

POSTFIX(1)  POSTFIX(1)
...
   upstart
  Start the Postfix mail system (skipping the "check"  phase)  and
  do  not  disappear  into  the  background.  See  "RUNNING  UNDER
  UPSTART" below.

...
RUNNING UNDER UPSTART
   The  upstart system is designed for automated stopping and (re)starting
   of daemon applications.

   The following is an example of the core entries for an upstart job def-
   inition:

  # Boot-time health check and repair.
  pre-start exec postfix check

  # Due to its "one PID per job" model, upstart cannot
  # support automatic restart in Postfix multi-instance
  # mode.
  exec postfix upstart

  # Orderly shut down before upstart sends SIGKILL.
  pre-stop exec postfix stop

   Note:  upstart assumes that there is one PID per job, therefore it can-
   not support automatic restart in Postfix multi-instance mode.

This is now running on an Ubuntu virtual machine.

Wietse

Re: Starting postfix

[lst_hoe02]

Zitat von Wietse Venema :


Christian Roessner:

This is, what I learned. So now my question: what do you have in mind
Wietse, if you say, you may provide something? Do not get me wrong


I have written a "postfix upstart" command as described below.

This can automatically respawn Postfix in single instance mode
(even if I have never seen Postfix die in 14 years of development).
It automatically handles the SIGHUP signal from upstart.

In the case of "multi instance mode" Postfix it just becomes an
idle persistent process. Here, I still need to add code that executes
"postfix reload" when it receives the SIGHUP signal from upstart.

Some details are still in flux, for example I may decide to merge
"postfix check" functionality under "postfix upstart".

Wietse

POSTFIX(1)   
POSTFIX(1)

...
   upstart
  Start the Postfix mail system (skipping the "check"   
phase)  and
  do  not  disappear  into  the  background.  See   
"RUNNING  UNDER

  UPSTART" below.

...
RUNNING UNDER UPSTART
   The  upstart system is designed for automated stopping and  
(re)starting

   of daemon applications.

   The following is an example of the core entries for an  
upstart job def-

   inition:

  # Boot-time health check and repair.
  pre-start exec postfix check

  # Due to its "one PID per job" model, upstart cannot
  # support automatic restart in Postfix multi-instance
  # mode.
  exec postfix upstart

  # Orderly shut down before upstart sends SIGKILL.
  pre-stop exec postfix stop

   Note:  upstart assumes that there is one PID per job,  
therefore it can-

   not support automatic restart in Postfix multi-instance mode.

This is now running on an Ubuntu virtual machine.


Cool...
And BTW i also have never seen Postfix die. It is one of the most  
stable non-trivial software systems i have seen until now.


Many Thanks

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Starting postfix

[Patrick Ben Koetter]

* lst_ho...@kwsoft.de :
> Zitat von Wietse Venema :
> >This is now running on an Ubuntu virtual machine.
> 
> Cool...
> And BTW i also have never seen Postfix die. It is one of the most
> stable non-trivial software systems i have seen until now.

Postfix is frustrating. At first tt's fun because it is setup easily. But once
you've done, you don't need to touch it again. It simply sits there and does
its job. No more fun. Nothing to play with. Very frustrating... ;)

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):



smime.p7s
Description: S/MIME cryptographic signature

Re: Starting postfix

[Larry Stone]

On 2/25/11 6:45 AM, Christian Roessner at
c+postfix_org...@roessner-network-solutions.com wrote:

> That postfix must not be started directly by calling master should also
> be documented in the master man page, as people like me (and my idea was
> based on Apple's practise, like they DO START postfix with launchctl on
> Mac OS X Server edition).

This got my attention because I run the Apple provided Postfix (2.5.5) on
Mac OS X client (10.6.6 specifically). What do you know - when I look at the
launchctl plist Apple provides to start Postfix, it does so by running
master directly. Thanks Apple!

-- 
Larry Stone
lston...@stonejongleux.com
http://www.stonejongleux.com/

Re: Starting postfix

[Wietse Venema]

Larry Stone:
> On 2/25/11 6:45 AM, Christian Roessner at
> c+postfix_org...@roessner-network-solutions.com wrote:
> 
> > That postfix must not be started directly by calling master should also
> > be documented in the master man page, as people like me (and my idea was
> > based on Apple's practise, like they DO START postfix with launchctl on
> > Mac OS X Server edition).
> 
> This got my attention because I run the Apple provided Postfix (2.5.5) on
> Mac OS X client (10.6.6 specifically). What do you know - when I look at the
> launchctl plist Apple provides to start Postfix, it does so by running
> master directly. Thanks Apple!

The upstart hacks will hopefully make it easier for other integrators
to "do the right thing".

Wietse

Re: Starting postfix

[john]

The operative words are desktop computer, the problem it would seem to 
me, is that Upstart is being used in an environment for which it has not 
been designed and is trying to solve problems that do not occur on a server.

Perhaps we need to point this out to the good folks at Ubuntu etc.

jut my 2c worth
John A

[snip]
Since Upstart is new to me I decided to read about it: "[The 
shortcomings of sysvinit] leaves it unable to handle various tasks on 
a moderndesktop computer 
elegantly, including: 
The addition or 

[snip]

--
"All that is necessary for the triumph of evil is that good men do nothing." 
(Edmund Burke)

Re: Starting postfix

[Christian Roessner]

Hi,

> This got my attention because I run the Apple provided Postfix (2.5.5) on
> Mac OS X client (10.6.6 specifically). What do you know - when I look at the
> launchctl plist Apple provides to start Postfix, it does so by running
> master directly. Thanks Apple!

Calling /usr/libexec/postfix/master in the plist. That should not be
critics. My friend Lars runs three X-Serve servers. One Tiger, Leopard
and before posting here, I asked him to please just look into the plist
and tell me, what is called.

I do not know for Snow Leopard I must admit.

Was that said wrong?

Christian
-- 
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com

Re: Starting postfix

[Christian Roessner]

Am Samstag, den 26.02.2011, 08:51 +0100 schrieb Christian Roessner: 
> Hi,
> 
> > This got my attention because I run the Apple provided Postfix (2.5.5) on
> > Mac OS X client (10.6.6 specifically). What do you know - when I look at the
> > launchctl plist Apple provides to start Postfix, it does so by running
> > master directly. Thanks Apple!
> 
> Calling /usr/libexec/postfix/master in the plist. That should not be
> critics. My friend Lars runs three X-Serve servers. One Tiger, Leopard
> and before posting here, I asked him to please just look into the plist
> and tell me, what is called.

cat /System/Library/LaunchDaemons/org.postfix.master.plist 

http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


Label
org.postfix.master
Program
/usr/libexec/postfix/master
ProgramArguments

master
-e
60

QueueDirectories

/var/spool/postfix/maildrop

AbandonProcessGroup




Here you see the plist. It must not start postfix by calling master
directly.

Christian
-- 
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com

Re: Starting postfix

[Larry Stone]

On 2/26/11 2:06 AM, Christian Roessner at
c+postfix_org...@roessner-network-solutions.com wrote:

> Am Samstag, den 26.02.2011, 08:51 +0100 schrieb Christian Roessner:
>> Hi,
>> 
>>> This got my attention because I run the Apple provided Postfix (2.5.5) on
>>> Mac OS X client (10.6.6 specifically). What do you know - when I look at the
>>> launchctl plist Apple provides to start Postfix, it does so by running
>>> master directly. Thanks Apple!
>> 
>> Calling /usr/libexec/postfix/master in the plist. That should not be
>> critics. My friend Lars runs three X-Serve servers. One Tiger, Leopard
>> and before posting here, I asked him to please just look into the plist
>> and tell me, what is called.
> 
> cat /System/Library/LaunchDaemons/org.postfix.master.plist
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
> 
> 
> Label
> org.postfix.master
> Program
> /usr/libexec/postfix/master
> ProgramArguments
> 
> master
> -e
> 60
> 
> QueueDirectories
> 
> /var/spool/postfix/maildrop
> 
> AbandonProcessGroup
> 
> 
> 
> 
> Here you see the plist. It must not start postfix by calling master
> directly.

I think a little of what you are trying to say is getting lost in
translation. What you posted is the Apple provided plist that is supposed to
run Postfix for only 60 seconds as an outgoing only server. I had modified
it to remove the "-e 60" so it runs all the time as a full server.

But as of last night, I have disabled it and replaced it with a "run at boot
only" plist (note that user or 3rd party provided plists go in
/Library/LaunchDaemons with /System/Library/LaunchDaemons reserved for Apple
provided plists):
# cat /Library/LaunchDaemons/postfix.plist

http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


Label
postfix
OnDemand

ProgramArguments

/var/root/start_postfix.sh

RunAtLoad

ServiceIPC




The script it calls is simply:
# cat /var/root/start_postfix.sh
#!/bin/sh
postfix start
sleep 1

With the "sleep 1" being necessary to deal with launchd not liking programs
that daemonize. It wants things it starts to stick around so it can monitor
them. But with OnDemand set to true, it does not do anything when that
script dies. And as Wietse said, he's never seen Postfix die so not a big
deal that no launchd monitoring will be provided (this is SOHO server - I am
on e-mail enough that I'll know if there is a problem and there are no paid
users I need to worry about).

-- 
Larry Stone
lston...@stonejongleux.com
http://www.stonejongleux.com/

Re: Starting postfix

[Stan Hoeppner]

Patrick Ben Koetter put forth on 2/25/2011 4:20 PM:
> * lst_ho...@kwsoft.de :
>> Zitat von Wietse Venema :
>>> This is now running on an Ubuntu virtual machine.
>>
>> Cool...
>> And BTW i also have never seen Postfix die. It is one of the most
>> stable non-trivial software systems i have seen until now.
> 
> Postfix is frustrating. At first tt's fun because it is setup easily. But once
> you've done, you don't need to touch it again. It simply sits there and does
> its job. No more fun. Nothing to play with. Very frustrating... ;)

On the bright side, this stability freed up time allowing you to write a
book about it.  :)

-- 
Stan

Problem starting Postfix: mysql_alias.cf, line 1: missing '='

[Jose Carlos Madrid]

Hi, I am just dealing with my first Postfix installation.
 After
following a few tutorials, I’m still not able to start the Postfix
server. I looked for solutions in many forums, but I cannot find this
problem and no one could help me. Tailing the log files there is an error 
coming over and over:

Sep 14 11:25:30 hostname postfix/cleanup[30095]: fatal: 
/etc/postfix/mysql_alias.cf, line 1: missing '=' after attribute name: "??h"
Sep 14 11:25:31 hostname postfix/master[30043]: warning: process 
/usr/lib/postfix/cleanup pid 30095 exit status 1
Sep 14 11:25:31 hostname postfix/master[30043]: warning: 
/usr/lib/postfix/cleanup: bad command startup -- throttling

This is the mysql_alias.cf file:

hosts = 127.0.0.1
user = 
password =  
dbname = maildb 
table = aliases 
select_field = destination 
where_field = mail 
additional_conditions = and enabled = 1

(I omitted user and password)

TIP: Whe I change the lines 1 and 2. First line would be "user =". Then I get 
"..line 1: missing '=' after attribute name: "??u"
I also tried changin host = 127.0.0.1 by localhost, but nothing.



This is my main.cf:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
# myorigin = /etc/mailname

# Basic Server Configuration 

myhostname = smtp.solobuenoslobros.es
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
local_recipient_maps =
mynetworks_style = host

# Setup Alias Maps

alias_maps = hash:/etc/postfix/aliases 
alias_database = hash:/etc/postfix/aliases 

# Configure Virtual Hosting 

virtual_mailbox_base = /var/spool/mail/virtual 
virtual_mailbox_maps = mysql:/etc/postfix/mysql_mailbox.cf 
virtual_uid_maps = mysql:/etc/postfix/mysql_uid.cf 
virtual_gid_maps = mysql:/etc/postfix/mysql_gid.cf 
virtual_mailbox_domains = mysql:/etc/postfix/mysql_domains.cf 
virtual_alias_maps = mysql:/etc/postfix/mysql_alias.cf 


# Additional Configuration: *

myorigin=solobuenoslibros.es

smtpd_banner = $myhostname ESMTP $mail_name 
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
delay_warning_time = 4h
unknown_local_recipient_reject_code = 450 
maximal_queue_lifetime = 7d 
minimal_backoff_time = 1000s 
maximal_backoff_time = 8000s
smtp_helo_timeout = 60s 
smtpd_recipient_limit = 16
smtpd_soft_error_limit = 3 
smtpd_hard_error_limit = 12

readme_directory = no

# TLS parameters
#smtp_use_tls = no 
smtp_tls_security_level = may 
#smtpd_use_tls=yes 
smtpd_tls_security_level = may 
#smtpd_tls_auth_only = no 
smtp_tls_note_starttls_offer = yes 
smtpd_tls_loglevel = 1 
smtpd_tls_received_header = yes 
smtpd_tls_session_cache_timeout = 3600s 
tls_random_source = dev:/dev/urandom 
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem 
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key 
#smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache 
#smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_helo_restrictions = permit_mynetworks, warn_if_reject 
reject_non_fqdn_hostname, reject_invalid_hostname, permit 
smtpd_sender_restrictions = permit_mynetworks, warn_if_reject 
reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, 
permit 
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org, 
reject_rbl_client blackholes.easynet.nl, reject_rbl_client dnsbl.njabl.org 
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks, 
permit_sasl_authenticated, reject_non_fqdn_recipient, 
reject_unknown_recipient_domain, reject_unauth_destination, 
check_policy_service inet:127.0.0.1:6, permit

smtpd_helo_required = yes 
# waste spammers time before rejecting them
smtpd_delay_reject = yes 
disable_vrfy_command = yes


# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

# content_filter = amavis:[127.0.0.1]:10024

mydomain = solobuenoslobros.es

relayhost = 
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128

mailbox_size_limit = 0
recipient_delimiter = +
debug_peer_list = 127.0.0.1

I'd really appreciate your help...


_
Descárgate Internet Explorer 8 ¡Y gana gratis viajes con Spanair!
http://www.vivelive.com/spanair

Starting postfix at boot time on Centos 7

[info]

Hi all.

I compiled postfix 3.0.3 from source code but (maybe a stupid question).
don't know how to start it at boot of a Centos 7 machine!

Tried with "chkconfig" and "systemctl" without any results!

How can I do this? Is there a "postfix.service" to be enabled with
systemctl?

Thank you very much for your help

-Francesco



---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus

Re: Problem starting Postfix: mysql_alias.cf, line 1: missing '='

[Rob Foehl]

On Tue, 15 Sep 2009, Jose Carlos Madrid wrote:


Sep 14 11:25:30 hostname postfix/cleanup[30095]: fatal: /etc/postfix/mysql_alias.cf, line 
1: missing '=' after attribute name: "??h"


It appears you have saved mysql_alias.cf in a UTF-16 encoding.  Don't do 
that; Postfix configuration files are plain ASCII text.


-Rob

RE: Problem starting Postfix: mysql_alias.cf, line 1: missing '='

[Jose Carlos Madrid]

Thank you Rob,

you were right. I edited the file in Windows. I didn't realize. But after save 
it with vi editor It still keeps giving me this error. Notice it is not (line 
1: missing '=' after attribute name: "??u") anymore but similar.


Sep 15 23:26:01 r25841 postfix/trivial-rewrite[31130]: fatal:
/etc/postfix/mysql_domains.cf, line 1: missing '=' after attribute
name: "??u"

Sep 15 23:26:02 r25841 postfix/master[31125]: warning: process 
/usr/lib/postfix/trivial-rewrite pid 31130 exit status 1

Sep 15 23:26:02 r25841 postfix/master[31125]: warning: 
/usr/lib/postfix/trivial-rewrite: bad command startup -- throttling
This is the mysql_alias.cf file:
 
hosts = 127.0.0.1
user = 
password =  
dbname = maildb 
table = aliases 
select_field = destination 
where_field = mail 
additional_conditions = and enabled = 1

> Date: Tue, 15 Sep 2009 14:26:54 -0400
> From: r...@loonybin.net
> To: postfix-users@postfix.org
> Subject: Re: Problem starting Postfix: mysql_alias.cf, line 1: missing '='
>
> On Tue, 15 Sep 2009, Jose Carlos Madrid wrote:
>
>> Sep 14 11:25:30 hostname postfix/cleanup[30095]: fatal: 
>> /etc/postfix/mysql_alias.cf, line 1: missing '=' after attribute name: "??h"
>
> It appears you have saved mysql_alias.cf in a UTF-16 encoding. Don't do
> that; Postfix configuration files are plain ASCII text.
>
> -Rob

_
Messenger cumple 10 años ¡Descárgate ya los nuevos emoticonos!
http://www.vivelive.com/felicidades

RE: Problem starting Postfix: mysql_alias.cf, line 1: missing '='

[Rob Foehl]

On Tue, 15 Sep 2009, Jose Carlos Madrid wrote:

you were right. I edited the file in Windows. I didn't realize. But 
after save it with vi editor It still keeps giving me this error. Notice 
it is not (line 1: missing '=' after attribute name: "??u") anymore but 
similar.


Please don't top post.


Sep 15 23:26:01 r25841 postfix/trivial-rewrite[31130]: fatal:
/etc/postfix/mysql_domains.cf, line 1: missing '=' after attribute
name: "??u"


You mentioned mysql_alias.cf last time; this is mysql_domains.cf.  You may 
want to double check each file referenced in your configuration.


Note that if you are using vim, it is smart enough to preserve the Unicode
byte order mark and file encoding.  Try pasting your expected content into
a fresh editor session.

-Rob

Re: Problem starting Postfix: mysql_alias.cf, line 1: missing '='

[Gerard]

On Tue, 15 Sep 2009 18:03:48 -0400 (EDT)
Rob Foehl  wrote:

> On Tue, 15 Sep 2009, Jose Carlos Madrid wrote:
> 
> > you were right. I edited the file in Windows. I didn't realize. But 
> > after save it with vi editor It still keeps giving me this error.
> > Notice it is not (line 1: missing '=' after attribute name: "??u")
> > anymore but similar.
> 
> Please don't top post.
> 
> > Sep 15 23:26:01 r25841 postfix/trivial-rewrite[31130]: fatal:
> > /etc/postfix/mysql_domains.cf, line 1: missing '=' after attribute
> > name: "??u"
> 
> You mentioned mysql_alias.cf last time; this is mysql_domains.cf.
> You may want to double check each file referenced in your
> configuration.
> 
> Note that if you are using vim, it is smart enough to preserve the
> Unicode byte order mark and file encoding.  Try pasting your expected
> content into a fresh editor session.

You could just do something like this I believe:

iconv -f utf8 -t ascii oldfile > newfile

-- 
Gerard
postfix.u...@yahoo.com

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

A chicken is an egg's way of producing more eggs.

RE: Starting postfix at boot time on Centos 7

[Wolfe, Robert]

Not sure if this will help, but a Google search returned this link:

 

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference

 

 

From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of i...@itrezero.it
Sent: Wednesday, February 24, 2016 11:25 AM
To: postfix-users@postfix.org
Subject: Starting postfix at boot time on Centos 7

 

Hi all. 

I compiled postfix 3.0.3 from source code but (maybe a stupid question)… don’t 
know how to start it at boot of a Centos 7 machine!

Tried with “chkconfig” and “systemctl” without any results! 

How can I do this? Is there a “postfix.service” to be enabled with systemctl?

Thank you very much for your help

-Francesco

 


Questa e-mail è stata inviata da un computer privo di virus protetto da Avast. 
 <https://www.avast.com/sig-email> www.avast.com 

 

Re: Starting postfix at boot time on Centos 7

[Mike Coddington]

On Wed, Feb 24, 2016 at 06:25:08PM +0100, i...@itrezero.it wrote:
> Hi all.
> 
> I compiled postfix 3.0.3 from source code but (maybe a stupid question).
> don't know how to start it at boot of a Centos 7 machine!
> 
> Tried with "chkconfig" and "systemctl" without any results!
> 
> How can I do this? Is there a "postfix.service" to be enabled with
> systemctl?
> 
> Thank you very much for your help
> 
> -Francesco


For what it's worth, I run Postfix on CentOS 7 also. Here's what my service 
file looks like. I'm running 2.10 because that's what the distribution comes 
with, but as far as I can tell, the file should still work for you.

[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop

[Install]
WantedBy=multi-user.target

Re: Starting postfix at boot time on Centos 7

[Danny Horne]

Because you installed for source rather than through Yum, you haven't
got the System V init scripts.  If you try to install these via Yum
it'll want to install Postfix as well, to avoid that run -

|rpm -Uvh --nodeps $(repoquery --location postfix-sysvinit)|

Then you'll be able to run -

systemctl enable postfix
systemctl start postfix


On 24/02/2016 5:25 pm, i...@itrezero.it wrote:
>
> Hi all.
>
> I compiled postfix 3.0.3 from source code but (maybe a stupid
> question)… don’t know how to start it at boot of a Centos 7 machine!
>
> Tried with “chkconfig” and “systemctl” without any results!
>
> How can I do this? Is there a “postfix.service” to be enabled with
> systemctl?
>
> Thank you very much for your help
>
> -Francesco
>
>
> Questa e-mail è stata inviata da un computer privo di virus protetto
> da Avast.
> www.avast.com 
>




signature.asc
Description: OpenPGP digital signature

Re: Starting postfix at boot time on Centos 7

[Danny Horne]

This command should just read

rpm -Uvh --nodeps $(repoquery --location postfix-sysvinit)



On 24/02/2016 5:48 pm, Danny Horne wrote:
> rpm -Uvh --nodeps $(repoquery --location postfix-sysvinit)




signature.asc
Description: OpenPGP digital signature

R: Starting postfix at boot time on Centos 7

[info]

Thank you all.

I preferred to use the “/etc/rc.d/init.d/postfix start script” from my old 
Centos 6 and installed on C7 with a simple chkconfig.

Many thanks again.

-Francesco





Da: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
Per conto di Wolfe, Robert
Inviato: mercoledì 24 febbraio 2016 18:32
A: i...@itrezero.it; postfix-users@postfix.org
Oggetto: RE: Starting postfix at boot time on Centos 7



Not sure if this will help, but a Google search returned this link:



 
<https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference>
 
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference





From:  <mailto:owner-postfix-us...@postfix.org> owner-postfix-us...@postfix.org 
[ <mailto:owner-postfix-us...@postfix.org> 
mailto:owner-postfix-us...@postfix.org] On Behalf Of  <mailto:i...@itrezero.it> 
i...@itrezero.it
Sent: Wednesday, February 24, 2016 11:25 AM
To:  <mailto:postfix-users@postfix.org> postfix-users@postfix.org
Subject: Starting postfix at boot time on Centos 7



Hi all.

I compiled postfix 3.0.3 from source code but (maybe a stupid question)… don’t 
know how to start it at boot of a Centos 7 machine!

Tried with “chkconfig” and “systemctl” without any results!

How can I do this? Is there a “postfix.service” to be enabled with systemctl?

Thank you very much for your help

-Francesco




Questa e-mail è stata inviata da un computer privo di virus protetto da Avast.
 <https://www.avast.com/sig-email> www.avast.com





---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus

Re: Starting postfix at boot time on Centos 7

[Peter]

On 25/02/16 06:25, i...@itrezero.it wrote:
> I compiled postfix 3.0.3 from source code but (maybe a stupid question)…
> don’t know how to start it at boot of a Centos 7 machine!
> 
> Tried with “chkconfig” and “systemctl” without any results!
> 
> How can I do this? Is there a “postfix.service” to be enabled with
> systemctl?

There is no need to compile postfix yourself on CentOS.  You can get the
latest version of postfix pre-built for CentOS 7 (and even 5 and 6) from
the ghettoforge-plus repo at www.ghettoforge.org, complete with init.d
(for 5 and 6) or systemd service files (for 7) as appropriate.


Peter