Keep Postfix running in the foreground

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

Wietse Venema
Wietse Venema:

> Wietse Venema:
> > A. Schulze:
> > > Am 04.04.2018 um 19:08 schrieb Wietse Venema:
> > > > Eray Aslan:
> > > >> On Tue, Apr 03, 2018 at 07:46:42PM -0400, Wietse Venema wrote:
> > > >>> I updated both the postfix-script file and the master daemon.
> > > >>>
> > > >>> I'd appreciate it if someone could verify that this will run the
> > > >>> master daemon with PID 1, and that 'postfix stop' in the container
> > > >>> will stop the master daemon. If it doesn't, then Linux does weird
> > > >>> stuff with PID 1 processes.
> > >
> > > I found the same...
> > >
> > > > Just for the heck of it, can you replace in src/master/master_sig.c
> > > > this code:
> > > >
> > > >     if (kill(pid, SIGKILL) < 0)
> > > >         msg_fatal("%s: kill myself: %m", myname);
> > > >
> > > > With this code:
> > > >
> > > >     exit(0);
> > > >
> > > > And see if that fixes the PID=1 behavior?
> > >
> > > it does in any way. Thanks, Wietse!
> > >
> > > I tried both, exit(0) and _exit(0) :-)
> >
> > Andreas, thanks for the encouraging words :-)
>
> I also need you guys to verify that with the Postfix master running
> as PID=1, "docker stop" will no longer leave the master daemon
> running until Docker times out and forcibly terminates everything.
>
> By default, "docker stop" should send signal SIGTERM (signal 15) which
> is what Postfix expects, but it is good to verify.

BTW postfix-3.4-20180404 has the _exit() call.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

HAKNER J
In reply to this post by A Debian User
> > > >>> I'd appreciate it if someone could verify that this will run the
> > > >>> master daemon with PID 1, and that 'postfix stop' in the container
> > > >>> will stop the master daemon. If it doesn't, then Linux does weird
> > > >>> stuff with PID 1 processes.

Correct.  The Linux kernel doesn't allow you to send a signal to pid 1
that would cause its termination.  pid 1 is normally the init process,
and terminating it essentially renders the system useless.
Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

Wietse Venema
HAKNER J:
> > > > >>> I'd appreciate it if someone could verify that this will run the
> > > > >>> master daemon with PID 1, and that 'postfix stop' in the container
> > > > >>> will stop the master daemon. If it doesn't, then Linux does weird
> > > > >>> stuff with PID 1 processes.
>
> Correct.  The Linux kernel doesn't allow you to send a signal to pid 1
> that would cause its termination.  pid 1 is normally the init process,
> and terminating it essentially renders the system useless.

That may be so, but why does the lame Linux kernel silently ignore
the kill() call instead of properly returning an error.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

HAKNER J
In reply to this post by A Debian User

>That may be so, but why does the lame Linux kernel silently ignore
>the kill() call instead of properly returning an error.
>
> Wietse

:)  I don't write the code, just reporting the bad news!

I think however the reasoning is as follows:  clearly a user-mode process
can send a signal to init to force it to re-read its config, etc.
At the time that said process generates the signal with the kill system
call, it could be masked.  It isn't until the signal is actually delivered
to pid 1 that the kernel, acting in the context of pid 1, realizes that
the signal is now unmasked and the signal's disposition is set to SIG_DFL
which will cause process termination.  At that point, the signal is silently
discarded.  /usr/src/linux/kernel/signal.c:3646 or thereabouts depending
on kernel version.

Signal generation and signal delivery are asynchronous of each other so
a condition discovered during signal delivery can not be reported back as
an error code to a system call.

I can see your point that at the time the user-mode process tries to send
the signal to pid 1, if that signal is unmasked and is SIG_DFL, then the
kill system call could fail synchronously maybe with EINVAL or EPERM.
Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

Bastian Blank-3
In reply to this post by Wietse Venema
On Wed, Apr 04, 2018 at 08:56:46PM -0400, Wietse Venema wrote:
> That may be so, but why does the lame Linux kernel silently ignore
> the kill() call instead of properly returning an error.

The signal is ignored the same way as if someone had called
| signal(SIGFOO, SIG_IGN)

Bastian

--
You!  What PLANET is this!
                -- McCoy, "The City on the Edge of Forever", stardate 3134.0
Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

Eray Aslan-2
In reply to this post by Wietse Venema
On Wed, Apr 04, 2018 at 07:19:56PM -0400, Wietse Venema wrote:
> I also need you guys to verify that with the Postfix master running
> as PID=1, "docker stop" will no longer leave the master daemon
> running until Docker times out and forcibly terminates everything.
>
> By default, "docker stop" should send signal SIGTERM (signal 15) which
> is what Postfix expects, but it is good to verify.

Looks good.  Thank you.

$ docker run -d -v /dev/log:/dev/log eraya/postfix:3.4_pre20180404-r1
9cb6c36eb8f2e03785389521a601a54be49c817522a35f8464ae7b71a8e51fe6
$ docker ps
CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS              PORTS               NAMES
9cb6c36eb8f2        eraya/postfix:3.4_pre20180404-r1   "/usr/sbin/postfix s…"   5 seconds ago       Up 4 seconds        25/tcp              laughing_chebyshev
$ docker exec 9cb6c36eb8f2 ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1  71540  2880 ?        Ss   06:42   0:00 /usr/libexec/postfix/master -i
postfix     76  0.0  0.1  71524  2840 ?        S    06:42   0:00 pickup -l -t unix -u
postfix     77  0.0  0.1  71572  2864 ?        S    06:42   0:00 qmgr -l -t unix -u
root        78  0.0  0.0  17556  1188 ?        Rs   06:42   0:00 ps aux
$ docker exec 9cb6c36eb8f2 postconf mail_version
mail_version = 3.4-20180404
$ time docker exec 9cb6c36eb8f2 postfix stop

real 0m0.172s
user 0m0.067s
sys 0m0.008s
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$ docker run -d -v /dev/log:/dev/log eraya/postfix:3.4_pre20180404-r1
d9a7e481bfec046b5cdd859b61a8dacb3958cf7ce32af9e22bfca0a9e88504d0
$ docker ps
CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS              PORTS               NAMES
d9a7e481bfec        eraya/postfix:3.4_pre20180404-r1   "/usr/sbin/postfix s…"   4 seconds ago       Up 3 seconds        25/tcp              ecstatic_mccarthy
$ time docker stop d9a7e481bfec
d9a7e481bfec

real 0m0.210s
user 0m0.068s
sys 0m0.007s
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

--
Eray
Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

Wietse Venema
In reply to this post by Bastian Blank-3
Bastian Blank:
> On Wed, Apr 04, 2018 at 08:56:46PM -0400, Wietse Venema wrote:
> > That may be so, but why does the lame Linux kernel silently ignore
> > the kill() call instead of properly returning an error.
>
> The signal is ignored the same way as if someone had called
> | signal(SIGFOO, SIG_IGN)

Postfix code is (while handling SIGTERM)

    sigemptyset(&action.sa_mask);
    action.sa_flags = 0;
    action.sa_handler = SIG_DFL;
    if (sigaction(sig, &action, (struct sigaction *) 0) < 0)
        msg_fatal("%s: sigaction: %m", myname);
    if (kill(pid, sig) < 0)
        msg_fatal("%s: kill myself: %m", myname);

So Linux also ignores sigaction with SIG_DFL without returning an
error. Undocumented behavior -> Lame.

        Wietse

Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

A. Schulze
In reply to this post by Eray Aslan-2

Eray Aslan:

> On Wed, Apr 04, 2018 at 07:19:56PM -0400, Wietse Venema wrote:
>> I also need you guys to verify that with the Postfix master running
>> as PID=1, "docker stop" will no longer leave the master daemon
>> running until Docker times out and forcibly terminates everything.
>>
>> By default, "docker stop" should send signal SIGTERM (signal 15) which
>> is what Postfix expects, but it is good to verify.
>
> Looks good.  Thank you.
>
> $ docker run -d -v /dev/log:/dev/log eraya/postfix:3.4_pre20180404-r1
> 9cb6c36eb8f2e03785389521a601a54be49c817522a35f8464ae7b71a8e51fe6
> $ docker ps
> CONTAINER ID        IMAGE                              COMMAND        
>            CREATED             STATUS              PORTS              
>   NAMES
> 9cb6c36eb8f2        eraya/postfix:3.4_pre20180404-r1    
> "/usr/sbin/postfix s…"   5 seconds ago       Up 4 seconds        
> 25/tcp              laughing_chebyshev
> $ docker exec 9cb6c36eb8f2 ps aux
> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
> root         1  0.0  0.1  71540  2880 ?        Ss   06:42   0:00  
> /usr/libexec/postfix/master -i
> postfix     76  0.0  0.1  71524  2840 ?        S    06:42   0:00  
> pickup -l -t unix -u
> postfix     77  0.0  0.1  71572  2864 ?        S    06:42   0:00  
> qmgr -l -t unix -u
> root        78  0.0  0.0  17556  1188 ?        Rs   06:42   0:00 ps aux
> $ docker exec 9cb6c36eb8f2 postconf mail_version
> mail_version = 3.4-20180404
> $ time docker exec 9cb6c36eb8f2 postfix stop
>
> real 0m0.172s
> user 0m0.067s
> sys 0m0.008s
> $ docker ps
> CONTAINER ID        IMAGE               COMMAND             CREATED  
>            STATUS              PORTS               NAMES
> $ docker run -d -v /dev/log:/dev/log eraya/postfix:3.4_pre20180404-r1
> d9a7e481bfec046b5cdd859b61a8dacb3958cf7ce32af9e22bfca0a9e88504d0
> $ docker ps
> CONTAINER ID        IMAGE                              COMMAND        
>            CREATED             STATUS              PORTS              
>   NAMES
> d9a7e481bfec        eraya/postfix:3.4_pre20180404-r1    
> "/usr/sbin/postfix s…"   4 seconds ago       Up 3 seconds        
> 25/tcp              ecstatic_mccarthy
> $ time docker stop d9a7e481bfec
> d9a7e481bfec
>
> real 0m0.210s
> user 0m0.068s
> sys 0m0.007s
> $ docker ps
> CONTAINER ID        IMAGE               COMMAND             CREATED  
>            STATUS              PORTS               NAMES
>
> --
> Eray

Hello,

I like to confirm that explicit. That's what I mean with "it does in  
any way" yesterday...

Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

Wietse Venema
Thank you both for verifying that PID-1 mode now works as expected.
It saved me a few hours to set stuff up and do it myself; my time
for Postfix is very limited.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Keep Postfix running in the foreground

Postfix User-2
In reply to this post by Wietse Venema
On Thu, 5 Apr 2018 07:07:06 -0400 (EDT), Wietse Venema stated:

>Bastian Blank:
>> On Wed, Apr 04, 2018 at 08:56:46PM -0400, Wietse Venema wrote:  
>> > That may be so, but why does the lame Linux kernel silently ignore
>> > the kill() call instead of properly returning an error.  
>>
>> The signal is ignored the same way as if someone had called
>> | signal(SIGFOO, SIG_IGN)  
>
>Postfix code is (while handling SIGTERM)
>
>    sigemptyset(&action.sa_mask);
>    action.sa_flags = 0;
>    action.sa_handler = SIG_DFL;
>    if (sigaction(sig, &action, (struct sigaction *) 0) < 0)
>        msg_fatal("%s: sigaction: %m", myname);
>    if (kill(pid, sig) < 0)
>        msg_fatal("%s: kill myself: %m", myname);
>
>So Linux also ignores sigaction with SIG_DFL without returning an
>error. Undocumented behavior -> Lame.
>
> Wietse

Well, you could file a bug report; however, they would just ignore it.

--
Jerry
123