On Fri, 14 Apr 2017 10:35:42 +1000 Charlie <taoques...@gmail.com> wrote:
> Received this on attempted upgrade: > > systemctl status exim4.service > ● exim4.service - LSB: exim Mail Transport Agent > Loaded: loaded (/etc/init.d/exim4; generated; vendor preset: > enabled) Active: failed (Result: resources) since Fri 2017-04-14 > 10:24:05 AEST; 4min 44s ago > Docs: man:systemd-sysv-generator(8) > Process: 9436 ExecStart=/etc/init.d/exim4 start (code=exited, > status=0/SUCCESS) > > Assume nothing I can do? Something that needs to be done higher up > the scale? > > Can't uninstall or purge exim4 either. > I don't know if it helps, it may be a red herring, but... ..years ago, long before systemd, I had this happen to exim4 during a dist-upgrade of one stable to the next. The exim4 upgrade stuck part of the way through, and would go neither forward nor back nor run, and even dpkg was not able to remove it to reinstall. In the end, I had to manually delete files to get it to the point where I could reinstall from scratch. The reason turned out to be that exim4 needed a version upgrade to one which not only didn't honour debconf statements in the configuration file, but was violently sick on finding them, to the extent of breaking the upgrade. It installed fine with a default config file, and I then transferred my configurations to that. So this just *might* be an incompatible configuration issue, and you just *might* have to rip files out by hand. There was certainly an issue with exim4, which may not have been fixed, which resulted in some kind of deadlock over old and new parts during the upgrade. Exim4 seemed to need to restart part of the way through the upgrade, and couldn't restart with an incompatible config file. I didn't have the means to reproduce the situation and file a useful bug, and in any case, the developer would just have told me I should have read the release notes for the new exim4 and not been so stupid as to try to re-use the old config file. -- Joe
