[torqueusers] torque daemons can not be stopeed during
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 :-)
>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
>>> 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
>>> 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
>> 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
>>> as an Admin I would actually expect that an rpm package would stop
>>> daemon and remove it. Why would anyone not want it removed if that's
>>> what they asked for?
>> Well, there are 2 possible scenerios.
>> 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
>torqueusers mailing list
>torqueusers at supercluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the torqueusers