The task. A receiver behaves strangely, and you need to see what it actually replies — without editing the configuration, without logging into the node with a shell and without leaving traces.
What it is made of:
The parts have different scopes. All three are node commands and an endpoint of the management interface the Hub already works with; the configuration file is not touched, and there is nothing to roll back.
How they interact. The manual calls trace –to-log a shortcut for the procedure “enable recording in the configuration, reload, schedule an attempt and revert everything”. Rotating before the attempt limits the file, and the download brings the attempt rather than a day of log. The order is not arbitrary: rotation, attempt, download. For watching a receiver over time, recording in the <domain> block remains.
Three steps:
| Step | Command | What it gives |
|---|---|---|
| rotation | pmta rotate log | a fresh log file |
| attempt | pmta trace –to-log gmail.com/vmta1 | the SMTP conversation in the log |
| download | GET /getFile?file=… | the log file without logging into the node |
# rotation, one attempt logged to the log file, download pmta rotate log pmta trace --to-log --log-resolution gmail.com/vmta1curl -s 'http://127.0.0.1:8080/getFile?file=log.txt' -o log.txt
grep -n 'starting gmail.com' /var/log/pmta/log | tail -3