Comment 57 for bug 149076

Revision history for this message
hpp3 (hpp3) wrote :

After some research, I have come to the conclusion that this is a FEATURE, NOT a BUG, of WODIM.
From the wodim man page, concerning Process Scheduling Priority:

"Wodim tries to get higher process priority using different methods. This is important because the burn process is usually a realtime task, no long delays should occur while transmitting fresh data to the recorder. This is especially important on systems with insufficient RAM where swapping can create delays of many seconds.

A possible workaround on underpowered systems is the use of the burnfree or similar feature, allowing the recorder to resume.

Root permissions are usually required to get higher process scheduling priority.

On SVr4 compliant systems, wodim uses the real time class to get the highest scheduling priority that is possible (higher than all kernel processes). On systems with POSIX real time scheduling wodim uses real time scheduling too, but may not be able to gain a priority that is higher than all kernel processes.

In order to be able to use the SCSI transport subsystem of the OS, run at highest priority and lock itself into core wodim either needs to be run as root, needs to be installed suid root or must be called via RBACs pfexec mechanism."

So, judging by the error logs everybody submitted, wodim is refusing to do the job because it needs permission to set memory limits. To do this, you either run wodim as root or set the SUID bit for /usr/bin/wodim and introduce potential security risks, OR...
Add this line to /etc/security/limits.conf:

@cdrom - memlock unlimited

Just make sure you are part of the 'cdrom' group.
Apparently, some people are not affected by this because their particular setup is able to make use of the burnfree feature to avoid buffer underruns.
How to fix this distro-wide?
Dunno.