You are here

Linux

MySQL encoding error: Warning (Code 1366): Incorrect string value: '\xE9, a <...' for column 'body' at row 3

While performing a CSV import recently, I ran into the following error messages:

Warning (Code 1366): Incorrect string value: '\xE9, a <...' for column 'body' at row 3
Warning (Code 1366): Incorrect string value: '\xE6. He ...' for column 'body' at row 24
Warning (Code 1366): Incorrect string value: '\xE9, and...' for column 'body' at row 26

The first message was triggered due to the accented é in the word, protegé, in the input. The rest of the field was not imported. The others were similarly triggered.

Changing a file's encoding using Vim

During imports and stuff, it's imperative that all steps utilise the same encoding/character set. If a text file is not using the preferred encoding, we can use Vim to change it during its save action as follows:

:set fileencoding=utf8
:w

or if you want to save it to a different file and leave the current file unchanged:

:w ++enc=utf-8 newfile.txt

Upgrading KTorrent in Kubuntu Precise

KTorrent on the LTS release of Kubuntu—Precise Pangolin aka 12.04—is perfectly fine except for the fact that it comes only with version 4.1. Unfortunately, this package is missing a few features that I was looking for, especially the option to add magnet links via its web interface.

Upgrading from 4.1 to 4.3 (the latest version at the time of writing) is pretty straightforward if one is happy to accept PPA sources.

Replacing all occurences of a string in a file with another

In Linux, replacing all instances of a string with another string is easy thanks to sed. A simple example is as follows:

To replace the string foo with the string bar in all .txt files:

sed 's#foo#bar#g' *.txt

This will replace the strings. However, it won't actually save the changes and will instead output the modified text to the screen. To retain the changes or, in other words, to perform the replacements in place within the file, use the -i switch:

PDOException: SQLSTATE[HY000]: General error: 144 Table 'cache_menu' is marked as crashed and last (automatic?) repair failed: DELETE FROM {cache_menu};

While trying to edit a menu on a Drupal site, I found that none of my changes were being saved. Looking at the logs led me to the following error message:

PDOException: SQLSTATE[HY000]: General error: 144 Table 'cache_menu' is marked as crashed and last (automatic?) repair failed: DELETE FROM {cache_menu};

Simply restarting MySQL did not fix things and it looked like I had to get my hands a li'l dirty.

flashplugin-installer: Unable to download plugin from archive.canonical.com

Attempting to update flashplugin on Ubuntu Precise resulted in an error. Removing the package and reinstalling it resulted in the following:

MySQL will not start due to corrupt InnoDB tables

After a recent server migration, I found that my MySQL instance was not starting up (on Debian Squeeze). A look in the logs revealed that MySQL was having issues with corrupt InnoDB tables and therefore refusing to start. A number of forums informed me to do the following.

dpkg cannot install as there's no space left on the device even though there is

I ran into this issue a couple of days ago and cannot recall the exact error message. However, the problem was effectively that aptitude could not install the new kernel update because my partition had apparently run out of space. An interrupted update to Klipper is one thing and the Linux kernel a whole 'nother kettle of fishies. Thinking that I simply needed to free up some space on my partition, I checked the current status via df. I surprisingly had 30% of free space still left lying about (my /home is mounted on a different partition). So what ...

Cron: pam_unix (cron:session): session opened/closed for user root by (uid=0)

This is my week of playing around with mail servers and I have been keeping an eye on the logs on a regular basis. I noticed that the auth.log was riddled with millions of these pointless (from my POV anyhow) log entries:
CRON: pam_unix(cron:session): session opened for user root by (uid=0)
CRON: pam_unix(cron:session): session closed for user root

Cyrus sasld testsaslauthd connect() : No such file or directory 0

While trying to debug a postfix authentication issue in Debian 6, I had to use testsaslauthd to test things out:
testsaslauthd -s smtp -u foo@example.com -p test

only to get the following error:
connect() : No such file or directory 0

This is apparently because a lot of people (and authors) follow the same guide for configuring postfix and saslauthd. One of the steps missing is to symlink and saslauthd directory to a location within postfix. To fix:

Pages

Subscribe to RSS - Linux