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@23:17:~$ sudo /etc/init.d/exim4 stop
[ ok ] Stopping exim4 (via systemctl): exim4.service.
sonata@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
