[Plugin] CA Fix Common Problems


Recommended Posts

Squid posted in another thread that FCP will scan for duplicates, which I did not know.  I've just done it, and it did find many on my system; which is great.  however, the only way to see the results was in the popup window, and the formatting made it quite hard to follow and get to the problem files.

 

Is there/could there be a report/log I could grab to pull into some other program to help format to make it easier to act upon?

 

Also, some of the errors referred to illegal characters, and 3 of my files had ... as the 'character' it seems to have had issue with.  I checked in my media program, and it seems I have it entered as 3 dots, not one ellipsis character, so I'm not sure if it's not saving that way, or if the test is flawed.  I'm not sure how to 'fix' the issue either way.

 

Otherwise; great job on this test, it helped me clean up a lot of stuff.  I'm running again to see what I may have missed on the first pass.

Link to comment

Upon entering the page to re-run the extended test, I was greeted with the scanning window.  it's been scanning for almost 10 minutes now.  I understand this is not normal.  how do I help troubleshoot why it's taking so long scanning, and/or how can I just stop it?

 

I opened a new window and quickly hit run extended test, and it started.  I was then able to see this error...

 

Unable to communicate with GitHub.com Reset your modem / router or try again later, or set your

to 8.8.8.8 and 8.8.4.4 Also make sure that you have a Gateway address set up (Your Router's IP address)

 

I assume that's the cause of the extended hanging of the scan.  Problem is I have shitty satellite internet and it's pretty intermittent, so there's not much I can do to fix this, other than try again.  I can't do that while the popup window is displayed though.

Edited by JustinChase
Link to comment
Hi @Squid,
 
Here is a laundry list of ideas for FCP to check. It is possible they are too opinionated or too obscure or too hard to support, but I thought I'd mention them. And apologies if FCP already does any of them :)
 
1. Check if a cache drive need to be reformatted because it was created in an older version of UD:
 
2. Check docker xml files for environment variables being passed as extra params ("- e") . This is being recommended in the Lets Encrypt thread and it causes problems when the extra params conflict with variables set in the docker templates:
 
3. Check for "--device" being passed to dockers as extra params. This is being recommended in these threads:
and could result in the same issue as above. Better to use fields rather than extra params when the fields are available.
 
4. If unRAID < 4.6.0 and VMs are enabled, see if domain.cfg is missing a MEDIADIR as this causes problems with the upgrade to 4.6.0
Then again, if 4.6.1 relaxes this requirement it may no longer be an issue.
 
5. if there are any packages in /boot/extras, recommend that users delete them and install via Nerd Tools plugin instead. 
 
6. Check go script for references to cache_dirs script and suggest installing the Dynamix Cache Directories plugin instead. 
 
7. If the go script (< 6.4.0) or ident.cfg (>= 6.4.0) references ports other than 80 or 443, and if those customized ports are less than 1000, warn the user. The risk is that misusing a "well known" port will cause problems if other services are added to unRAID down the road.
 
8. If the go script includes "zenstates" without the full path "/usr/local/sbin/zenstates", warn user that it is not actually running. ( When the go script executes, the $PATH variable does not contain "/usr/local/sbin" )
 
 
9. Also... currently I have multiple exclusions related to disks being spun down:
* "Disk(s)  disk1  disk2  disk3  are spun down.  Skipping write check and HPA check": "true",
* "Disk(s)  disk2  disk3  are spun down.  Skipping write check and HPA check": "true",
* "Disk(s)  disk3  are spun down.  Skipping write check and HPA check": "true",
Would it be possible to consolidate those down to one exclusion? As I add more drives there will be more combinations.  Actually, I'm a little surprised there isn't one for "disk1 disk3" yet.
 
 
Link to comment

I have experienced several crashes of my UnRaid system over the past few months, most recently, yesterday.  I understand that if I enable troubleshooting mode, logs as well as diagnostics will be continually written to my flash  drive.  My only concern is that these crashes happen infrequently, maybe once every two weeks or so.  I have a 32 gig flash drive so I should have enough space but will the constant writing over a period of weeks damage the drive?  If so, what are the alternatives?  Hooking up a monitor after the crash before I manually reboot the system?  Running memtest? BTW, I'm running a Ubuntu VM if that's still an issue. Thanks, any feedback is appreciated.

Link to comment
19 hours ago, ljm42 said:

1. Check if a cache drive need to be reformatted because it was created in an older version of UD:

I don't like adding in tests that I can't replicate.  Should get less and less frequent over time

19 hours ago, ljm42 said:
4. If unRAID < 4.6.0 and VMs are enabled, see if domain.cfg is missing a MEDIADIR as this causes problems with the upgrade to 4.6.0
 

I expect 6.4.1 to fix this issue.  Then the test becomes moot anyways

19 hours ago, ljm42 said:
5. if there are any packages in /boot/extras, recommend that users delete them and install via Nerd Tools plugin instead. 
 

I currently check for 32 bit packages only.  I'll think about it.

 

19 hours ago, ljm42 said:

. If the go script (< 6.4.0) or ident.cfg (>= 6.4.0) references ports other than 80 or 443, and if those customized ports are less than 1000, warn the user. The risk is that misusing a "well known" port will cause problems if other services are added to unRAID down the road.

IDK.  Seems to me to be user preference, and if they're changing the port in the first place, then they damn well should know what they're doing anyways.

 

19 hours ago, ljm42 said:

If the go script includes "zenstates" without the full path "/usr/local/sbin/zenstates", warn user that it is not actually running. ( When the go script executes, the $PATH variable does not contain "/usr/local/sbin" )

Easy enough, but is this patch being implemented in 6.4.1?  I don't have a Ryzen, so don't particularly follow the thread.

 

19 hours ago, ljm42 said:
9. Also... currently I have multiple exclusions related to disks being spun down:
* "Disk(s)  disk1  disk2  disk3  are spun down.  Skipping write check and HPA check": "true",
* "Disk(s)  disk2  disk3  are spun down.  Skipping write check and HPA check": "true",
* "Disk(s)  disk3  are spun down.  Skipping write check and HPA check": "true",

Not in the current incarnation.  (IIRC, I add that as an "OTHER" which doesn't need an ignore in the first place since it won't trigger a notification.)  A future version will actually allow selective tests to be run

Link to comment
12 hours ago, Woodpusherghd said:

I have experienced several crashes of my UnRaid system over the past few months, most recently, yesterday.  I understand that if I enable troubleshooting mode, logs as well as diagnostics will be continually written to my flash  drive.  My only concern is that these crashes happen infrequently, maybe once every two weeks or so.  I have a 32 gig flash drive so I should have enough space but will the constant writing over a period of weeks damage the drive?  If so, what are the alternatives?  Hooking up a monitor after the crash before I manually reboot the system?  Running memtest? BTW, I'm running a Ubuntu VM if that's still an issue. Thanks, any feedback is appreciated.

1-2 weeks is no problems at all for troubleshooting mode.  Its if its every couple months or so that it'll cause problems

Edited by Squid
Link to comment
1 hour ago, Squid said:

I don't like adding in tests that I can't replicate.  Should get less and less frequent over time

A couple of people have been caught off guard by it:
  https://lime-technology.com/forums/topic/67222-64-cache-issue-due-to-uad-plugin/ 

  https://lime-technology.com/forums/topic/68683-cache-drive-wont-load/
I have no idea how prevalent it is though.
 

1 hour ago, Squid said:

IDK.  Seems to me to be user preference

 

Thinking about it more... when people pick a port that is already in use, they'll discover there is a problem before FCP can help anyway. And convincing people to change a working system "just in case" is an uphill battle. Probably makes more sense for the webgui to take a stand before FCP does:
  https://lime-technology.com/forums/topic/61773-64-needs-to-help-users-avoid-port-conflicts/

 

 

1 hour ago, Squid said:

Easy enough, but is this patch being implemented in 6.4.1?  I don't have a Ryzen, so don't particularly follow the thread.

True, Ryzen is definitely a moving target

 

I couldn't test that myself either, but I did try adding "diagnostics" to my go script and it failed.  Then I had it echo the $PATH variable and discovered /usr/local/sbin isn't part of the $PATH available to the go script. So I do believe the full path is needed for it to have any effect. But it might make sense to wait and see what 6.4.1 does with zenstates/Ryzen.

 

 

Anyway, hopefully this wasn't a complete waste of your time :)  I do realize that you're basically stuck supporting / defending anything you add to FCP, so I completely understand that you can't do something you don't believe in.

Edited by ljm42
Link to comment

This may be a little Ironic but I have a problem with Fix Common Problems Installation..

 

I'm not seeing a lifesaver icon in the settings..

 

I'm only seeing a Green Jigsaw Piece in Plugins tab..

image.thumb.png.8e3917601b101a86b8d99522a8e2f382.png

 

Clicking the jigsaw takes me to a blank page at: [IP addr]/Settings/FixProblems

 

I've tried removing and re installing from Community Applications but always the same result...

 

any suggestions?

 

 

 

 

 

Link to comment
34 minutes ago, Parax said:

This may be a little Ironic but I have a problem with Fix Common Problems Installation..

 

I'm not seeing a lifesaver icon in the settings..

 

I'm only seeing a Green Jigsaw Piece in Plugins tab..

image.thumb.png.8e3917601b101a86b8d99522a8e2f382.png

 

Clicking the jigsaw takes me to a blank page at: [IP addr]/Settings/FixProblems

 

I've tried removing and re installing from Community Applications but always the same result...

 

any suggestions?

 

 

 

 

 

reboot, try again, and take a screenshot of all the text that happens during install plugin

Link to comment
11 hours ago, Parax said:

Rebooted, removed, rebooted, reinstalled... screenshot

image.thumb.png.53fbe1f00c9ad5f8a9974eddaaeffb22.png

 

 

Same result .. nothing in settings:

image.thumb.png.9b922291837c7eb36d05bf0ef4aebe97.png

 

 

and same jigsaw icon in plugins

image.thumb.png.ff23aff1f5daf7adae0f08ae7bc25d5a.png

 

 

Here is the Server Log for the install:

image.thumb.png.0c6b50e3b746569fd7092f7ed5763b3a.png

Something's messed on the flash drive.  Delete /config/plugins/fix.common.problems folder.  Delete /config/plugins/fix.common.problems.plg

 

Reboot and try again.

Link to comment
5 hours ago, Squid said:

Something's messed on the flash drive.  Delete /config/plugins/fix.common.problems folder.  Delete /config/plugins/fix.common.problems.plg

 

Reboot and try again.

 

That seems to have done the job, thanks!

 

Whilst I was there, I also deleted the file in plugins-removed: /config/plugins-removed/fix.common.problems.plg

 

 

Link to comment

Recently I have seen that this plugin is telling me "

 

The template URL the author specified is https://raw.githubusercontent.com/linuxserver/docker-templates/master/linuxserver.io/plex.xml. The template can be updated automatically with the correct URL.

 

When I click "fix" it gives me a success message, but the warning does not go away. I click fix again, and get another success message but I'm not sure if it's actually changing anything. Should I just click fix then ignore warning?

 

Sorry if this is a silly question it just doesn't seem to work as expected.

Link to comment
That did the trick. Thanks! Weird that it kept saying success though. Appreciate it wgstarks
All errors / warnings found will always be shown until a rescan is done. Because a scan takes some time to run the display is static so it's faster to fix the problems if you're bouncing back and forth from different screens in the GUI
Link to comment

I have had an issue with my server just randomly powering off with no apparent reason I can think of. User wgstarks suggested using your (awesome) Fix Common Problems "Troubleshooting Mode". Just a few minutes ago, my server again randomly powered off, a parity check was initiated as it was not a clean shutdown. I did have troublshooting mode running when this happened. I did not get a screenshot of the screen when this happened as it seems completely random and I am unable to reproduce it at will. However I can upload my syslog, but where is the file that the troubleshooting mode log resides (or is it the same file?) so I can also upload this? 

 

Thanks again in advance very much Squid, your work and attention to these forums and users speaks for itself.

tower-diagnostics-20180209-1918.zip

Edited by mikedpitt420
Link to comment

When I first set up the plugin I accidentally told the plugin to ignore the FTP warnings.

 

download?id=qbhAbmXu9JOLPvzpc1wSafwUtRTI

 

 

I don't want this to be the case any more however whenever I click the Monitor Warning/Error button, the items stay. What is strange about this is if I tell it to ignore the warning on other items, I am able to set them to Monitor again just fine, it is just these two items that are stuck. This has persisted through multiple restarts, rescans, and versions of the plugin. I'm currently on unRAID 6.4.1 and Fix Common Problems 2018-02-14

 

Any help to get these monitoring again would be great.

Edited by halorrr
Link to comment

hello

 

seems that fix common problems plugin report the gitlab-ce ports as non-standard.

Getting in FCP errors like:

Docker Application GitLab-CE, Container Port 22 not found or changed on installed application

Docker Application GitLab-CE, Container Port 80 not found or changed on installed application

Docker Application GitLab-CE, Container Port 443 not found or changed on installed application

somebody else reporting this in the GL-CE docker support thread.

i guess we can ignore, but probably the plugin reporting such error should be corrected?

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.