Bug 810925

I cannot reproduce, from the sources:

> Consequently, Exim 4 writes a pid file only
>
>  (a) When running in the test harness, or
>  (b) When -bd is used and -oX is not used, or
>  (c) When -oP is used to supply a path.
>
> The variable daemon_write_pid is used to control this. */

(b) is our case, you can check /etc/init.d/exim (start function).

My reproducer:
# rpm -q exim
exim-4.76-4.fc16.1.x86_64

# service exim restart
Restarting exim (via systemctl): [ OK ]

# systemctl status exim.service
exim.service - SYSV: Exim is a Mail Transport Agent, which is the program that moves mail from one machine to another.
	  Loaded: loaded (/etc/rc.d/init.d/exim)
	  Active: active (running) since Tue, 07 Feb 2012 10:24:17 +0100; 27s ago
	 Process: 13457 ExecStop=/etc/rc.d/init.d/exim stop (code=exited, status=0/SUCCESS)
	 Process: 13462 ExecStart=/etc/rc.d/init.d/exim start (code=exited, status=0/SUCCESS)
	Main PID: 13470 (exim)
	  CGroup: name=systemd:/system/exim.service
		  └ 13470 /usr/sbin/exim -bd -q1h

# cat /run/exim.pid
13470


From you systemctl status, it seems it had started and later failed, thus the PID was removed. Could you check the logs (/var/log/exim/main.log)? Also check the package:
# rpm -qV exim
Try without selinux (setenforce 0) and also try to run it directly from command line (exim -bd).

all as root on command line.

cat /var/log/exim/main.log
cat: /var/log/exim/main.log: No such file or directory

drwxr-x---. 2 exim       exim          4096 Feb 24 15:36 exim

# rpm -qV exim
.M.......    /etc/rc.d/init.d/exim



 [root@frank01 ~]# exim -bd
[root@frank01 ~]# cat /run/exim.pid
18890

[root@frank01 ~]# systemctl status exim.service
exim.service - SYSV: Exim is a Mail Transport Agent, which is the program that moves mail from one machine to another.
	  Loaded: loaded (/etc/rc.d/init.d/exim)
	  Active: failed since Tue, 10 Apr 2012 08:53:48 +0100; 5h 36min ago
	 Process: 1273 ExecStop=/etc/rc.d/init.d/exim stop (code=exited, status=0/SUCCESS)
	 Process: 1263 ExecStart=/etc/rc.d/init.d/exim start (code=exited, status=0/SUCCESS)
	Main PID: 1268 (code=exited, status=1/FAILURE)
	  CGroup: name=systemd:/system/exim.service

setenforce=0, results same as above

(In reply to comment #2)
> # rpm -qV exim
> .M.......    /etc/rc.d/init.d/exim
> 
Your mode differs, could you reinstall the exim package? Also try:
# bash -x /etc/rc.d/init.d/exim start
# pgrep -l exim
# cat /var/run/exim.pid

Installed:
  exim.x86_64 0:4.76-4.fc16.1 

bash -x /etc/rc.d/init.d/exim start
+ . /etc/init.d/functions
++ TEXTDOMAIN=initscripts
++ umask 022
++ PATH=/sbin:/usr/sbin:/bin:/usr/bin
++ export PATH
++ '[' 2384 -ne 1 -a -z '' ']'
++ /bin/mountpoint -q /cgroup/systemd
++ /bin/mountpoint -q /sys/fs/cgroup/systemd
++ case "$0" in
++ _use_systemctl=1
++ '[' -z '' ']'
++ COLUMNS=80
++ '[' -z '' ']'
++ '[' -c /dev/stderr ']'
+++ /sbin/consoletype
++ CONSOLETYPE=pty
++ '[' -z '' ']'
++ '[' -z '' ']'
++ '[' -f /etc/sysconfig/i18n -o -f /etc/locale.conf ']'
++ . /etc/profile.d/lang.sh
++ unset LANGSH_SOURCED
++ '[' -z '' ']'
++ '[' -f /etc/sysconfig/init ']'
++ . /etc/sysconfig/init
+++ BOOTUP=color
+++ RES_COL=60
+++ MOVE_TO_COL='echo -en \033[60G'
+++ SETCOLOR_SUCCESS='echo -en \033[0;32m'
+++ SETCOLOR_FAILURE='echo -en \033[0;31m'
+++ SETCOLOR_WARNING='echo -en \033[0;33m'
+++ SETCOLOR_NORMAL='echo -en \033[0;39m'
+++ AUTOSWAP=no
+++ ACTIVE_CONSOLES='/dev/tty[1-6]'
+++ SINGLE=/sbin/sushell
++ '[' pty = serial ']'
++ __sed_discard_ignored_files='/\(~\|\.bak\|\.orig\|\.rpmnew\|\.rpmorig\|\.rpmsave\)$/d'
++ '[' 1 = 1 ']'
++ '[' xstart = xstart -o xstart = xstop -o xstart = xrestart -o xstart = xreload -o xstart = xtry-restart -o xstart = xforce-reload -o xstart = xcondrestart ']'
++ systemctl_redirect /etc/rc.d/init.d/exim start
++ local s
++ local prog=exim
++ local command=start
++ local options=
++ case "$command" in
++ s='Starting exim (via systemctl): '
++ '[' -n '' ']'
++ action 'Starting exim (via systemctl): ' /bin/systemctl start exim.service
++ local STRING rc
++ STRING='Starting exim (via systemctl): '
++ echo -n 'Starting exim (via systemctl):  '
Starting exim (via systemctl):  ++ shift
++ /bin/systemctl start exim.service
Job failed. See system logs and 'systemctl status' for details.
++ failure 'Starting exim (via systemctl): '
++ local rc=1
++ '[' color '!=' verbose -a -z '' ']'
++ echo_failure
++ '[' color = color ']'
++ echo -en '\033[60G'
                                                           ++ echo -n '['
[++ '[' color = color ']'
++ echo -en '\033[0;31m'
++ echo -n FAILED
FAILED++ '[' color = color ']'
++ echo -en '\033[0;39m'
++ echo -n ']'
]++ echo -ne '\r'
++ return 1
++ '[' -x /bin/plymouth ']'
++ /bin/plymouth --details
++ return 1
++ rc=1
++ echo

++ return 1
++ exit 1


[root@frank01 ~]# pgrep -l exim
[root@frank01 ~]# cat /var/run/exim.pid
2129
[root@frank01 ~]# 

service exim restart
Restarting exim (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                           [FAILED]

Please provide tail of your /var/log/messages after the failure, i.e.:
# tail -n 50 /var/log/messages

and:

# ls /etc/pki/tls/certs/exim.pem

A friend dropped over yesterday got it working.

He said when I changed a permission on /var/log,
I changed it for all logs, not just the one aimed for.


Apologies for any noise.


systemctl status exim.service
exim.service - SYSV: Exim is a Mail Transport Agent, which is the program that moves mail from one machine to another.
	  Loaded: loaded (/etc/rc.d/init.d/exim)
	  Active: active (running) since Thu, 12 Apr 2012 08:16:34 +0100; 13min ago
	 Process: 1265 ExecStart=/etc/rc.d/init.d/exim start (code=exited, status=0/SUCCESS)
	Main PID: 1273 (exim)
	  CGroup: name=systemd:/system/exim.service
		  └ 1273 /usr/sbin/exim -bd -q1h

Thanks for info, closing.

Hm, in the past this would have caused Exim to attempt to write to its panic log, wouldn't it? And spew to stderr when that failed?

I'm fairly sure I've made similar mistakes myself, and it's been immediately obvious when I attempt to restart exim.

If error handling is no longer working properly, that *is* an issue we should care about.

Did this change with the move to systemd? If so, is there something wrong in our Exim package, or is it a problem that needs to be fixed in systemd?

(In reply to comment #8)
Hi David, F16 still uses the original sysv initscript, so there shouldn't be the problem. I think the following happened: It tried to open /var/log/exim/main.log at first. It failed due to wrong permissions, thus it tried to write this to panic log /var/log/exim/panic.log. This probably also failed, because the whole dir had wrong permission, so it fall-backs to syslog and sent this message about failure to syslog. There is a rule in /etc/rsyslog.conf that directs mail messages to /var/log/maillog, so my reproducer:

# chmod a-w -R /var/log/exim
# systemctl start exim.service
# tail -n 1 /var/log/maillog
Apr  12 13:41:08 localhost exim[1543]: exim: could not open panic log - aborting: see message(s) above

The same result after starting with:
# exim -bd

Thus it is a bit hidden, but so far we cannot blame the systemd.

AFAIK if there are stderr messages during the startup they are by default directed by systemd to syslog. This can be overridden in /etc/systemd or AFAIK there are kernel command line boot parameters for this.

Maybe we could simplify this and drop the /var/log/exim and log all to /var/log/maillog through syslog (as other MTAs already do), but this is only proposal.

Maybe I also got the source of problem for bug 782827 (commenting there).

Well, commenting here, because the symptoms of bug 782827 seems a bit different.

The source of wrong /var/run/exim.pid problem:
If exim is run from console by hand, (e.g. 'exim -bd'), the /var/run/exim.pid got wrong SELinux label. If the daemon is later killed, the pid file remains there. Later if started by systemd the daemon doesn't have permission to relabel/recreate the file, thus it fails.

Reproducer:
# exim -bd
# pkill exim
# restorecon -nv /var/run/exim.pid

We could easily override this by simple hack in initscript/unit file (i.e. restorecon call). Or this could be overrided in systemd.

Michal, could there be implemented workaround in systemd for problem described in comment 11 (i.e. removal or restorecon on explicitly specified pid file before the main process is launched)? I think it could be beneficial for other packages as well.