Fwd: Re: Wiki advice on running getmail on INBOX access - how does that work?
Just re-tried this, and it doesn't seem to fire getmail on access for me.
My incrontab is as follows:
/home/user/Maildir/cur/ IN_ALL_EVENTS,IN_ONESHOT /home/user/bin/mvmail.sh
The incrontab rule does work, but only if I make a physical change in /home/user/Maildir/cur/ e.g. by moving a mail from another folder in there. Just accessing the particular inbox doesn't seem to trigger anything.
On 18/10/14 19:54, c128 mail wrote:
Yeah, I see what you mean - it should trigger by IN_ACCESS (from IN_ALL_EVENTS) shouldn't it. I hadn't previously scanned over the full set of events: http://manpages.ubuntu.com/manpages/intrepid/man5/incrontab.5.html
I'll set this up again and report back one way or another.
Thanks.
On 18/10/14 19:50, Gedalya wrote:
On 10/18/2014 02:38 PM, c128 mail wrote:
What exactly did happen?
Oh, yeah, didn't make that clear ;-)
Nothing happened...not without coaxing.
If I forced a change to the directory, then it worked - but there wouldn't be a change to the directory in normal operation, other than by mail population? It's not supposed to require changes. Note the IN_ALL_EVENTS definition. This would include any attempt to open the directory and take a peek. If you configured it according to the wiki and it's not working then we have troubleshooting to do, but that's the theory. I'm not familiar with incron but I've worked with Linux's inotify.
On 18/10/14 19:28, Gedalya wrote:
On 10/18/2014 01:24 PM, c128 mail wrote:
Hi,
I'm currently running getmail in a cron job every 2 minutes, so I was quite intrigued by this on the wiki:
http://wiki2.dovecot.org/HowTo/TriggerGetmailOnIMAPAccess
Thing is - I couldn't see how it would work and, when I tried it, it didn't work (at least not for me). What exactly did happen?
It details using incrontab to monitor /home/username/.maildir/cur in order to trigger getmail.
However, "cur" won't change unless populated with mail...as an initial result of actually running getmail? Seems like a chicken and egg situation.
access != change
I reckon I'm missing something fundamental :-), but what is it?
Ta.
On 10/18/2014 03:26 PM, c128 mail wrote:
Just re-tried this, and it doesn't seem to fire getmail on access for me.
My incrontab is as follows:
/home/user/Maildir/cur/ IN_ALL_EVENTS,IN_ONESHOT /home/user/bin/mvmail.sh
The incrontab rule does work, but only if I make a physical change in /home/user/Maildir/cur/ e.g. by moving a mail from another folder in there. Just accessing the particular inbox doesn't seem to trigger anything.
In my testing I get 3 events every single time I list the test directory, if I remove the IN_ONESHOT. With IN_ONESHOT, I get only one, for the first time. The script on the wiki ends with: incrontab --reload # Rearm the one-shot rule So that makes sense.
Debian Jessie, Linux 3.16.5-1 amd64, incron 0.5.10-2
On 18/10/14 19:54, c128 mail wrote:
Yeah, I see what you mean - it should trigger by IN_ACCESS (from IN_ALL_EVENTS) shouldn't it. I hadn't previously scanned over the full set of events: http://manpages.ubuntu.com/manpages/intrepid/man5/incrontab.5.html
I'll set this up again and report back one way or another.
Thanks.
On 18/10/14 19:50, Gedalya wrote:
On 10/18/2014 02:38 PM, c128 mail wrote:
What exactly did happen?
Oh, yeah, didn't make that clear ;-)
Nothing happened...not without coaxing.
If I forced a change to the directory, then it worked - but there wouldn't be a change to the directory in normal operation, other than by mail population? It's not supposed to require changes. Note the IN_ALL_EVENTS definition. This would include any attempt to open the directory and take a peek. If you configured it according to the wiki and it's not working then we have troubleshooting to do, but that's the theory. I'm not familiar with incron but I've worked with Linux's inotify.
On 18/10/14 19:28, Gedalya wrote:
On 10/18/2014 01:24 PM, c128 mail wrote:
Hi,
I'm currently running getmail in a cron job every 2 minutes, so I was quite intrigued by this on the wiki:
http://wiki2.dovecot.org/HowTo/TriggerGetmailOnIMAPAccess
Thing is - I couldn't see how it would work and, when I tried it, it didn't work (at least not for me). What exactly did happen?
It details using incrontab to monitor /home/username/.maildir/cur in order to trigger getmail.
However, "cur" won't change unless populated with mail...as an initial result of actually running getmail? Seems like a chicken and egg situation.
access != change
I reckon I'm missing something fundamental :-), but what is it?
Ta.
Thanks for trying that.
I'm running:
Ubuntu 14.04, Linux 3.4.79 #1 SMP PREEMPT Wed May 14 18:19:18 CST 2014 armv7l armv7l armv7l GNU/Linux
incrontab 0.5.10
Just found that if I "ls" that directory, the rule is fired. So - I suspect incrontab is fine.
Is this an oddity of Thunderbird access to the particular mail folder, I wonder, as that's my use case for testing this?
On 18/10/14 20:58, Gedalya wrote:
On 10/18/2014 03:26 PM, c128 mail wrote:
Just re-tried this, and it doesn't seem to fire getmail on access for me.
My incrontab is as follows:
/home/user/Maildir/cur/ IN_ALL_EVENTS,IN_ONESHOT /home/user/bin/mvmail.sh
The incrontab rule does work, but only if I make a physical change in /home/user/Maildir/cur/ e.g. by moving a mail from another folder in there. Just accessing the particular inbox doesn't seem to trigger anything.
In my testing I get 3 events every single time I list the test directory, if I remove the IN_ONESHOT. With IN_ONESHOT, I get only one, for the first time. The script on the wiki ends with: incrontab --reload # Rearm the one-shot rule So that makes sense.
Debian Jessie, Linux 3.16.5-1 amd64, incron 0.5.10-2
On 18/10/14 19:54, c128 mail wrote:
Yeah, I see what you mean - it should trigger by IN_ACCESS (from IN_ALL_EVENTS) shouldn't it. I hadn't previously scanned over the full set of events: http://manpages.ubuntu.com/manpages/intrepid/man5/incrontab.5.html
I'll set this up again and report back one way or another.
Thanks.
On 18/10/14 19:50, Gedalya wrote:
On 10/18/2014 02:38 PM, c128 mail wrote:
What exactly did happen?
Oh, yeah, didn't make that clear ;-)
Nothing happened...not without coaxing.
If I forced a change to the directory, then it worked - but there wouldn't be a change to the directory in normal operation, other than by mail population? It's not supposed to require changes. Note the IN_ALL_EVENTS definition. This would include any attempt to open the directory and take a peek. If you configured it according to the wiki and it's not working then we have troubleshooting to do, but that's the theory. I'm not familiar with incron but I've worked with Linux's inotify.
On 18/10/14 19:28, Gedalya wrote:
On 10/18/2014 01:24 PM, c128 mail wrote: > Hi, > > I'm currently running getmail in a cron job every 2 minutes, so I > was > quite intrigued by this on the wiki: > > http://wiki2.dovecot.org/HowTo/TriggerGetmailOnIMAPAccess > > Thing is - I couldn't see how it would work and, when I tried it, it > didn't work (at least not for me). What exactly did happen?
> > It details using incrontab to monitor /home/username/.maildir/cur in > order to trigger getmail. > > However, "cur" won't change unless populated with mail...as an > initial > result of actually running getmail? Seems like a chicken and egg > situation. access != change
> > I reckon I'm missing something fundamental :-), but what is it? > > Ta.
Bit more investigation...
So - the incrontab rule seems to work to the extent that if I directly "ls" the cur folder on the system then it's triggered.
However, the only way I seem to be able to be able to get it to trigger from a mail client (I use both Thunderbird and Roundcube) is by performing some sort of action on the mail that's already in the folder e.g. shifting mail in/out, marking mail read, reading an existing mail (in Roundcube only, for the last one, which I suspect is related to Thunderbird and local caching?).
Either way, I can't seem to get it to trigger on just access to the folder its monitoring...
On 18/10/14 21:20, c128 mail wrote:
Thanks for trying that.
I'm running:
Ubuntu 14.04, Linux 3.4.79 #1 SMP PREEMPT Wed May 14 18:19:18 CST 2014 armv7l armv7l armv7l GNU/Linux
incrontab 0.5.10
Just found that if I "ls" that directory, the rule is fired. So - I suspect incrontab is fine.
Is this an oddity of Thunderbird access to the particular mail folder, I wonder, as that's my use case for testing this?
On 18/10/14 20:58, Gedalya wrote:
On 10/18/2014 03:26 PM, c128 mail wrote:
Just re-tried this, and it doesn't seem to fire getmail on access for me.
My incrontab is as follows:
/home/user/Maildir/cur/ IN_ALL_EVENTS,IN_ONESHOT /home/user/bin/mvmail.sh
The incrontab rule does work, but only if I make a physical change in /home/user/Maildir/cur/ e.g. by moving a mail from another folder in there. Just accessing the particular inbox doesn't seem to trigger anything.
In my testing I get 3 events every single time I list the test directory, if I remove the IN_ONESHOT. With IN_ONESHOT, I get only one, for the first time. The script on the wiki ends with: incrontab --reload # Rearm the one-shot rule So that makes sense.
Debian Jessie, Linux 3.16.5-1 amd64, incron 0.5.10-2
On 18/10/14 19:54, c128 mail wrote:
Yeah, I see what you mean - it should trigger by IN_ACCESS (from IN_ALL_EVENTS) shouldn't it. I hadn't previously scanned over the full set of events: http://manpages.ubuntu.com/manpages/intrepid/man5/incrontab.5.html
I'll set this up again and report back one way or another.
Thanks.
On 18/10/14 19:50, Gedalya wrote:
> What exactly did happen?
Oh, yeah, didn't make that clear ;-)
Nothing happened...not without coaxing.
If I forced a change to the directory, then it worked - but there wouldn't be a change to the directory in normal operation, other than by mail population? It's not supposed to require changes. Note the IN_ALL_EVENTS definition. This would include any attempt to open the directory and take a peek. If you configured it according to the wiki and it's not working
On 10/18/2014 02:38 PM, c128 mail wrote: then we have troubleshooting to do, but that's the theory. I'm not familiar with incron but I've worked with Linux's inotify.
On 18/10/14 19:28, Gedalya wrote: > On 10/18/2014 01:24 PM, c128 mail wrote: >> Hi, >> >> I'm currently running getmail in a cron job every 2 minutes, so I >> was >> quite intrigued by this on the wiki: >> >> http://wiki2.dovecot.org/HowTo/TriggerGetmailOnIMAPAccess >> >> Thing is - I couldn't see how it would work and, when I tried >> it, it >> didn't work (at least not for me). > What exactly did happen? > >> >> It details using incrontab to monitor >> /home/username/.maildir/cur in >> order to trigger getmail. >> >> However, "cur" won't change unless populated with mail...as an >> initial >> result of actually running getmail? Seems like a chicken and egg >> situation. > access != change > >> >> I reckon I'm missing something fundamental :-), but what is it? >> >> Ta. >
Maybe off-topic, still: (If your remote server is imap,) why not use fetchmail?
Here's a mangled/working /etc/fetchmailrc for an SSL imap account:
poll smtp.provider.net protocol IMAP port 993 user 'somone@somewhere.com' is 'someone' here password 'MyPass123' folder 'INBOX' fetchall idle ssl
mda "HOME=/home/%T /usr/bin/sudo -u %T /usr/lib/dovecot/deliver"
## cf. /etc/sudoers.d/fetchmail-deliver #fetchmail ALL=(ALL) NOPASSWD:/usr/lib/dovecot/deliver
This uses imap idle over there and fetches new mail, as it arrives. Local users will be notified of new mail without looking explicitly…
-- peter
Thanks - not so off-topic at all, just looking for a good solution really to move away from using crontab to pull every 2 minutes.
I'm currently using getmail to pull from about 10 accounts - haven't used fetchmail for quite some time, but that's definitely something to look into.
Semi-related...I know there's also this:
https://github.com/marschap/fetchmail_wakeup
...which does have a getmail script.
I'm sure it's fine, but I'm semi-put off by the fact that it's not a dovecot-distributed plugin, so I wonder how it fares with upgrades etc.
Still kind of wondering whether anyone has the incrontab approach working on a system though...
On 18/10/14 23:32, Peter Chiochetti wrote:
Maybe off-topic, still: (If your remote server is imap,) why not use fetchmail?
Here's a mangled/working /etc/fetchmailrc for an SSL imap account:
poll smtp.provider.net protocol IMAP port 993 user 'somone@somewhere.com' is 'someone' here password 'MyPass123' folder 'INBOX' fetchall idle ssl
mda "HOME=/home/%T /usr/bin/sudo -u %T /usr/lib/dovecot/deliver"
## cf. /etc/sudoers.d/fetchmail-deliver #fetchmail ALL=(ALL) NOPASSWD:/usr/lib/dovecot/deliver
This uses imap idle over there and fetches new mail, as it arrives. Local users will be notified of new mail without looking explicitly…
On 10/18/2014 05:39 PM, c128 mail wrote:
Bit more investigation...
So - the incrontab rule seems to work to the extent that if I directly "ls" the cur folder on the system then it's triggered.
However, the only way I seem to be able to be able to get it to trigger from a mail client (I use both Thunderbird and Roundcube) is by performing some sort of action on the mail that's already in the folder e.g. shifting mail in/out, marking mail read, reading an existing mail (in Roundcube only, for the last one, which I suspect is related to Thunderbird and local caching?).
Either way, I can't seem to get it to trigger on just access to the folder its monitoring...
Looks like the wiki page may be somewhat outdated. Try /home/user/Maildir rather than /home/user/Maildir/cur. It seems dovecot doesn't actually need to open the cur directory if it doesn't seem to have changed since indexes were last updated ... or something like that. As for Thunderbird, my guess is the problem is that it keeps connections already open. I guess it doesn't need to actually re-open things when you click "Get Messages", dovecot uses mmap alot. I've been able to get the events to trigger for /Maildir only when a new connection is opened. It should work for roundcube but perhaps not if you use imapproxy.
Switched to using /home/user/Maildir and, yes, I think you're totally right.
With the changed location:
Roundcube seems to work as it generates much more traffic with Dovecot - lots of opening and closing of connections and (when re-armed) the incrontab rule is triggered as you would expect it to be.
Thunderbird doesn't work - much less traffic. You can get it fire the command with the ways detailed earlier (manipulating the folder in some way from the client), or just opening and closing the application, but no from "Get Messages" or entering the inbox.
Considering the https://github.com/marschap/fetchmail_wakeup approach (with its getmail script) - dunno whether that would be any better in this respect though?
On 19/10/14 11:25, Gedalya wrote:
On 10/18/2014 05:39 PM, c128 mail wrote:
Bit more investigation...
So - the incrontab rule seems to work to the extent that if I directly "ls" the cur folder on the system then it's triggered.
However, the only way I seem to be able to be able to get it to trigger from a mail client (I use both Thunderbird and Roundcube) is by performing some sort of action on the mail that's already in the folder e.g. shifting mail in/out, marking mail read, reading an existing mail (in Roundcube only, for the last one, which I suspect is related to Thunderbird and local caching?).
Either way, I can't seem to get it to trigger on just access to the folder its monitoring...
Looks like the wiki page may be somewhat outdated. Try /home/user/Maildir rather than /home/user/Maildir/cur. It seems dovecot doesn't actually need to open the cur directory if it doesn't seem to have changed since indexes were last updated ... or something like that. As for Thunderbird, my guess is the problem is that it keeps connections already open. I guess it doesn't need to actually re-open things when you click "Get Messages", dovecot uses mmap alot. I've been able to get the events to trigger for /Maildir only when a new connection is opened. It should work for roundcube but perhaps not if you use imapproxy.
participants (3)
-
c128 mail
-
Gedalya
-
Peter Chiochetti