The problem: You’ve enabled automatic security update installation, and yet, security updates are not being automatically installed.

First possible solution: This one is easy. Check the file /etc/cron.daily/apt and make sure that it is marked executable. Permissions on this file should look like rwxr-xr-x (755). This file somehow lost its executability when I upgraded from one Ubuntu release to the next, which broke the daily update check and thus no automatic security update installation.

In the more recent occurrence of this problem for me, the daily update check was obviously happening. I would connect to the server via SSH and see something like…

Welcome to the Ubuntu Server!
* Documentation: http://www.ubuntu.com/server/doc

5 packages can be updated.
5 updates are security updates.

So, the daily update check was happening, but the automatic update installation was not. What could cause this?

Well, it turns out that the script that does the update installation will only proceed to that point if the check for updates was successful (no errors at all). This leads us to…

Second possible solution: Run a sudo aptitude update or sudo apt-get update and see if there are any errors. If there are, address them, and hopefully that will resolve the problem. In my case, I had a third-party repository that had become inaccessible, so although the main Ubuntu repositories were updating fine, this error still prevented automatic security update installation.

If you want to know how to set up automatic security updates, there are (at least) three possible ways:

• When first installing the system, you will be given the option to enable automatic security updates.
• Follow the directions on this page in the Ubuntu Wiki. I recommend the apt.conf.d method (which is what will be set up for you using either of the other options presented here), but, the cron method may help you get around other similar issues that prevent automatic updates from working.
• You can set it up using the GUI method like you would with a desktop version of Ubuntu. First, install Synaptic (sudo aptitude install synaptic). Then, make sure that you are connected to your server via SSH with X11 forwarding (by adding the -Y parameter to ssh when you connect). Then, run Synaptic on the server as root (just type “sudo synaptic” at the terminal) and the Synaptic window should appear on your desktop. Then, select “Settings -> Repositories” from the menu, click on the “Updates” tab, and configure automatic updates as you see fit.

SQLException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
SQLState: 08S01
VendorError: 0

After searching for a while and going through some solutions that didn’t work for me, I found the answer here.  I’m re-posting it because that answer is posted in Spanish. 

All you have to do is open /etc/init.d/tomcat6 in your favorite text editor (as root), find the line that looks like TOMCAT6_SECURITY=yes, and change it to TOMCAT6_SECURITY=no.  Then, restart the Tomcat server (sudo service tomcat6 restart).  Ta da!!  MySQL connections are now working.

Now, there’s probably a better way to do this that doesn’t involve completely turning off “TOMCAT6_SECURITY,” but this seems fine for a small test project which is what I’m working on (it will eventually be deployed on the JBoss server).  I’ll be sure to update this post if I find it… or if you know anything, leave a note in the comments below.

I recently replaced the machine that powers this very web site with a better one.  This was my first migration since switching to Ubuntu Server last winter.  I essentially took the hard drive out of the old machine and plopped it in the new one, booted it up, and hoped for the best.  Since Linux is not as picky as Windows about being moved to a new set of hardware, I figured it would work out fine.

Sure enough, Ubuntu booted right up on the new machine without so much as a complaint.  However, network connectivity was gone.  The old machine was using a PCI Ethernet card, while the new machine had an on-board controller that I hoped to use.  Anyway, I took the PCI card from the old machine and put it in the new machine, and then the network connectivity was back.

Why wouldn’t Ubuntu just start using the on-board controller, though?

Well, it turns out Ubuntu Server, in its default configuration, remembers which MAC address goes with which Ethernet device.  (This as opposed to the default configuration on the desktop version, where NetworkManager handles this dynamically.)  This information is stored in /etc/udev/rules.d/70-persistent-net.rules, and looks something like this:

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x14e4:0x4401 (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Here, my old Ethernet card (e100) and my new card (b44) are listed as eth0 and eth1.  In /etc/network/interfaces, I only had a configuration for eth0.  Thus, no network connectivity when that card was not present.

The solution is simply to modify /etc/udev/rules.d/70-persistent-net.rules so that the card you want is eth0, or to add an appropriate configuration for eth1 in /etc/network/interfaces.  Of course, the entry in the rules file for the adapter that is no longer present should be commented out or erased. Anyway, after making these changes and bouncing the Ethernet kernel modules (or just rebooting the machine), things should work how you like.

I don’t think that this was caused by the kernel update (I even booted up the old kernel to make sure), but some other update that came along recently is probably to blame, and the problem didn’t show itself until I had to log out and log back in.

I don’t use a fancy theme, just the regular default Ubuntu theme.  In this situation, the window borders were still themed properly (although now an ugly blue color, which you can’t see in this screen shot), but the icon set was the default GNOME set no matter which set I chose in the appearence preferences, and most of the controls weren’t themed either (see the bottom-left and top-right of the screen shot).

I thought that maybe something had gone bad in my profile, but I created a new account and it also had the problem, so something had apparently broken system-wide.  This is what makes me suspect that a recent software update is to blame, because I haven’t been poking around in any system-wide stuff on this machine in a while.

I didn’t realize that using the FreeNX server was part of the problem at first, but I finally found some other people who have the same issue this evening, and one of them mentioned this bug report, which mentions another bug report, which has the solution to the problem.  (It doesn’t just affect FreeNX either, some people have the same problem with VNC.)  It turns out that gnome-settings-daemon is crashing, and without it running, the theme is messed up (among other things).  To get it running again, you have to disable its keyboard plug-in.  (I’m not yet sure what you lose by disabling this plug-in, but the keyboard still works even without gnome-settings-daemon running, so what’s there to lose…).

Here’s the solution.

• Run gconf-editor
• Navigate to /apps/gnome_settings_daemon/plugins/keyboard
• Uncheck the “active” box on the right
• Log out and log back in (or manually start gnome-settings-daemon)

There you have it.  This will tie us over until the issue is actually fixed in gnome-settings-daemon.  Maybe, if you are experiencing this issue, you didn’t have to search around for as long as I did to find the solution.

Update: August 5, 2009

There is a new bug report on this issue.

Also, a user reported that the fix above did not work.  I suggest also disabling the mouse plug-in for gnome-settings-daemon (by following the steps above, but going to /apps/gnome_settings_daemon/plugins/mouse instead), since some of the comments in the first gnome-settings-daemon bug report indicated that this was necessary for them to fix the problem.  If that doesn’t help, then something else is causing gnome-settings-daemon to crash… or if it is not crashing, you must have a completely different issue.

Update: September 23, 2009

Reportedly, you can fix this problem by reverting libxklavier to version 3.9-0ubuntu1.