[torqueusers] torque daemons can not be stopeed during uninstall

onceihave onceihave at 163.com
Tue Dec 9 18:21:02 MST 2008


 
 


On 2008-12-10£¬"Steve Young" <chemadm at hamilton.edu> wrote£º
>Ahh.. I guess I mis-understood I was under the impression this  
>"onceihave"??? was getting an rpm version of torque from somewhere. If  
>he's building it himself then why not just modify the rpm to suit his  
>own needs... Ok Garrick I gotcha.. put me down on your side =). Sorry  
>for the confusion.. my bad.
>

Yeah. I downloaded Torque tarball and compiled rpms with my preferred 
options and configurations. Why I opened this thread is that I like
daemons can be stopped as other software, in default spec file :-)

Thanks.

Steven Wang

?>-Steve
>
>
>
>On Dec 9, 2008, at 4:39 PM, Garrick Staples wrote:
>
>> On Tue, Dec 09, 2008 at 04:32:39PM -0500, Steve Young alleged:
>>> 	No I don't use rpm versions of torque server because too many times
>>> you get all sorts of dependancy problems. I'd rather compile it
>>> against the libs I currently have installed on the server.
>>
>> Again, we are talking about rpms that you are building.  You can not  
>> build rpms
>> against libs that aren't on your own machine.
>>
>>
>>> I do expect that for rpm packages (that I do use), when I tell it to
>>> remove the package that it actually does stop the daemon and remove
>>> the package. That seems to be the way most rpm's work. I would be a
>>> little confused to remove the rpm and find that afterwards there is
>>> still the daemon running? I could see using an rpm package for the
>>> client nodes (pbs_mom).  There I would still expect that a uninstall
>>> would stop the daemon and then remove the package.
>>
>> How about a compromise?  How about printing a warning message?
>>
>>
>>> 	For me, It's much easier to compile the app and when I need to make
>>> changes/upgrades I can compile another version and a quick stop of  
>>> the
>>> daemon and start of the new daemon will get me running. If there are
>>> problems I can quickly revert back to the previous version. Suppose I
>>> remove the rpm package and try to install a new version only to find
>>> out that because of dependancies that I can't install the new  
>>> version.
>>> Now I'm stuck and I hope I can re-install the old version of the
>>> package and get everything configured back the way I had it. This is
>>> why I don't like to use rpm's for certain server applications.
>>
>> Again, you *are* compiling the app.  CRI doesn't distribute binary  
>> rpms.
>>
>> And that stuff about deps is silly.  Rpms are upgraded with 'rpm -U'  
>> which does
>> the uninstall of the old package *after* installing the new  
>> package.  You can't
>> remove a package because you don't have the deps for the new package.
>>
>> Of course, you are free to use whatever you want.  I'm not actually  
>> saying that
>> you should be using rpms.  I would just hate for you to make that  
>> decision with
>> bad information!
>>
>>
>>> 	I do understand your point Garrick, and I agree with you about
>>> torque. It can be a tricky beast sometimes. I'm just pointing out  
>>> that
>>> as an Admin I would actually expect that an rpm package would stop  
>>> the
>>> daemon and remove it.  Why would anyone not want it removed if that's
>>> what they asked for?
>>
>> Well, there are 2 possible scenerios.
>>
>> *shrug*
>>
>> -- 
>> Garrick Staples, GNU/Linux HPCC SysAdmin
>> University of Southern California
>>
>> See the Dishonor Roll at http://www.californiansagainsthate.com/
>>
>> _______________________________________________
>> torqueusers mailing list
>> torqueusers at supercluster.org
>> http://www.supercluster.org/mailman/listinfo/torqueusers
>
>_______________________________________________
>torqueusers mailing list
>torqueusers at supercluster.org
>http://www.supercluster.org/mailman/listinfo/torqueusers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.supercluster.org/pipermail/torqueusers/attachments/20081210/c5bf9aa7/attachment.html


More information about the torqueusers mailing list