Bug#544999: Alas, the fix doesn't work
On Thu, Sep 10, 2009 at 01:25:06PM +0200, Adam Borowski wrote: Sadly, man-db still spams. The line you added is: if ! grep -q 'envID:.*[1-9]' /proc/self/status; then but /proc/self/status doesn't include that envID line you're looking for, neither on 2.6.18 nor 2.6.26. This approach was provided by Karl Chen in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511771. I'm not familiar with these virtualisation systems so I probably didn't even realise that vserver and OpenVZ weren't the same thing. Can you provide an authoritative way to detect that we're in a vserver container, preferably with a reference? I also wonder, perhaps it would be better to instead ask for having start-stop-daemon hush nice/ionice messages when -q is given, as that's more of an informative message rather than a real error. I CCed the dpkg guys on another similar bug today. It's certainly annoying to have to work around this in multiple places. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544999: Alas, the fix doesn't work
On Thu, Sep 24, 2009 at 01:32:13PM +0100, Colin Watson wrote: On Thu, Sep 10, 2009 at 01:25:06PM +0200, Adam Borowski wrote: Sadly, man-db still spams. The line you added is: if ! grep -q 'envID:.*[1-9]' /proc/self/status; then but /proc/self/status doesn't include that envID line you're looking for, neither on 2.6.18 nor 2.6.26. Can you provide an authoritative way to detect that we're in a vserver container, preferably with a reference? An authoritative way, not really. A non-authoritative way: /proc/self/status will have a line: VxID: 0in the host VxID: xwhere x is a number!=0 in containers So this looks exactly like that envID thingy in OpenVZ. I also wonder, perhaps it would be better to instead ask for having start-stop-daemon hush nice/ionice messages when -q is given, as that's more of an informative message rather than a real error. I CCed the dpkg guys on another similar bug today. It's certainly annoying to have to work around this in multiple places. Yeah, that's why I insist on hushing these non-fatal messages instead. This way you'll have it working when a yet another type of virtualization crops up -- and changing this in start-stop-daemon means anything which uses it will be taken care of. Cheers, -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544999: Alas, the fix doesn't work
reopen 544999 thanks Hi! Sadly, man-db still spams. The line you added is: if ! grep -q 'envID:.*[1-9]' /proc/self/status; then but /proc/self/status doesn't include that envID line you're looking for, neither on 2.6.18 nor 2.6.26. I also wonder, perhaps it would be better to instead ask for having start-stop-daemon hush nice/ionice messages when -q is given, as that's more of an informative message rather than a real error. # cat /proc/self/status Name: cat State: R (running) SleepAVG: 88% Tgid: 11495 Pid:11495 PPid: 10073 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 256 Groups: 0 VmPeak: 5084 kB VmSize: 5084 kB VmLck: 0 kB VmHWM: 540 kB VmRSS: 540 kB VmData: 168 kB VmStk:84 kB VmExe:40 kB VmLib: 1424 kB VmPTE:24 kB Threads:1 SigQ: 0/16377 SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: 344c04ff CapEff: 344c04ff Cpus_allowed: Mems_allowed: ,0001 s_context: 49153 ctxflags: 202020010 initpid: 0 ipv4root: 8523ce59/00ff ipv4root_bcast: -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
