On 24 Dec 2015, at 14:26, David Becher <[email protected]> wrote: > > Hey! > > I was just wondering what would be the best way to debug a plugin I am > currently writing for dovecot. > The plugin basically registers a new IMAP capability and I want to set a > breakpoint to the "cmd_handle_new_capability" function (thats just a function > name for better explaining purposes). > > Right now I have opened a connection via openssl ('openssl s_client -connect > example:143 -starttls imap') to be able to mess around with the my server. > Then I am able to login into the server via 'a login "username" "password"' > and feed the server with my self created IMAP capability command. > > I know that I can start gdb and attach to an already running process via its > PID. But how do I know which process I have to attach to? Looking at the > output of 'top' it seems to be an instance of the 'imap' command > > PID USER PR NI VIRT RES SHR S > %CPU %MEM TIME+ COMMAND > 13413 vmail 20 0 21004 1844 1524 S 0.0 > 0.0 0:00.00 Iman > > But its only started the exact moment I issue my IMAP command towards the > server, so of course I am not fast enough to track down the PID before the > function has returned, so the process handling the command seems to be up > only for the short period of time to handle the command, there is no process > before which I can attach to. > > My current workaround is that I put a tail onto /var/log/mail.log and from > within my shared library function (cmd_handle_new_capability) I log the PID > of the current process, then sleep(10) for 10 seconds, which gives me enough > time to have a look at mail.log to get to know the PID which I then can > attach to. But isn't there a better way to do this? Maybe attach to the > process which originally creates the new process handling the IMAP command > and then stepping into it?
If you need to actually login the normal way, that's pretty much the only way. Otherwise you could just run: gdb --args /usr/libexec/dovecot/imap -u user@domain
