Re: sendmail on debian testing

[Ansgar Burchardt <ansgar@debian.org>]

Hi,

Michael Grant <mgrant@grant.org> writes:
> On Tue, Feb 3, 2015 at 4:04 PM, Reco <recoverym4n@gmail.com> wrote:
>> A nessesary correction - /etc/init.d/sendmail *tries* to run
>> '/bin/systemctl start sendmail.service'.
>>
>> But, since no sendmail* package provide systemd's service file -
>> nothing happens.

Not true. Systemd is supposed to handle sysvinit scripts as well,
i.e. when there is no native .service file for systemd it will run the
scripts in /etc/init.d/*. This seems to not work here for some reason.

>> Try adding
>> export _SYSTEMCTL_SKIP_REDIRECT="true"
>> to /etc/init.d/sendmail
>
> Thanks, this is progress, I can now start sendmail by hand by running
> '/etc/init.d/sendmail start', but it's not starting automatically at boot
> time.
>
> I don't know if this has anything to do with that:
>
> # systemctl enable sendmail
> Synchronizing state for sendmail.service with sysvinit using update-rc.d...
> Executing /usr/sbin/update-rc.d sendmail defaults
> Executing /usr/sbin/update-rc.d sendmail enable
>
> # systemctl is-enabled sendmail
> Failed to get unit file state for sendmail.service: No such file or
> directory

That should be fine for services without a systemd .service file.

> also, a better place to add this:
>
> export _SYSTEMCTL_SKIP_REDIRECT="true"
>
> to is /etc/default/sendmail and not modify /etc/init.d/sendmail.  Adding
> this to /etc/default/sendmail seems to work equally as well in that running
> '/etc/init.d/sendmail start' does manually start sendmail.

That is no surprise: at boot it's still systemd calling
/etc/init.d/sendmail so workarounds to bypass systemd don't work.

Could you try restarting sendmail (systemctl restart sendmail) and show
the output of `systemctl status sendmail'? It also shows the most recent
log entries, but the output of journalctl --unit sendmail --since -5min
might also be useful (if it shows more messages).

I tried installing sendmail on a minimal test installation and systemd
started at least one daemon ("sendmail: MTA: accepting connections"),
so at least something gets started (though it complained about the test
installation not having a FQDN so other parts might be broken and not
have started).

Ansgar