[Debian] Re: Bug#576227: insserv: warning: script is corrupt or invalid: /etc/init.d/../rc6.d/S00vzreboot

Kir Kolyshkin kir at openvz.org
Mon Apr 5 06:56:54 EDT 2010


On 04/03/2010 04:04 PM, Ola Lundqvist wrote:
> Hi Christian
>
> On Sat, Apr 03, 2010 at 11:13:38AM +0200, Christian Hofstaedtler wrote:
>    
>> Hi Ola,
>>
>> * Ola Lundqvist<opal at debian.org>  [100402 00:49]:
>>      
>>> I have never used insserv myself. Can you send me your
>>> S00vzreboot file? I need to determine why it considers it to be
>>> corrupt.
>>>        
>> Squeeze seems to install insserv by default, so this was not my choice ;-)
>>
>>      
>>>  From the source in squeeze it looks like it generates the following file:
>>> #!/bin/bash
>>>        
>>>> /reboot
>>>>          
> Ok. Creates a /reboot file. It must have some function in openvz to reboot it.
>
>    
>> Lenny version generates this:
>>
>>     # cat /etc/init.d/../rc6.d/S00vzreboot
>>     #!/bin/bash
>>     >//reboot
>>      
> Ok. Both has same function.
>
>    
>>> And that is about it. It is understandable if insserv considers it to be
>>> corrupt. On the other hand, it is really just an empty file so maybe
>>> insserv should be changed here.
>>>
>>> It would be possible to generate more in that script so that insserv determines
>>> that this is something empty and ignores it.
>>>        
>> This is probably the right thing to do, even if it exposes something which looks
>> like a hack even more.
>>      
> Yes. I'm checking with upstream now.
>    

The problem is not with the text inside the file, the problem is that 
the file
itself is a real file, while insserv expects symlink.

Nevertheless, the complaint from insserv is just a warning, and although
it looks bad nothing bad is happening.

We can redo the logic and create a real file in init.d and then a symlink
in rc6.d but this will make things more complex, and the sole benefit
would be that insserv stops complaining. Because of that, I'd rather
let it stay as is.

More to say, this reboot hack will be replaced by a event-driven daemon
in future OpenVZ releases so it doesn't make much sense to fix something
that is not broken and will be gone in the future.

--kir


More information about the Debian mailing list