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.