Ondrej - aha! with the debug, this is making more sense now. Yes, since the ureadahead-touch job spawns a process in the background (ureadahead) and then the job itself exits, the log associated with the main job process gets added to the unflushed list. ureadahead then writes output and the NihIo is automatically serviced to flush the log to disk and set log->unflushed->len to zero. Later, 'initctl notify-disk-writable' gets called and the assert fires as all the output from both /etc/init/ureadahead-touch.conf and from the ureadahead daemon itself has already been logged.
Another point - the fact that ureadahead-touch is triggering the problem does point to an issue with that job - as can be seen, even when the script section ends (and that associated shell dies), 'ureadahead --daemon' continues and if it produces output, that gets logged. A simple work-around is to remove --daemon so that the job process and the log never become detached.
Ondrej - aha! with the debug, this is making more sense now. Yes, since the ureadahead-touch job spawns a process in the background (ureadahead) and then the job itself exits, the log associated with the main job process gets added to the unflushed list. ureadahead then writes output and the NihIo is automatically serviced to flush the log to disk and set log->unflushed->len to zero. Later, 'initctl notify- disk-writable' gets called and the assert fires as all the output from both /etc/init/ ureadahead- touch.conf and from the ureadahead daemon itself has already been logged.
Could you try the following which should be a minimal fix: http:// paste.ubuntu. com/11095313/
Another point - the fact that ureadahead-touch is triggering the problem does point to an issue with that job - as can be seen, even when the script section ends (and that associated shell dies), 'ureadahead --daemon' continues and if it produces output, that gets logged. A simple work-around is to remove --daemon so that the job process and the log never become detached.