SQL1042C An unexpected system error occurred

[rjminsha]

I'm getting SQL1042C An unexpected system error occurred when running the build script.

If I add the following to the Dockerfile things work for me.

Setup instance directory as an ext4 volume, db2 cannot write to AUFS

VOLUME /home/db2inst1

Are others not seeing this issue?
Also see that you removed the 'sysctl -w kernel.shmmax=18446744073709551615' command from the startup script. Have you started to simply set this on the docker host ?

[jbonhag]

Thanks for the note -- I'm checking this out now.

[jbonhag]

So, now for some reason the initial setup fails for me, whereas before setup would finish but the database wouldn't start.

Removing sysctl -w kernel.shmmax=18446744073709551615 shouldn't affect that, though, because it didn't run until after the initial build.

At what point does the build break on your machine?

[rjminsha]

The first sign of an error was found when trying to start a newly created instance with db2start:
$ db2start
SQL1042C An unexpected system error occurred

Here is an explanation from a member of the DB2 team (my knowledge in this space is pretty limited).
A couple of flags to the open Unix system call are disabled on AUFS to enforce copy on write. DB2 happens to use one of those flags when running instances, specifically O_DIRECT. Although installation is possible on AUFS, creating and using a DB2 instance is not.

The root cause of the error was due to the failure of an open call with O_DIRECT supplied as one of the flags. The fix is to mount a Docker volume to the DB2 instance's home directory. The volume will have a ext4 filesystem, one that readily accepts calls to open with O_DIRECT specified.

[rieske]

Another solution to this problem is to switch the docker storage backend from AUFS to devicemapper:
http://muehe.org/posts/switching-docker-from-aufs-to-devicemapper/

I was initially using a dated RHEL box as a host system which apparently had devicemapper as default storage backend. When hosting this image on a recent Ubuntu system, I experienced the same issue and the fix was either to use an externally mounted volume or switch to devicemapper.

[jbonhag]

So, is this more of a Docker issue than an issue with this particular container? Can we include either fix in the Dockerfile?

[rjminsha]

I have not dug further into this over the past week or so but so far all I have found are solutions that are containable within the dockerFile. Perhaps there are startup options with DB2 that can be explored. I think this is a good topic for the docker-dev IRC.

[jbonhag]

After doing a little more testing (whew, has it been two months already?!?!) I agree with @rieske that the solution is to switch the Docker backend. I don't know if you can switch the backend per-Dockerfile. I'm using boot2docker at the moment and it looks like it's a one-or-the-other decision.

This seems to confirm that DB2 is picky about its filesystem: http://xcoolwinds.wordpress.com/2013/05/20/db2-doesnt-start-on-linux/

[deeky666]

Btw if you do not want to switch to devicemapper, you can also use btrfs storage backend which is probably a much better alternative (had many problems with devicemapper).
A pretty easy and good tutorial can be found here: https://meta.discourse.org/t/rough-notes-getting-btrfs-working-on-digital-ocean/20246
Hope this helps.

[jbonhag]

@deeky666 Appreciate it!