PR0014.html

LSB Problem Report

Problem Report Number 0014 (INT.0003)
Submitter's Classification Specification Problem (INT)
State Resolved
Resolution Interpretation (INT)
Raised 2002-08-16 16:42
Updated 2002-09-05 08:28
Published 2002-09-05 08:28
Certification Program Linux Standard Base Conformance Release 1.2
Test Suite lsb-runtime IA32 version 1.2.1-1
Test Identification LSB.os/procenv/nice/T.nice 5-8
Specification Linux Standard Base Specification 1.2
Location in Spec A-16
Problem Summary Requirements for nice@GLIBC_2.2 break binary compatability
Problem Text Sorry about this :(

The SUS spec for nice@GLIBC_2.2, as tested in the LSB test
suite, are different to what was nice@GLIBC_2.2 in glibc up
until recently (March 2, 2002 in glibc CVS). Unfortunately
the change in return codes make a number of applications
misinterpret the result of a nice() call as having failed,
most notably start-stop-daemon for Debian systems. A brief
review of the apps that use nice on my system comes up with:
atd ignores the return value. procmail expects it to be
SUS-ish, and doesn't raise it's priority properly if not.
python checks for it at compile time, and uses getpriority()
to emulate SUS-style if it found a Linux-style nice(). grip
ignores the return value. samuel/saml treats non-zero
returns as errors. xscreensaver-gnome assumes SUS-like
behaviour, and won't behave quite as expected if it's
initially running at a nice level != 0. Although, actually
the code for that's broken too. zsh ignores the return
value. scm expects Linux-style nice and looks like it
exports that expectation to Scheme scripts that use nice.
procinfo ignores the return value.

For comparison, programs that expect nice to behave as SUS
specifies generally cope reasonably gracefully with the
Linux breakage -- they don't error out unnecessarily, they
either treat is as a success, at worst not managing to get
quite the nice level they wanted.

Unfortunately programs that expect Linux-style returns from
nice and get SUS-style returns tend to fail outright. More
unfortunately, making this change in a point release of the
Debian "stable" distribution doesn't seem plausible to
either myself (as release manager), or Martin Schulze (as
stable release manager) -- it has the potential to break too
much software, and that's something we just don't do
(deliberately, anyway) in stable.

So, what we'd like is to have this portion of the test
battery waived, on account of any of:

* spec should transition to using nice@GLIBC_2.2.6, leaving
nice@GLIBC_2.2 for backwards compatability.

* current spec should allow either Linux or SUS style nice
behaviour, with Linux style deprecated, and made illegal
with LSB 2.0 or so.

* spec should stay as it is, but Debian should be let get
away with this ever-so minor infraction because we're all
such nice people at heart, and it probably won't affect any
ISV's anyway.

Once again, sorry about doing this :(
Test Output -

Review Information

Review Type SA Review
Start Date 2002-08-16 16:42
Last Updated 2002-09-04 11:14
Completed 2002-09-04 11:14
Status Complete
Review Resolution Interpretation (INT)
Review Conclusion Spec has been modified to allow either SUS or GNU
behavior. Applications are advised to check return code
and errno carefully to determine the result.

 

Copyright 2005, The Free Standards Group, All Rights Reserved