Menu
▾
▴
fetchmail-users
|
From: Chris <cpo...@em...> - 2017-02-12 14:56:16
Attachments:
signature.asc
|
This is a logrotate configuration file that I modified from what
Matthias had put out about 10yrs ago. I modified it to fit my needs:
/home/chris/fetchmaillog {
weekly
rotate 8
compress
dateext
missingok
notifempty
create 0664 chris chris
sharedscripts
postrotate
/usr/local/bin/fetchmail --quit
/usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile
/home/chris/fetchmaillog --uidl -m procmail
endscript
}
This is the command to execute the rotation Sunday mornings at 8am. For
some reason without the -f it will tell me the log doesn't need
rotation.
/usr/sbin/logrotate -f -v --state=/home/chris/logrotate/status
/home/chris/logrotate/fetchmail.logrotate
It ran fine on 5 Feb:
reading config file /home/chris/logrotate/fetchmail.logrotate
Handling 1 logs
rotating pattern: /home/chris/fetchmaillog forced from command line (8
rotations)
empty log files are not rotated, old logs are removed
considering log /home/chris/fetchmaillog
log needs rotating
rotating log /home/chris/fetchmaillog, log->rotateCount is 8
dateext suffix '-20170205'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /home/chris/fetchmaillog to /home/chris/fetchmaillog-20170205
creating new /home/chris/fetchmaillog mode = 0664 uid = 1000 gid = 1000
running postrotate script
fetchmail: background fetchmail at 1700 killed.
compressing log with: /bin/gzip
Although to be honest I can't recall if it was restarted or not. That's
why I have it running at 8am when I can observe. When logrotate was run
this morning however:
reading config file /home/chris/logrotate/fetchmail.logrotate
Handling 1 logs
rotating pattern: /home/chris/fetchmaillog forced from command line (8
rotations)
empty log files are not rotated, old logs are removed
considering log /home/chris/fetchmaillog
log needs rotating
rotating log /home/chris/fetchmaillog, log->rotateCount is 8
dateext suffix '-20170212'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /home/chris/fetchmaillog to /home/chris/fetchmaillog-20170212
creating new /home/chris/fetchmaillog mode = 0664 uid = 1000 gid = 1000
running postrotate script
fetchmail: background fetchmail at 3786 killed.
fetchmail: can't accept options while a background fetchmail is
running.
argc = 9, arg list:
arg 1 = "-v"
arg 2 = "--nokeep"
arg 3 = "--nosyslog"
arg 4 = "--logfile"
arg 5 = "/home/chris/fetchmaillog"
arg 6 = "--uidl"
arg 7 = "-m"
arg 8 = "procmail"
error: error running shared postrotate script for
'/home/chris/fetchmaillog '
I don't understand why it worked the first time but not the 2nd as
nothing was changed in between.
Apologies Matthias when I said yesterday it was working.
Chris
--
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:40:34 up 9 days, 38 min, 2 users, load average: 0.61, 0.44, 0.34
Ubuntu 16.04.1 LTS, kernel 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18
14:10:15 UTC 2017 |
|
From: Matthias A. <mat...@gm...> - 2017-02-12 15:25:56
|
Am 12.02.2017 um 15:56 schrieb Chris: > postrotate > /usr/local/bin/fetchmail --quit > /usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile > /home/chris/fetchmaillog --uidl -m procmail > endscript > [...] > running postrotate script > fetchmail: background fetchmail at 3786 killed. > fetchmail: can't accept options while a background fetchmail is > running. > I don't understand why it worked the first time but not the 2nd as > nothing was changed in between. Hi Chris, Looks like a race between the three instances of fetchmail involved: 1. you have 3786 2. postrotate starts fetchmail -q, which just signals 3786 to exit, but does not wait for its exit (because it's not its child that wouldn't be 100% safe anyhow) 3. postrotate immediately starts a new fetchmail, which stumbles over the still existing instance that's still cleaning up. It'd probably be good to wait until the prior instance has really quit before starting the next one, like so (adjust the pid file's path): /usr/local/bin/fetchmail --quit while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done /usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile /home/chris/fetchmaillog --uidl -m procmail and possibly adding a counter so it does not wait too long or otherwise use SIGKILL to get rid of the old instance. Neither will be 100% bullet-proof unless you defer to a service supervisor such as runit, upstart, systemd, or thereabouts, and just request a fetchmail restart from such a supervisor in your postrotate script. HTH Matthias |
|
From: Chris <cpo...@em...> - 2017-02-12 17:04:04
Attachments:
signature.asc
|
On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote: > Am 12.02.2017 um 15:56 schrieb Chris: > > > > postrotate > > /usr/local/bin/fetchmail --quit > > /usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile > > /home/chris/fetchmaillog --uidl -m procmail > > endscript > > [...] > > running postrotate script > > fetchmail: background fetchmail at 3786 killed. > > fetchmail: can't accept options while a background fetchmail is > > running. > > > > > I don't understand why it worked the first time but not the 2nd as > > nothing was changed in between. > > Hi Chris, > > Looks like a race between the three instances of fetchmail involved: > > 1. you have 3786 > 2. postrotate starts fetchmail -q, which just signals 3786 to exit, > but > does not wait for its exit (because it's not its child that wouldn't > be > 100% safe anyhow) > 3. postrotate immediately starts a new fetchmail, which stumbles over > the still existing instance that's still cleaning up. > > It'd probably be good to wait until the prior instance has really > quit > before starting the next one, like so (adjust the pid file's path): > > /usr/local/bin/fetchmail --quit > > while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done > > /usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile > /home/chris/fetchmaillog --uidl -m procmail > > > and possibly adding a counter so it does not wait too long or > otherwise > use SIGKILL to get rid of the old instance. > > Neither will be 100% bullet-proof unless you defer to a service > supervisor such as runit, upstart, systemd, or thereabouts, and just > request a fetchmail restart from such a supervisor in your postrotate > script. > > HTH > Matthias > Thanks Matthias, I'm sure it will. I'll make the changes and give it some test runs until I get it right. Appreciate the assistance. Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 11:01:44 up 9 days, 2:59, 2 users, load average: 0.22, 0.16, 0.10 Ubuntu 16.04.1 LTS, kernel 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 |
|
From: Chris <cpo...@em...> - 2017-02-16 13:45:29
Attachments:
signature.asc
|
On Sun, 2017-02-12 at 11:03 -0600, Chris wrote: > On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote: > > > > Am 12.02.2017 um 15:56 schrieb Chris: > > > > > > > > > postrotate > > > /usr/local/bin/fetchmail --quit > > > /usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile > > > /home/chris/fetchmaillog --uidl -m procmail > > > endscript > > > [...] > > > running postrotate script > > > fetchmail: background fetchmail at 3786 killed. > > > fetchmail: can't accept options while a background fetchmail is > > > running. > > > > > > > > > > > I don't understand why it worked the first time but not the 2nd > > > as > > > nothing was changed in between. > > > > Hi Chris, > > > > Looks like a race between the three instances of fetchmail > > involved: > > > > 1. you have 3786 > > 2. postrotate starts fetchmail -q, which just signals 3786 to exit, > > but > > does not wait for its exit (because it's not its child that > > wouldn't > > be > > 100% safe anyhow) > > 3. postrotate immediately starts a new fetchmail, which stumbles > > over > > the still existing instance that's still cleaning up. > > > > It'd probably be good to wait until the prior instance has really > > quit > > before starting the next one, like so (adjust the pid file's path): > > > > /usr/local/bin/fetchmail --quit > > > > while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done > > > > /usr/local/bin/fetchmail -v --nokeep --nosyslog --logfile > > /home/chris/fetchmaillog --uidl -m procmail > > > > > > and possibly adding a counter so it does not wait too long or > > otherwise > > use SIGKILL to get rid of the old instance. > > > > Neither will be 100% bullet-proof unless you defer to a service > > supervisor such as runit, upstart, systemd, or thereabouts, and > > just > > request a fetchmail restart from such a supervisor in your > > postrotate > > script. > > > > HTH > > Matthias > > > Thanks Matthias, I'm sure it will. I'll make the changes and give it > some test runs until I get it right. Appreciate the assistance. > Adding that one line to the script got it to run perfectly Matthias, thanks so much for the help Chris -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 07:43:27 up 12 days, 23:41, 2 users, load average: 2.88, 1.87, 1.11 Description: Ubuntu 16.04.2 LTS, kernel 4.4.0-62-generic |
|
From: Matthias A. <mat...@gm...> - 2017-02-16 21:35:26
|
Am 16.02.2017 um 14:45 schrieb Chris: >> On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote: >>> while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done > Adding that one line to the script got it to run perfectly Matthias, > thanks so much for the help Hi Chris, good to know that, but you need to keep an eye on it if you're using it as is. If the previous fetchmail instance *crashed* and left the fetchmail.pid file behind, this loop will wait forever without starting fetchmail anew. Cheers, Matthias |
|
From: Chris <cpo...@em...> - 2017-02-16 22:24:13
Attachments:
signature.asc
|
On Thu, 2017-02-16 at 22:35 +0100, Matthias Andree wrote: > Am 16.02.2017 um 14:45 schrieb Chris: > > > > > > > > On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote: > > > > > > > > while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done > > Adding that one line to the script got it to run perfectly > > Matthias, > > thanks so much for the help > > Hi Chris, > > good to know that, but you need to keep an eye on it if you're using > it > as is. > If the previous fetchmail instance *crashed* and left the > fetchmail.pid > file behind, this loop will wait forever without starting fetchmail > anew. > > Cheers, > Matthias > Ah, good to know Matthias, the cronjob runs at midnight but I check in the morning to make sure the new log is being written to. -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 16:21:08 up 13 days, 8:19, 2 users, load average: 1.04, 0.81, 0.80 Description: Ubuntu 16.04.2 LTS, kernel 4.4.0-62-generic |
|
From: Peter P. <ro...@ri...> - 2017-02-17 01:45:20
Attachments:
signature.asc
|
On Thu, Feb 16, 2017 at 10:35:12PM +0100, Matthias Andree wrote: > Am 16.02.2017 um 14:45 schrieb Chris: > >> On Sun, 2017-02-12 at 16:25 +0100, Matthias Andree wrote: > >>> while [ -e /path/to/fetchmail.pid ] ; do sleep 1 ; done > > Adding that one line to the script got it to run perfectly Matthias, > > thanks so much for the help > > Hi Chris, > > good to know that, but you need to keep an eye on it if you're using it > as is. > If the previous fetchmail instance *crashed* and left the fetchmail.pid > file behind, this loop will wait forever without starting fetchmail anew. So this looks more and more like I should brush up my stalepid tool from years ago and let people actually know about it, doesn't it... Chris, could you take a look at https://devel.ringlet.net/sysutils/stalepid/ and see if this utility will help you? Something like: stalepid /path/to/fetchmail.pid fetchmail ...should be able to do the trick; afterwards, if fetchmail.pid no longer exists, this means that it was stale. Of course, if stalepid fails to work for you for some reason, please do not hesitate to let me know! G'luck, Peter -- Peter Pentchev ro...@ri... ro...@Fr... pp...@st... PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 |
Thanks for helping keep SourceForge clean.
X