fetchmail-users — User questions and discussion

Re: [Fetchmail-users] time stamp format in log

[joea- l. <joe...@j4...>]

> On Sat, Jan 29, 2022 at 11:17:51AM -0500, joea- lists wrote:
>> 
>> > Am 28.01.22 um 21:43
>> > joea‑ lists:
>> >> I'd prefer to see time stamps in the fetchmail log in 24 hr
format,
>> but I 
>> > see this:
>> >>
>> >> fetchmail: 6.4.21 querying imap.AAAA.com (protocol IMAP) at Fri
28
>> Jan 2022 
>> > 03:35:22 PM EST: poll completed
>> >> fetchmail: sleeping at Fri 28 Jan 2022 03:35:22 PM EST for 120
>> seconds
>> >>
>> >> Did not find a time format in man pages or via searching the
wilds.
>> >>
>> >> It is probably right under my nose.  Or will be once someone
tells
>> me how.
>> > 
>> > Yes, it is a system standard feature that people appear to be
>> oblivious
>> > of, so is not documented in fetchmail. See:
>> > 
>> >
https://wiki.archlinux.org/title/Locale#LC_TIME:_date_and_time_format

>> <‑
>> > grarpamp watch this
>> > 
>> > locale(7) manual page.
>> > 
>> 
>> No change.  Perhaps there is a "local" setting for fetchmail? 
Seems
>> there
>> should be but if there is, it has escaped my efforts to find it. 
Easy
>> to do
>> it seems. 
>> 
>> Other logs and terminal display all show 24hr format.with no
>> alterations
>> to environment settings.
>> 
>> I tried changing /etc/locale.conf and think I caused
>> it to take effect (via "localectl"), and restarted fetchmail, but
no
>> change.
> 
> If you run fetchmail using a systemd service file, try adding
> something like:
> 
>   Environment=LC_TIME=....
> 
> ...specifying the name of the locale you want fetchmail to use.
> Then restart the fetchmail systemd service.
> 
> If this doesn't work, try using LC_ALL instead of LC_TIME, or
> trying to figure out whether anything else sets an LC_ALL
> environment variable to override your LC_TIME setting.
> 
> G'luck,
> Peter
> 

Thanks, "Environment=LC_TIME=en_GB.UTF-8"  appears to have worked.  

I even searched for more data on systemd "Unit file" options and did
not see that.

joe a.

Re: [Fetchmail-users] time stamp format in log

[Peter P. <ro...@ri...>]

On Sat, Jan 29, 2022 at 11:17:51AM -0500, joea- lists wrote:
> 
> > Am 28.01.22 um 21:43
> > joea‑ lists:
> >> I'd prefer to see time stamps in the fetchmail log in 24 hr format,
> but I 
> > see this:
> >>
> >> fetchmail: 6.4.21 querying imap.AAAA.com (protocol IMAP) at Fri 28
> Jan 2022 
> > 03:35:22 PM EST: poll completed
> >> fetchmail: sleeping at Fri 28 Jan 2022 03:35:22 PM EST for 120
> seconds
> >>
> >> Did not find a time format in man pages or via searching the wilds.
> >>
> >> It is probably right under my nose.  Or will be once someone tells
> me how.
> > 
> > Yes, it is a system standard feature that people appear to be
> oblivious
> > of, so is not documented in fetchmail. See:
> > 
> > https://wiki.archlinux.org/title/Locale#LC_TIME:_date_and_time_format
> <‑
> > grarpamp watch this
> > 
> > locale(7) manual page.
> > 
> 
> No change.  Perhaps there is a "local" setting for fetchmail?  Seems
> there
> should be but if there is, it has escaped my efforts to find it.  Easy
> to do
> it seems. 
> 
> Other logs and terminal display all show 24hr format.with no
> alterations
> to environment settings.
> 
> I tried changing /etc/locale.conf and think I caused
> it to take effect (via "localectl"), and restarted fetchmail, but no
> change.

If you run fetchmail using a systemd service file, try adding
something like:

  Environment=LC_TIME=....

...specifying the name of the locale you want fetchmail to use.
Then restart the fetchmail systemd service.

If this doesn't work, try using LC_ALL instead of LC_TIME, or
trying to figure out whether anything else sets an LC_ALL
environment variable to override your LC_TIME setting.

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: [Fetchmail-users] time stamp format in log

[joea- l. <joe...@j4...>]

> Am 28.01.22 um 21:43
> joea‑ lists:
>> I'd prefer to see time stamps in the fetchmail log in 24 hr format,
but I 
> see this:
>>
>> fetchmail: 6.4.21 querying imap.AAAA.com (protocol IMAP) at Fri 28
Jan 2022 
> 03:35:22 PM EST: poll completed
>> fetchmail: sleeping at Fri 28 Jan 2022 03:35:22 PM EST for 120
seconds
>>
>> Did not find a time format in man pages or via searching the wilds.
>>
>> It is probably right under my nose.  Or will be once someone tells
me how.
> 
> Yes, it is a system standard feature that people appear to be
oblivious
> of, so is not documented in fetchmail. See:
> 
> https://wiki.archlinux.org/title/Locale#LC_TIME:_date_and_time_format
<‑
> grarpamp watch this
> 
> locale(7) manual page.
> 

No change.  Perhaps there is a "local" setting for fetchmail?  Seems
there
should be but if there is, it has escaped my efforts to find it.  Easy
to do
it seems. 

Other logs and terminal display all show 24hr format.with no
alterations
to environment settings.

I tried changing /etc/locale.conf and think I caused
it to take effect (via "localectl"), and restarted fetchmail, but no
change.


joe a.

Re: [Fetchmail-users] time stamp format in log

[Andrew C A. <fet...@ai...>]

On Fri, 28 Jan 2022, joea- lists wrote:

> I'd prefer to see time stamps in the fetchmail log in 24 hr format, but I see this:
>
> fetchmail: 6.4.21 querying imap.AAAA.com (protocol IMAP) at Fri 28 Jan 2022 03:35:22 PM EST: poll completed
> fetchmail: sleeping at Fri 28 Jan 2022 03:35:22 PM EST for 120 seconds
>
> Did not find a time format in man pages or via searching the wilds.
>
> It is probably right under my nose.  Or will be once someone tells me how.

>From https://sourceforge.net/projects/fetchmail/files/branch_6.5/
version 6.5 has (or will have, it is still in beta)

* fetchmail, with --logfile, now logs time stamps into the file, in localtime
    and in the format "Jun 20 23:45:01 fetchmail: ". It will be localized
    through the environment variables LC_TIME (or LC_ALL) and TZ.

I did't run v6.4 in verbose mode, so didn't get the
     sleeping at ...
messages.

-- 
Andrew C. Aitchison					Kendal, UK
 			an...@ai...

Re: [Fetchmail-users] time stamp format in log

[Matthias A. <mat...@gm...>]

Am 28.01.22 um 21:43
joea- lists:
> I'd prefer to see time stamps in the fetchmail log in 24 hr format, but I see this:
>
> fetchmail: 6.4.21 querying imap.AAAA.com (protocol IMAP) at Fri 28 Jan 2022 03:35:22 PM EST: poll completed
> fetchmail: sleeping at Fri 28 Jan 2022 03:35:22 PM EST for 120 seconds
>
> Did not find a time format in man pages or via searching the wilds.
>
> It is probably right under my nose.  Or will be once someone tells me how.

Yes, it is a system standard feature that people appear to be oblivious
of, so is not documented in fetchmail. See:

https://wiki.archlinux.org/title/Locale#LC_TIME:_date_and_time_format <-
grarpamp watch this

locale(7) manual page.

Re: [Fetchmail-users] time stamp format in log

[grarpamp <gra...@gm...>]

> time format

As to globally agreed standard formats, being
single field parseable and easily human readable,
please search: iso8601

[Fetchmail-users] time stamp format in log

[joea- l. <joe...@j4...>]

I'd prefer to see time stamps in the fetchmail log in 24 hr format, but I see this:

fetchmail: 6.4.21 querying imap.AAAA.com (protocol IMAP) at Fri 28 Jan 2022 03:35:22 PM EST: poll completed
fetchmail: sleeping at Fri 28 Jan 2022 03:35:22 PM EST for 120 seconds

Did not find a time format in man pages or via searching the wilds.

It is probably right under my nose.  Or will be once someone tells me how.

joe a

Re: [Fetchmail-users] The saga of wrestling with systemd (was) Re: logrotate options?

[joea- l. <joe...@j4...>]

> Am 23.01.22 um 19:35 schrieb Joe Acquisto-j4:
>>> On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
>>> [snip]
>>>> directory if necessary). Something like this works for me (note that
>>>> I do not have a logfile directive in my fetchmail config file, so
>>>> it will send its output to the standard output stream by default):
>>>>
>>>>    [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service
>>>>    [Unit]
>>>>    Description=Run fetchmail in daemon mode.
>>>>    Documentation=man:fetchmail(1)
>>>>    After=network-online.target
>>>>    Wants=network-online.target
>>>>
>>>>    [Service]
>>>>    Type=simple
>>>>    ExecStartPre=-fetchmail -ve200
>>>>    ExecStart=fetchmail -ve25 -Nd120
>>>>    ExecStop=fetchmail --quit
>>>>    KillMode=process
>>> ...and of course, I forgot two lines that are kind of important:
>>>
>>> [Install]
>>> WantedBy=default.target
>>>
>>> G'luck,
>>> Peter
>>>
>>> --
>> Thanks to all.
>>
>> This is how I achieved success (getting Fetchmail to start and stop in 
> systemd world that is):
>>
>> -------------------------------------
>> [Unit]
>> Description=remote-mail retrieval utility runin daaemon mode
>> After=network.target
>> Wants=network.target
>>
>> [Service]
>> Type=simple
>> EnvironmentFile=/root/.fetchmailrc
>> #User=fetchmail
> 
> 
> Guys, seriously, do not run fetchmail as root user. This is generally
> bad practice, violating the principle of least privilege. Create that
> fetchmail user, move the .fetchmailrc and possibly .fetchids files,
> change their owner, and then run as fetchmail user.
> 
> I will take this feature away in a future version and without
> replacement to protect you while you pretend to be innocent. The
> warnings have been there for long enough.
> 
> 

So, in poking about to prepare for the anticipated wailing and gnashing of teeth,
I attempted to create user fetchmail, only to discover an exiting system user
named fetchmail, member of group daemon.

This gives me pause.    

joe a.

[Fetchmail-users] Another fetchmail?

[joea- l. <joe...@j4...>]

While searching "fetchmail" I found this:

http://www.fetchmail.org/index.html

Curious.

joe a.

Re: [Fetchmail-users] The saga of wrestling with systemd (was) Re: logrotate options?

[joea- l. <joe...@j4...>]

> Am 23.01.22 um 19:35 schrieb Joe Acquisto-j4:
>>> On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
>>> [snip]
>>>> directory if necessary). Something like this works for me (note that
>>>> I do not have a logfile directive in my fetchmail config file, so
>>>> it will send its output to the standard output stream by default):
>>>>
>>>>    [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service
>>>>    [Unit]
>>>>    Description=Run fetchmail in daemon mode.
>>>>    Documentation=man:fetchmail(1)
>>>>    After=network-online.target
>>>>    Wants=network-online.target
>>>>
>>>>    [Service]
>>>>    Type=simple
>>>>    ExecStartPre=-fetchmail -ve200
>>>>    ExecStart=fetchmail -ve25 -Nd120
>>>>    ExecStop=fetchmail --quit
>>>>    KillMode=process
>>> ...and of course, I forgot two lines that are kind of important:
>>>
>>> [Install]
>>> WantedBy=default.target
>>>
>>> G'luck,
>>> Peter
>>>
>>> --
>> Thanks to all.
>>
>> This is how I achieved success (getting Fetchmail to start and stop in 
> systemd world that is):
>>
>> -------------------------------------
>> [Unit]
>> Description=remote-mail retrieval utility runin daaemon mode
>> After=network.target
>> Wants=network.target
>>
>> [Service]
>> Type=simple
>> EnvironmentFile=/root/.fetchmailrc
>> #User=fetchmail
> 
> 
> Guys, seriously, do not run fetchmail as root user. This is generally
> bad practice, violating the principle of least privilege. Create that
> fetchmail user, move the .fetchmailrc and possibly .fetchids files,
> change their owner, and then run as fetchmail user.
> 
> I will take this feature away in a future version and without
> replacement to protect you while you pretend to be innocent. The
> warnings have been there for long enough.
> 

Your advice is certainly appreciated and I will once more attempt to 
do as suggested.

>From my own history, I recall attempting to do that in the dim time and
encountered some permissions related issues that did not yield to a 
cursory effort to resolve.  The path of least resistance called to me and
I went on to other matters.

I did not understand all of your last paragraph, but, it is probably
a good idea to remove the option to run as root.  Perhaps with option to
choose a different user name, though that may be too much.

joe a.

Re: [Fetchmail-users] The saga of wrestling with systemd (was) Re: logrotate options?

[Matthias A. <mat...@gm...>]

Am 23.01.22 um 19:35 schrieb Joe Acquisto-j4:
>> On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
>> [snip]
>>> directory if necessary). Something like this works for me (note that
>>> I do not have a logfile directive in my fetchmail config file, so
>>> it will send its output to the standard output stream by default):
>>>
>>>    [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service
>>>    [Unit]
>>>    Description=Run fetchmail in daemon mode.
>>>    Documentation=man:fetchmail(1)
>>>    After=network-online.target
>>>    Wants=network-online.target
>>>
>>>    [Service]
>>>    Type=simple
>>>    ExecStartPre=-fetchmail -ve200
>>>    ExecStart=fetchmail -ve25 -Nd120
>>>    ExecStop=fetchmail --quit
>>>    KillMode=process
>> ...and of course, I forgot two lines that are kind of important:
>>
>> [Install]
>> WantedBy=default.target
>>
>> G'luck,
>> Peter
>>
>> --
> Thanks to all.
>
> This is how I achieved success (getting Fetchmail to start and stop in systemd world that is):
>
> -------------------------------------
> [Unit]
> Description=remote-mail retrieval utility runin daaemon mode
> After=network.target
> Wants=network.target
>
> [Service]
> Type=simple
> EnvironmentFile=/root/.fetchmailrc
> #User=fetchmail


Guys, seriously, do not run fetchmail as root user. This is generally
bad practice, violating the principle of least privilege. Create that
fetchmail user, move the .fetchmailrc and possibly .fetchids files,
change their owner, and then run as fetchmail user.

I will take this feature away in a future version and without
replacement to protect you while you pretend to be innocent. The
warnings have been there for long enough.

[Fetchmail-users] Re(solved): logrotate options?

[Joe Acquisto-j. <jo...@j4...>]

. . . 

More goodliness to report (Every one can relax now)
After a bit of fine hand sanding and careful waxing, 
logrotate seems to work now.

(with /etc/logrotate.d/fetchmail below)

----------------------------------------------
/var/log/fetchmail.log {
    compress
    dateext
    maxage 365
    rotate 99
    size=+1024k
    notifempty
    missingok
    copytruncate
    create 0600 fool fool
    postrotate
        /usr/bin/systemctl restart fetchmail.service > /dev/null
    endscript
}
--------------------------------------------------

To test:
logrotate -vfd /etc/logrotate.d/fetchmail

To do:
logrotate -vf /etc/logrotate.d/fetchmail

Result:

-rw-r--r-- 1 fool fool   74968 Jan 23 21:23 /var/log/fetchmail.log
-rw-r--r-- 1 fool fool 872115 Jan 23 21:15 /var/log/fetchmail.log-20220123.gz

The names have been changed to protect, well, practically nothing.

Thanks again for all the leads and asssitance.

joe a

Re: [Fetchmail-users] The saga of wrestling with systemd (was) Re: logrotate options?

[Joe Acquisto-j. <jo...@j4...>]

. . . 
. . . 
> In any case, it works fine, but on "stop" it quits but gives the "failed" 
> message
> below.  It does stop as shown and does not seem to affect restart.  So far.
> 
> Jan 23 15:01:03 auxilary fetchmail[11981]: fetchmail: background fetchmail 
> at 11958 killed.
> Jan 23 15:01:03 auxilary systemd[1]: fetchmail.service: Unit entered failed 
> state.
> Jan 23 15:01:03 auxilary systemd[1]: fetchmail.service: Failed with result 
> 'exit-code'.
> 
> This really does not bother me, but might look into it at leisure.
> 
>  . . .
>> G'luck,
>> Peter
>> 
>> -- 
>> 
> 
> Again, thanks to all, your assistance was most helpful. 
> 
> joe a.
> 

As a follow up "systemctl restart fetchmail.service" also
seems to work without a hitch. I don't see that my attempts
at adding a time delay after stop, before restarting have had
any effect.  But, it works, so call it good.

joe a.

Re: [Fetchmail-users] The saga of wrestling with systemd (was) Re: logrotate options?

[Joe Acquisto-j. <jo...@j4...>]

. . .
> It's great that you got it running! Congratulations!
> (yes, I know that fighting with systemd service and unit definition
>  files for the first time... or sometimes even for the fifteenth time...
>  may be, um, exhausting. There is some logic to them, but it takes
>  a while to get used to it)
> 
> If I may make a couple of comments to what you showed below...
> 
>> [Unit]
>> Description=remote-mail retrieval utility runin daaemon mode
> 
> A couple of typos there ("runin", "daaemon"), but I guess they won't
> affect the operation of the service :)

Yeah, I left them as an indication of the "quality of my work"
 
>> After=network.target
>> Wants=network.target
>> 
>> [Service]
>> Type=simple
>> EnvironmentFile=/root/.fetchmailrc
> 
> Hm. This one looks a bit weird to me. I don't think that your
> .fetchmailrc file is indeed in the "variable=value" format that systemd
> would expect for a file to read environment variables from. Also,
> I don't think that your .fetchmailrc file even contains environment
> variable settings...
> 
> Does it work if you remove this line? If so, then I think you may want
> to remove it.

Yes, it works either way.  I did see that it was probably for an actual environment variable
file, but I put it in when it did not seem to be reading some of my set commands.   After
I confirmed it was not what I wanted, I left it uncommented.  It is now uncommented.

> 
>> #User=fetchmail
>> #ExecStart=/usr/lib/fetchmail-systemd-exec
>> ExecStart=/usr/local/bin/fetchmail -v
>> #-Nd120
> 
> This will only work if your .fetchmailrc file already contains
> a "set daemon ..." line and also a "nodetach" line. Otherwise, systemd
> will be kind of surprised when fetchmail creates a separate daemon
> process in the background and the fetchmail process that systemd started
> decides to exit since it has done its part of the work (started
> the daemon process in the background). If your .fetchmailrc file has
> the "set daemon" and "nodetach" lines, then yeah, this will work.

I went with removing those items from the command line as I was having issues
with a single line (non verbose) of the log, one per "poll" going to /var/log/fetchmail
and the verbose part (fetching) going to /var/log/messages.  

My .fetchmailrc does have set daemon, but not "nodetach" which does not seem to 
be a set command.

In any case, it works fine, but on "stop" it quits but gives the "failed" message
below.  It does stop as shown and does not seem to affect restart.  So far.

Jan 23 15:01:03 auxilary fetchmail[11981]: fetchmail: background fetchmail at 11958 killed.
Jan 23 15:01:03 auxilary systemd[1]: fetchmail.service: Unit entered failed state.
Jan 23 15:01:03 auxilary systemd[1]: fetchmail.service: Failed with result 'exit-code'.

This really does not bother me, but might look into it at leisure.

 . . .
> G'luck,
> Peter
> 
> -- 
> 

Again, thanks to all, your assistance was most helpful. 

joe a.

Re: [Fetchmail-users] Fechmail dosn't pick up mail

[Carlos E. R. <rob...@te...>]

On 23/01/2022 16.56, ul...@ul... wrote:
> my fetchmailrc doesn't pick up mail. Instead, I get a messsage
> 
> etchmail: es wurden keine mailserver angegeben.
> 
> I really don*i know what to do.

First thing: change those passwords this minute, assuming they are real 
and not faked.


Second, you can make any program run in English, assuming you are using 
Linux. Create this script:

cer@Telcontar:~> cat /usr/local/bin/ingles
#!/bin/sh
LANG=en_US.UTF-8 \
   LC_ALL=en_US.UTF-8 \
   DICTIONARY=english \
   KDE_LANG=en_US.UTF-8 \
   LANGUAGE=en_US.UTF-8:en \
   exec "$@"
cer@Telcontar:~>


Then you can do:

ingles fetchmail ...

and it will run in English instead of the language you have by default, 
so that everybody in an international mail list can read the error messages.


Guesing, your fetchmail is using a different configuration file than the 
one you think.


-- 
Cheers / Saludos,

		Carlos E. R.
		(from 15.3 x86_64 at Telcontar)

Re: [Fetchmail-users] The saga of wrestling with systemd (was) Re: logrotate options?

[Peter P. <ro...@ri...>]

On Sun, Jan 23, 2022 at 01:35:52PM -0500, Joe Acquisto-j4 wrote:
> > On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
> > [snip]
> >> directory if necessary). Something like this works for me (note that
> >> I do not have a logfile directive in my fetchmail config file, so
> >> it will send its output to the standard output stream by default):
> >> 
> >>   [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service 
> >>   [Unit]
> >>   Description=Run fetchmail in daemon mode.
> >>   Documentation=man:fetchmail(1)
> >>   After=network-online.target
> >>   Wants=network-online.target
> >>   
> >>   [Service]
> >>   Type=simple
> >>   ExecStartPre=-fetchmail -ve200
> >>   ExecStart=fetchmail -ve25 -Nd120
> >>   ExecStop=fetchmail --quit
> >>   KillMode=process
> > 
> > ...and of course, I forgot two lines that are kind of important:
> > 
> > [Install]
> > WantedBy=default.target
> > 
> > G'luck,
> > Peter
> > 
> > -- 
> 
> Thanks to all.
> 
> This is how I achieved success (getting Fetchmail to start and stop in systemd world that is):

It's great that you got it running! Congratulations!
(yes, I know that fighting with systemd service and unit definition
 files for the first time... or sometimes even for the fifteenth time...
 may be, um, exhausting. There is some logic to them, but it takes
 a while to get used to it)

If I may make a couple of comments to what you showed below...

> [Unit]
> Description=remote-mail retrieval utility runin daaemon mode

A couple of typos there ("runin", "daaemon"), but I guess they won't
affect the operation of the service :)

> After=network.target
> Wants=network.target
> 
> [Service]
> Type=simple
> EnvironmentFile=/root/.fetchmailrc

Hm. This one looks a bit weird to me. I don't think that your
.fetchmailrc file is indeed in the "variable=value" format that systemd
would expect for a file to read environment variables from. Also,
I don't think that your .fetchmailrc file even contains environment
variable settings...

Does it work if you remove this line? If so, then I think you may want
to remove it.

> #User=fetchmail
> #ExecStart=/usr/lib/fetchmail-systemd-exec
> ExecStart=/usr/local/bin/fetchmail -v
> #-Nd120

This will only work if your .fetchmailrc file already contains
a "set daemon ..." line and also a "nodetach" line. Otherwise, systemd
will be kind of surprised when fetchmail creates a separate daemon
process in the background and the fetchmail process that systemd started
decides to exit since it has done its part of the work (started
the daemon process in the background). If your .fetchmailrc file has
the "set daemon" and "nodetach" lines, then yeah, this will work.

I personally prefer to keep those options out of the configuration file
so that I may invoke fetchmail by hand sometimes to fetch a couple of
messages and exit, but that's me. If you decide to remove them from
your configuration file, then you'd have to pass them here (as I did
with the -N and -d120 command-line parameters).

> ExecStop=/usr/local/bin/fetchmail -q
> KillMode=process
> #RestartSec=1
> 
> [Install]
> WantedBy=multi-user.target
> ---------------------------------------------
> 
> Thanks again to all.

Glad to have been of assistance! Of course, feel free to come back with
any further questions or issues that you may have with running fetchmail
under systemd (in case somebody objects to discussing such topics on
this list, personal e-mail is also fine).

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[Fetchmail-users] The saga of wrestling with systemd (was) Re: logrotate options?

[Joe Acquisto-j. <jo...@j4...>]

> On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
> [snip]
>> directory if necessary). Something like this works for me (note that
>> I do not have a logfile directive in my fetchmail config file, so
>> it will send its output to the standard output stream by default):
>> 
>>   [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service 
>>   [Unit]
>>   Description=Run fetchmail in daemon mode.
>>   Documentation=man:fetchmail(1)
>>   After=network-online.target
>>   Wants=network-online.target
>>   
>>   [Service]
>>   Type=simple
>>   ExecStartPre=-fetchmail -ve200
>>   ExecStart=fetchmail -ve25 -Nd120
>>   ExecStop=fetchmail --quit
>>   KillMode=process
> 
> ...and of course, I forgot two lines that are kind of important:
> 
> [Install]
> WantedBy=default.target
> 
> G'luck,
> Peter
> 
> -- 

Thanks to all.

This is how I achieved success (getting Fetchmail to start and stop in systemd world that is):

-------------------------------------
[Unit]
Description=remote-mail retrieval utility runin daaemon mode
After=network.target
Wants=network.target

[Service]
Type=simple
EnvironmentFile=/root/.fetchmailrc
#User=fetchmail
#ExecStart=/usr/lib/fetchmail-systemd-exec
ExecStart=/usr/local/bin/fetchmail -v
#-Nd120
ExecStop=/usr/local/bin/fetchmail -q
KillMode=process
#RestartSec=1

[Install]
WantedBy=multi-user.target
---------------------------------------------

Thanks again to all.

joe a

Re: [Fetchmail-users] Fechmail dosn't pick up mail

[Joe Acquisto-j. <jo...@j4...>]

> my fetchmailrc doesn't pick up mail. Instead, I get a messsage
> 
> etchmail: es wurden keine mailserver angegeben.
> 
> I really don*i know what to do.
> 
> 
> set postmaster "postmaster"
> set daemon 900
> set no syslog
> set logfile /u/tmp/fetchmail
> set nobouncemail
> set no spambounce
> set no bouncemail
> set properties ""
> no dns
> poll server23.domainregistry.de with proto IMAP and options no dns
>         user "in...@ul..." there with password  "Oqxq67&3" is "ulw" 
> here fetchsizelimit 0
> 
> 
> poll server23.domainregistry.de with proto IMAP and options no dns
>         user "ul...@ul..." there with password "iFw5u8@4" is "ulw" here 
> fetchsizelimit 0
> 
> 
> poll server23.domainregistry.de with proto IMAP and options no dns
>         user "ul...@ul..." there with password "Pkb228a%" is "ulm" here 
> fetchsizelimit 0
> 
> ##POLL "ulmke2.fritz.box" AKA ulmke2
> smtphost  ulmke2.ulmke.com
> 
> rEGARDS, Walter Ulmke
>                                                            14,0-1     
> Anfang
> 

If those are actual credentials, the very first thing I would do is change the passwords
on those accounts.  Immediately.

I may be able to translate that message, but other native speakers can probably help you
better than I.

You would do well to try again with verbose logging enabled, which may expose the problem.

joe a 

[Fetchmail-users] Fechmail dosn't pick up mail

[<ul...@ul...>]

my fetchmailrc doesn't pick up mail. Instead, I get a messsage

etchmail: es wurden keine mailserver angegeben.

I really don*i know what to do.


set postmaster "postmaster"
set daemon 900
set no syslog
set logfile /u/tmp/fetchmail
set nobouncemail
set no spambounce
set no bouncemail
set properties ""
no dns
poll server23.domainregistry.de with proto IMAP and options no dns
        user "in...@ul..." there with password  "Oqxq67&3" is "ulw" 
here fetchsizelimit 0


poll server23.domainregistry.de with proto IMAP and options no dns
        user "ul...@ul..." there with password "iFw5u8@4" is "ulw" here 
fetchsizelimit 0


poll server23.domainregistry.de with proto IMAP and options no dns
        user "ul...@ul..." there with password "Pkb228a%" is "ulm" here 
fetchsizelimit 0

##POLL "ulmke2.fritz.box" AKA ulmke2
smtphost  ulmke2.ulmke.com

rEGARDS, Walter Ulmke
                                                           14,0-1     
Anfang

Re: [Fetchmail-users] logrotate options?

[Joe Acquisto-j. <jo...@j4...>]

> On 21/01/2022 01.17, Joe Acquisto-j4 wrote:
On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
>>> [snip]
>>>> directory if necessary). Something like this works for me (note that
>>>> I do not have a logfile directive in my fetchmail config file, so
>>>> it will send its output to the standard output stream by default):
>>>>
>>>>    [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service
>>>>    [Unit]
>>>>    Description=Run fetchmail in daemon mode.
>>>>    Documentation=man:fetchmail(1)
>>>>    After=network-online.target
>>>>    Wants=network-online.target
>>>>    
>>>>    [Service]
>>>>    Type=simple
>>>>    ExecStartPre=-fetchmail -ve200
>>>>    ExecStart=fetchmail -ve25 -Nd120
>>>>    ExecStop=fetchmail --quit
>>>>    KillMode=process
>>>
>>> ...and of course, I forgot two lines that are kind of important:
>>>
>>> [Install]
>>> WantedBy=default.target
> 
> 
>> Wow.  Thanks for the most detailed and understandable descriptions of the 
> workings
>> I have yet seen,
>> 
>> Remains to be seen if I can muster what it take to implement it.
> 
> Please remember that as you are using openSUSE, the system already has 
> fetchmail.service installed.
> 
> -- 
> Cheers / Saludos,
> 
> 		Carlos E. R.
> 
>    (from oS Leap 15.3 x86_64 (Erebor-4))

Yes, I know.  From our discussion on the openSuse forum, you may
recall it has never worked for me.   The whys and wherefores of that
have been quite amusing to attempt to discover, given the somewhat
varying descriptions and diverse argot I've happened to stumble across 
in the vast regions of the web.

Now, yes even now, I allow the hope to once more spring forth that I 
may again, some day soon, rejoin the ranks of "those than can" and
cast aside the stigma of "those that can't".   

And when, not IF, I should succeed in this mighty task, I will display
genuine humility, will not crow at all, but modestly thank the Academy,
not forgetting to praise those that helped me, on the way up.

joe a.






---------------------------------
       j4computers, llc
   Stone Ridge, NY 12484
        845-687-3734
   www.j4computers.com
---------------------------------

Re: [Fetchmail-users] logrotate options?

[Carlos E. R. <rob...@te...>]

On 21/01/2022 01.17, Joe Acquisto-j4 wrote:
>> On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
>> [snip]
>>> directory if necessary). Something like this works for me (note that
>>> I do not have a logfile directive in my fetchmail config file, so
>>> it will send its output to the standard output stream by default):
>>>
>>>    [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service
>>>    [Unit]
>>>    Description=Run fetchmail in daemon mode.
>>>    Documentation=man:fetchmail(1)
>>>    After=network-online.target
>>>    Wants=network-online.target
>>>    
>>>    [Service]
>>>    Type=simple
>>>    ExecStartPre=-fetchmail -ve200
>>>    ExecStart=fetchmail -ve25 -Nd120
>>>    ExecStop=fetchmail --quit
>>>    KillMode=process
>>
>> ...and of course, I forgot two lines that are kind of important:
>>
>> [Install]
>> WantedBy=default.target


> Wow.  Thanks for the most detailed and understandable descriptions of the workings
> I have yet seen,
> 
> Remains to be seen if I can muster what it take to implement it.

Please remember that as you are using openSUSE, the system already has 
fetchmail.service installed.

-- 
Cheers / Saludos,

		Carlos E. R.

   (from oS Leap 15.3 x86_64 (Erebor-4))

Re: [Fetchmail-users] logrotate options?

[Joe Acquisto-j. <jo...@j4...>]

> On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
> [snip]
>> directory if necessary). Something like this works for me (note that
>> I do not have a logfile directive in my fetchmail config file, so
>> it will send its output to the standard output stream by default):
>> 
>>   [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service 
>>   [Unit]
>>   Description=Run fetchmail in daemon mode.
>>   Documentation=man:fetchmail(1)
>>   After=network-online.target
>>   Wants=network-online.target
>>   
>>   [Service]
>>   Type=simple
>>   ExecStartPre=-fetchmail -ve200
>>   ExecStart=fetchmail -ve25 -Nd120
>>   ExecStop=fetchmail --quit
>>   KillMode=process
> 
> ...and of course, I forgot two lines that are kind of important:
> 
> [Install]
> WantedBy=default.target
> 
> G'luck,
> Peter
> 
> -- 
> Peter Pentchev  ro...@ri... ro...@de... pp...@st... 
> PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc 
> Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Wow.  Thanks for the most detailed and understandable descriptions of the workings
I have yet seen,

Remains to be seen if I can muster what it take to implement it.

(don't think it will be today though, time for my nap).

joe a.

Re: [Fetchmail-users] logrotate options?

[Peter P. <ro...@ri...>]

On Thu, Jan 20, 2022 at 11:34:26AM +0200, Peter Pentchev wrote:
[snip]
> directory if necessary). Something like this works for me (note that
> I do not have a logfile directive in my fetchmail config file, so
> it will send its output to the standard output stream by default):
> 
>   [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service 
>   [Unit]
>   Description=Run fetchmail in daemon mode.
>   Documentation=man:fetchmail(1)
>   After=network-online.target
>   Wants=network-online.target
>   
>   [Service]
>   Type=simple
>   ExecStartPre=-fetchmail -ve200
>   ExecStart=fetchmail -ve25 -Nd120
>   ExecStop=fetchmail --quit
>   KillMode=process

...and of course, I forgot two lines that are kind of important:

[Install]
WantedBy=default.target

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: [Fetchmail-users] logrotate options?

[Peter P. <ro...@ri...>]

On Wed, Jan 19, 2022 at 10:18:47PM -0500, Joe Acquisto-j4 wrote:
> > On Wed, Jan 19, 2022 at 04:35:35PM -0500, Joe Acquisto-j4 wrote:
> >> This is fetchmail release 6.4.21+SSL-SSLv2-SSLv3+NLS
> >> 
> >> Looking for examples I can follow to implement log rotation with
> >> fetchmail.   Links, examples, tutorials kindly accepted.
> > 
> > If you have the logrotate tool installed on your system, the fetchmail
> > source contains a sample fetchmail.logrotate file:
> > 
> >   
> > https://gitlab.com/fetchmail/fetchmail/-/blob/next/contrib/fetchmail.logrota 
> > te
> > 
> > Of course, you can customize it however you wish - specify different
> > rotation criteria, point to a different fetchmail logfile - but, most
> > importantly, you will most probably need to modify the command to be
> > executed after the logfile has been rotated - the contents of
> > the logrotate configuration file's "postrotate" section.
> > In the sample file, the command in the postrotate section is a POSIX
> > shell "if" statement that examines the server that it is running on and
> > figures out the appropriate command to run to make the fetchmail
> > instance that is running as a system service reopen its logfiles.
> > 
> > If you run fetchmail as root, something like that will probably work for
> > you. If you run fetchmail from a normal user account, there might be
> > a slight problem here, since the logrotate tool will need to restart
> > fetchmail. So if your fetchmail instance is run under some kind of
> > service manager (supervise, runsv, a systemd user service, etc), then
> > the postrotate section is where you place the appropriate command to
> > restart that particular service.
> > 
> > Of course, if you run fetchmail under some kind of service manager, then
> > there may be no need for a separate logfile at all, since most of
> > the service managers can already handle a program that sends messages to
> > its standard output stream, as fetchmail does by default in daemon mode.
> > So that service manager's functionality may already provide some kind of
> > log storage and rotation, and you don't need the logrotate tool.
> > 
> > Hope that helps! In short, it all depends on how you run fetchmail.
> > 
> > G'luck,
> > Peter
> > 
> > -- 
> > Peter Pentchev  ro...@ri... ro...@de... pp...@st... 
> > PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc 
> > Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
> 
> Some well strained infant food and spoon feeding may be required here.  I've never
> had to deal with logrotate before this, which may be obvious.
> 
> It is not clear to me how logrotate runs.  That would be a first spoonful.

On most installations logrotate is run automatically through cron - both
my Debian and CentOS Linux systems have an /etc/cron.daily/logrotate
file that makes sure that it runs at least once a day. When it does,
it first reads the /etc/logrotate.conf file, then it checks whether
there are any files in the /etc/logrotate.d/ directory, and it processes
all the logs and commands in all of these files. So, if you have
an /etc/logrotate.d/ directory, then placing a file similar to
fetchmail.logrotate there (with the rotate conditions and
pre/post-rotation commands updated for your specific installation) could
handle it... if you run fetchmail in a way that can be restarted
automatically. So see below.

> The linked config seems decipherable but I pause at the post rotate part as it is not apparent 
> where fetchmail was stopped prior to this.  I imagine it must be paused  to "quiesce" 
> the log.  Or is that necessary?

Not exactly. This is how logrotate works:
- logrotate reads a configuration file that says "check this logfile
  and, if it fits these criteria (it has grown too large, or too many
  days have passed since it was last rotated, or something else), then
  proceed, else skip it"
- logrotate renames the logfile while the program that writes to it
  probably still has it open
- at this point, if the program (fetchmail) wants to log more into the
  file, it will automatically write into the renamed file (the kernel
  should make sure of that)
- logrotate reads the "postrotate" section and runs the command that is
  specified there to tell the program "please stop writing to this file,
  I have renamed it, start writing to a new one"
- the program (fetchmail) starts writing to a new, currently empty,
  logfile
- logrotate compresses the renamed file

So the point of the postrotate section is to have a command that will
tell the program to stop writing to the old file and start writing to
the new one. Some programs can be told that by sending them a signal,
some don't really need that level of control or, for some reason, it may
be hard to implement (e.g. they may have already changed their user and
group ID, switched to some chroot environment, etc, so it maynot even be
possible for them to create/open a new logfile). For the latter - and
fetchmail is one of them - the postrotate section contains instructions
for the OS to restart the program altogether. This is what
fetchmail.logrotate does - its postrotate section says "find out how we
can restart the fetchmail system service and do it".

> That config post rotate stuff looks to be for init.d, while my stuff uses systemd.

This does not really matter. When systemd first appeared, there were no
programs at all that had systemd service files written for them, and
there were many programs that had SysV init scripts
(/etc/init.d/program) files already written. So what the OS packages did
was make sure that all the /etc/init.d/program files would check whether
systemd is currently running and, if so, automatically run systemctl
with the command that was passed to the SysV init script - so on most
OSs and Linux distributions that run systemd, /etc/init.d/program
stop/start/restart will still work, it will automatically pass
the command to systemctl to control the systemd service.

> I never got fetchmail to start (or maybe restart) properly, so am just
> starting with fetchmail -v (I like noisy logs).  But that is another
> story.

Right... this is actually the most important part of this conversation.
When I wrote at the end of my first message "it all depends on how you
run fetchmail", the point was that for the logrotate file to work, there
must be a way to restart fetchmail automatically, and you must put it in
the postrotate section of the logrotate file.

So if what you are saying is that you run fetchmail by hand, e.g. in
a xterm window or a screen/tmux pane, and just let it run there, then
that might be a problem, since logrotate will need to have a way to stop
it and start it again. If your system runs systemd, then it might be
possible to create a relatively simple systemd user service file that
you place in the ~/.config/systemd/user/ directory (creating that
directory if necessary). Something like this works for me (note that
I do not have a logfile directive in my fetchmail config file, so
it will send its output to the standard output stream by default):

  [roam@straylight ~]$ cat ~/.config/systemd/user/fetchmail.service 
  [Unit]
  Description=Run fetchmail in daemon mode.
  Documentation=man:fetchmail(1)
  After=network-online.target
  Wants=network-online.target
  
  [Service]
  Type=simple
  ExecStartPre=-fetchmail -ve200
  ExecStart=fetchmail -ve25 -Nd120
  ExecStop=fetchmail --quit
  KillMode=process

This is somewhat modeled on the /usr/lib/systemd/user/fetchmail.service
file that the Debian package of fetchmail already ships, but I had to
modify it a bit for my own use case, which is that sometimes I do not
have a stable Internet connection for a long time and then I'd like to
fetch a lot of mail in a single burst. If this does not apply to you,
remove the ExecStartPre line.  After creating this file, I ran:

  systemctl --user daemon-reload
  systemctl --user disable fetchmail
  journalctl --user --follow -u fetchmail.service

And then, in another shell, since journalctl took over this one:

  systemctl --user start fetchmail

...and the journalctl window started showing me fetchmail log messages.

This particular setup leads to fetchmail logging to its standard output
stream, not to a logfile (as noted above, I do not have a logfile line
in my fetchmail config file), and systemd capturing those log lines and
storing them in its own journal (that's why journalctl can show them).
If you want a separate logfile (there are many reasons people do not
necessarily like systemd's journal, some of them are valid for some use
cases), you can still specify a logfile in the fetchmail config file and
it will log to that file. In that case, if you want to rotate that file
through logrotate, there are two ways you can go about it:

- make use of the fact that logrotate runs every day as a system
  service, create an /etc/logrotate.d/fetchmail.service file, point it
  to the logfile that your fetchmail instance creates, tell it to run
  from your user account (look at its "su" config directive), and
  use `systemctl --user restart fetchmail.service` as the postrotate
  command

- find a way to run logrotate periodically from your own user account,
  either from a cron job or from a systemd timer, and either point it
  specifically at a config file for fetchmail, or at a directory that
  contains a config file for fetchmail. Again, the postrotate command
  should be "systemctl --user restart fetchmail.service".

Hope that helps!

G'luck,
Peter

-- 
Peter Pentchev  ro...@ri... ro...@de... pp...@st...
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: [Fetchmail-users] logrotate options?

[Joe Acquisto-j. <jo...@j4...>]

> On Wed, Jan 19, 2022 at 04:35:35PM -0500, Joe Acquisto-j4 wrote:
>> This is fetchmail release 6.4.21+SSL-SSLv2-SSLv3+NLS
>> 
>> Looking for examples I can follow to implement log rotation with
>> fetchmail.   Links, examples, tutorials kindly accepted.
> 
> If you have the logrotate tool installed on your system, the fetchmail
> source contains a sample fetchmail.logrotate file:
> 
>   
> https://gitlab.com/fetchmail/fetchmail/-/blob/next/contrib/fetchmail.logrota 
> te
> 
> Of course, you can customize it however you wish - specify different
> rotation criteria, point to a different fetchmail logfile - but, most
> importantly, you will most probably need to modify the command to be
> executed after the logfile has been rotated - the contents of
> the logrotate configuration file's "postrotate" section.
> In the sample file, the command in the postrotate section is a POSIX
> shell "if" statement that examines the server that it is running on and
> figures out the appropriate command to run to make the fetchmail
> instance that is running as a system service reopen its logfiles.
> 
> If you run fetchmail as root, something like that will probably work for
> you. If you run fetchmail from a normal user account, there might be
> a slight problem here, since the logrotate tool will need to restart
> fetchmail. So if your fetchmail instance is run under some kind of
> service manager (supervise, runsv, a systemd user service, etc), then
> the postrotate section is where you place the appropriate command to
> restart that particular service.
> 
> Of course, if you run fetchmail under some kind of service manager, then
> there may be no need for a separate logfile at all, since most of
> the service managers can already handle a program that sends messages to
> its standard output stream, as fetchmail does by default in daemon mode.
> So that service manager's functionality may already provide some kind of
> log storage and rotation, and you don't need the logrotate tool.
> 
> Hope that helps! In short, it all depends on how you run fetchmail.
> 
> G'luck,
> Peter
> 
> -- 
> Peter Pentchev  ro...@ri... ro...@de... pp...@st... 
> PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc 
> Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Some well strained infant food and spoon feeding may be required here.  I've never
had to deal with logrotate before this, which may be obvious.

It is not clear to me how logrotate runs.  That would be a first spoonful.

The linked config seems decipherable but I pause at the post rotate part as it is not apparent 
where fetchmail was stopped prior to this.  I imagine it must be paused  to "quiesce" 
the log.  Or is that necessary?

That config post rotate stuff looks to be for init.d, while my stuff uses systemd.  I never got fetchmail 
to start (or maybe restart) properly, so am just starting with fetchmail -v (I like noisy logs).  But that is
another story.

I may have to disengage for the evening and restart tomorrow,

joe a.