40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 338 of 344  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  3420   Fri Aug 13 13:11:30 2010 DmassUpdateelogrestarted

Quote:

Quote:

 script

 More of the same. 

Who is putting weird figures into the elog?!?!  I haven't checked lately, but this is what usually crashes the elog.  It's been happening a lot lately, and it might be the .pdf's. 

Let's play a new game.  We'll call this game "Everyone only use .png files for the next week" Ready? GO!

Do we know what causes the crashes for definite? Let's give the whole knowledge gathering a shot. Surfs welcome to post. Please follow the format and keep it brief. P.S. if the elog stops responding or hangs while you're trying to edit a post or write a post, you may have crashed it.

Person

  • Crashes

Dmass

  • I have crashed the elog with downsized jpegs (~300-900kB).
  • I see jpegs on the front page of the 40m (which seem to have not crashed it?)
  • I have posted pdf's with and without png thumbnails (associated automatically via the Mac program preview) without problem.

 

Edit this post to add your own experience using the above format

  3426   Mon Aug 16 23:13:25 2010 ZachUpdateeloge to the log

 Zach

  • I get so many freebies it's ridiculous
  3429   Tue Aug 17 09:06:08 2010 AlbertoUpdateelogelog was down

I just restarted the elog after I found it down a few minutes ago.

  3431   Tue Aug 17 23:59:46 2010 KatharineUpdateelogMaglev update

Katharine, Sharmila

Update: 
We haven't been posting in the elog regularly, for which we are very sorry.  We have been taking notes in our log books, but we ought to have posted here as well.  We apologize and now present an overview of what we've been up to.

Some time ago, we created a Simulink model to predict the response of our system, but for the model to be useful we needed to include approximately correct gains for each block in the diagram, including the magnet force and coil force gradients and OSEM "gain." We also needed to better quantify the 1x1 levitation.


Adjusting the potentiometers:

The circuit which converts current to voltage in the Quadrant maglev control has a variable resistor. This is useful as it gives us a way to zero the current when the levitated object is in the equilibrium position. It was done as follows. The output voltage from the circuit converting current to voltage is fed into the oscilloscope. The voltage values for zero and complete blockage of the LED is noted(say 2V). We adjust the resistor to make the voltage output to be V when the flag completey bolcks the LED. This gives a zero current when the flag is in the equilibrium position.

OSEM Calibration:

The OSEM works by blocking the light that goes into the photodetector from the LED by a flag. To simulate the model we had on simulink, we needed to find what the gain of the OSEM was. The gain of the OSEM is the current it gives per unit displaccement of the flag. To determine this we attached a micrometer to the OSEM flag. The micrometer was long eneough to push the flag to completey block the OSEM. We connected the output of the PD test point (which was the voltage after the photodiode current was converted into voltage) to the oscilloscope. We noted down the voltage difference in the oscilloscope with a fixed reference for different positons of the flag. From the oscilloscope output, we were able to get the PD current. We then selected a linear region of the plot of PD current vs flag position(which is usually in the middle) to fit the graph with a straight line. The slope gives the OSEM gain.

Magnet strength
    We need to know about the relative strengths of our magnets (levitated and fixed in the coil) in order to do magnet matching.  We used a Gaussmeter to measure the field from each coil magnet at  ~2 mm away from the center (the probe was fixed to an aluminum block, so that the tip had the same vertical separation for each of the four fixed plate magnets).  We labeled each of the four magnets and calculated the field at this distance to be 0.206 kG, 0.210 kG, 0.212 kG, and 0.206 kG,  respectively, for coils 1-4.  However, each measurement had a rather large uncertainty of 0.01 kG, because the field strength varied a lot with position on the magnet, and the measurements were limited by how well we could align the probe tip with the center.

Fixed Plate Magnets - magnetic field (kG)           
meas't    1        2        3        4
1       0.205    0.213    0.209    0.204
2       0.211    0.219    0.223    0.207
3       0.199    0.205    0.211    0.201
4       0.207    0.203    0.206    0.213
average 0.206    0.210    0.212    0.206
stdev   0.005    0.007    0.007    0.005

    We also planned to take the same measurements for the coil magnets.  We noted that the magnetic field varied a lot depending on the probe's location, but not in the way we would expect.  At the edges of the magnet, the field was much stronger (~2 kG) than at the center (~0.5 kG).  We initially thought this might have to do with how we were holding the probe -- for instance, if we measured the force towards the edge by moving the tip all the way across the center of the magnet, there might be some kind of integration effect which does not accurately represent the field.   However, we measured the field at the edge with the probe across the magnet and also with the probe, so this is clearly not the case.

    We also noticed that the cylindrical magnet we used for single-magnet levitation was not attracted to the coil magnets in the way we expected.    Though the cylindrical magnet was oriented so that it was strongly attracted to the coil magnet, it was attracted more to the edges than the center, so that it seemed to be repelled by the centers of the coil magnets.  Though this follows somewhat from the Gaussmeter readings, it is not the behavior we would expect when considering the coil magnets as magnetic dipoles.

Attempting single-magnet levitation for each coil:
    We attempted to levitate single magnets using all four OSEM/coil combinations.   We assembled the magnets and OSEMs using Haixing's mount, and, adjusting the height of the OSEM plate, attempted to levitate the single magnet with a flag with which we were previously successful.   This was completely unsuccessful using all of the coil magnets (and when we tried to levitate using the south magnets, we flipped the cylindrical magnet's orientation).
    Since we had already achieved this levitation, this seemed particularly wrong.  We disassembled the fixed OSEM plate in Haixing's mount and built a cursory OSEM mount, similar to the one we had used for levitation before, and did not fix it in place.  After a little experimenting with the height and position of the OSEM, we were able to achieve levitation with coils 1 and 4.
    We noted the levitation magnet separation (~4.5 mm) and the height of the OSEMs at which levitation was achieved (147 +/- 1 mm for coil 1, 146 +/- 1 mm for coil 4).  Then, we reassembled Haixing's OSEM plate and tried to levitate the cylindrical magnet at coil 1 and coil 4, respectively, adjusting the OSEM plate so that the height of the OSEM of interest was the same as when we achieved single-magnet levitation.  This was unsuccessful, which leads us to believe that there is some alignment issue between the fixed coil magnets and the OSEMs in the mount,  possibly due to the unusual field from the fixed coil magnets.
    We also were completely unable to levitate using coils 2 and 3.  Coils 1 and 4 have identical circuit paths, whereas 2 and 3 differ slightly.  With more time, we need to investigate this further.

Force-distance measurements
    We also measured the repulsive force between the cylindrical magnet and the coil magnets as a function of separation.  We fixed each of the coil magnets, individually, on a stack of sticky notes on a precision balance (the stack of sticky notes was to prevent the coil magnet from interacting with the digital balance) and zeroed the balance.  We then fixed the cylindrical magnet (oriented so that it would be repelled by the coil magnet) to a teflon rod, and mounted the rod so that we could slide it up and down a long cylindrical post.  Noting the position of the rod and cylindrical magnet, we were able to measure the repulsive force as a function of separation (see Excel graph).
    However, because the magnetic field varied so much with position on the coil magnet, there is a lot of uncertainty associated with these measurements.    We tried to keep the cylindrical magnet in the same horizontal position, but it was impossible to keep the exact position while sliding the mounted teflon rod up and down the posts.    In spite of this, we fit the linear region of this graph, near the equilibrium separation of the magnets, for a very approximate measurement of the magnetic field force gradient. The slope gives the force per unit distance of the magnet.

Coil-force measurement
    We measured the force by changing the current through the coil of wire, using a very similar setup as described above.  Since we are concerned with the magnetic force as a function of current, not separation, we fixed the teflon rod so that the cylindrical magnet and coil magnet were separated by ~4.5 mm, the approximate levitation separation of the two magnets.   We then completely blocked the OSEM with the flag, creating a maximum PD current, and measured the coil current using an oscilloscope when the LED was fully blocked and the current when we removed the flag.  At the same time, we measured the repulsive force by looking at the precision balance.
    Unfortunately, we had difficulty taking further readings, because our circuit starting behaving oddly (described below).  Otherwise, we would repeat this process by blocking the OSEM LED by various amount and measuring the change in coil current, and the corresponding reading on the precision balance.   However, the force should be linearly dependent on coil current, and we ought to know one other point: when there is no current in the coil, there should be no magnetic force from the coil to the magnet.  Using this information, we can determine the slope of magnetic force by coil current, but it's not very reliable as we have only one real data point.
    One additional aspect makes this reading questionable.  When we switched on the power supply, the reading on the precision balance changed, before we had blocked the OSEM LED at all. Since no light was blocked, theoretically no photocurrent should be coming from the PD and there should not be a coil current from the feedback, so the force should not be changing. We are not sure why this is.

Recent Circuit Behavior
    Some noise in the circuit appears to be hugely amplified when the gains of each coil are high, resulting in a high frequency signal of a few hundred kHz.  When the gains are all sufficiently high, this noise can saturate the coil current so that when PD current changes, there is no visible change in coil current.
    On Saturday, we noticed some odd behavior from the circuit.  We hooked up the oscilloscope so we could see both PD current and coil current, and were very surprised that the PD current signal was oscillating and continually changing even when no flag was inside the OSEM.   This was also affecting the coil current as well.  We thought this might be due to some component burning out in our circuit, or RC coupling somewhere, but we did not get a chance to pinpoint the origin of this problem.

Modeling
Initially we had attempted to model the force-distance treating the two cylindrical magnets as dipoles, and finding the attraction/repulsions between the four distinct poles.  However, the resulting equation did not have a maximum, which is what we got in our measured values, so it seems this is not the best approach.  We would like to try the current loop approximation.

Attachment 1: repulsiveforce.png
repulsiveforce.png
Attachment 2: OSEMcalibration.png
OSEMcalibration.png
Attachment 3: OSEMslopes.png
OSEMslopes.png
  3436   Wed Aug 18 19:14:59 2010 JenneUpdateelogelog dead again

The elog was so dead this time that the restart script didn't work.  I followed the restart-by-hand instructions instead, with success.

  3439   Thu Aug 19 01:49:14 2010 JenneUpdateelogelog dead again

Quote:

The elog was so dead this time that the restart script didn't work.  I followed the restart-by-hand instructions instead, with success.

 Just for added interest, I tried a different method when the restart script broke.  The "start-elog-nodus" script has a line "kill elogd".  This seems not to be actually killing anything anymore, which means the elog can't restart.  So this time I went for "kill <pid number>", and then ran the startup script.  This worked.  So it's the "kill elogd" which isn't working reliably.

  3440   Thu Aug 19 09:51:43 2010 josephbUpdateelogelog dead again

I found the elog dead again this morning, and the script didn't kill again. I modified the script to use the following line instead of "pkill elogd":

kill `ps -ef | grep elogd | grep -v grep | grep -v start-elog-nodus | awk '{print $2}'`

Hopefully the script will be a bit more robust in the future.

Quote:

Quote:

The elog was so dead this time that the restart script didn't work.  I followed the restart-by-hand instructions instead, with success.

 Just for added interest, I tried a different method when the restart script broke.  The "start-elog-nodus" script has a line "kill elogd".  This seems not to be actually killing anything anymore, which means the elog can't restart.  So this time I went for "kill <pid number>", and then ran the startup script.  This worked.  So it's the "kill elogd" which isn't working reliably.

 

  3445   Thu Aug 19 21:56:02 2010 ZachUpdateelogrestarted

 script

  3446   Fri Aug 20 13:09:53 2010 josephbUpdateelogRebooted elog

I had to restart the elog again.

At this point, I'm going to try to get one of the GC guys to install gdb on nodus, and run the elog in the debugger, that way when it crashes the next time, I have some error output I can send back to the developer and ask why its crashing there.

  3453   Sun Aug 22 16:20:24 2010 ZachUpdateelogrestarted (with my phone this time)
  3454   Mon Aug 23 00:08:24 2010 JenneUpdateelogJoe, I think this's your cue...
  3464   Tue Aug 24 14:29:18 2010 josephbUpdateelogElog down for 1 minute

I'm going to take the elog down for one minute and restart it under gdb (using a copy of gdb stolen from fb40m since I couldn't figure out how to install an old enough version on nodus from source).  The terminal with information is running on Rosalba under the "Phase Noise" panel, so please don't close it.  Ideally, the next time the elog crashes, I'll have some output indicating why or at least the line in the code.  I can then look at the raw source code or send the line back to the developer and see if he has any ideas.

  3465   Tue Aug 24 17:57:57 2010 ZachUpdateelogrestarted

 Restarted the elog using the script. I had to do it twice for it to work. This is not the first time this has happened---does anyone know why this might be?

  3466   Tue Aug 24 22:26:16 2010 ZachUpdateelogrestarted

took two again

Quote:

 Restarted the elog using the script. I had to do it twice for it to work. This is not the first time this has happened---does anyone know why this might be?

 

  3467   Wed Aug 25 12:18:47 2010 josephbUpdateelogTrying new version of elog to see if it helps stability

So unfortunately, I made the start-elog-nodus script smart enough to kill the debugging run I had (although thats probably good since there might have been issues with continuing to run - just poor timing on part of the crash).

In related news, I have gotten the latest version of the elog code to actually compile on Nodus.  I had to hack the cryptic.c file (elog/src/cryptic.c) to get it to work though.

The following was copied from the #ifdef _MSC_VER section of the code into the #else directly following that section. 

#define MAX(x,y) ((x)>(y)?(x):(y))
#define MIN(x,y) ((x)<(y)?(x):(y))
#define __alignof__(x) sizeof(x)
#define alloca(x) malloc(x)
#define mempcpy(d, s, n) ((char *)memcpy(d,s,n)+n)
#define ERANGE 34


I also removed #include <stdint.h> as the functionality it provides is covered by inttypes.h on Solaris machines, which is automatically included.

This new code was released August 5th 2010, while the old elog code we were running was 2.7.5 and was released sometime in 2008.  There are several crash fixes mentioned in the version notes so I'm hoping this may improve stability. I'm in the process of making a copy of the elog logbooks into the elog-2.8.0 install (so as to have a backup with the original 2.7.5).  I'm also copying over all the configuration files.   In a few minutes I'm going to try switching over to the new elog.  If it doesn't work, or is worse, its easy enough to just start up the current version.

All files are located in /cvs/cds/caltech/elog/elog-2.8.0 (the old directory is elog-2.7.5).  I've made  a new startup script called start-elog-nodus-2.8.0.  To start the new one, just run that script.  To start the old one, just go to the elog-2.7.5 directory and run the old start-elog-nodus script.

  3468   Wed Aug 25 12:40:28 2010 josephbUpdateelogReverted back to 2.7.5 until further testing is done

So apparently the themes/configurations didn't work so nicely on some of the logbooks with 2.8.0, so I'm reverting to 2.7.5 until I can figure out (assuming I can) how to get them to display properly.

  3471   Wed Aug 25 15:55:33 2010 josephbUpdateelogStaying with 2.7.5 until passwords sorted out

Turns out the elog version 2.8.0 uses a different encryption method than 2.7.5.  This mean the encrypted passwords stored in the elogd.cfg don't work with the new code.  elogd includes functionality to generate encrypted passwords, but unfortunately I don't know the administration passwords for some of the logbooks.  So I'm going to leave 2.7.5 running until I can get those added properly to the 2.8.0 cfg file.

  3533   Tue Sep 7 14:42:02 2010 DmassConfigurationelogelog restarted

elog crashed on an upload. restarted and it worked fine with the same file.

  3538   Tue Sep 7 22:21:47 2010 DmassConfigurationelogelog restarted

Quote:

elog crashed on an upload. restarted and it worked fine with the same file.

 Again. Resubmitted an old entry with just text changes. Elog hung for 5 min +.

  3613   Mon Sep 27 21:57:59 2010 ZachUpdateelogelog restarted

 took two runs of the script as usual

  3704   Wed Oct 13 09:35:41 2010 ranaUpdateelogstart script edited

The existing elog restart script was running the kill process in the background using the '&' symbol before starting new elog process. This is a BAD idea since there's no way to make sure that the background process has actually worked before the new one tries to start.

That's why you sometimes had to run the script twice. I've removed all of the background "cleverness" so now it will take ~2s more for the script to run - however, it now actually works. We may also upgrade from v2.7.5 to 2.8 today.

  3772   Sun Oct 24 19:23:41 2010 ranaConfigurationelogELOG 2.8.0
I stopped the ELOG and restarted us on 2.8.0.

To make sure nothing got lost, I killed the old process, copied over the logbooks/, themes/, and elogd.cfg to the new 2.8.0/ directory before starting the new Daemon.

I encountered the same Administrator bug as Joe had before. I delete all the old Admin passwords to bypass the issue.

To restart the ELOGD on NODUS, you now type '/cvs/cds/caltech/elog/start-elog.csh'.
I also added ELOG to the man pages in /usr/local/man/ on nodus by putting the *.1 files in man1/ and the *.8 files into man8/.
  3775   Mon Oct 25 02:23:47 2010 KojiConfigurationelogELOG 2.8.0
When I push the reply button, the raw html shows up in the edit window and have to use HTML to write the entry.
Does this happen only to me???


Quote:
I stopped the ELOG and restarted us on 2.8.0.

To make sure nothing got lost, I killed the old process, copied over the logbooks/, themes/, and elogd.cfg to the new 2.8.0/ directory before starting the new Daemon.

I encountered the same Administrator bug as Joe had before. I delete all the old Admin passwords to bypass the issue.

To restart the ELOGD on NODUS, you now type '/cvs/cds/caltech/elog/start-elog.csh'.
I also added ELOG to the man pages in /usr/local/man/ on nodus by putting the *.1 files in man1/ and the *.8 files into man8/.
  3780   Mon Oct 25 23:59:37 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

ELOG reverted to 2.7.5 due to editing difficulties

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5

- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

  3783   Tue Oct 26 07:02:05 2010 AlbertoConfigurationelogELOG 2.8.0 -> ELOG 2.7.5

Quote:

ELOG reverted to 2.7.5 due to editing difficulties

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.7.5

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.7.5

- logbook dir of 2.8.0 was copied in the dir of 2.7.5. The old and obsolete 2.7.5 was discarded.

I think I had the same problem when I switched to 2.75 from 2.65.

Then the problem was FCKeditor.

We should try the solution I put in the elog page of the wiki.

 

  3784   Tue Oct 26 10:50:08 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5 -> ELOG 2.8.0

ELOG restarted with 2.8.0 again.

- moved elog-2.8.0/script dir to elog-2.8.0/script.orig

- copied elog-2.7.5/script to elog-2.8.0/script

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.8.0

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.8.0

- logbooks on 25th and 26th were copied from 2.7.5 to 2.8.0.

 

  3795   Wed Oct 27 11:52:45 2010 josephbUpdateelogElog needed to be restarted

I had to restart the elog on Nodus because it was no longer responding.

  3989   Mon Nov 29 17:45:28 2010 ZachUpdateelogrestarted elog

 The elog was down so I restarted it. The instructions on the wiki do not work as the process has some complicated name (i.e. it is not just 'elogd'). I used kill and the pid number.

I will get around to updating the restart script to work with 2.8.0.

  3993   Tue Nov 30 11:44:36 2010 ZachUpdateelogelog restarted -- SCRIPT adapted for 2.8.0

 I have created an updated version of the "start-elog-nodus" script and put it in .../elog/elog-2.8.0. It seems to work fine.

  3994   Tue Nov 30 12:10:44 2010 josephbUpdateelogElog restarted again

The elog seemed to be down at around 12:05pm.  I waited a few minutes to see if the browser would connect, but it did not.

I used the existing script in /cvs/cds/caltech/elog/ (as opposed to Zach's new on in elog/elog-2.8.0/) which also seems to have worked fine.

  3998   Tue Nov 30 14:21:21 2010 ZachUpdateelogScript unnecessary
I didn't realize that the script in .../elog was configured to start 2.8.0 already. I will revert the instructions on the wiki to point to that 
one.
  4001   Tue Nov 30 19:35:09 2010 ZachUpdateelogrestarted again

 Restarted the elog again, this time using .../elog/start-elog.csh, which Joe pointed out works just fine. I have amended the wiki instructions to point to this script, instead.

  4017   Mon Dec 6 22:43:19 2010 FrankConfigurationelogelog restarted

I restarted the elog because i changed the configuration for the cryo-elog.

Used the "start-elog.csh" script in /cvs/cds/caltech/elog/

  4052   Tue Dec 14 09:26:17 2010 ZachUpdateelogrestarted

 Restarted the elog with the script

  4071   Sat Dec 18 06:24:49 2010 ranaUpdateelogrestarted

The process was taking up 100% of the CPU and not responding via web. The .log file showed the last action was somebody reading/editing one of Jenne's entries from August regarding TT ECD. The restart script didn't work, so I had to do a 'kill -9' to get it to die.

  4072   Sat Dec 18 23:33:06 2010 KojiUpdateelogrestarted

Did the same.

Quote:

The process was taking up 100% of the CPU and not responding via web. The .log file showed the last action was somebody reading/editing one of Jenne's entries from August regarding TT ECD. The restart script didn't work, so I had to do a 'kill -9' to get it to die.

 

  4073   Sun Dec 19 11:19:42 2010 KojiUpdateelogrestarted

Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log.
Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.

  4074   Sun Dec 19 22:45:28 2010 ranaUpdateelogrestarted

I deleted the yellow box which showed up by default when making an elog entry. Would be nice if we could make it so that you have to click a button to 'opt-in' for the yellow box rather than get it by default.

I added a 'robots.txt' file to the /users/public_html/ area using Google's instructions (it only works with robot compliant crawlers), but am not sure how to put robots.txt into the elog port.

  4081   Tue Dec 21 08:26:08 2010 ranaUpdateelogelogd is getting killed by Suresh

Suresh killed the elogd again from India. This was the log file:

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Referer: http://www.ligo.caltech.edu/~ajw/40m_upgrade.html
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f
Via: 1.1 sfire5.du.ac.in:3128 (squid/2.6.STABLE6)
X-Forwarded-For: 10.11.1.120
Cache-Control: max-age=259200
Connection: keep-alive

Stop killing our elog!

  4085   Wed Dec 22 06:50:19 2010 ranaUpdateelogelogd is getting killed by Suresh

After another elog crash, I've blacklisted the domain that Suresh is using by editing the apache httpd.conf. Let's see what happens now.

  4091   Thu Dec 23 03:15:11 2010 KojiUpdateelogelogd is getting killed by Suresh

ELOG has crashed and I restarted it.

Actually the filtering is not effective so far as elog is not using apache but has its own web server inside.
So this just block the access to port 30889 (=SVN, Dokuwiki, etc).

Quote:

After another elog crash, I've blacklisted the domain that Suresh is using by editing the apache httpd.conf. Let's see what happens now.

 

  4092   Thu Dec 23 08:54:32 2010 SureshUpdateelogthe delhi univ syndrome

Sorry folks!  I couldnt get to the elog and didnt know that the elog was crashing every time I tried to access it. 

But have found other means to access it and the elog is safe for now!

  4098   Wed Dec 29 18:53:11 2010 ranaSummaryelogfound hung - restarted

This was the error today:

GET /40m/ HTTP/1.1
Host: nodus.ligo.caltech.edu:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.ligo.caltech.edu/~ajw/40m_upgrade.html
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f

  4102   Mon Jan 3 10:32:27 2011 kiwamuSummaryelogfound hung - restarted

Found exactly the same error messages at the end of the log file.

Quote: #4098

This was the error today:

GET /40m/ HTTP/1.1
Host: nodus.ligo.caltech.edu:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.ligo.caltech.edu/~ajw/40m_upgrade.html
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f

 

  4111   Wed Jan 5 10:45:51 2011 KojiUpdateelogrestarted

Google bot  crashed the elog again. Then, I found that Google bot (and I) can crash elogd by trying to show the threaded view.
There looks similar issue reported to the elog forum, the author did not think this is a true bag.

Note: This happens only for the 40m elog. The other elogs (ATF/PSL/TCS/SUS/Cryo) are OK for the threaded view.

Quote:

Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log.
Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.

 

  4114   Wed Jan 5 21:19:29 2011 ZachUpdateelogrestarted

 Restarted the elog with the script

  4121   Thu Jan 6 10:47:11 2011 KojiUpdateelogELOG fixed (re: restarted)

Fixed the 40m elog crashing with the threaded display.

This morning I found that Google bot crashed the elog again. I started the investigation and found the threaded mode is fine if we use the recent 10 entries.

I gradually copied the old entries to a temporary elog and found that a deleted elog entry on August 6 had a corrupted remnant in the elog file. This kept crashed the threaded mode.

Once this entry has been eliminated again, the threaded mode got functional.

I hope this eliminates those frequent elog crashing.

Quote:

Google bot  crashed the elog again. Then, I found that Google bot (and I) can crash elogd by trying to show the threaded view.
There looks similar issue reported to the elog forum, the author did not think this is a true bag.

Note: This happens only for the 40m elog. The other elogs (ATF/PSL/TCS/SUS/Cryo) are OK for the threaded view.

Quote:

Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log.
Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.

 

 

  4168   Wed Jan 19 10:31:24 2011 josephbUpdateelogElog restarted again

Elog wasn't responding at around 10 am this morning.  I killed the elogd process, then used the restart script.

  4332   Mon Feb 21 11:05:51 2011 ZachUpdateelogrestarted

 I restarted the elog using the script.

  4334   Mon Feb 21 23:00:06 2011 ZachSummaryelogrestarted

 again

ELOG V3.1.3-