Sheldon Hearn wrote:
> On (2003/11/27 19:00), Bill Hacker wrote:
>
>
>> W/R exim.sh & rc.subr interaction: (Dunno who maintains
>> rc.subr....)
>>
>> The postcmd line:
>>
>> rm -f $pidfile
>
>
> Someone mentioned off-list that you put exim.sh in /etc/rc.d/
> yourself?
>
> Is this true?
>
I think I have said that on-list at least twice, and yes, but that is
irrelevant. Some of us greying old farts (M33, AN/FSQ-7, AN/GSA-51 and
most everything since..) are slow to change <G>
> If so, it changes the way I view the problems you're having. My job
> is to make the port work when used as intended, and I take that
> quite seriously. If you want to poke around with the way it works,
> you're more than welcome to do so, but then don't feel I have to
> worry so much when it breaks for you.
>
That particular change has FA to do with the problem.
The problem was twofold:
1) The port expects a pre-existing sendmail installation (enabled or
NOT) - with the relevant directory structures and files, to wit:
/etc/mail/<mailer.conf and so on>
These did not exist on my box.
After reinstalling sendmail, then disabling it, Exim installed correctly.
2) For reasons still not clear, on the first go 'round, 'rc.subr' was
not installed *anywhere*.
I have no reason to believe that [2] was related to [1] above.
>
>> This gives a (harmless) error message on start, works fine on stop,
>> and insures that abnormal termination cannot leave a pid file
>> behind - which event screws the pooch on a postgresql start, just
>> to name one.
>
>
> I wish I knew exactly what you were doing from start to finish.
Well....
...as root:wheel the command "/<wherever>/exim.sh stop" succeeds in
terminating exim, but throws an error .."check the pid file"
...and leaves the file /var/run/exim.pid in place.
Same if called as "sh /<wherever>/exim.sh stop" (I am usually in bash)
Possible reasons:
When exim.sh (whether it lies in /etc.rc.d or in /etc/local/rc.d) is
invoked at boot time, it is root's alter-ego, 'toor' with the same
privileges, that makes the call. Not a lot different if the call is
made manually by a wheel user su'ed to root.
- If /var/run/exim.pid is created at that time, as I believe it is, then
/var/run/exim.pid will be owned by root:wheel. It *is*, anyway, per ls -lF.
- If then exim has first grabbed the reserved mail ports as root (which
I believe it must) and has then su'ed to another UID:GID to run
(exim:mail in my case) and is still in that identity when postcmd tries
to rm /var/run/exim.pid, it will not be permitted to do so, as
root:wheel owns the file and we have neither chowned nor chmoded it to
something exim:mail is allowed to delete.
- Mind that the as-issued exim.sh *does* stop exim - it just fails to
accomplish the postcmd step of removing /var/run/exim.pid
My "BFBI" patch set an unconditional "rm /var/run/exim.pid" at a point
in exim.sh where I *believe* the UID:GID of the caller is still
effective - whether starting or stopping. This *does* result in removal
of /var/run/exm.pid w/o error messages on issuance of a 'stop'.
- This *also* reports an error when a start' is issued, as rm can't find
any such file as /var/run/exim.pid. IMNSHO, *this* error is harmless,
though there should be a better way, such as 'touching' the fiel,
chowning and chmoding it...etc.
OTOH, IMNSHO, leaving an obsolete pid file around is NOT ALWAYS
harmless. At least one package, to wit PostgreSQL, can refuse to start
as the presence of a pid file makes it *think* it is already running...
(These *are* rare, but can happen, and *have* if somebody trips over a
power cord...)
HTH to explain that A) We are past the build and install problems, and
enroute to cleaning up unexpected post-install behaviour... >
> Installing the latest version of the port on 4.9-RELEASE should
> install rc_subr support and put exim.sh in /usr/local/etc/rc.d.
ACK. It does so once the sendmail environment was first restored.
> Provided you don't hand-roll anything that tries to start Exim in
> /etc/rc.d,
Irrelevant.
this > should all "just work" once you've made these changes in
> /etc/rc.conf:
>
> sendmail_enable="NONE" daily_status_include_submit_mailq="NO"
> daily_clean_hoststat_enable="NO"
> Mmmmh... First is a given, thought the others were covered in a patch
applied to /etc/periodic... ?
> I've just tested this again on a 4.9-RELEASE box and it works as
> expected.
As it does here, so long as a valid sendmail install is treated as a
prerequisite <G>
>
> Ciao, Sheldon.
>
- But the as-issued '...exim.sh stop', whether invoked from
/usr/local.etc/rc.d or the dark side of the moon, does not
remove /var/run/exim.pid on my 4.9 box!
Please have a look at that file and its perms right after starting exim,
and again after a stop.
If yours is gone after the stop, where mine was not, then the port is
OK, and I will happily go off and do a cvsup and make build world cycle.
