Log Files Always Empty

Hi, please try the following. Disable and re-enable the plugin and then check the log files after a few days. Report back.

Thank you

Ok, just a plugin restart basically, don’t set or change anything right? Just want to make sure I do it right

BTW, for what its worth this has been like this since the day I installed it, nothing new and that was safely at least 10 months ago around or after Valentine’s.

It has been updated since then, so was hoping that had the same effect. But will do and get back to you. Thanks.

Hi, one possible reason why your log files are empty is that the log files are always emptied on plugin update.

I believe this “feature” is not intended and rather a side-effect of an unfortunate decision to keep the log files inside plugin’s directory. Expect this to be fixed in some future version of the plugin.

Cheers,
?eslav

I see, that makes sense why it can happen. But it’s been a while since the last time it has been updated and never that frequently that would cause it to never have any logs, right?

Hmm…interesting; maybe they can look into protecting the logs a bit more by maybe using the same method as some security tools which put their “log” folders or whatnot in an upload sub-directory with a restrictive .htaccess file that protects them from external access yet still gives internal control over having permission there and whatever happens in the plugin directory won’t affect those since they won’t be ensnared. SO the logs can be trimmed based on in-plugin option of trimming schedule instead.

Just a thought, thinking out loud. As for the directory name in the upload folder, I have worked with colleagues on custom solutions where we had the plugin generate a random folder name on first-use and then stores that in its own settings so it knows what the path is but since its random, public facing side of the website will never know it and throw in an .htaccess file, this makes it entirely protected for all but the most insidious techniques to gain access.

Thanks again. In the meantime, I did what I was told and “restarted” the plugin and will wait a couple of days to see if anything shows up. SO far, I checked prior to this posting, nothing was there yet. Will keep you posted.

Ok, as a good sport, I did what I was told even though I knew it had nothing to do with the lack of logs but wanted to make sure.

As usual, no logs, and I took this screenshot BEFORE the update that came today and as you can see, since what you told me and this update, NOTHING.

So what now? I mean I can’t rely on a security tool that provides no logs, so easily dumps them apparently (since they now put that in the notes too), and if it is not going to be fixed or seriously supported.

Hmm, it’s strange, logs should be working. Just to be sure, since you haven’t mentioned it – you have logging enabled in settings (AIOWPSF > Settings (page) > General Settings (tab) > Enable Debug)?

Btw. thanks for your thoughts regarding .htaccess file. The plugin actually creates this file, but in a flawed way. A patch for this has been just merged and should be available in next version.

@chesio, thank you for the kind words, glad for your efforts and look forward to the update.

In the meantime, I want to make sure that THIS setting is what you are referring to and what creates the files missing in the shots above:

In the meantime, I decided to reset (aka uncheck/save/recheck/save) this setting in case the earlier advice to restart the plugin was a misspeak and it was maybe actually meant to say restart THIS setting. By the time you confirm it, I would have an answer if resetting this made a difference BTW. Let’s sleep on it ??

@guardian74, yes, it’s this setting. I think resetting it shouldn’t be necessary, but let’s see, if it makes any difference in your case.

@chesio, Thank you, and well having to restart a plugin should not be necessary either but that was offered as a solution, so this wasn’t any more silly to try given nothing else seems to make it work right.

And no, it did nothing, the setting is checked, still checked, and we have waited enough before/after the updates that it should be there, but still empty files. I am not even going to bother with a screenshot because it is no different than all the ones already submitted.

wp-security-log.txt: Log file is empty!
wp-security-log-cron-job.txt: Log file is empty!

So where to now? because this has more than jumped the shark into the ridiculous. Let me know what else you need to figure this out.

Thanks, Mike.

Hi Mike,

The recent version (4.2.3) now has a permanent .htaccess file with access deny directives in logs directory. Thanks once more for your thoughts on this!

So where to now? because this has more than jumped the shark into the ridiculous. Let me know what else you need to figure this out.

Ok, let us please tackle your problem step by step:

1. Update the plugin to 4.2.3 so we are on the same level.
2. Make sure you have logging enabled in plugin settings. I know you already did, but just in case.
3. Run an action that result in a message being written to log file. One example is running a manual DB backup – if the backup procedure proceeds correctly, there should be a message in the wp-security-log informing you about attempted deletion of old backup files.
4. Check contents of wp-security-log via plugin dashboard. If it says the log is empty, please check the contents of the file directly on your webserver – either via FTP or webFTP if you have one. Log files are in logs subdirectory of the plugin.

If the log file is empty, the only explanation I can think about is that your webserver cannot write to it due file permissions. Could you please check what are file permissions of log files? Related questions: Can you update your plugins from within WordPress dashboard? If so, did you have to give WordPress your FTP credentials or did it work right away?

Cheers,
?eslav

• This reply was modified 8 years ago by ?eslav Przywara.
• This reply was modified 8 years ago by ?eslav Przywara.
• This reply was modified 8 years ago by ?eslav Przywara.

I wanted to confirm that I got your instructions and I will get on them ASAP but you have to forgive me about a day or so to get to it as I am in the midst of grading class projects for C++ and to say I have come across some real freakshows is an understatement. I want to make sure I can focus on it without distractions so I can give you useful feedback. Thank you.

Quick responses:
#1 – already done, this morning
#2 – already done, will recheck
#3 – will do
#4 – last time the file was also empty, will recheck

Permissions are and to the best of my knowledge always have been as follows:

[rwxr-xr-x] ..
 [rw-r--r--] .htaccess
 [rw-r--r--] index.html
 [rw-r--r--] wp-security-log.txt
 [rw-r--r--] wp-security-log-cron-job.txt

I was just looking and oh my god since the update this morning, the wp-security-log-cron-job.txt suddenly has something in it:

[11/28/2016 8:46 PM] - SUCCESS : Filescan - Scheduled fcd_scan is enabled. Checking now to see if scan needs to be done...
[11/28/2016 8:46 PM] - SUCCESS : Filescan - Scheduled fcd_scan is enabled. Checking now to see if scan needs to be done...
[11/28/2016 9:46 PM] - SUCCESS : Filescan - Scheduled fcd_scan is enabled. Checking now to see if scan needs to be done...
[11/28/2016 10:47 PM] - SUCCESS : Filescan - Scheduled fcd_scan is enabled. Checking now to see if scan needs to be done...
[11/28/2016 11:46 PM] - SUCCESS : Filescan - Scheduled fcd_scan is enabled. Checking now to see if scan needs to be done...
[11/29/2016 12:47 AM] - SUCCESS : Filescan - Scheduled fcd_scan is enabled. Checking now to see if scan needs to be done...
[11/29/2016 12:53 AM] - SUCCESS : Filescan - Scheduled fcd_scan is enabled. Checking now to see if scan needs to be done...
[11/29/2016 1:47 AM] - SUCCESS : Filescan - Scheduled fcd_scan is enabled. Checking now to see if scan needs to be done...

I don’t know what changed since the update but at least now it has some life, I will keep feeding it and see if I can make it grow then we can safely say it is resolved. OK?

• This reply was modified 8 years ago by Gμ?rD???. Reason: formatting

[…] as I am in the midst of grading class projects for C++ and to say I have come across some real freakshows is an understatement.

Sounds like a lot of fun ?? Take your time!

• This reply was modified 8 years ago by ?eslav Przywara.

The only fun part of it is the reminder of all the epic fails mishandling pointers and memory allocations; like going down memory lane circa 1990. Phew, but that’s the learning process right?

But to still be amazed and surprised by new creative ways by which they completely BOMB the system nearly causing a meltdown – now that never gets old (if I may twirl my mustache and do a bad Mr. Burns impression).

Now back on topic.

As of the writing of this reply, and still haven’t had a chance to purposefully trigger anything; but seems it has generated some entries on its own. For example, wp-security-log now shows:

[11/29/2016 11:54 AM] - SUCCESS : File Change Detection Feature: change to filesystem detected!

this was empty the last reply. It is only one line but that’s enough to see it is working and you really don’t want or see a lot in there anyway if everything is ok, that’s my assumption. As for wp-security-log-cron-job, it added a ton more entries to what I posted in the last reply, much of them were same type already posted but the especially new are these two lines it seems since last review:

[11/29/2016 8:48 AM] - SUCCESS : Cronjob_Handler - Daily cron handler got fired.
[11/29/2016 8:48 AM] - SUCCESS : DB Cleanup - checking if a cleanup needs to be done now...

so cursory evaluation would say whatever it was resolved itself and the update was a good one, so first thing – thank you. If you’d like, you can tentatively mark this as resolved and I will update it should something creep back up; how’s that? work for you guys?

Thanks again for sticking with this, it was very refreshing to see developers stick to an issue until resolved instead of pretending it doesn’t exist ??

Thanks again for sticking with this, it was very refreshing to see developers stick to an issue until resolved instead of pretending it doesn’t exist ??

Well, thanks for sticking with this issue too ?? There’s a plenty of support requests that are “unsolved”, because their reporters fail to provide additional feedback or just never come back to say “Thank you, my problem is solved”.

Well you have no idea how many developers become defensive and stick their head in the sand and claim that the problem is the user and no matter what they provide to prove it, it always comes back, I can’t see it on my perfect bubble system so it is not happening and if a million people are not reporting it, then again its not real. It is such a dumb approach that I often get frustrated enough to lash out or just dump their crap and move on. The whole policy of its free so it’s ok for it to be crap and for me to not support it is such a shameful crutch for bad wannabe programmers who can’t find their asses with both hands and a GPS.

That being said, I ALWAYS put in my due diligence and time to help figure something out because often that’s your only contact with the developer, so if you don’t meet them half way, no relationship can be built. Also, there is no way to know what kind of developer you are dealing with and their integrity, until you see how they approach the support request. Especially complicated when delusional and narcissistic wannabes act like they are too perfect to make any mistake and makes the whole process devolve.

Consider that the long explanation for why I said that to you and showed my gratitude. It has become more and more rare and devolving into money grabs – here is a broken solution so you have to pay me for the pro – and what they don’t realize is, why would anyone in their right mind want to pay for your pro service, if they can’t even get your program to work? right? They are so blinded by greed, they completely overlook the bad impression that will result in no conversion. </rant>

Again, thank you for your help, it has resolved the issue. I am glad good things came out of this interaction and I look forward to continuing to support it. Once vested in something, I remain loyal to it’s success. Good on you for handling it right.

PS. The logs keep growing and adding more information, so it seems we can safely say it is fixed, thanks man. I will disable the logging now that I know it works when I need it, so to lighten the overhead a bit; although it seems to be good at not throwing a monkey wrench in things, can’t say that about others whose db backup was locking up the server for days and never releasing causing the site to break, so dumb – and they don’t even acknowledge it or fix it since they have posted on the forums here that they don’t provide support unless you pay them, so stupid.