Bug#412478: tomcat5.5: should load capability module if required
reassign 412478 jsvc retitle 412478 jsvc: clarify error message if capabilities module is missing tag 412478 -wontfix +upstream severity 412478 minor thanks Adrian Bridgett wrote: That was in fact, part of the problem - either it didn't produce any error message, or it wasn't clear (until I googled) what the problem was. Both I think! Ok, reassigning this to jsvc, the error message could be improved at least. Marcus pgpLcQ3jJ6KFu.pgp Description: PGP signature
Bug#412478: tomcat5.5: should load capability module if required
tag 412478 +wontfix thanks On 2/27/07, Marcus Better [EMAIL PROTECTED] wrote: tag 412478 -wontfix +upstream Marcus, I think you were right about the wontfix tag. Also, if it's upstream fix the bug, then we can close it. The wontfix tag means we don't want to fix it in the package, but if it's fixed upstream, it'll be ok. Don't close the bug so people with the same problem can see it and maybe comment it. Thanks, -- Arnaud Vandyck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412478: tomcat5.5: should load capability module if required
clone 412478 -1 reassign -1 tomcat55 retitle -1 tomcat5.5: should load capability module if required severity -1 wishlist tag -1 -upstream tag 412478 -wontfix thanks Arnaud Vandyck wrote: I think you were right about the wontfix tag. Hmm, did you notice that I reassigned the bug to jsvc and retitled it? (Isn't the BTS fun! :-) I'm cloning it back and leaving the wontfix tag on the Tomcat bug (about loading modules), but removing it from the jsvc bug about printing a sensible error message, which I can fix even though it's an upstream issue. (Upstream happens to do a very bad job of maintaining commons-daemon lately.) Marcus pgplBjXKICSUy.pgp Description: PGP signature
Bug#412478: tomcat5.5: should load capability module if required
Package: tomcat5.5 Version: 5.5.20-4 This is probably worth adding to the tomcat5.5 startup script. # load capability module to prevent errors # http://issues.apache.org/bugzilla/show_bug.cgi?id=33154 modprobe capability /dev/null 21 If this doesn't happen then jsvc doesn't start on recent kernels if capabilities are compiled as a module. You have to set errfile adn outfile to see the error: 23/02/2007 08:45:49 7517 jsvc.exec error: syscall failed in set_caps 23/02/2007 08:45:49 7517 jsvc.exec error: set_caps(CAPS) failed 23/02/2007 08:45:49 7516 jsvc.exec error: Service exit with a return value of 4 Thanks, Adrian -- Adrian Bridgett - [EMAIL PROTECTED] GPG key available on public key servers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412478: tomcat5.5: should load capability module if required
tag 412478 wontfix thanks AFAIK the Debian kernels have capabilities compiled in (please correct me if I am wrong). Tomcat should not deal with loading kernel modules. If you compile a custom kernel, you are responsible for loading required modules. Just add it to /etc/modules. (Or compile it in, which seems to make more sense.) Regards Marcus pgpFVgtaoEYrT.pgp Description: PGP signature
Bug#412478: tomcat5.5: should load capability module if required
AFAIK the Debian kernels have capabilities compiled in (please correct me if I am wrong). Tomcat should not deal with loading kernel modules. Sure; however why would it be hard to modprobe || true in the init script if it helps in the non-default case? It may be easy, but it will get less easy when more people start filing bugs after removing some essential kernel feature. And we would have to do the same for any other apps that happen to rely on this module, ending up with potentially lots of init scripts that load modules on their own. (Besides the problem is in jsvc, not Tomcat.) I would like to close this bug as a non-issue. Marcus pgpTWFP6MvA1E.pgp Description: PGP signature
Bug#412478: tomcat5.5: should load capability module if required
On Mon, Feb 26, 2007 at 12:31:56PM +0100, Marcus Better wrote: tag 412478 wontfix thanks AFAIK the Debian kernels have capabilities compiled in (please correct me if I am wrong). Tomcat should not deal with loading kernel modules. If you compile a custom kernel, you are responsible for loading required modules. Just add it to /etc/modules. (Or compile it in, which seems to make more sense.) Its not even a good idea to compile this as module. If you want this functioniality, put it directly into the kernel. Cheers, Michael -- .''`. | Michael Koch [EMAIL PROTECTED] : :' : | Free Java Developer http://www.classpath.org `. `' | `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412478: tomcat5.5: should load capability module if required
On Mon, Feb 26, 2007, Marcus Better wrote: AFAIK the Debian kernels have capabilities compiled in (please correct me if I am wrong). Tomcat should not deal with loading kernel modules. Sure; however why would it be hard to modprobe || true in the init script if it helps in the non-default case? /etc/modules is a different workaround, but I think it should be avoided when possible. -- Loïc Minier [EMAIL PROTECTED]
Bug#412478: tomcat5.5: should load capability module if required
On Mon, Feb 26, 2007, Marcus Better wrote: It may be easy, but it will get less easy when more people start filing bugs after removing some essential kernel feature. Applications are supposed to error out when required features are missing, but this is all a separate issue. And we would have to do the same for any other apps that happen to rely on this module, ending up with potentially lots of init scripts that load modules on their own. I would like to close this bug as a non-issue. Well, it's up to you, but I think it's common practice to support this on a best effort basis: bee% grep modprobe /etc/init.d -rl /etc/init.d/libdevmapper1.02 /etc/init.d/lvm /etc/init.d/modutils /etc/init.d/udev /etc/init.d/discover /etc/init.d/module-init-tools /etc/init.d/acpid /etc/init.d/pcmciautils /etc/init.d/nfs-common /etc/init.d/alsa /etc/init.d/apmd /etc/init.d/avahi-daemon /etc/init.d/hotkey-setup /etc/init.d/cupsys /etc/init.d/lwresd /etc/init.d/ipw3945d /etc/init.d/mdadm-raid /etc/init.d/vmware (This is only on my laptop obviously, YMMV.) My suggestion would be to downgrade this to wishlist and add a modprobe when you find the time. (Besides the problem is in jsvc, not Tomcat.) Oh; I suppose this bug can be reassigned or perhaps jsvc can be made a shell wrapper which loads the module as well; or even tomcat can source an init shell snippet from the jsvc package before invoking jsvc then? -- Loïc Minier [EMAIL PROTECTED]
Bug#412478: tomcat5.5: should load capability module if required
Well, it's up to you, but I think it's common practice to support this on a best effort basis: bee% grep modprobe /etc/init.d -rl Those are nearly all low-level utilities or drivers. I see your point though. Oddly enough /etc/init.d/avahi-daemon does load the capabilities module, see #352858. Incidentally, that discussion shows that a user had problems because he left out the capabilities module altogether... I don't really feel like opening this can of worms. Anyone who doesn't compile in the capabilities module is asking for trouble, including security issues. It seems to be a bad idea to encourage or support it, but I will consider it a bit more... Marcus pgpB92sq3lzaC.pgp Description: PGP signature
Bug#412478: tomcat5.5: should load capability module if required
On Mon, Feb 26, 2007 at 13:39:10 +0100 (+0100), Lo?c Minier wrote: On Mon, Feb 26, 2007, Marcus Better wrote: It may be easy, but it will get less easy when more people start filing bugs after removing some essential kernel feature. Applications are supposed to error out when required features are missing, but this is all a separate issue. That was in fact, part of the problem - either it didn't produce any error message, or it wasn't clear (until I googled) what the problem was. Both I think! Adrian -- Adrian Bridgett - [EMAIL PROTECTED] GPG key available on public key servers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
