That would have to have been a mariadb config file/code change to no
longer allow root at localhost to access without a password.
Based on this change adding the root@localhost type auth on Windows
then it should work.
https://jira.mariadb.org/browse/MDEV-26715
Those changes were 10.11.0 so I
Worked fine with Fedora before 40, but now get message.
Line in /etc/logrotate.d/mariadb
/usr/bin/mariadb-admin $EXTRAPARAM --local flush-error-log \
flush-engine-log flush-general-log flush-slow-log
#OUTPUT
#/usr/bin/mariadb-admin: connect to server at 'localhost' failed
#error: 'Access
t; so that the new
> file is picked up.
>
>> However, there doesn't seem to be a timer entry in systemctl output.
>> Ideas on how to get started would be appreciated.
>
> It seems that the triggering timer isn't ment
as on how to get started would be appreciated.
It seems that the triggering timer isn't mentioned in the log, but you
should see the log entries for running logrotate.
"journalctl -b -u logrotate" will list only those.
___
users mailing list -- use
Hi,
I have a fedora32 system and would like the maillog to rotate exactly
at a specific time. How do I do that? It used to be that I could
create a crontab entry but now there appears to be this timer service,
including /usr/lib/systemd/system/logrotate.timer included with the
package that appear
OK. I found by reading the head of the new messages log.
I see its termination message...
On 5/10/20 1:29 AM, Robert Moskowitz wrote:
actually the change occurred at 1am.
On 5/10/20 1:19 AM, Robert Moskowitz wrote:
I see that my various log files have been rolled over at midnight.
But
I see this line in /etc/logrotate.d/syslog:
/bin/kill -HUP `cat /var/run/syslogd.pid 2/dev/null` 2/dev/null||true
The PID file for rsyslog is actually /var/run/rsyslogd.pid, therefore
once logrotate runs the new log files, e.g., messages, maillog, etc.,
are empty. Sound like a bug to you all
On 06/11/15 03:11, Mark C. Allman wrote:
I see this line in /etc/logrotate.d/syslog:
/bin/kill -HUP `cat /var/run/syslogd.pid 2/dev/null` 2/dev/null||true
The PID file for rsyslog is actually /var/run/rsyslogd.pid, therefore
once logrotate runs the new log files, e.g., messages, maillog, etc
The script should be written to use 'file' not just parse the extension.
Why? Just because in .001% of the time the extension will be wrong? Not
exactly an efficient use of resources.
Are you in that much of a hurry to get your logwatch reports?
I'd prefer to have a more accurate program
I have an fc15 box and I'm having a problem with logwatch. I'm using
bzip2 for the compresscmd for logrotate, yet it somehow is giving the
compressed files a gz instead of bz2 extension. Logwatch uses this to
determine which command to use to read the compressed files, so it
therefore
On 10/24/2012 08:58 AM, Alex wrote:
The script should be written to use 'file' not just parse the extension.
Why? Just because in .001% of the time the extension will be wrong?
Not exactly an efficient use of resources.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or
Am 24.10.2012 19:20, schrieb Joe Zeff:
On 10/24/2012 08:58 AM, Alex wrote:
The script should be written to use 'file' not just parse the extension.
Why? Just because in .001% of the time the extension will be wrong? Not
exactly an efficient use of resources.
because it is NOT the
Alex pise:
Hi,
I have an fc15 box and I'm having a problem with logwatch. I'm using
bzip2 for the compresscmd for logrotate, yet it somehow is giving the
compressed files a gz instead of bz2 extension. Logwatch uses this to
determine which command to use to read the compressed files, so
Hi,
I have an fc15 box and I'm having a problem with logwatch. I'm using
bzip2 for the compresscmd for logrotate, yet it somehow is giving the
compressed files a gz instead of bz2 extension. Logwatch uses this to
determine which command to use to read the compressed files, so it
therefore
but there are a few remaining problems -
the main one at the moment involves Logrotate, Systemctl, Httpd and SSL.
My logrotate.conf is set up for daily rotations so I get old logs like:
/var/log/httpd/access_log-20120202
but, presumably because of the changes in Fedora from service to
systemctl
16 (x86_64) - most
things are going again happily but there are a few remaining problems -
the main one at the moment involves Logrotate, Systemctl, Httpd and SSL.
My logrotate.conf is set up for daily rotations so I get old logs like:
/var/log/httpd/access_log-20120202
People,
I have upgraded my server from Fedora 14 to Fedora 16 (x86_64) - most
things are going again happily but there are a few remaining problems -
the main one at the moment involves Logrotate, Systemctl, Httpd and SSL.
My logrotate.conf is set up for daily rotations so I get old logs like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/2011 12:23 AM, Andre Speelmans wrote:
It sounds like fail2ban still has the old log file open. You need to
have logrotate tell fail2ban that the log file has changed.
Change the config file for logrotate so that it does not create a new
I was referring to the fail2ban RPM. This has to be a problem for
just about any installation that uses logrotate.
Most daemons seem to use their own logfile and therefore can use their
own logrotate configuration script in /etc/logrotate.d.
But /var/log/secure is not handled by a specific
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/2011 09:07 AM, Andre Speelmans wrote:
I was referring to the fail2ban RPM. This has to be a problem for
just about any installation that uses logrotate.
Most daemons seem to use their own logfile and therefore can use their
own
It looks like you would have to modify the syslog logrotate script
and add a second command in the postrotate section after it restarts
syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
Or make it do copy-truncate, which is meant just for these cases where
a daemon keeps
On 10/25/2011 01:23 AM, Andre Speelmans wrote:
Change the config file for logrotate so that it does not create a new
file, but that it uses copy-and-truncate. The exact syntax is easily
found in the man-page.
Ah, that looks like what I need. I read the man page and spaced on the
implications
On 10/25/2011 11:12 AM, Mikkel L. Ellertson wrote:
It looks like you would have to modify the syslog logrotate script
and add a second command in the postrotate section after it restarts
syslogd. Does fail2ban accept a SIGHUP to close and reopen the log file?
That was my first thought, but I
On 10/25/2011 4:12 PM, Mike Wohlgemuth wrote:
On 10/25/2011 11:12 AM, Mikkel L. Ellertson wrote:
It looks like you would have to modify the syslog logrotate script
and add a second command in the postrotate section after it restarts
syslogd. Does fail2ban accept a SIGHUP to close and reopen
On Tue, 2011-10-25 at 16:12 -0400, Mike Wohlgemuth wrote:
I don't see any way to get fail2ban to reopen the log file without
also forgetting the current ban list.
As I recall, it's supposed to make temporary bans. So does it really
need to keep a ban list forever? You'd be banning things that
I've installed fail2ban on Fedora 15 to block repeated failed ssh
connections. It works great up until logrotate kicks in. When it
rotates /var/log/secure then fail2ban stops noticing failed ssh
attempts. Using fail2ban-client to reload the jail fixes the problem,
but it also causes
On Mon, Oct 24, 2011 at 10:14 AM, Mike Wohlgemuth m...@woogie.net wrote:
I've installed fail2ban on Fedora 15 to block repeated failed ssh
connections. It works great up until logrotate kicks in. When it
rotates /var/log/secure then fail2ban stops noticing failed ssh
attempts. Using
On Mon, Oct 24, 2011 at 20:17, Marvin Kosmal mkos...@gmail.com wrote:
Hi
This does not address your problem directly.
I use a program called denyhosts for blocking ssh attempts. It creates a
list in /etc/hosts.deny.
Great program.
+1 to denyhosts.
Good luck
Marvin
--
Suvayu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/24/2011 12:14 PM, Mike Wohlgemuth wrote:
I've installed fail2ban on Fedora 15 to block repeated failed ssh
connections. It works great up until logrotate kicks in. When it
rotates /var/log/secure then fail2ban stops noticing failed ssh
It sounds like fail2ban still has the old log file open. You need to
have logrotate tell fail2ban that the log file has changed.
Change the config file for logrotate so that it does not create a new
file, but that it uses copy-and-truncate. The exact syntax is easily
found in the man-page
logrotate: ALERT exited abnormally with [1]
in crontab daily i have shedule the cron job to rotatelog for specific time
2 0 * * * /usr/bin/logrotate /etc/logrotate.conf
priviously it was rotating log with no problem but from last some days
On Fri, 2011-03-18 at 00:38 -0400, Todd Zullinger wrote:
Patrick O'Callaghan wrote:
The Fedora Bugzilla is at http://bugzilla.redhat.com. You can create
an account there and then report your bug (and patch) against the
logrotate package. If it needs to be reported upstream, the package
On Fri, 2011-03-18 at 06:26 -0500, Aaron Konstam wrote:
While I try to forward reports upstream as needed, I really don't
want
to see anyone be discouraged from reporting bugs directly upstream.
That benefits us all, IMO.
OK, it is time to report ignorance. I have difficulty with the
On Thu, Mar 17, 2011 at 9:38 PM, Todd Zullinger t...@pobox.com wrote:
Patrick O'Callaghan wrote:
The Fedora Bugzilla is at http://bugzilla.redhat.com. You can create
an account there and then report your bug (and patch) against the
logrotate package. If it needs to be reported upstream
Colin McCabe wrote:
Thanks for the helpful suggestions, guys! I appreciate it.
I would like to submit this upstream, but I'm having a bit of
difficulty finding the upstream for this project. Do you happen to
have a home page or mailing list for the logrotate upstream?
I believe the current
Hi Patrick,
I was unable to create a ticket on the bug report system I found on
https://fedorahosted.org/logrotate/
It allows me to view tickets by clicking on View Tickets, but I
can't create one.
Perhaps I need to create an account, or perhaps there is another bug
tracker that would be more
On Thu, 17 Mar 2011 16:51:29 -0700
Colin McCabe cmcc...@alumni.cmu.edu wrote:
Hi Patrick,
I was unable to create a ticket on the bug report system I found on
https://fedorahosted.org/logrotate/
It allows me to view tickets by clicking on View Tickets, but I
can't create one.
Perhaps I
On Thu, 2011-03-17 at 16:51 -0700, Colin McCabe wrote:
I was unable to create a ticket on the bug report system I found on
https://fedorahosted.org/logrotate/
It allows me to view tickets by clicking on View Tickets, but I
can't create one.
Perhaps I need to create an account, or perhaps
Patrick O'Callaghan wrote:
The Fedora Bugzilla is at http://bugzilla.redhat.com. You can create
an account there and then report your bug (and patch) against the
logrotate package. If it needs to be reported upstream, the package
maintainer will do it.
As a package maintainer, I greatly
On Fri, 2011-03-18 at 00:38 -0400, Todd Zullinger wrote:
Patrick O'Callaghan wrote:
The Fedora Bugzilla is at http://bugzilla.redhat.com. You can create
an account there and then report your bug (and patch) against the
logrotate package. If it needs to be reported upstream, the package
This patch fixes a buffer overflow in logrotate. The diff was done
against trunk on http://svn.fedorahosted.org/svn/logrotate/
Sorry if this is the wrong place to post this. I didn't see a mailing
list mentioned on the project page at
https://fedorahosted.org/logrotate/
Index: config.c
This patch fixes a buffer overflow in logrotate. The diff was done
against trunk on http://svn.fedorahosted.org/svn/logrotate/
Sorry if this is the wrong place to post this. I didn't see a mailing
list mentioned on the project page at
https://fedorahosted.org/logrotate/
Fixed version with proper
On Wed, 2011-03-16 at 18:15 -0700, Colin McCabe wrote:
This patch fixes a buffer overflow in logrotate. The diff was done
against trunk on http://svn.fedorahosted.org/svn/logrotate/
Sorry if this is the wrong place to post this. I didn't see a mailing
list mentioned on the project page
Hi,
is there a way to scp or rsync the files to a remote host older than
15 days in the logrotate config and than delete it on localhost older
than 15 days, so that at a time only 15 days of logs are available on
localhost.
Thanks,
Kaushal
--
users mailing list
users@lists.fedoraproject.org
People,
Every day I want to run a script on the current, complete maillog file
so I set it up in crontab for 04:01 - one minute before the cron.daily
logrotate happens but all the maillog log files start with lines in the
file that vary between 03:00 and 04:02 - how is this possible
Philip Rhoades wrote:
People,
Every day I want to run a script on the current, complete maillog file
so I set it up in crontab for 04:01 - one minute before the cron.daily
logrotate happens but all the maillog log files start with lines in the
file that vary between 03:00 and 04:02 - how
46 matches
Mail list logo
