On Tue, Feb 3, 2015 at 6:16 PM, Reco <recovery...@gmail.com> wrote:
>
> On Tue, Feb 03, 2015 at 05:31:26PM +0000, Michael Grant wrote:
> > On Tue, Feb 3, 2015 at 4:04 PM, Reco <recovery...@gmail.com> wrote:
> ...
> >
> >     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.
>
> An expected result, sadly (see below).
>
>
> > 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
>
> No, it doesn't have anything with it.
>
> Systemd uses it's own way to define a service called a 'service unit'.
> Presumably, systemd has something for the compatibility with old init
> (aka sysvinit), which *should* start those /etc/init.d/ scripts just as
> good as if sysvinit itself would do it. Well, now we see how well it
> works in the reality :)
>
>
> Ok, let's try something different then - based on [1]. Try creating the
> file called /etc/systemd/system/sendmail.service with the following
> contents:
>
> ###cut###
>
> [Unit]
> Description=Sendmail Mail Transport Agent
> After=syslog.target network.target
> Conflicts=postfix.service exim.service
>
> [Service]
> Type=forking
> PIDFile=/run/sendmail.pid
> Environment=SENDMAIL_OPTS=-q1h
> EnvironmentFile=-/etc/default/sendmail
> ExecStartPre=-/etc/mail/make
> ExecStartPre=-/etc/mail/make aliases
> ExecStart=/usr/sbin/sendmail -bd $SENDMAIL_OPTS $SENDMAIL_OPTARG
>
> [Install]
> WantedBy=multi-user.target
>
> ###cut###
>
>
> Revert the _SYSTEMCTL_SKIP_REDIRECT change, see how it goes now.
> This unit file may require tweaking in $SENDMAIL_OPTS $SENDMAIL_OPTARG
> part - I'm unable to check now what kind of variables are sourced by
> /etc/default/sendmail.
>
> Ok, I tried creating that file and removing the line from
/etc/default/sendmail.  It still did not come up when the machine booted.

>
>
> > Incidentally, the sendmail package even in experimental is significantly
> out of date. The package appears orphaned. Several people seem to have
> tried to step
> > up to do something about this but nothing has happened. Is sendmail dead
> on Debian?
>
> Unknown to me. Truth to be told, personally I try to avoid using
> sendmail whenever possible. Sendmail.cf's syntax is way too arcane to me.
> Still, I can't stand a broken Debian package more than a certain MTA :)


I've used sendmail since the '80s.  It's difficult find a more stable  and
well tested mailer.  Almost impossible to get it to drop a message to
/dev/null unlike some other mailers out there.  I used to write my own cf
files back in the day but you really don't have to mess with that now.  The
m4 syntax is a bit ugly but usable and now it's just a configuration file.

Reply via email to