Bug#810938: exim4-daemon-light: Cannot assign requested address: daemon abandoned at each startup

[Manuel Bilderbeek]

On 16-01-16 14:36, Marc Haber wrote:
>> /etc/networks has:
>> loopback        127.0.0.0
>>
>> Not sure how to check this in detail, I never had to do this in 15
>> years of using Debian.
>
> You have never used ifconfig or ip addr show to see which IP addresse
> you have configured?

Ah, is that what you're asking...

lo: flags=8<LOOPBACK>  mtu 65536
         inet 127.0.0.1  netmask 255.0.0.0
         loop  txqueuelen 0  (Local Loopback)
         RX packets 4  bytes 240 (240.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 4  bytes 240 (240.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


>> sonata at 23:17:~$ sudo /etc/init.d/exim4 stop
>> [ ok ] Stopping exim4 (via systemctl): exim4.service.
>> sonata at 23:17:~$ sudo netstat -napt | grep :25
>> tcp        0      0 127.0.0.1:25            0.0.0.0:* LISTEN
>> 8769/exim4
>>
>> Although I stop it, it's still running...?
>
> On a system with systemd as PID 1 you should not call init scripts
> directly, but use systemctl instead.

It's doing that for me, isn't it? (I'm still used to sysv.)

> Actually, you shouldn't run init scripts directly even on a sysvinit
> system, you should use service(1) to do that.

OK, see above.

> The Debian exim4 packages do not use systemd yet, they still use
> traditional sysv init scripts.

So, why does it keep running then when I try to stop it?

>> Is it possible this has to do with the automatic removal of
>> 'ifupdown'? It started when installing/upgrading several packages as
>> listed in my original report.
>
> Probably not, you're the only one with that issue.

Well, that's all what I changed. It was running fine before that and I 
didn't change anything at all.

>>> For basic Unix administration skills, you might want to refer to the
>>> relevant -user mailing lists.
>>
>> Do you really think that's a helpful remark?
>
> Yes. This is with utmost certainty not a bug in exim. By asking your
> questions in a bug report against exim and thus only to the exim4
> maintainers, you're depraving yourself of 99.9% of people who would
> be able and willing to help.

I'm not asking questions to acquire Unix administration skills, I'm 
asking questions to be sure to run the tests that help you to help me to 
determine what is going wrong with exim here.

Besides that I'm the only one who reported this, what makes you so sure 
it's not a bug in exim or the way it is setup in Debian?

If it isn't a bug in Debian, I'd expect you as an expert on exim, to 
know what to look into, so what could cause the package you're 
maintaining to behave like this.

I'm just a Debian desktop user, following testing and trying to help by 
reporting issues I see.

-- 
Kind regards,

Manuel