I had a issue with exim4. I asked a number of question of the exim4 mailing list, several of which ended up being related to debugging, which I'd already tried . The upshot was all the clever debugging options they suggested and ones I made up, did not work.
Many resulted in no debug, one ...killing exim and starting by hand with debug options on the command line produced a little debug then stopped (it looked as if it had forked of a child to do the and child was not talking debug, or maybe had stderr pointing elsewhere).
Anyhow their advice was "ask on the Debian forum!" , so here I am:
So it's a question of packaging, processes are kicked off by systemd (cron?) etc. They have defaults in /etc/defaults and of course the Debian script update-exim4.conf(8) . So ...
What is a good/typical debug workflow for exim4 ?
Now I have a very small system and can afford to just stop the exim service and have debug in the real files but I guess in terms of an answer it would be good to consider also a big (production?) system.
If it helps with a "use case" what I was trying to debug (for several days, but now in the past) was. I was getting failures back from smarterhost (bad email addresses somewhere) but it was not clear what "line" they were objecting to. It became evident the mails in question had gone via a users ~/.forward...so I could not be sure what was in the data sent. So I did not know what the issue was (from smarthost) and I did not know what I had sent. Ideally what I would have like to have seen was the dialogue between the two mail systems (e.g SMTP traffic)
Many resulted in no debug, one ...killing exim and starting by hand with debug options on the command line produced a little debug then stopped (it looked as if it had forked of a child to do the and child was not talking debug, or maybe had stderr pointing elsewhere).
Anyhow their advice was "ask on the Debian forum!" , so here I am:
So it's a question of packaging, processes are kicked off by systemd (cron?) etc. They have defaults in /etc/defaults and of course the Debian script update-exim4.conf(8) . So ...
What is a good/typical debug workflow for exim4 ?
Now I have a very small system and can afford to just stop the exim service and have debug in the real files but I guess in terms of an answer it would be good to consider also a big (production?) system.
If it helps with a "use case" what I was trying to debug (for several days, but now in the past) was. I was getting failures back from smarterhost (bad email addresses somewhere) but it was not clear what "line" they were objecting to. It became evident the mails in question had gone via a users ~/.forward...so I could not be sure what was in the data sent. So I did not know what the issue was (from smarthost) and I did not know what I had sent. Ideally what I would have like to have seen was the dialogue between the two mail systems (e.g SMTP traffic)
Statistics: Posted by graemev2 — 2024-03-05 01:09 — Replies 1 — Views 46