Error with logrotate.

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Error with logrotate.

Philip-8
Afternoon,

I just updated from Debian 8 to 9 and I'm getting the following error. 
I'm guessing it's something to do with permissions?

Something to do with the create 640 root adm?

/etc/cron.daily/logrotate:
error: unable to open /home/philip/logs/access.log.1 for compression
error: unable to open /home/philip/logs/error.log.1 for compression
run-parts: /etc/cron.daily/logrotate exited with return code 1

/home/philip/logs/*.log {
        su philip philip
        daily
        missingok
        rotate 14
        compress
        delaycompress
        notifempty
        create 640 root adm
        sharedscripts
        postrotate
                 if /etc/init.d/apache2 status > /dev/null ; then \
                     /etc/init.d/apache2 reload > /dev/null; \
                 fi;
        endscript
        prerotate
                if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
                        run-parts /etc/logrotate.d/httpd-prerotate; \
                fi; \
        endscript
}


Philip

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Teemu Likonen-2
[hidden email] [2019-08-13T09:30:34+12] wrote:

> I just updated from Debian 8 to 9 and I'm getting the following error. 
> I'm guessing it's something to do with permissions?
>
> Something to do with the create 640 root adm?
>
> /etc/cron.daily/logrotate:
> error: unable to open /home/philip/logs/access.log.1 for compression
> error: unable to open /home/philip/logs/error.log.1 for compression
> run-parts: /etc/cron.daily/logrotate exited with return code 1

It could be because of /home not being writable for logrotate service.
See Sven Joachim's message in 2019-07-21:

    https://lists.debian.org/debian-user/2019/07/msg01102.html

--
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tlikonen@...
/  https://keybase.io/tlikonen  https://github.com/tlikonen

signature.asc (707 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Gene Heskett-4
On Monday 12 August 2019 23:59:39 Teemu Likonen wrote:

> [hidden email] [2019-08-13T09:30:34+12] wrote:
> > I just updated from Debian 8 to 9 and I'm getting the following
> > error.  I'm guessing it's something to do with permissions?
> >
> > Something to do with the create 640 root adm?
> >
> > /etc/cron.daily/logrotate:
> > error: unable to open /home/philip/logs/access.log.1 for compression
> > error: unable to open /home/philip/logs/error.log.1 for compression
> > run-parts: /etc/cron.daily/logrotate exited with return code 1
>
> It could be because of /home not being writable for logrotate service.
> See Sven Joachim's message in 2019-07-21:
>
>     https://lists.debian.org/debian-user/2019/07/msg01102.html

Its good that we can fix it, BUT IF you are going to restrict where we
keep logfiles like this then FIX the /var/log perms so that fetchmail,
procmail, spamassassin, clamav and its ilk, running as the user can
access /var/log to keep its logs.  Debian's legendary paranoia about who
can write a log in /var/log has long since forced most of us that want
that log, into moving it to /home/username/log and reprogramming
logrotate to maintain it there years ago.

Now you want to prevent logrotate from just doing its job? Does your
paranoia not have any limits to how difficult you are making the users
job?

So just where in tunket _are_ we supposed to be able to keep our logs
then?  A place that Just Works would sure be appreciated.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Sven Joachim
In reply to this post by Teemu Likonen-2
On 2019-08-13 06:59 +0300, Teemu Likonen wrote:

> [hidden email] [2019-08-13T09:30:34+12] wrote:
>
>> I just updated from Debian 8 to 9 and I'm getting the following error. 
>> I'm guessing it's something to do with permissions?
>>
>> Something to do with the create 640 root adm?
>>
>> /etc/cron.daily/logrotate:
>> error: unable to open /home/philip/logs/access.log.1 for compression
>> error: unable to open /home/philip/logs/error.log.1 for compression
>> run-parts: /etc/cron.daily/logrotate exited with return code 1
Perhaps, but it is hard to tell without seeing the reason why logrotate
failed to open the file.  You could try to rebuild it with the attached
patch (untested).

> It could be because of /home not being writable for logrotate service.
> See Sven Joachim's message in 2019-07-21:
>
>     https://lists.debian.org/debian-user/2019/07/msg01102.html

No, the logrotate package in Debian 9 does not use a systemd unit.


--- logrotate-3.11.0.orig/logrotate.c
+++ logrotate-3.11.0/logrotate.c
@@ -670,7 +670,8 @@ static int compressLogFile(char *name, s
     sprintf(compressedName, "%s%s", name, log->compress_ext);

     if ((inFile = open(name, O_RDWR | O_NOFOLLOW)) < 0) {
- message(MESS_ERROR, "unable to open %s for compression\n", name);
+ message(MESS_ERROR, "unable to open %s for compression: %s\n",
+ name, strerror(errno));
  return 1;
     }

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Sven Joachim
In reply to this post by Gene Heskett-4
On 2019-08-13 00:38 -0400, Gene Heskett wrote:

[rant skipped]
> So just where in tunket _are_ we supposed to be able to keep our logs
> then?  A place that Just Works would sure be appreciated.

Putting them under /home is fine, see this comment in
/lib/systemd/system/logrotate.service:

,----
| # hardening options
| #  details: https://www.freedesktop.org/software/systemd/man/systemd.exec.html
| #  no ProtectHome for userdir logs
`----

Cheers,
       Sven

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Erik Christiansen
In reply to this post by Gene Heskett-4
On 13.08.19 00:38, Gene Heskett wrote:
> Its good that we can fix it, BUT IF you are going to restrict where we
> keep logfiles like this then FIX the /var/log perms so that fetchmail,
> procmail, spamassassin, clamav and its ilk, running as the user can
> access /var/log to keep its logs.  Debian's legendary paranoia about who
> can write a log in /var/log has long since forced most of us that want
> that log, into moving it to /home/username/log and reprogramming
> logrotate to maintain it there years ago.

Nuthin' wrong with that. An individual user's logs in his tree, and
system logs in theirs. No effort:

$ grep log .fetchmailrc .procmailrc
.fetchmailrc:set logfile "/tmp/fetchmail_log"
...
.procmailrc:LOGFILE=$MAILDIR/tmp_log.$$
.procmailrc:FINAL_LOG=$MAILDIR/log

If you had a house full of rowdy teenagers, would you really want them
all able to wallop /var/log? And what if it were a tribe of uni
students? (I think I have you sufficiently worried now, Gene.)

Erik
(Who was both, once.)

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

deloptes-2
In reply to this post by Gene Heskett-4
Gene Heskett wrote:

> Its good that we can fix it, BUT IF you are going to restrict where we
> keep logfiles like this then FIX the /var/log perms so that fetchmail,
> procmail, spamassassin, clamav and its ilk, running as the user can
> access /var/log to keep its logs.  Debian's legendary paranoia about who
> can write a log in /var/log has long since forced most of us that want
> that log, into moving it to /home/username/log and reprogramming
> logrotate to maintain it there years ago.

So why should user be able to write in /var/log? It is the systems log
directory not the users. I am not aware of any program I've been using for
the past 15y that would have a problem writing in /var/log

User programs you can put everywhere you want and you can customize whatever
you want, but do not change things that are good and working please.

usually you use opt for custom stuff, so why don't you put
there /opt/<user>/log

Logrotate also does not need to be modified - only for your custom stuff, so
it is expected and desired and it is easy to adjust.

just my 5c

regards


Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Gene Heskett-4
In reply to this post by Erik Christiansen
On Tuesday 13 August 2019 01:30:09 Erik Christiansen wrote:

> On 13.08.19 00:38, Gene Heskett wrote:
> > Its good that we can fix it, BUT IF you are going to restrict where
> > we keep logfiles like this then FIX the /var/log perms so that
> > fetchmail, procmail, spamassassin, clamav and its ilk, running as
> > the user can access /var/log to keep its logs.  Debian's legendary
> > paranoia about who can write a log in /var/log has long since forced
> > most of us that want that log, into moving it to /home/username/log
> > and reprogramming logrotate to maintain it there years ago.
>
> Nuthin' wrong with that. An individual user's logs in his tree, and
> system logs in theirs. No effort:
>
> $ grep log .fetchmailrc .procmailrc
> .fetchmailrc:set logfile "/tmp/fetchmail_log"
> ...
> .procmailrc:LOGFILE=$MAILDIR/tmp_log.$$
> .procmailrc:FINAL_LOG=$MAILDIR/log
>
> If you had a house full of rowdy teenagers, would you really want them
> all able to wallop /var/log? And what if it were a tribe of uni
> students? (I think I have you sufficiently worried now, Gene.)
>
> Erik
> (Who was both, once.)

So was I, a long time ago.

Not a bit Eric. I'm hiding behind dd-wrt. Keyboard events if they occur,
were created by my fingers.

The last time I had children with me was nominally '85, when the 2nd
decided she didn't like WV and took heer & the kids back to Nebraska
where she could game the welfare system I had a timex-1000 I'd built a
16k rampack for.  They wore out that membrane keyboard in less than a
week and I had to cobble up a box with a surplus ti-99 keyboard with a
rewired matrix for it. Now my youngest is in his late 40's and 1500+
miles west on i-80 in Nebraska. Fixing gear from nuclear power
facilities.  Next up has his own tractor, pulling a powder wagon full of
portland for the Kansas Hyway Dept. Next up is all over the country
planting new power poles where-ever the last big storm hit & put a few
hundred thousand in the dark, and the oldest is doing contract takeoffs
for the biggest electrical contractor on the right coast.

I am it, my 79 yo wife is an invalid, no longer mobile enough to even get
in the same room with a keyboard, and has zero interest in it if I took
her a keyboard.  And I am close to calling it a good run at 84, my
ticker is going to get looked at Wednesday. Needs some bypasses I
suspect. In the meantime, my regular schedule is on hold, just taking
care of the missus, cooking and dishwashing in a dishwasher.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Gene Heskett-4
In reply to this post by deloptes-2
On Tuesday 13 August 2019 02:24:34 deloptes wrote:

> Gene Heskett wrote:
> > Its good that we can fix it, BUT IF you are going to restrict where
> > we keep logfiles like this then FIX the /var/log perms so that
> > fetchmail, procmail, spamassassin, clamav and its ilk, running as
> > the user can access /var/log to keep its logs.  Debian's legendary
> > paranoia about who can write a log in /var/log has long since forced
> > most of us that want that log, into moving it to /home/username/log
> > and reprogramming logrotate to maintain it there years ago.
>
> So why should user be able to write in /var/log? It is the systems log
> directory not the users.

I don't have a beef with that. My beef is that there has been no effort
to make it easy for the user to take care of his own logs, and now
systemd wants to disable housekeeping the only sensible place for a user
to keep his logs in. And I totally fail to see how that level of
paranoia can be justified.

> I am not aware of any program I've been using
> for the past 15y that would have a problem writing in /var/log

Then tell me how fetchmail, procmail, clamav or spamd running as me, can
keep their logs in /var/log, the permissions just aren't there after a
reboot.

> User programs you can put everywhere you want and you can customize
> whatever you want, but do not change things that are good and working
> please.
>
> usually you use opt for custom stuff, so why don't you put
> there /opt/<user>/log

Would that work from /etc/logrotate stuffs? Short answer no.

IMO if it can't reliably use /var/log, the alternative is to create ones
own logrotate scheme. Possibly running a local modified copy of
logrotate living in his own ~/bin and  driven from his own crontab.

> Logrotate also does not need to be modified - only for your custom
> stuff, so it is expected and desired and it is easy to adjust.

Maybe for someone intimately fam with how it works, not so easy on a
onetime basis after an install. One doesn't get familiar enough, nor
manage to commit it to short term memory.
> just my 5c

Chuckle, inflation has made it worth more than that. I can remember
walking the 2 blocks to the store and bringing back a loaf of Wonder
Bread for 8 cents.  Can you?

> regards

Take care deloptes.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Dan Purgert
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Gene Heskett wrote:
> On Tuesday 13 August 2019 02:24:34 deloptes wrote:
> [...]
>> I am not aware of any program I've been using
>> for the past 15y that would have a problem writing in /var/log
>
> Then tell me how fetchmail, procmail, clamav or spamd running as me, can
> keep their logs in /var/log, the permissions just aren't there after a
> reboot.

Aren't all four of those system services; with their own system users,
with their own directories in /var/log (or well, at least by default)?

>> [...]
>> Logrotate also does not need to be modified - only for your custom
>> stuff, so it is expected and desired and it is easy to adjust.
>
> Maybe for someone intimately fam with how it works, not so easy on a
> onetime basis after an install. One doesn't get familiar enough, nor
> manage to commit it to short term memory.

Assuming a Debian-standard /etc/logrotate.conf; it should give one the
necessary examples to set up a functioning schedule for things in their
$HOME (or other places).


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl1Shd8ACgkQjhHd8xJ5
ooHWAQf/fFpJq38BCynCpMptc307adtIjGzh2+eoYKplvXgV5EgrundNCVvul0xX
V8YS+V2ycvVLAKguM/Sq0AluXCvRvfGfBn10mT+ZJlpG5i7ogvN6GjnH68aQN/Hg
WQ1yT950jYXgOJ1lNhNOBK5ufekEFcl3Fz7nzbpJtew8pqznZFOLSZaWkBZtciTY
gVR1htNNBsUKPCD306Y0z5EMUsobCty3rmrhGA4ENnZLTPV1dN/wYrdNvVvHaxTA
qeFQmRVTofUl9WllgyfwFVPG+3BYGN0CSiu8YgnOF7z9nyiCH/lJLgx+y8PZnc4S
4iRwEA3hiXSglya2oCsluWtUbpsdCA==
=Sypc
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Reply | Threaded
Open this post in threaded view
|

Re: OT: While we're talking about logrotate (was: Re: Error with logrotate.)

rhkramer
In reply to this post by deloptes-2
PS: I do (now) recall that one of the descriptions of how to do what I wanted
was in an old (online) issue of Dr. Dobbs, and I spent a fair amount of time
trying to get that one to do what I wanted, but it refused to cooperate ;-)

On Tuesday, August 13, 2019 07:58:16 AM [hidden email] wrote:

> While we're talking about logrotate, I'd like to ask if anyone else has
> seen (and solved) the problem I had with logrotate.
>
> There were times in the past when I wanted to do things like keep a log (or
> a backup of one or more files) something like this: 7 daily logs for one
> week, then 4 (or 5) weekly logs for one month, then, 12 monthly logs for
> one year (and, ideally, in some circumstances, n yearly logs forever).
>
> I found various descriptions of how (iiuc) I could make logrotate do that
> for me, but they never worked correctly for me.  (I forget the exact
> problem, it may have been that they would not, for example, delete (or
> overwrite), for example, the daily logs -- but, as I say, I really don't
> remember the problem, just that I couldn't get it to work.)
>
> If this rings the bell for anyone, and you had a similar problem and found
> the solution, I'd appreciate any hints you can offer.  (If you think the
> solutions on the web "just work", then you probably haven't encountered
> the problem I found.)
>
> Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Greg Wooledge
In reply to this post by Philip-8
On Tue, Aug 13, 2019 at 09:30:34AM +1200, Philip wrote:
> I just updated from Debian 8 to 9 and I'm getting the following error.  I'm
> guessing it's something to do with permissions?
>
> Something to do with the create 640 root adm?
>
> /etc/cron.daily/logrotate:
> error: unable to open /home/philip/logs/access.log.1 for compression

Could be permissions, yes.

> /home/philip/logs/*.log {
> su philip philip
[...]
> create 640 root adm

If you're running as "philip:philip" then you can't create files as
"root:adm".

Moreover, any existing files like /home/philip/logs/access.log.1 that
are owned by "root:adm" can't be written by a process running as
"philip:philip".

Most likely, what you want to do is replace the "create 640 root adm"
with "create 640 philip philip", and then verify/change the ownership
of any existing files, as well as the directory they're in, so that
the logrotate process running as "philip:philip" can read and write
everything.

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Gene Heskett-4
In reply to this post by Dan Purgert
On Tuesday 13 August 2019 05:41:52 Dan Purgert wrote:

> Gene Heskett wrote:
> > On Tuesday 13 August 2019 02:24:34 deloptes wrote:
> > [...]
> >
> >> I am not aware of any program I've been using
> >> for the past 15y that would have a problem writing in /var/log
> >
> > Then tell me how fetchmail, procmail, clamav or spamd running as me,
> > can keep their logs in /var/log, the permissions just aren't there
> > after a reboot.
>
> Aren't all four of those system services; with their own system users,
> with their own directories in /var/log (or well, at least by default)?
>
No, while they may be callable by anyone, they all become the user
calling them.

> >> [...]
> >> Logrotate also does not need to be modified - only for your custom
> >> stuff, so it is expected and desired and it is easy to adjust.
> >
> > Maybe for someone intimately fam with how it works, not so easy on a
> > onetime basis after an install. One doesn't get familiar enough, nor
> > manage to commit it to short term memory.
>
> Assuming a Debian-standard /etc/logrotate.conf; it should give one the
> necessary examples to set up a functioning schedule for things in
> their $HOME (or other places).

O0kkaayy, splain this:
my entry for these logs in /etc/logrotate.d:

/home/gene/log/fetchmail.log
/home/gene/log/procmail.log
/home/gene/log/mail.log
{
        su gene mail
        rotate 4
        maxsize 5000000
        weekly
        missingok
        notifempty
        copytruncate
        compress
        delaycompress
        postrotate
                kill -HUP fetchmail
                kill -HUP procmail
                kill -HUP spamd
        endscript
}

and an ls -l of ~/log

gene@coyote:/etc/logrotate.d$ ls -l  ~/log
total 68804
-rw-r--r-- 1 gene gene  5413354 Aug 13 09:36 fetchmail.log
-rw------- 1 gene mail        0 Aug 12 00:08 fetchmail.log.1
-rw------- 1 gene mail       20 Aug  4 00:10 fetchmail.log.2.gz
-rw------- 1 gene mail       20 Jul 28 00:09 fetchmail.log.3.gz
-rw-r--r-- 1 gene gene   636567 Aug 13 09:36 mail.log
-rw------- 1 gene mail        0 Aug 12 00:08 mail.log.1
-rw------- 1 gene mail       20 Aug  4 00:10 mail.log.2.gz
-rw------- 1 gene mail       20 Jul 28 00:09 mail.log.3.gz
-rw-r--r-- 1 gene gene 64361979 Aug 13 09:36 procmail.log
-rw------- 1 gene mail        0 Aug 12 00:08 procmail.log.1
-rw------- 1 gene mail       20 Aug  4 00:10 procmail.log.2.gz
-rw------- 1 gene mail       20 Jul 28 00:09 procmail.log.3.g

Which does not look like its being properly rotated to me.
Yet this worked (without the maxsize option I just now added) for all the
years on wheezy.  And yes, I am a member of group mail

Thanks.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Dan Purgert
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Gene Heskett wrote:

> On Tuesday 13 August 2019 05:41:52 Dan Purgert wrote:
>
>> Gene Heskett wrote:
>> > On Tuesday 13 August 2019 02:24:34 deloptes wrote:
>> > [...]
>> >
>> >> I am not aware of any program I've been using
>> >> for the past 15y that would have a problem writing in /var/log
>> >
>> > Then tell me how fetchmail, procmail, clamav or spamd running as me,
>> > can keep their logs in /var/log, the permissions just aren't there
>> > after a reboot.
>>
>> Aren't all four of those system services; with their own system users,
>> with their own directories in /var/log (or well, at least by default)?
>>
> No, while they may be callable by anyone, they all become the user
> calling them.

Ah, spamd & clamav are their own users here; and I don't use the other
two (so assumed wrongly). Thanks for clarifying.

>> [...]
>> Assuming a Debian-standard /etc/logrotate.conf; it should give one the
>> necessary examples to set up a functioning schedule for things in
>> their $HOME (or other places).
>
> O0kkaayy, splain this:
> my entry for these logs in /etc/logrotate.d:
>
> /home/gene/log/fetchmail.log
> /home/gene/log/procmail.log
> /home/gene/log/mail.log
> {
>         su gene mail
>         rotate 4
>         maxsize 5000000
>         weekly
>         missingok
>         notifempty
>         copytruncate
>         compress
>         delaycompress
>         postrotate
>                 kill -HUP fetchmail
>                 kill -HUP procmail
>                 kill -HUP spamd
>         endscript
> }
>
> and an ls -l of ~/log
>
> gene@coyote:/etc/logrotate.d$ ls -l  ~/log
> total 68804
> -rw-r--r-- 1 gene gene  5413354 Aug 13 09:36 fetchmail.log
> -rw------- 1 gene mail        0 Aug 12 00:08 fetchmail.log.1
> -rw------- 1 gene mail       20 Aug  4 00:10 fetchmail.log.2.gz
> -rw------- 1 gene mail       20 Jul 28 00:09 fetchmail.log.3.gz
> -rw-r--r-- 1 gene gene   636567 Aug 13 09:36 mail.log
> -rw------- 1 gene mail        0 Aug 12 00:08 mail.log.1
> -rw------- 1 gene mail       20 Aug  4 00:10 mail.log.2.gz
> -rw------- 1 gene mail       20 Jul 28 00:09 mail.log.3.gz
> -rw-r--r-- 1 gene gene 64361979 Aug 13 09:36 procmail.log
> -rw------- 1 gene mail        0 Aug 12 00:08 procmail.log.1
> -rw------- 1 gene mail       20 Aug  4 00:10 procmail.log.2.gz
> -rw------- 1 gene mail       20 Jul 28 00:09 procmail.log.3.g
>
> Which does not look like its being properly rotated to me.
> Yet this worked (without the maxsize option I just now added) for all the
> years on wheezy.  And yes, I am a member of group mail

Looks like it's trying to run correctly (June 28 -> Aug 4 being a week;
4th to 12th being 8 days). Although it looks like your options may be
having problems such that the processes aren't moving the logs
properly.

Although, as I recall, multiple lines cause issues (or at least they did
for me); you'll probably be better served with something like this:

  /home/gene/log/*.log
  {
          rotate 4
          maxsize 5000000
          weekly
          missingok
          notifempty
          copytruncate
          compress
          delaycompress
          postrotate
                  /bin/kill -HUP fetchmail
                  /bin/kill -HUP procmail
                  /bin/kill -HUP spamd
          endscript
  }

Note that:

  - I removed the 'su' line; as I don't see it as an option in my
    manpage
  - I used the full path to kill, as I cron doesn't usually have a $PATH
    set

HTH

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl1S7g4ACgkQjhHd8xJ5
ooFvJgf+O43AC0aYx6aVrWjvcpGhcNQr3elp42UscofoS2I4Ctiy0cRvM2e509cT
NP/uLrt5cnu6QKnUun0LWOW/tsZXxEoPvOzIRM3JGybV5/iloCF00vYbHMIht4wh
H6C8TvTmblpCsUMKns+YCfRIwykj1+jpRjEIVWsbny/ZbVHK19bGqUp8PK2lZHT9
LQ7YLt5cw4jgS9NBOOamaKn9wQwStZrN7YHUgVyxixVbJ/MarsYzZ3QvrElSPgEy
9Wy/witCKIdd2vAxhtWMxpmrL6RwQw6VJ4vokhyZuA7KjJrYqK1HGOVOHd0pGm9r
i4ApD6WAKsgooqD0OPgIfEvLk7mJnA==
=GlKw
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Gene Heskett-4
On Tuesday 13 August 2019 13:06:23 Dan Purgert wrote:

> Gene Heskett wrote:
> > On Tuesday 13 August 2019 05:41:52 Dan Purgert wrote:
> >> Gene Heskett wrote:
> >> > On Tuesday 13 August 2019 02:24:34 deloptes wrote:
> >> > [...]
> >> >
> >> >> I am not aware of any program I've been using
> >> >> for the past 15y that would have a problem writing in /var/log
> >> >
> >> > Then tell me how fetchmail, procmail, clamav or spamd running as
> >> > me, can keep their logs in /var/log, the permissions just aren't
> >> > there after a reboot.
> >>
> >> Aren't all four of those system services; with their own system
> >> users, with their own directories in /var/log (or well, at least by
> >> default)?
> >
> > No, while they may be callable by anyone, they all become the user
> > calling them.
>
> Ah, spamd & clamav are their own users here; and I don't use the other
> two (so assumed wrongly). Thanks for clarifying.
>
> >> [...]
> >> Assuming a Debian-standard /etc/logrotate.conf; it should give one
> >> the necessary examples to set up a functioning schedule for things
> >> in their $HOME (or other places).
> >
> > O0kkaayy, splain this:
> > my entry for these logs in /etc/logrotate.d:
> >
> > /home/gene/log/fetchmail.log
> > /home/gene/log/procmail.log
> > /home/gene/log/mail.log
> > {
> >         su gene mail
> >         rotate 4
> >         maxsize 5000000
> >         weekly
> >         missingok
> >         notifempty
> >         copytruncate
> >         compress
> >         delaycompress
> >         postrotate
> >                 kill -HUP fetchmail
> >                 kill -HUP procmail
> >                 kill -HUP spamd
> >         endscript
> > }
> >
> > and an ls -l of ~/log
> >
> > gene@coyote:/etc/logrotate.d$ ls -l  ~/log
> > total 68804
> > -rw-r--r-- 1 gene gene  5413354 Aug 13 09:36 fetchmail.log
> > -rw------- 1 gene mail        0 Aug 12 00:08 fetchmail.log.1
> > -rw------- 1 gene mail       20 Aug  4 00:10 fetchmail.log.2.gz
> > -rw------- 1 gene mail       20 Jul 28 00:09 fetchmail.log.3.gz
> > -rw-r--r-- 1 gene gene   636567 Aug 13 09:36 mail.log
> > -rw------- 1 gene mail        0 Aug 12 00:08 mail.log.1
> > -rw------- 1 gene mail       20 Aug  4 00:10 mail.log.2.gz
> > -rw------- 1 gene mail       20 Jul 28 00:09 mail.log.3.gz
> > -rw-r--r-- 1 gene gene 64361979 Aug 13 09:36 procmail.log
> > -rw------- 1 gene mail        0 Aug 12 00:08 procmail.log.1
> > -rw------- 1 gene mail       20 Aug  4 00:10 procmail.log.2.gz
> > -rw------- 1 gene mail       20 Jul 28 00:09 procmail.log.3.g
> >
> > Which does not look like its being properly rotated to me.
> > Yet this worked (without the maxsize option I just now added) for
> > all the years on wheezy.  And yes, I am a member of group mail
>
> Looks like it's trying to run correctly (June 28 -> Aug 4 being a
> week; 4th to 12th being 8 days). Although it looks like your options
> may be having problems such that the processes aren't moving the logs
> properly.
>
> Although, as I recall, multiple lines cause issues (or at least they
> did for me); you'll probably be better served with something like
> this:
>
>   /home/gene/log/*.log
>   {
>           rotate 4
>           maxsize 5000000
>           weekly
>           missingok
>           notifempty
>           copytruncate
>           compress
>           delaycompress
>           postrotate
>                   /bin/kill -HUP fetchmail
>                   /bin/kill -HUP procmail
>                   /bin/kill -HUP spamd
>           endscript
>   }
>
> Note that:
>
>   - I removed the 'su' line; as I don't see it as an option in my
>     manpage
your man page might be diff, from mine:
 su user group
              Rotate log files set under this user and group instead of
using default user/group (usually root). user specifies the user name
used for rotation and  group
              specifies  the group used for rotation. If the user/group
you specify here does not have sufficient privilege to make files with
the ownership you've speci‐
              fied in a create instruction, it will cause an error.

>   - I used the full path to kill, as I cron doesn't usually have a

fixed.

> HTH
might. Since the logfile is owned and grouped by me I changed to
 su gene gene
too.

We'll check again tomorrow.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Lee-7
In reply to this post by Gene Heskett-4
On 8/13/19, Gene Heskett <[hidden email]> wrote:

> On Tuesday 13 August 2019 02:24:34 deloptes wrote:
>
>> Gene Heskett wrote:
>> > Its good that we can fix it, BUT IF you are going to restrict where
>> > we keep logfiles like this then FIX the /var/log perms so that
>> > fetchmail, procmail, spamassassin, clamav and its ilk, running as
>> > the user can access /var/log to keep its logs.  Debian's legendary
>> > paranoia about who can write a log in /var/log has long since forced
>> > most of us that want that log, into moving it to /home/username/log
>> > and reprogramming logrotate to maintain it there years ago.
>>
>> So why should user be able to write in /var/log? It is the systems log
>> directory not the users.
>
> I don't have a beef with that. My beef is that there has been no effort
> to make it easy for the user to take care of his own logs, and now
> systemd wants to disable housekeeping the only sensible place for a user
> to keep his logs in. And I totally fail to see how that level of
> paranoia can be justified.
>
>> I am not aware of any program I've been using
>> for the past 15y that would have a problem writing in /var/log
>
> Then tell me how fetchmail, procmail, clamav or spamd running as me, can
> keep their logs in /var/log, the permissions just aren't there after a
> reboot.

I had the same problem with /var/log file permissions being reset so,
for bind, I made a /var/log/bind, set the permissions on the directory
& changed bind to log to /var/log/bind/named.log

^shrug^ probably not The Right Way To Do It, but it works & I'm happy.

If you make a /var/log/mail & configure fetchmail, procmail, etc. to
log there it'll probably work

Regards,
Lee

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Gene Heskett-4
On Tuesday 13 August 2019 15:03:53 Lee wrote:

> On 8/13/19, Gene Heskett <[hidden email]> wrote:
> > On Tuesday 13 August 2019 02:24:34 deloptes wrote:
> >> Gene Heskett wrote:
> >> > Its good that we can fix it, BUT IF you are going to restrict
> >> > where we keep logfiles like this then FIX the /var/log perms so
> >> > that fetchmail, procmail, spamassassin, clamav and its ilk,
> >> > running as the user can access /var/log to keep its logs.
> >> > Debian's legendary paranoia about who can write a log in /var/log
> >> > has long since forced most of us that want that log, into moving
> >> > it to /home/username/log and reprogramming logrotate to maintain
> >> > it there years ago.
> >>
> >> So why should user be able to write in /var/log? It is the systems
> >> log directory not the users.
> >
> > I don't have a beef with that. My beef is that there has been no
> > effort to make it easy for the user to take care of his own logs,
> > and now systemd wants to disable housekeeping the only sensible
> > place for a user to keep his logs in. And I totally fail to see how
> > that level of paranoia can be justified.
> >
> >> I am not aware of any program I've been using
> >> for the past 15y that would have a problem writing in /var/log
> >
> > Then tell me how fetchmail, procmail, clamav or spamd running as me,
> > can keep their logs in /var/log, the permissions just aren't there
> > after a reboot.
>
> I had the same problem with /var/log file permissions being reset so,
> for bind, I made a /var/log/bind, set the permissions on the directory
> & changed bind to log to /var/log/bind/named.log
>
> ^shrug^ probably not The Right Way To Do It, but it works & I'm happy.
>
> If you make a /var/log/mail & configure fetchmail, procmail, etc. to
> log there it'll probably work
>
ISTR I tried that, making mail's owner and group both me. Didn't work,
error was no permission, I assume because parent log was owned by
root:root.

I tried chmod 0777, which did work, till the next reboot at which point
it was reset to 0640 again.


> Regards,
> Lee


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Error with logrotate.

Gene Heskett-4
In reply to this post by Lee-7
On Tuesday 13 August 2019 15:03:53 Lee wrote:

> On 8/13/19, Gene Heskett <[hidden email]> wrote:
> > On Tuesday 13 August 2019 02:24:34 deloptes wrote:
> >> Gene Heskett wrote:
> >> > Its good that we can fix it, BUT IF you are going to restrict
> >> > where we keep logfiles like this then FIX the /var/log perms so
> >> > that fetchmail, procmail, spamassassin, clamav and its ilk,
> >> > running as the user can access /var/log to keep its logs.
> >> > Debian's legendary paranoia about who can write a log in /var/log
> >> > has long since forced most of us that want that log, into moving
> >> > it to /home/username/log and reprogramming logrotate to maintain
> >> > it there years ago.
> >>
> >> So why should user be able to write in /var/log? It is the systems
> >> log directory not the users.
> >
> > I don't have a beef with that. My beef is that there has been no
> > effort to make it easy for the user to take care of his own logs,
> > and now systemd wants to disable housekeeping the only sensible
> > place for a user to keep his logs in. And I totally fail to see how
> > that level of paranoia can be justified.
> >
> >> I am not aware of any program I've been using
> >> for the past 15y that would have a problem writing in /var/log
> >
> > Then tell me how fetchmail, procmail, clamav or spamd running as me,
> > can keep their logs in /var/log, the permissions just aren't there
> > after a reboot.
>
> I had the same problem with /var/log file permissions being reset so,
> for bind, I made a /var/log/bind, set the permissions on the directory
> & changed bind to log to /var/log/bind/named.log
>
I don't use bind, haven't touched it since it was attacked at RH6.2, in
what, 2001? decade+ ago. I don't even think its installed. yes it is but
its not running. In that case I sensed something wrong and rebooted the
machine before he could clean up his tracks, then kept a list as I
housecleaned, and sent it to his ISP along with a nastygram. 10 minutes
later his address disappeared from the logs never to appear again.  
Since then I've only run hosts based systems. dnsmasq in the router, no
avahi or dhcp findable & the only dns address in any machine this side
of the router is the router. If the router doesn't have it in the cache,
it queries the ISP.  Its all attack-proof, and it all Just Works.

Theres lots of ways to skin that cat but I always start by making sure
its well and truly dead. :)

> ^shrug^ probably not The Right Way To Do It, but it works & I'm happy.

Didn't work here, didn't dig deep enough to find out why. I maybe could
have made it work, but since it was  my logs, why not just move them to
~/log ?  So I did, but stretches renewed paranoia just had to screw
something up. Hopefully these changes will work.

> If you make a /var/log/mail & configure fetchmail, procmail, etc. to
> log there it'll probably work
>
> Regards,
> Lee


Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>