<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Fehler on Marco Gabriel Blog</title>
    <link>https://www.marcogabriel.com/tags/fehler/</link>
    <description>Recent content in Fehler on Marco Gabriel Blog</description>
    <image>
      <title>Marco Gabriel Blog</title>
      <url>https://www.marcogabriel.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</url>
      <link>https://www.marcogabriel.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</link>
    </image>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sun, 30 Nov 2014 13:38:12 +0100</lastBuildDate>
    <atom:link href="https://www.marcogabriel.com/tags/fehler/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>mysqldump: Error 2020: Got packet bigger than ‘max_allowed_packet’ bytes</title>
      <link>https://www.marcogabriel.com/posts/642-mysqldump-error-2020-got-packet-bigger-than-max-allowed-packet-bytes/</link>
      <pubDate>Sun, 30 Nov 2014 13:38:12 +0100</pubDate>
      <guid>https://www.marcogabriel.com/posts/642-mysqldump-error-2020-got-packet-bigger-than-max-allowed-packet-bytes/</guid>
      <description>&lt;p&gt;Für ein &lt;a href=&#34;http://www.inett.de/produkte/zarafa&#34;&gt;Zarafa&lt;/a&gt; Upgrade von 6.40 auf 7.1 musste ich eine MySQL Datenbank von einem alten auf einen neuen Server übernehmen. Da es sich um eine relativ große Datenbank handelte, testete ich den Vorgang vorab und alles funktionierte - inklusive dem Dump und dem Restore der Datenbank.&lt;/p&gt;
&lt;p&gt;Beim eigentlichen Upgrade dann brach der Dump mit der folgenden Meldung ab:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;mysqldump: Error 2020: Got packet bigger than &amp;#39;max_allowed_packet&amp;#39;
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Das Problem ist, dass &lt;code&gt;mysqldump&lt;/code&gt; nicht die gleichen Konfigurationsparameter wie der &lt;code&gt;mysqld&lt;/code&gt; verwendet. In der &lt;code&gt;/etc/mysql/my.cnf&lt;/code&gt; kommt ganz weit unten eine Sektion namens &lt;code&gt;[mysqldump]&lt;/code&gt;, in der man die &lt;code&gt;max_allowed_packet&lt;/code&gt; Größe anpassen muss, wenn der Server ebenfalls größere Pakete zulässt. Passt man diese Größe nicht an, können Backups unbrauchbar sein weil sie mittendrin abbrechen.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Error: bad minute; while reading /etc/crontab</title>
      <link>https://www.marcogabriel.com/posts/515-error-bad-minute-while-reading-etccrontab/</link>
      <pubDate>Thu, 09 Jul 2009 14:22:17 +0200</pubDate>
      <guid>https://www.marcogabriel.com/posts/515-error-bad-minute-while-reading-etccrontab/</guid>
      <description>&lt;p&gt;Gerade eben stellte ich fest, dass auf einem Ubuntu 8.04 Server die Cron-Jobs nicht mehr ausgeführt werden. Also machte ich mich auf die Suche nach dem Grund, konnte ihn aber zunächst nicht finden. In der /var/log/syslog dann der erste Hinweis:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;Error: bad minute; while reading /etc/crontab
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Die /etc/crontab sah allerdings sehr normal aus. Da gab es keine falschen Einträge oder fehlende Angaben. Nach einigem auskommentieren und testen bin ich dann auf die Lösung gekommen. In der crontab fand ich folgende Zeile, bei der ich mir erst mal nichts dachte:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
