rsyslog only generates files when logs arrive to go in them, so immediatly after rotation, dynamicly generated files probably don't exist, but as logs arrive to go in them they will be created.

David Lang

On Tue, 2 Jun 2020, Anthony Benitez Borges via rsyslog wrote:

Date: Tue, 2 Jun 2020 12:06:54 -0400
From: Anthony Benitez Borges via rsyslog <[email protected]>
To: Rainer Gerhards <[email protected]>
Cc: Anthony Benitez Borges <[email protected]>,
    rsyslog-users <[email protected]>
Subject: Re: [rsyslog] Dynamic file not generated after log rotation

To test if it is a permission issue, I moved my logrotate script under
/etc/logrotate.d/ (there is another script here that rotates
/var/log/messages and other logs under /var/log/ which is where I
originally found the execution of the HUP signal to rsyslog), and made sure
that the permissions and ownership of my file matched every other file in
the directory. When I execute the script that reads from /etc/logrotate.d/
(/etc/cron.daily/logrotate), the dynamic files are not generated, while
files under /var/log/ are being rotated and generated appropriately.

If I run the same command that is being used in these other logrotate
scripts:

/bin/kill -HUP `cat /var/run/rsyslog.pid 2> /dev/null` 2> /dev/null

manually in the CLI, only then do the dynamic files are generated.

The file matches in permission, ownership, and location other files that
are shown to work and when executing logrotate on the single script and
seeing the process that handles the execution, the effective UID for the
process is root.

Which is why I asked if there is a difference between dynamic files from
messages received through imudp/imtcp modules and routing local messages by
selectors, because it seems that that is the only difference.

On Tue, Jun 2, 2020 at 11:36 AM Rainer Gerhards <[email protected]>
wrote:

The question is as which user it is executed? Does that user have
permissions to send HUP to the rsyslog process, which may run as
another user.

When you say "one works, one other not" it smells strongly like
permission issues....

Rainer

El mar., 2 jun. 2020 a las 17:17, Anthony Benitez Borges
(<[email protected]>) escribió:
>
> How is my logrotate script different from the logrotate script in
/etc/cron.daily/logrotate? They are both executed by cron, so they should
have the same permissions. Does it make a difference between
/var/log/messages and /syslog_data/logs/*/*.log that the former is
generated by rsyslog routing messages under a selector/filter to it and the
latter is a defined dynamic file?
>
> -ABB
>
> On Tue, Jun 2, 2020 at 10:45 AM Rainer Gerhards <
[email protected]> wrote:
>>
>> Sounds like logrotate has no permission to send hup to rsyslog
process...
>>
>> Rainer
>>
>> Sent from phone, thus brief.
>>
>> Anthony Benitez Borges via rsyslog <[email protected]> schrieb
am Di., 2. Juni 2020, 16:29:
>>>
>>> I have some switches/firewalls sending logs to my logging server
through
>>> both TCP/UDP and I have noticed that whenever these logs are rotated,
the
>>> dynamic files are not generated when logrotate sends a HUP signal to
>>> rsyslog.
>>>
>>> I have the following rsyslog ruleset that is applied to the inputs for
the
>>> imudp and imtcp modules:
>>> ----------------------------------------------------
>>> template(name="remote_log_path" type="string"
>>> string="/syslog_data/logs/%fromhost-ip%/%fromhost-ip%.syslog.log")
>>>
>>> ruleset(name="remote_logging_rules") {
>>>     # filter junk messages using if-statement
>>>     action(
>>>         type="omfile"
>>>         dynaFile="remote_log_path"
>>>         dirOwner="root"
>>>         dirGroup="root"
>>>         dirCreateMode="0700"
>>>         fileOwner="root"
>>>         fileGroup="root"
>>>         fileCreateMode="0600"
>>>         dynaFileCacheSize="50"
>>>         asyncWriting="on"
>>>         flushOnTXEnd="off"
>>>         ioBufferSize="64k"
>>>     )
>>>     stop
>>> }
>>>
>>> module(load="imudp")
>>> module(load="imtcp")
>>>
>>> input(type="imudp" port="514" ruleset="remote_logging_rules")
>>> input(type="imtcp" port="514" ruleset="remote_logging_rules")
>>> ----------------------------------------------------
>>>
>>> I have a script under /etc/cron.daily that executes logrotate using the
>>> following file:
>>> ----------------------------------------------------
>>> /syslog_data/logs/*/*.log {
>>>     notifempty
>>>     rotate 4
>>>     size 10M
>>>     olddir /syslog_data/archive
>>>     compress
>>>     sharedscripts
>>>     postrotate
>>>         /bin/kill -HUP `cat /var/run/rsyslog.pid 2> /dev/null` 2>
/dev/null
>>> || true
>>>     endscript
>>> }
>>> ----------------------------------------------------
>>>
>>> If I send the HUP signal myself, then rsyslog proceeds to generate the
>>> files, but not when sent by logrotate. The devices sending logs are
>>> constantly sending logs (every minute), so I know the issue is not that
>>> they are not sending logs and therefore rsyslog doesn't generate a new
>>> file. How can I fix this?
>>>
>>> Thank you!
>>> -ABB
>>> _______________________________________________
>>> rsyslog mailing list
>>> https://lists.adiscon.net/mailman/listinfo/rsyslog
>>> http://www.rsyslog.com/professional-services/
>>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a
myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if
you DON'T LIKE THAT.

_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.

Reply via email to