I have some app filling up my log, so went to look at the log...and saw this...

 

http://my.jetscreenshot.com/12412/20161227-x854-115kb.jpg[/img]

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(300) : eval()'d code on line 73

 

My log is set at 128mb.

 

Is this an error because its trying to write beyond the max size of the log?

 

I could not find the log on the flash drive.  Latest log is dated yesterday...

 

I suppose I could just reboot and watch the log for a while, but this is puzzling...

An app filling up your log isn't normal. If you want help with that particular problem you will have to give us more information.

Apologies, didn't see the error in the img code above.  Fixed that.

 

As to more info, I don't actually have more info to share - that's the problem, my syslog is empty!?! 

 

This indicates the log is full, correct?

http://my.jetscreenshot.com/12412/20161229-bge3-33kb.jpg[/img]

 

Yet, these are all the ways I know to get to the syslog.  Everything is blank, and MC shows the /var/log/syslog as 0 bytes.

http://my.jetscreenshot.com/12412/20161229-z76j-281kb.jpg[/img]

 

In the diagnostics file, the syslog has 0 bytes.  There is a syslog1.txt which has numerous entries.  I'm not familiar with what the community apps log entries should look like, but there are thousands of entries from community apps, appdata backup and plex.  Dynamix seems to have hundreds of entries like this.  All unique based on the 12 digit number at the end of the entry. All appear to be notifications for hot disks (when a parity or appdata backup runs, disks always get hot (50-55c), there are notifications for each disk in the array), appdata files backed up, etc.

 

Community_Applications_USB_Backup/config/plugins/dynamix/notifications/archive/unRAID_Status_1464412801.notify
Dec 27 03:04:32 HunterNAS rsyncd[30020]: >f+++++++++ 

Community_Applications_USB_Backup/config/plugins/dynamix/notifications/archive/unRAID_Disk_10_message_1455437461.notify
Dec 27 03:04:32 HunterNAS rsyncd[30020]: >f+++++++++ 

etc...

 

They all look reasonable, but I'm not familiar enough with normal log behavior with these apps...is there a place to learn what is normal log behavior...or is it just something you eventually discover?

 

I've also included the diagnostics file.  Should have done that first, again apologies.

 

Am I missing something?

hunternas-diagnostics-20161229-0752.zip

CA Backup logs everything under normal circumstances to the docker.img file (or to RAM if docker isn't running)

 

But, if the docker.img is completely filled up (or has issues), then rsync on its own accord switches the log file from the one that I specify to the syslog.

 

But without looking at your diagnostics, it appears that the docker.img is fine, so not quite sure why rsync decided to log into the syslog.  I have been thinking about switching everything over to a temp file on the array to avoid this problem in the future however.

 

A reboot will however fix you up...

Looks like some issue with the way you have CA Backup configured.

 

In my syslog I have this line when the appdata backup starts:

Dec 29 03:00:44 unSERVER root: Backing Up appData from /mnt/cache/appdata/ to /mnt/disk5/Backup/unRAID_cache/appdata

and then after that I don't get anything in my syslog about each file that gets backed up from appdata.

 

In your syslog, you have this line when the appdata backup starts:

Dec 27 03:02:01 HunterNAS root: Backing Up appData from /mnt/cache/appdata/ to /[email protected]

the [email protected] is the result of diagnostics anonymizing your email address, but of course your email address should not be the destination of the backup. Then after that your syslog begins to fill up logging each file in your appdata, including the Plex library, which of course has many thousands of files.

 

So possibly a side effect of a misconfigured CA Backup.

So possibly a side effect of a misconfigured CA Backup.

Its not anything misconfigured in the Backup.  Like I've said, if rsync can't write to the specified log file, then rather than not logging anything it instead logs to the syslog.  A PITA for me, but not much I can do about it. 

 

I've been thinking about relocating the location of where I store the logs (currently within the docker.img file), but ultimately no matter where it gets placed the same issue might still pop up....  And everything has to be logged since any errors in the backup will get displayed based upon the logged errors.  Unfortunately it is potentially a very large file....

So possibly a side effect of a misconfigured CA Backup.

Its not anything misconfigured in the Backup.  Like I've said, if rsync can't write to the specified log file, then rather than not logging anything it instead logs to the syslog.  A PITA for me, but not much I can do about it. 

 

I've been thinking about relocating the location of where I store the logs (currently within the docker.img file), but ultimately no matter where it gets placed the same issue might still pop up....  And everything has to be logged since any errors in the backup will get displayed based upon the logged errors.  Unfortunately it is potentially a very large file....

I meant the way he had configured CA Backup. If it is not misconfigured in some way, then why does it have this:

...

In your syslog, you have this line when the appdata backup starts:

Dec 27 03:02:01 HunterNAS root: Backing Up appData from /mnt/cache/appdata/ to /[email protected]

the [email protected] is the result of diagnostics anonymizing your email address, but of course your email address should not be the destination of the backup...

So possibly a side effect of a misconfigured CA Backup.

Its not anything misconfigured in the Backup.  Like I've said, if rsync can't write to the specified log file, then rather than not logging anything it instead logs to the syslog.  A PITA for me, but not much I can do about it. 

 

I've been thinking about relocating the location of where I store the logs (currently within the docker.img file), but ultimately no matter where it gets placed the same issue might still pop up....  And everything has to be logged since any errors in the backup will get displayed based upon the logged errors.  Unfortunately it is potentially a very large file....

I meant the way he had configured CA Backup. If it is not misconfigured in some way, then why does it have this:

...

In your syslog, you have this line when the appdata backup starts:

Dec 27 03:02:01 HunterNAS root: Backing Up appData from /mnt/cache/appdata/ to /[email protected]

the [email protected] is the result of diagnostics anonymizing your email address, but of course your email address should not be the destination of the backup...

I've seen that in prior diagnostics, but admittedly have never looked at my own to see what the anonomizer does to it.

The [email protected] is normal depending upon how you have CA Backup configured.  If you're using dated backup sets, then the anomizer will put that in there.  Simply because it looks like it assumes anything with an @ sign is an email address, and the destination folder in this case does have an @ in the name.

 

Even stranger is that on the following line where the actual rsync command is displayed, the anonomizer simply removes the destination instead of anonomizing it (which makes the command appear to be invalid) 

So possibly a side effect of a misconfigured CA Backup.

Its not anything misconfigured in the Backup.  Like I've said, if rsync can't write to the specified log file, then rather than not logging anything it instead logs to the syslog.  A PITA for me, but not much I can do about it. 

 

I've been thinking about relocating the location of where I store the logs (currently within the docker.img file), but ultimately no matter where it gets placed the same issue might still pop up....  And everything has to be logged since any errors in the backup will get displayed based upon the logged errors.  Unfortunately it is potentially a very large file....

I meant the way he had configured CA Backup. If it is not misconfigured in some way, then why does it have this:

...

In your syslog, you have this line when the appdata backup starts:

Dec 27 03:02:01 HunterNAS root: Backing Up appData from /mnt/cache/appdata/ to /[email protected]

the [email protected] is the result of diagnostics anonymizing your email address, but of course your email address should not be the destination of the backup...

I've seen that in prior diagnostics, but admittedly have never looked at my own to see what the anonomizer does to it.

Nevertheless /[email protected] is not a valid backup destination. Whether he put that as the backup destination, or he put in something that anonymizer thought it needed to anonymize because it looked like an email address, or something else about processing the form caused that to appear where the backup destination should be, I couldn't say.

Nevertheless /[email protected] is not a valid backup destination. Whether he put that as the backup destination, or he put in something that anonymizer thought it needed to anonymize because it looked like an email address, or something else about processing the form caused that to appear where the backup destination should be, I couldn't say.

Mine shows the same thing.  Its because the anonymizer is taking the destination folder which is 12-29-16@13:53 and changing it to [email protected] simply because of the @ sign in the destination

Nevertheless /[email protected] is not a valid backup destination. Whether he put that as the backup destination, or he put in something that anonymizer thought it needed to anonymize because it looked like an email address, or something else about processing the form caused that to appear where the backup destination should be, I couldn't say.

Mine shows the same thing.  Its because the anonymizer is taking the destination folder which is 12-29-16@13:53 and changing it to [email protected] simply because of the @ sign in the destination

OK, that makes sense. I've never used dated backups (as you might have guessed from another post I made about CA Backup). I guess anonymizer is taking a very lazy approach of parsing emails addresses.

So here's my CA config.  Nothing out of the ordinary and I didn't configure any email address...in fact I didnt see one with the CA config... ?

 

http://my.jetscreenshot.com/12412/20170106-paa9-209kb.jpg[/img]

So here's my CA config.  Nothing out of the ordinary and I didn't configure any email address...in fact I didnt see one with the CA config... ?

I will let Squid respond on the CA Backup specifics, but the email address used would be the one you have configured in Settings - Notifications.

So here's my CA config.  Nothing out of the ordinary and I didn't configure any email address...in fact I didnt see one with the CA config... ?

I will let Squid respond on the CA Backup specifics, but the email address used would be the one you have configured in Settings - Notifications.

So here's my CA config.  Nothing out of the ordinary and I didn't configure any email address...in fact I didnt see one with the CA config... ?

 

http://my.jetscreenshot.com/12412/20170106-paa9-209kb.jpg[/img]

You guys missed and/or didn't understand my responses.  The mere fact of having Dated Backups enabled is triggering the anonymizer on the logs because the folder name has an @ within the folder name.  There is no issue (outside of the fact that the diagnostics anonymizer thinks that anything that has an @ sign is an email address)

You guys missed and/or didn't understand my responses.  The mere fact of having Dated Backups enabled is triggering the anonymizer on the logs because the folder name has an @ within the folder name.  There is no issue (outside of the fact that the diagnostics anonymizer thinks that anything that has an @ sign is an email address)

Actually I did understand at the time, but that was over a week ago and I didn't bother to review the thread.

You guys missed and/or didn't understand my responses.  The mere fact of having Dated Backups enabled is triggering the anonymizer on the logs because the folder name has an @ within the folder name.  There is no issue (outside of the fact that the diagnostics anonymizer thinks that anything that has an @ sign is an email address)

 

Sorry, I get it now.  So, what can I do to correct this issue?  I have no logs being created.  Not even a syslog.  They are all blank...

odds on in the dashboard you'll see the log is at 100%.  A reboot will fix it up.  Before the backup log was going into your syslog because rsync decided that there was something wrong with your docker.img

odds on in the dashboard you'll see the log is at 100%.  A reboot will fix it up.  Before the backup log was going into your syslog because rsync decided that there was something wrong with your docker.img

 

You are correct.  A reboot and I'm seeing my logs now.  So now, I guess, the challenge is to determine what's filling it up.  I've attached my diagnostics (right after boot).  See anything of interest?

 

hunternas-diagnostics-20170106-2115.zip

Outside of the fact that you need to increase the number of inotifywatches so that dynamix file integrity will work properly, there's nothing wrong.

 

*But* your original diagnostics showed CA Backup filling up the log, and I just ran through a thought experiment on what possible events could cause the datastore directory to not get created on a perfectly valid docker.img which would cause CA to fill up the log, and I came up with one.  Will be issuing an update to CA backup tomorrow to address this.

Outside of the fact that you need to increase the number of inotifywatches so that dynamix file integrity will work properly, there's nothing wrong.

 

*But* your original diagnostics showed CA Backup filling up the log, and I just ran through a thought experiment on what possible events could cause the datastore directory to not get created on a perfectly valid docker.img which would cause CA to fill up the log, and I came up with one.  Will be issuing an update to CA backup tomorrow to address this.

 

I'm glad this furthered our technology along!  RE: inotifywatches, how/where do I increase those?

Outside of the fact that you need to increase the number of inotifywatches so that dynamix file integrity will work properly, there's nothing wrong.

 

*But* your original diagnostics showed CA Backup filling up the log, and I just ran through a thought experiment on what possible events could cause the datastore directory to not get created on a perfectly valid docker.img which would cause CA to fill up the log, and I came up with one.  Will be issuing an update to CA backup tomorrow to address this.

 

I'm glad this furthered our technology along!  RE: inotifywatches, how/where do I increase those?

I would think that your using dynamix file integrity, so it should have a method to increase it there

 

I would think that your using dynamix file integrity, so it should have a method to increase it there

 

I've looked at both the File Integrity Control page and the File Integrity Settings page, but not seeing any parameter called inotifywatches.  I've not seen any advanced tabs on any of those pages.  Where should I look?

I would think that your using dynamix file integrity, so it should have a method to increase it there

 

I've looked at both the File Integrity Control page and the File Integrity Settings page, but not seeing any parameter called inotifywatches.  I've not seen any advanced tabs on any of those pages.  Where should I look?

Don't use the plugin, so really can't say.  You should probably post in the thread asking about adding it in.

 

You can see how many maximum watches are currently set via

cat /proc/sys/fs/inotify/max_user_watches

 

To increase them,

 

echo 1234567 > /proc/sys/fs/inotify/max_user_watches

(change the number to suit)

 

However, you'd want to add this command to the "go" file so that it's persistent through a reboot.  Hence why I suggest to post about the max # of watches.  (your syslog stated that you had exceeded the maximum number of watches)