Good Ener­max sup­port in Germany

The pow­er sup­ply of my serv­er at home failed at the end of last month. As I was busy with ren­o­va­tion at home, it took me a while to check if it is real­ly the PSU or some­thing else. When I was sure about the failed piece, I have sent the PSU to the RMA address the Ener­max sup­port gave me (the PSU has a 5 year war­ran­ty, and I have it since one year). Due to hol­i­days it took a while to get the repaired unit back, but I want to say thank you to the Ener­max support:

  • Thank you for hand writ­ten respons­es, I did not get obvi­ous auto­mat­ic respons­es or canned respons­es (well, maybe they did some copy&paste for the RMA address and such, but each mail had at least a part which was not com­ing from copy&paste).
  • Thank you for get­ting back to me with­in a rea­son­able time.
  • Thank you for polite­ly answer­ing all my sup­port requests.
  • Thank you for being hon­est in your com­mu­ni­ca­tion (slow han­dling of the repair due to peo­ple being in hol­i­day, not because of miss­ing pieces from sup­pli­ers or oth­er excus­es out­side Enermax).

This is how the sup­port shall be, unfor­tu­nate­ly this is not always the case, but at least here it was. Thank you!

VDR ports docs

After a quick dis­cus­sion with nox@ I made a copy&paste of his “VDR is com­mit­ted now”-mail into the FreeB­SD wiki. I also re-styled some small parts of it to fit bet­ter into the wiki. It is not per­fect, but already usable. Now inter­est­ed peo­ple can go and improve the docs there.

Thanks to Juer­gen for all his work in this area!

Cheap process mon­i­tor­ing (no addi­tion­al soft­ware required)

I have an old sys­tem (only the hard­ware, it runs ‑cur­rent) which reboots itself from time to time (most­ly dur­ing the dai­ly periodic(8) run, but also dur­ing a lot of com­pil­ing (por­tup­grade)). There is no obvi­ous rea­son (no pan­ic) why it is doing this. It could be that there is some hard­ware defect, or some­thing else. It is not impor­tant enough to get a high enough pri­or­i­ty that I try hard to ana­lyze the prob­lem with this machine. The annoy­ing part is, that some­times after a restart apache does not start. So if this hap­pens, the solu­tion is to login and start the web­serv­er. If the web­serv­er would start each time, near­ly nobody would detect the reboot (root gets an EMail on each reboot via an @reboot crontab entry).

My prag­mat­ic solu­tion (for ser­vices start­ed via a good rc.d script which has a work­ing sta­tus com­mand) is a crontab entry which checks peri­od­i­cal­ly if it is run­ning and which restarts the ser­vice if not. As an exam­ple for apache and an inter­val of 10 minutes:

*/10 * * * *    /usr/local/etc/rc.d/apache22 status >/dev/null 2>&1 || /usr/local/etc/rc.d/apache22 restart

For the use case of this service/machine, this is enough. In case of a prob­lem with the ser­vice, a mail with the restart out­put would arrive each time it runs, else only after a reboot for which the ser­vice did not restart.

Debug­ging lang/mono – 2nd round

Today I had again some ener­gy to look at why mono fails to build on FreeBSD-current.

I decid­ed to do a debug-build of mono. This did not work ini­tial­ly, I had to pro­duce some patches. 🙁

Does this mean nobody is doing debug builds of mono on FreeBSD?

I have to say, this expe­ri­ence with lang/mono is com­plete­ly unsatisfying.

Ok, bot­tom line, either the debug build seems to pre­vent a race con­di­tion in most cas­es (I had a lot less lock­ups for each of the two builds I did).

What­ev­er it is, I do not care ATM (if the con­fig­ure stuff is look­ing at the archi­tec­ture of the sys­tem, it may be the case that the i386-portbld-freebsdX does not enable some impor­tant stuff which would be enabled when run with i486-portbld-freebsdX or bet­ter). Here are the patch­es I used in case some­one is inter­est­ed (warn­ing, copy&paste con­vert­ed tabs to spaces, you also have to apply the map.c (a gen­er­at­ed file… maybe a touch of the right file would allow to apply this patch in the nor­mal patch stage) relat­ed stuff when the build fails, else there is some pars­er error in mono):

--- mcs/class/Mono.Posix/Mono.Unix/UnixProcess.cs.orig       2010-01-29 11:34:00.592323482 +0100
+++ mcs/class/Mono.Posix/Mono.Unix/UnixProcess.cs    2010-01-29 11:34:18.540607357 +0100
@@ -57,7 +57,7 @@ namespace Mono.Unix {
 int r = Native.Syscall.waitpid (pid, out status,
 Native.WaitOptions.WNOHANG | Native.WaitOptions.WUNTRACED);
 UnixMarshal.ThrowExceptionForLastErrorIf (r);
-                       return r;
+                       return status;
 }

 public int ExitCode {

--- mono/io-layer/processes.c.orig    2010-01-29 11:36:08.904331535 +0100
+++ mono/io-layer/processes.c 2010-01-29 11:42:21.819159544 +0100
@@ -160,7 +160,7 @@ static gboolean waitfor_pid (gpointer te
 ret = waitpid (process->id, &status, WNOHANG);
 } while (errno == EINTR);

-       if (ret <= 0) {
+       if (ret == 0 || (ret < 0 && errno != ECHILD)) {
 /* Process not ready for wait */
 #ifdef DEBUG
 g_message ("%s: Process %d not ready for waiting for: %s",
@@ -169,6 +169,17 @@ static gboolean waitfor_pid (gpointer te

 return (FALSE);
 }
+
+       if (ret < 0 && errno == ECHILD) {
+#ifdef DEBUG
+               g_message ("%s: Process %d does not exist (anymore)", __func__,
+                          process->id);
+#endif
+               /* Faking the return status. I do not know if it is correct
+                * to assume a successful exit.
+                */
+               status = 0;
+       }

 #ifdef DEBUG
 g_message ("%s: Process %d finished", __func__, ret);

--- mono/metadata/mempool.c.orig      2010-01-29 11:58:16.871052861 +0100
+++ mono/metadata/mempool.c   2010-01-29 12:30:45.143367454 +0100
@@ -212,12 +212,14 @@ mono_backtrace (int size)

         EnterCriticalSection (&mempool_tracing_lock);
         g_print ("Allocating %d bytes\n", size);
+#if defined(HAVE_BACKTRACE_SYMBOLS)
         symbols = backtrace (array, BACKTRACE_DEPTH);
         names = backtrace_symbols (array, symbols);
         for (i = 1; i < symbols; ++i) {
                 g_print ("\t%s\n", names [i]);
         }
         free (names);
+#endif
         LeaveCriticalSection (&mempool_tracing_lock);
 }

--- mono/metadata/metadata.c.orig     2010-01-29 11:59:38.552316989 +0100
+++ mono/metadata/metadata.c  2010-01-29 12:00:43.957337476 +0100
@@ -3673,12 +3673,16 @@ mono_backtrace (int limit)
         void *array[limit];
         char **names;
         int i;
+#if defined(HAVE_BACKTRACE_SYMBOLS)
         backtrace (array, limit);
         names = backtrace_symbols (array, limit);
         for (i =0; i < limit; ++i) {
                 g_print ("\t%s\n", names [i]);
         }
         g_free (names);
+#else
+       g_print ("No backtrace available.\n");
+#endif
 }
 #endif

--- support/map.c.orig        2010-01-29 12:05:22.374653708 +0100
+++ support/map.c 2010-01-29 12:10:29.024412452 +0100
@@ -216,7 +216,7 @@
 #define _cnm_dump(to_t, from) do {} while (0)
 #endif /* def _CNM_DUMP */

-#ifdef DEBUG
+#if defined(DEBUG) && !defined(__FreeBSD__)
 #define _cnm_return_val_if_overflow(to_t,from,val)  G_STMT_START {   \
         int     uns = _cnm_integral_type_is_unsigned (to_t);             \
         gint64  min = (gint64)  _cnm_integral_type_min (to_t);           \

Some com­pa­nies do not want to get money…

The rea­son for our prob­lems with the phone @Work (see relat­ed posts) is known now. The com­pa­ny pay­ing for the phone lines changed the tax num­ber (fall­out of a require­ment to make busi­ness with banks here), informed the 2 phone com­pa­nies they are using about it, got a bill from one with the old tax num­ber and from the oth­er one with the cor­rect tax num­ber, informed the phone com­pa­ny which used the old num­ber again, got again a bill with the wrong tax num­ber, informed them again, … until the phone com­pa­ny cut the line (pay­ing the bill while there is the wrong tax num­ber on it seems to cause big prob­lems lat­er in the tax/money han­dling chain).

So there a sev­er­al kinds of phone com­pa­nies here. Those which want to make busi­ness with cus­tomers (e.g. Ver­i­zon in LU), and those which do not (e.g. P&T in LU).

Let us wait and see when we get work­ing phone lines and from whom… 🙂