I have a problem with Fail2Ban
2018-02-23 18:23:48,727 fail2ban.datedetector [4859]: DEBUG Matched time template (?:DAY )?MON Day 24hour:Minute:Second(?:\.Microseconds)?(?: Year)?
2018-02-23 18:23:48,727 fail2ban.datedetector [4859]: DEBUG Got time 1519352628.000000 for "'Feb 23 10:23:48'" using template (?:DAY )?MON Day 24hour:Minute:Second(?:\.Microseconds)?(?: Year)?
2018-02-23 18:23:48,727 fail2ban.filter [4859]: DEBUG Processing line with time:1519352628.0 and ip:158.140.140.217
2018-02-23 18:23:48,727 fail2ban.filter [4859]: DEBUG Ignore line since time 1519352628.0 < 1519381428.727771 - 600
It says "ignoring Line" because the time skew is greater than the inspection period. However, this is not the case.
If indeed 1519352628.0 is derived from Feb 23, 10:23:48, then the other date: 1519381428.727771 must be wrong.
I have run tests for 'invalid user' hitting this repeatedly. But Fail2ban is always ignoring the line.
I am positive I am getting Filter Matches within 1 second.
This is Ubuntu 16.04 and Fail2ban 0.9.3
Thanks for any help you might have!
Looks like there is a time zone issue on your machine that might cause the confusion. Try to set the correct time zone and restart both rsyslogd and fail2ban.
Regarding your debug log:
1519352628.0 = Feb 23 02:23:48
-> timestamp parsed from line in log file with time Feb 23 10:23:48 - 08:00 time zone offset!
1519381428.727771 = Feb 23 10:23:48
-> timestamp of current time when fail2ban processed the log.
Coincidently this is the same time as the time in the log file. That's what makes it so confusing in this case.
1519381428.727771 - 600 = Feb 23 10:13:48
-> limit for how long to look backwards in time in the log file since you've set findtime = 10m in jail.conf.
Fail2ban 'correctly' ignores the log entry that appears to be older than 10 minutes, because of the set time zone -08:00.
btw:
If you need IPv6 support for banning, consider upgrading fail2ban to v0.10.x.
And there is also a brand new fail2ban version v0.11 (not yet marked stable, but running without issue for 1+ month on my machines) that has this wonderful new auto-increment bantime feature.
Related
Yesterday we had crash of PostgreSQL 9.5.14 running on Debian 8 (Linux xxxxxx 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux) - Segmentation fault. Database closed all connections and reinitialized itself staying ~1 minute in recovery mode.
PostgreSQL log:
2018-10-xx xx:xx:xx UTC [580-2] LOG: server process (PID 16461) was
terminated by signal 11: Segmentation fault
kern.log:
Oct xx xx:xx:xx xxxxxxxx kernel: [117977.301353] postgres[16461]:
segfault at 7efd3237db90 ip 00007efd3237db90 sp 00007ffd26826678 error
15 in libc-2.19.so[7efd322a2000+1a1000]
According to libc documentation (https://support.novell.com/docs/Tids/Solutions/10100304.html) error code 15 means:
NX_EDEADLK 15 resource deadlock would occur - which does not tell me much.
Could you tell me please if we can do something to avoid this problem in the future? Because this server is of course production one.
All packages are up to date currently. Upgrade of PG is unfortunately not the option. Server runs on Google Compute Engine.
error code 15 means: NX_EDEADLK 15
No, it doesn't mean that. This answer explains how to interpret 15 here.
It's bits 0, 1, 2, 3 set => protection fault, write access, user mode, use of reserved bit. Most likely your postgress process attempted to write to some wild pointer.
if we can do something to avoid this problem in the future?
The only thing you can do is find the bug and fix it, or upgrade to a release of postgress where that bug is already fixed (and hope that no new ones were introduced).
To understand where the bug might be, you should check whether a core dump was produced (if not, do enable them). If you have the core, use gdb /path/to/postgress /path/to/core, and then where GDB command. That will give you crash stack trace, which may allow you to find similar bug reports.
So, I have been using celery/beat for a number of years, and have been ofsetting manually, the schedule of my tasks due to DST issues etc. As my codebase has become larger, the script that I run to change the times is getting bigger and bigger, and I have decided to sort the problem out.
So in short, my system clock updates automatically, from my shell I can run:
┌─[luke#freebsd] - [~/py3-apps/intranet] - [Thu Mar 29, 12:24]
└─[$]> date
Thu Mar 29 12:37:22 BST 2018
So presently I have a task to run at 10:30am, it will run at 11:30am. So I thought this would be easy, I added the following to my configuration:
CELERY_TIMEZONE = Europe/London
CELERY_ENABLE_UTC = False
When I run my celery beat schedule, via:
celery worker --beat -A pyramid_celery.celery_app --ini development.ini -n celeryIntranetAPI
Now I thought this would solve my problems, however my cron tasks are still an hour behind, how can I make celery keep up with the system clock?
Note I have tried:
CELERY_TIMEZONE = UTC
CELERY_ENABLE_UTC = True
As per a few suggestions, but this did not work either.
Can anyone can shed some light on how I can link my celery cron timings to the system clock?
This was fixed in celery here: https://github.com/celery/celery/commit/be55de622381816d087993f1c7f9afcf7f44ab33
Turns out this was a bug with celery, fixed here
I have a spring boot application using spring data to retrieve data from an Oracle database. When I run the code locally in embedded Tomcat, the date appears correctly. However, the same code when deployed to Weblogic server gives a completely different date/time result. I have confirmed that the timezone on the Weblogic server is the same as my local timezone (US/Eastern).
What is odd is that the minutes are being stripped out and always set to 00, and also the time difference between the correct date and the date displayed is unpredictable (one example is 16 hours behind, and with a different example, it's 19 hours)
jpa mapping:
import java.util.Date;
...
#Temporal(TemporalType.TIMESTAMP)
#Column(name = "INITIAL_CREATE_DATE")
private Date initialCreateDate;
controller log statement:
SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy hh:mm z");
...
log.info("~~create date: " + medley.getInitialCreateDate() + " sdf " + sdf.format(medley.getInitialCreateDate()));
output from Weblogic (WRONG):
~~create date: Thu Oct 26 20:00:00 EDT 2017 sdf 10/26/2017 08:00 EDT
output from local Tomcat and spring data unit tests (CORRECT):
~~create date: 2017-10-27 11:57:53.0 sdf 10/27/2017 11:57 EDT
Two things that stand out to me (besides the date/time being totally wrong)
1. The time is missing the minutes
2. The format is different on the .toString() output for the date
Any help or ideas how I can further troubleshoot this problem are very much appreciated!
I figured my problem out - posting my answer, maybe it will help someone else.
My "medley" object was not retrieved directly from the database here. It was retrieved by a job that then posted this medley object as JSON to this method here that outputs the date. While I still don't understand the odd date/time behavior, at least now I know the fix.
My previous version of the code was using #Temporal(TemporalType.DATE)
and serializing json as this...
"initialCreateDate": "2017-10-27",
which I don't understand why this was being converted to Thu Oct 26 20:00:00 - but at least I know that applying the #Temporal(TemporalType.TIMESTAMP) in my job fixed the problem. (i.e. updating the version of the repository code in pom.xml to the same version used by the service)
This is the correct serialization of the date/time:
"initialCreateDate":1509119873000
Im trying to measure our cisco router availability data based on downtime happened. I assume from show version, the time mentioned in tag "System returned to ROM" is when reload started, and next line "System restarted at" is when router back online again. The only thing confusing is RouterA node showing time when returned to ROM while RouterB is not.
Does anyone know the different? And how to make RouterB shows the exact time router reloaded next time on the show version command?
Thanks
Hadit
RouterA#show version
Cisco IOS Software, s72033_rp Software (s72033_rp-ITPK9V-M), Version 12.2(33)IRI, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Fri 04-May-12 14:04 by prod_rel_team
ROM: System Bootstrap, Version 12.2(17r)S4, RELEASE SOFTWARE (fc1)
RouterA uptime is 4 years, 11 weeks, 5 days, 17 hours, 27 minutes
Uptime for this control processor is 4 years, 11 weeks, 5 days, 17 hours, 19 minutes
System returned to ROM by reload at 00:01:24 JAVT Thu Oct 11 2012 (SP by reload)
System restarted at 00:05:58 JAVT Thu Oct 11 2012
System image file is "bootdisk:s72033-itpk9v-mz.122-33.IRI.bin"
Last reload type: Normal Reload
RouterB#show version
Cisco IOS Software, s72033_rp Software (s72033_rp-ITPK9V-M), Version 12.2(33)IRI, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Fri 04-May-12 14:04 by prod_rel_team
ROM: System Bootstrap, Version 12.2(17r)S4, RELEASE SOFTWARE (fc1)
RouterB uptime is 4 years, 12 weeks, 6 days, 17 hours, 51 minutes
Uptime for this control processor is 4 years, 12 weeks, 6 days, 17 hours, 54 minutes
System returned to ROM by reload (SP by reload)
System restarted at 00:16:21 JAVT Wed Oct 3 2012
System image file is "bootdisk:s72033-itpk9v-mz.122-33.IRI.bin"
Last reload type: Normal Reload
Do not rely on those commands to measure availability, you are much better off using a proper uptime tool to handle this for you, there are several free ones like Zabbix, PRTG and others and commercial ones like Solarwinds, HP NNM and others.
The output of those commands may change without notice hence not a good idea to rely on them for things that c an be automated using proper tools.
We're running the Context Broker on a CentOS server but it keeps crashing with certain update queries. We've tried version 0.26 and the latest 1.0.0-1 but the result is the same, we've also tried changing the mongoDB version between 3.0.6 and 3.0.7 but no luck. The logs doesn't give us much to go on so that's why we're asking here in SO.
What we're doing is to send an update of an entity of about 1MB in size routed in from a http call via nginx. The context broker crashes (see logs below) but mongodb and other services continue to function normally.
Log file: /var/log/contextBroker/contextBroker.log
terminate called after throwing an instance of 'mongo::MsgAssertionException'
what(): EOO Before end of object
Log file: /var/log/messages
Apr 28 07:15:50 gl abrt[11457]: Saved core dump of pid 11426 (/usr/bin/contextBroker) to /var/spool/abrt/ccpp-2016-04-28-07:15:49-11426 (63606784 bytes)
Apr 28 07:15:50 gl abrtd: Directory 'ccpp-2016-04-28-07:15:49-11426' creation detected
Apr 28 07:15:50 gl abrtd: Package 'contextBroker' isn't signed with proper key
Apr 28 07:15:50 gl abrtd: 'post-create' on '/var/spool/abrt/ccpp-2016-04-28-07:15:49-11426' exited with 1
Apr 28 07:15:50 gl abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2016-04-28-07:15:49-11426'
Output from the contextBroker when it's run in verbose mode:
INFO#14:05:27 logMsg.h[1792]: Starting transaction from 127.0.0.1:51245/v1/updateContext
INFO#14:05:27 connectionOperations.cpp[78]: Database Operation Successful (query: { id.id: "8a55c32500dfad.....06be56709b75b31c1f9beb7d2", id.type: "House", _id.servicePath: /^\/$/ })
terminate called after throwing an instance of 'mongo::MsgAssertionException'
what(): BSONElement: bad type 100
Any ideas about what could be causing this, or where we should continue looking?
This crash is due to a bug detected at Orion. A fix is on the way, so we hope it get merged and ready to be included in next Orion release (Orion 1.2.0).