myMain 1.5 - Now Integrated into unmenu


Recommended Posts

Never mind, I'll live with the missing images  :)

 

Are you running lightpd web server?  If yes, it would be pretty easy to get it to serve the images.

 

If not, Joe L. has come up with an amazingly light Web server.  I haven't tried it out yet, but will suggest that Joe L. send it to you as the guiney pig.  (Acutally Joe was his own guiney pig and he says it works beautifully.)  There is a value you can put in your local config file to change the image URL.  I am going to make that a setting on the myMain config screen so that MAC users that need to put in IP address and others, like you, that want to serve images via  lighttpd or Joe's Amazingly Light Image Server (JALIS ;)).  But until that, you can still add the line manually:

 

SetConstant(ImageHost,        "tower")

 

You should be able to add a port ...

 

SetConstant(ImageHost,        "tower:8088")

 

BTW, this (Joe's image server) might be the best approach to handle users that have a password.

 

I'm not running lightpd webserver, but am happy to be the guiney pig and try it  :)

Link to comment
  • Replies 136
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Is that an American spelling? In England we would spell it "Guinea Pig". Not being pedantic, just curious.

 

whoops i copied from bjp's post!  Shame on me being an englishman!  :-X

 

Indeed Sir. It may be a forgivable error for our Colonial cousins, but we Englishmen need to maintain certain standards.  ;)

Link to comment

Well - apologize for my atrocious spelling.  It has never caused an international incident before! :D

 

A new version of myMain is available today.  New features are ...

 

1 - load_cycle_count is now a selectable field (on the smart view)

2 - If the load_cycle_count > 1000 AND the load_cycle_count > power_on_hours, load_cycle_count will show up in the "Add'l Issues / Failures" column.  You can easily override the value by clicking on it and setting a max value before it show up again.  In my server, my highest load_cycle_count is 4,800, but power_on_hours are over 21,000.  There are reports of some people that have ridiculously high LCC values that begin to approach max lifetime.  My settings will allow a user to see this start to happen long before you're anywhere close to these limits.  Hope this will allow myMain users to see if this is happening.

3 - The ability to set the ImageHost has been placed on the myMain configuration page.

4 - I have also added some logic to try to prevent the first time issue after boot imaging loading problem.

 

Perhaps the most exciting "feature" has little to do with myMain itself.  Joe L. created a mini image server that can be loaded as a package (image_server.sh).  Once loaded, you can set your ImageHost to something like "tower:8088" on the myMain configuration screen.  Once you do that, the images will no longer be served via emhttp, but will be served by Joe L.'s image server.  This will get around password issues and running old versions of unRAID issues.  Appears same or slightly faster than emhttp!  There is a downside that the connections are logged to the syslog.  Not a big deal for occasional use.

 

Enjoy. Let me know if you have any problems.

Link to comment

Dec 15 22:31:33 Serenity bash[12498]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 22:31:50 Serenity unmenu[7237]: INFO: Dup token warranty

 

I saw a note that the "downside" is that it logs the connection to the syslog which I think is the first message. Is the second message where it says INFO: Dup token warranty expected as well?

Link to comment

Dec 15 22:31:33 Serenity bash[12498]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 22:31:50 Serenity unmenu[7237]: INFO: Dup token warranty

 

I saw a note that the "downside" is that it logs the connection to the syslog which I think is the first message. Is the second message where it says INFO: Dup token warranty expected as well?

I've never seen that here...  it was 17 seconds after the connection though... 

 

Even more curious is a google search for "Dup token warranty" turns up nothing. (except this thread)  If it was a standard error message from some software, you'd think it would have had some other post about it on the web.

 

Joe L.

Link to comment

Dec 15 22:31:33 Serenity bash[12498]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 22:31:50 Serenity unmenu[7237]: INFO: Dup token warranty

 

I saw a note that the "downside" is that it logs the connection to the syslog which I think is the first message. Is the second message where it says INFO: Dup token warranty expected as well?

I've never seen that here...  it was 17 seconds after the connection though...   

 

Even more curious is a google search for "Dup token warranty" turns up nothing. (except this thread)  If it was a standard error message from some software, you'd think it would have had some other post about it on the web.

 

Joe L.

 

Not sure, but I don't recall seeing that error before the latest unMenu update that I encountered the password problems with. That said, the only indication I have is the timing (could be coincidental of the upgrade) and the part the seems to indicate its coming from unmenu (could be coincidental) :).

 

Dec 15 23:24:06 Serenity bash[12353]: connect from 192.168.1.148 (192.168.1.148) (Routine)

Dec 15 23:24:06 Serenity bash[12357]: connect from 192.168.1.148 (192.168.1.148) (Routine)

Dec 15 23:24:06 Serenity bash[12354]: connect from 192.168.1.148 (192.168.1.148) (Routine)

Dec 15 23:24:06 Serenity bash[12356]: connect from 192.168.1.148 (192.168.1.148) (Routine)

Dec 15 23:24:06 Serenity bash[12364]: connect from 192.168.1.148 (192.168.1.148) (Routine)

Dec 15 23:24:06 Serenity bash[12450]: connect from 192.168.1.148 (192.168.1.148) (Routine)

Dec 15 23:24:06 Serenity unmenu[7237]: INFO: Dup token warranty

Dec 15 23:24:07 Serenity bash[14687]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 23:24:07 Serenity bash[14773]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 23:24:07 Serenity bash[14801]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 23:24:07 Serenity bash[14802]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 23:24:07 Serenity bash[14835]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 23:24:07 Serenity bash[14838]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 23:24:07 Serenity bash[14868]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 15 23:24:59 Serenity unmenu[7237]: INFO: Dup token warranty

 

This is the latest snippet that I have. With one of those Dup token warranty the timing looks right but then the other one is 52 seconds after the last connection. I'm not sure if I should be concerned :).

Link to comment

I'll agree it is being logged by unmenu (or rather, by something unmenu is invoking) but I haven't a clue from what???

 

The timing is odd. (not being consistent)

 

There is no string with the word "warranty" in the image_server.sh, furthermore, it has nothing to do with unMENU.  Its use is entirely between your browser and the unRAID inetd process.

 

The string does not exist in the "awk" process either.  That leaves something in linux we are invoking.

 

Joe L.

Link to comment

Slightly different question....why all the connect messages with the same timestamp?

 

Dec 16 17:32:19 Serenity bash[23700]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23775]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23782]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23781]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23785]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23780]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23791]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:33:19 Serenity unmenu[7237]: INFO: Dup token warranty

 

They're all coming from the same place with the same timestamp?

Link to comment

Slightly different question....why all the connect messages with the same timestamp?

 

Dec 16 17:32:19 Serenity bash[23700]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23775]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23782]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23781]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23785]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23780]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23791]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:33:19 Serenity unmenu[7237]: INFO: Dup token warranty

 

They're all coming from the same place with the same timestamp?

Actually, it is your browser... each image file requested gets its own connection by "inetd" to the image_server script.  Each image is sent to the browser by its own instance if the image_server script.  They connections just happen to all occur in the same second. 

 

It is something we need to live with.  The alternatives: install a full web-server and configure and use it, or, remove the password on unRAID, or log onto unRAID's web-page first, then access unMENU.

 

Joe L.

Link to comment

Slightly different question....why all the connect messages with the same timestamp?

 

Dec 16 17:32:19 Serenity bash[23700]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23775]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23782]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23781]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23785]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23780]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:32:19 Serenity bash[23791]: connect from 192.168.1.4 (192.168.1.4) (Routine)

Dec 16 17:33:19 Serenity unmenu[7237]: INFO: Dup token warranty

 

They're all coming from the same place with the same timestamp?

Actually, it is your browser... each image file requested gets its own connection by "inetd" to the image_server script.  Each image is sent to the browser by its own instance if the image_server script.  They connections just happen to all occur in the same second.   

 

It is something we need to live with.  The alternatives: install a full web-server and configure and use it, or, remove the password on unRAID, or log onto unRAID's web-page first, then access unMENU.

 

Joe L.

 

Ah ok, thanks! As long as it is expected behavior I'm ok with it.

Link to comment

Dec 16 17:33:19 Serenity unmenu[7237]: INFO: Dup token warranty

 

If you see this in your syslog, you likely need to comment out the following line in your mymain_local.conf file:

 

LoadToken(warranty,        warranty,            center,  "Warr")

 

by putting a pound sign (#) at the beginning of the line, like this:

 

# LoadToken(warranty,        warranty,            center,  "Warr")

 

Make sure you use a Linux compatible editor (like Notepad2).

 

That should eliminate the message.  (Note that this is not an error but an informational message only.)

Link to comment

Dec 16 17:33:19 Serenity unmenu[7237]: INFO: Dup token warranty

 

If you see this in your syslog, you likely need to comment out the following line in your mymain_local.conf file:

 

LoadToken(warranty,         warranty,            center,   "Warr")

 

by putting a pound sign (#) at the beginning of the line, like this:

 

# LoadToken(warranty,         warranty,            center,   "Warr")

 

Make sure you use a Linux compatible editor (like Notepad2).

 

That should eliminate the message.  (Note that this is not an error but an informational message only.)

You can use the "Config View/Edit" page in unMENU to edit the myMain_local.conf file.  It is the easiest to use.

 

Joe L.

Link to comment
  • 3 weeks later...

A minor update to myMain has been deployed to Google code and is ready for downloading ...

 

It addresses 2 issues:

 

1 - Unable to override the Current_Pending_Sector value in Smart View (reported and discussed in THIS thread)

 

2 - The prior version caused unMenu to restart if there was any change on the "main" configuration screen (where you can set the refresh interval, image widths, etc.).  Actually only 2 values require the restart.  I put in logic to not restart unmenu unless one of those two values changed.  Handy if you are trying to fine tune your image widths and don't want to wait 30 seconds between tries.

 

Let me know if you have any problems with this update.

 

Link to comment
  • 2 weeks later...

I have sent a myMain update to Joe L. to deploy.

 

New features / fixes:

 

1 - Option to display the partition alignment (63 or 64).  Shows on the default inventory screen.  Only displays for spun up disks.

 

2.  I have added a second refresh button on the Default and other views (any view where the "Temperature Data" option is selected on the view configuration).  When you click the right hand refresh option the temperature data is persisted from the last call.  This means that myMain is not having to call smartctl on every drive to get the temperature (which takes the lion's share of time).  So it results in a very quick refresh.

 

3 - Removal of smartctl permissive option.  While trying to run smartctl whle a preclear was occuring on a drive on the SuperMicro SASLP drive, I got these results:

 

smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Allen

Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===

Device Model:    Hitachi HDS722020ALA330

Serial Number:    JK11A5YAKDBxxx

Firmware Version: JKAOA3EA

User Capacity:    2,000,398,934,016 bytes

Device is:        Not in smartctl database [for details use: -P showall]

ATA Version is:  8

ATA Standard is:  ATA-8-ACS revision 4

Local Time is:    Sat Oct  2 13:52:13 2010 EDT

SMART support is: Available - device has SMART capability.

SMART support is: Enabled

Error SMART Status command failed

Please get assistance from http://smartmontools.sourceforge.net/

Register values returned from SMART Status command are:

ST =0x50

ERR=0x00

NS =0x00

SC =0xc8

CL =0x43

CH =0x3b

SEL=0x40

A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

 

Notice at the bottom it suggests adding the "-T permissive" option, which I did, by default (i.e., all the time), in myMain.  Seemed to fix the problem.

 

Seemingly unrelated, I have noticed a VERY occasional but nasty unRAID crash, with something like this in the syslog (once they start they happen over and over and over).  I upgraded the firmware which had no effect.:

 

Dec 27 00:46:15 Tower kernel: sas: command 0xf71c6600, task 0xc3ea1b80, timed out: BLK_EH_NOT_HANDLED

Dec 27 00:46:15 Tower kernel: sas: Enter sas_scsi_recover_host

Dec 27 00:46:15 Tower kernel: sas: trying to find task 0xc3ea1b80

Dec 27 00:46:15 Tower kernel: sas: sas_scsi_find_task: aborting task 0xc3ea1b80

Dec 27 00:46:15 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1701:mvs_abort_task:rc= 5

Dec 27 00:46:15 Tower kernel: sas: sas_scsi_find_task: querying task 0xc3ea1b80

Dec 27 00:46:15 Tower kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 1645:mvs_query_task:rc= 5

Dec 27 00:46:15 Tower kernel: sas: sas_scsi_find_task: task 0xc3ea1b80 failed to abort

Dec 27 00:46:15 Tower kernel: sas: task 0xc3ea1b80 is not at LU: I_T recover

Dec 27 00:46:15 Tower kernel: sas: I_T nexus reset for dev 0400000000000000

Dec 27 00:46:15 Tower kernel: sas: I_T 0400000000000000 recovered

Dec 27 00:46:15 Tower kernel: sas: --- Exit sas_scsi_recover_host

 

This crash prevents a smooth shutdown of unRAID (even with powerdown) and sometimes results in a drive being kicked from the array, requiring use of the "Trust My Parity" process.  I did some research and I am not the only person getting this error.  Some blame it on an immature Linux driver or a flakey controller.  So I'm not really sure what the problem might be.

 

But it seemed to occur more frequently while I was working on myMain enhancements.  It never happened during normal Samba usage.  After getting 2 in one day, I had a eureka moment and thought that this might be related to the "-T permissive" option on the smartctl command.  I took it off.  That was about 2 weeks ago and have not seen the crash since.  (Now that I'm posting this I will probably have three crashes tomorrow :) ).  The option is now controlled by a value in the config file, but can't be changed via the GUI.  I suggest that, if possible, you preclear on a controller other than the SASLP, and leave the permissive option off for now.  (Even if you preclear on the SASLP, pulling smart reports during the time is not required.)

 

I will continue to monitor the situation and let you know if I learn more.

 

Link to comment
  • 4 weeks later...

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.