Binary Sludge
Currently viewing the tag: "error"
Keeping the system clock on the right time is troublesome for a virtual machine if VM guest tools are not available to synchronise clocks. As the guest OS does not have access to the hardware clock it relies on software to tick over its own clock, and inaccuracies generally lead to slowdown (although over-compensation for loss of timer ticks may gain time).
Changing any system’s time can be risky – an OS relies on a contiguous series of time values. If a system event is scheduled to occur at a specified time and the clock is set forward beyond it, that time never occurs and the event will not occur.
Network Time Protocol (ntpd) avoids this problem by making minuscule adjustments to the clock frequency (the slew), effectively shortening the length of a unit of time to the OS. man ntpd states:
The slew rate of typical Unix kernels is limited to 0.5 ms/s, so for every second that the clock requires adjusting, 2000s are required to adjust it.
For a development VM that is off for periods of time this slew rate is too slow, and if the machine doesn’t run time-critical services ntpd can be configured to absolutely set the system time.
What
- Synchronise clock of virtual machine using ntp
Why
- Guest additions not available
Risks
- Time-based system events not occurring
How
-
Edit
/etc/sysconfig/ntpd and add the -x flag (mine looks like this):
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -x"
On startup the ntpd daemon will set the time irrespective of how incorrect it currently is.
-
Add this line in the root
crontab to refresh the time every 5 minutes.
*/5 * * * * /sbin/service ntpd restart >> /tmp/ntpd.log 2>&1
- Guest additions not available
Risks
- Time-based system events not occurring
How
-
Edit
/etc/sysconfig/ntpd and add the -x flag (mine looks like this):
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -x"
On startup the ntpd daemon will set the time irrespective of how incorrect it currently is.
-
Add this line in the root
crontab to refresh the time every 5 minutes.
*/5 * * * * /sbin/service ntpd restart >> /tmp/ntpd.log 2>&1
-
Edit
/etc/sysconfig/ntpdand add the-xflag (mine looks like this):OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -x"
On startup the ntpd daemon will set the time irrespective of how incorrect it currently is.
-
Add this line in the root
crontabto refresh the time every 5 minutes.*/5 * * * * /sbin/service ntpd restart >> /tmp/ntpd.log 2>&1
Here is a detailed explanation of Timekeeping in VMWare and What is a Reference Clock? from ntp.org‘s FAQ.
A Kindle will sync your progress through a book when it’s powered down (presumably only if it has sufficient battery to connect to a mobile or Wi-Fi network). This allows another device (another Kindle or the software on a mobile device or PC) to download that location so you can resume your reading from the same point.
If this doesn’t appear to be happening from the physical Kindle (i.e. your progress isn’t retrieved when you use a different device), the most likely reason is a corrupt filesystem. To fix:
- Attach Kindle to a PC via USB
- Your PC may prompt Do you want to scan and fix Kindle? – if so, click Yes
- If your device hasn’t prompted you:
- Navigate to Windows Explorer
- Right click on your Kindle
- Select Properties
- Navigate to the Tools tab
- Under Error-checking click “Check now”
- Select “Automatically fix filesystem errors” and click “Start”
- Once the filesystem is repaired the Kindle will sync to Whispernet again.
- In future, unmount the Kindle by ejecting it safely or change its removal policy.
I received an HTTP 500 response from YouTube today after submitting a search for Shlomo (an excellent beatboxer and human voice percussionist) and received the cryptic error mesage below.
It looks like potentially sensitive debug data have been serialised and encrypted into the error page, but it’s not immediately obvious why this is fed back to the user and not logged internally. Perhaps this error:
- occurred in an isolated system component without write permission to persistent storage
- is a trigger condition for a reroute from an overloaded component (possibly an aggregation service?)
- is infrequent enough to be considered non-critical
- is an undesired, undiagnosed emergent property of their architecture
- is unexpected, consequently not routed to the correct engineer and mothballed
Whatever it is, there isn’t any direction on how to contact the “highly trained monkeys” so most users won’t bother. The error is either considered minor or unfixable.
Serving 2 billion videos a day is non-trivial, but for any site without such well-publicised architectural prowess giving users encrypted debug messages and no method to report them is considered bad form!
500 Internal Server Error
Sorry, something went wrong.
A team of highly trained monkeys has been dispatched to deal with this situation.
If you see them, show them this information:
UOWacxCYxzsYHkLrZEkPJ42v33Rm1C1wn5HkrqJyEFGNk3WfVhFWNNNBnXif PBdrNCrIESBIpTwnU8M1R3DMOew5Oz8CKKbgOM_HzNYITN09NXUAidiDBQ5a 0ZSK0S-qKr51QgiwuVU-D5Luof6lVbO37ec5N5yiOoTY_4uOSR8_aofoZNS6 NGu5e2AfuOefgFoi6oAF2szkUjebTZkRu6Sty3F1VWCdDEbKlu1nUTmwubGE oEI-kRNhKrH9pWdb1D1AXLmD1cpKBgdLyUZkPZw0x9sj1uJaPoG_MkbcRggX glS0FWsoKxmzLFOpuCw5vV1KWx2qtA5OHUhc4SFopbXbdt_2xAf6wLeX-INq h_Mpy_I3U39wUdi0gCnTlQP6lOFlVY6j9oa4-Qoo3VB5qcKQPgNIRRcYExcv OGJjBX1Y4dtku649z_HqQZ7aMPL-XnY0AGISfFhmqmlifBXyqJKccWViybTa KOeAJglse94TgnlA_ZfWbqmUJqHQ4TZnS_5AMraiI6elzvk0NHoa7-ACj5X3 U7zMbfqsz-MLHTpBD0i84lG5mNsAbbEwiKOaE5mYyvFvGjV2nBLqfooHtmLG nq6nbTAOSmA22ci3eKrsWahmyC1XA07zhihpwN8bnjU1WXMBIeImhaMgxXSb YLg9yUzRoooHR245bqBfLo6FYOyl4ip8YV8vvzy4j-gl1EuCGdN63RGr1WLi 6jyqmIgnBN0aOQ3s9q9_wgcVMqkl_xNIG1NTWRtcaWQ42vh4GKDtgnUNB7F2 VVZJaztX2K_4CWGkkcs9a29Ep10OWJyoRXqy_AiFuIK7PVnHVcDFXJIpLhg0 YvVyhSdhOMeK3fe2gaoS-ZDbEBEZlj2iPpl01PWmP-jkCKBCtXe7um1jWIhg alCsqFgJeu2kfPh2Z37n71568tNxDauE0tA5aK8fAdJSgUt2P3eSEBj1xsm0 XgOO07Xwm4NBexDKFmkx9lQq-oSBk0zCK35ELAPJ2dJkt-4VVOH54wxbXJIj iRRZq0wSJtaa65v9EQLAzHg8XZOOVe5G5lIu9VL8iciQ5IoP4RK9bBXotEkG jElPUoITJEw7o6_sh17hSd3eFpCkX982res3tFMh7vSkVGpw-o0eLSTnlcZm EKmJCiTcqGBAdmoiFJ3e79BoJH5b84wCMDgr6vzjyFZmuzywJLuuVL61Xit1 9NlxLoBSNJ7klsD6-UqFC7zJu3Tij47lv9elsgPvvhCJMKcaMtKRO9bhBmTh 9ucAoKqR24lEQARzi6gYYvDyxv4U-4il7HLflAnIUUjrbFgx4pLYiVoNFxfo 8VlC-SbQbcJpZbsDqM3NiIXKs_zoOLYPITFxfM94MYBlvxI1rvYvbQtmaWcF JE1DDs90IS9NZHMWIQ_YW9R1MHb_Zx_C4dalLPfqKrAitYydQuMhvuq4baPg oPzt0zzl04azsAtHrhnWrGNzCf8AP9uMTx-pEXcRcUO3t_wtPXypDtuK_fBp bEJAioBndGfpsD-XUO9NGdvfLJUgAELNy1m9Hz_6w7tQ-NlkAviAqPz0kYEt AAboAZSjQDWOF5RK0p6kDdRfU3zqKMi9G_swc4S7EoN-sDwsPH7Pdp8y-wyg fYqObTNry8_ldQ7pEM4AEKBvVh5QZMYijztA3S8Jco-wEKo-Lt2WG2JNQHNP wMXtBJNp0M-hkHLQRzNrRdqObWU5OUvf88rjvQ7pDtui8KH4c7VnxIAYYxnu 1rXqZ0hdStTimt93WOGrS0-xf9nHtFgZ11gJTJwM1KII0nRnXEb4nP-hqkvU 8ifoTz-zougC-5UXTP3V7k_XCgpdbsuDNpfCv3V24H-d-WXZhWBz6R_j5ZdP viV7SqnTCuqOzOqCZykb3t6Bcd30olshmfA6XYNxfTVI1EdLkihMXUArNCZV xImCJfhpd_hoYlVy1XmXO6HTbnOobn8hXxDHWEu5OQzdIX-2sipGKC49_-60 M29bb18c060TZwhebR6BFhTDZd4BiH5ariv1hcMg1Ace-ClZzNM_GmRdK4va 1mjSjPt5XzobXyoGQqNw4JpSVag2r2P3WSQKGbjNc3HC0-9Fyg3zvft223Bt rM_ACshW6YbTg4IJFKtmPnSWBECZJjIndGUpyYG8zotdHDcpl3OnceH8IKem I_NY9gB-3o9o9U6qMf7HMLgzkL2nGdyPysdUFBM7BxYFZ0pZymg7VamZ6ckj _YrVv-XzHsZdBRWZgqCMdWj75O_ufJqwAV12oRlTm99HtUW-NdmCCrVBgGIy RF8nXd3PdHwopT-mHFR39xucPHS_UPFjTOZh6vUoLcYl64ot00YVjtMcKpmG wFHc2SHv5GqVqVb4cRfUi6--3F_TwqxoyrTRhRBOp1wi87Pcl7ISc1We4wVN EsFFe4J3rSzVGwcxLaX70XjYzUoV5RIoAGGh7ZX0BewbXotWRe1pGZ57BMve liFcBPSIkrxsxDwKku6CJV4Q4SPZ9Q64xK6abfeW4p0k38HlEyxmb8JjwFOA amXJWvcR0mFqe94SXwak9RDtZ1nRNY5JzIyjdMAa4WrcLWe53JZMeHjOkKcB bspm4zTRnugkCZXdoJZohcKnlvPg20ISuRUvyFEj07dPA2Xvhtr_aUpfvOCo EiVpoA0-2mGr7OIptFIC9l3oaOiHQdjdEPldpC8i_ufVc6lD8tjYvoqr0Klh E1cQFqFU5FUuCdxRXyG165Ex0QMKDdMelAisbDyyDTXdpCRMiD0SD3zwG6ac Gtk3xuj-1lZx9Q1_OytrEj8134JqYfhonArAvzC5FY8QFkHuq9b98ALsFfOP QTutc3sMVPjIdxmGvZ1L4jVTPYkU98ZvrmDLMaS-0MEcCIj-hXUXKH2Vqlxd K3hMJTqCRpv77XWUES57gWLQnAGg9VUVYJmeKCKLfTQWEeYLz6LqXaZuf_h_ QKlnjENZqJdu_H3Hh4brRlSXFYWReslG3elt2E3HGGkaVeH2Npfkbbn3_2Iq KsmHyVoGqTCR76tCZUEliBnyCerVPc7G1PFe5uj1TMTa34mHGWIIG9eeTjCI fMK90Z7evvkURGaJvsrSL8GntLKVhoFYFhjrzxE66H-47xOWMfe8yj7-tGcA sgbDavUPm3_sfEXBOSWSmKSEYj0aEGUToncKpu_3VdGSOUD70tyf3nGYKfe_ E4xG8QTEO4EE-U6X-_1w_ffeE5xu9tS-2R-McufulvBW9IUDYWnLxzay1bRm jdnt2zr_7GI-mewrbEtixOKUNmMaq3AlEgXdJ5Di5dsEh0gdCoaGUkYCowqR FQJwfyAyNdv5P-nmlRHEYG_ZrpDozmCjRKB2serGFjpNpXSkYC5_HGEwIQpI 4i4jfX2LG9A_iVjzx_rDWSiS2Dzr-Gs2HmlaCldHIQjl4fU5NLBPktTQt0vh owpAzHQxjTDqXZdc0pwEDPNiy5qJNs_uh-x-zNJra_gA4nQueB9jBOq7PZq8 bEIrEgVv
When setting up a query using a temporary lookup table, I got this error:
ERROR 1137 (HY000): Can't reopen table: 'tmp_journals'
It transpires that since 4.1 the way MySQL handles temporary tables has changed. This affects joins, unions and subqueries. There is an obvious fix:
mysql> CREATE TEMPORARY TABLE tmp_journals_2 LIKE tmp_journals; Query OK, 0 rows affected (0.00 sec) mysql> INSERT INTO tmp_journals_2 SELECT * FROM tmp_journals; Query OK, 3228659 rows affected (2.01 sec) Records: 3228659 Duplicates: 0 Warnings: 0
Then the query is easy:
SELECT COUNT(1) cnt, journal_invoice_ref FROM tmp_journals GROUP BY journal_date HAVING cnt > 10000</pre> UNION SELECT COUNT(1) cnt, journal_invoice_ref FROM tmp_journals_2 GROUP BY journal_invoice_ref HAVING cnt < 10
