Crash after permission denied on pid-file

[Vadim Tkachenko]

drizzled --datadir=/data/bench/drizzle/ --user=mysql

InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
120218 16:25:38 InnoDB: Error: Write to file /var/lib/drizzle/ibdata1 failed at offset 0 66060288.
InnoDB: 1048576 bytes should have been written, only 872448 were written.
InnoDB: Operating system error number 0.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 0 means 'Success'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
InnoDB: 127 rollback segment(s) active.
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
Can't start server: can't create PID file (/var/run/drizzle/drizzled.pid): Permission denied

drizzled: /usr/include/boost/thread/pthread/condition_variable_fwd.hpp:38: boost::condition_variable::~condition_variable(): Assertion `!pthread_cond_destroy(&cond)' failed.
120218 16:25:38 - drizzled got signal 6;
This could be because you hit a bug. It is also possible that this binary
 or one of the libraries it was linked against is corrupt, improperly built,
 or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

read_buffer_size=131072
max_used_connections=0
connection_count=0
It is possible that drizzled could use up to
(read_buffer_size + sort_buffer_size)*thread_count
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

call_backtrace() began at drizzled/signal_handler.cc:156 for drizzled_handle_segfault()
Number of stack frames obtained: 13
drizzled() [0x5418b4]
/lib64/libc.so.6() [0x389b632900]
gsignal()
abort()
/lib64/libc.so.6() [0x389b62b9fe]
__assert_perror_fail()
drizzled() [0x453aeb]
exit()
drizzled() [0x7af149]
thread_proxy()
/lib64/libpthread.so.0() [0x389be077f1]
clone()
Aborted

[Joe Daly (skinny.moey)]

This looks to be getting caused by:

Can't start server: can't create PID file (/var/run/drizzle/drizzled.pid): Permission denied

[Vadim Tkachenko (vadim-tk)]

Joe,

That indeed can be the cause, but that is not a reason for software to crash.

[Henrik Ingo (hingo)]

I can confirm that this happens also with the 7.1.31-rc (current trunk).

[Henrik Ingo (hingo)]

Just as an observation: It seems most daemons create their pid-file as root. Drizzle attempts to create its pid file when running under the drizzle user. This is possible, but seems to create trouble.

For instance on Debian the start_daemon function wants to create the PID file for you, and creates it as root, and then drizzle fails to access it's own pid file due to permssion denied. If drizzled would write to its pid file as root, the problem would be avoided. (Even then it shouldn't crash. The crash should be fixed first, then possibly also move to writing the pid file as root user, before dropping privileges.)

[Henrik Ingo (hingo)]

Brian: For your convenience, using this init script on Debian 6.0 (Squeeze) reliably triggers this bug:
http://bazaar.launchpad.net/~drizzle-developers/drizzle/drizzle-7.1-packaging/view/2513/support-files/deb/debian/drizzle.init

You need to use that revision, in the tip of that branch I already committed a workaround.

[Brian Aker (brianaker)]

We shouldn't crash, but we shouldn't start up either.

[Henrik Ingo (hingo)]

Wasn't this fixed in 7.1.32-rc?

[Patrick Crews (patrick-crews)]

IIRC, it is. I now see changed behavior in branches. Going to set this to fix released for now.