Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 431)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#1544 wontfix FTBFS Scientific Linux 5/RHEL5 wish
Description

bleeding edge from DARCS doesn't build on SL5 and presumably RHEL5 bombs out with the following message: configure.ac:14: error: possibly undefined macro: AC_USE_SYSTEM_EXTENSIONS

If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.

autoreconf: /usr/bin/autoconf failed with exit status: 1 error: Bad exit status from /var/tmp/rpm-tmp.3933 (%build)

RPM build errors:

Bad exit status from /var/tmp/rpm-tmp.3933 (%build)

The root cause is presumably that SL5 only provides autoconf-2.59 while the macro complained about is defined in version 2.61 AIUI.

If I understand Darcs annotate correctly this was introduced by the following patch:

Sun Apr 6 18:19:24 BST 2014 Dave Love <d.love@…>

  • Use large file macros, not ...64 functions
#185 fixed IZ1102: user belonging to too many groups sets all queues into error state wig
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=1102]

        Issue #:      1102             Platform:     All           Reporter: wig (wig)
       Component:     gridengine          OS:        Solaris
     Subcomponent:    qmaster          Version:      5.3              CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     ernst
          URL:
       * Summary:     user belonging to too many groups sets all queues into error state
   Status whiteboard:
      Attachments:

     Issue 1102 blocks:
   Votes for issue 1102:


   Opened: Fri Jun 18 07:51:00 -0700 2004 
------------------------


Followup on the following discussion on the
users@gridengine maillist:

Please change the behviour of such jobs from
"set queue into error state and resubmit job
to another queue" to "set job into error
state".


> Date: Wed, 28 May 2003 10:42:24 +0200 (MEST)
> From: Andy Schwierskott <andy.schwierskott@sun.com>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Subject: Re: [GE users] Too many groups send
queues go into (E)rror state
>
>
> Hi,
>
> > --- Jon  Kleinsmith <jon.kleinsmith@conexant.com>
> > wrote:
> > > Looking in the messages log, I see two
things that
> > > bother me:
> > >
> > > 1. the scheduler is trying to set uid and
euid 0 on
> > > the job?
> >
> > Actually the shepherd, not the scheduler. Each
job has
> > its own shepherd, which is used for
> > collecting/controlling the job.
> >
> > The message (uid=0, euid=0) tells you that SGE
> > couldn't add an additional group, but
uid=0/euid=0 is
> > not what SGE is trying to set to, it is
actually the
> > uid/euid of shepherd.
> >
> > > 1. Why does the scheduler need to add the
uid/euid
> > > info for the job?
> >
> > The shepherd needs to add an additional group
id to
> > the job for job control.
>
> There are two reasons why setting the additional
group id for the job may
> fail:
>
>    - the root user on that machine already has
(usually 16) add. group
> id's
>      This should be easy to fix for the admin.
All jobs on that machine
>      would be affected in put the queue into
error state.
>
>      (thinking about this I'm wondering if it
could be possible to reduce
>       the number of add. group id's in the
shepherd process to avoid this
>       source of failure, but I'm not sure if
that couldn't cause other
>       unexpected problems???)
>
>    - the 'job user' has 16 add. group id's.
While this is purely admin
>      related, it's not neccessarily in the
responsibility of the SGE admin
>
>      I think in practice it should be relativly
easy to reduce the number
> of
>      add. group id's of the users to 15, but I
understand that an SGE
> admin
>      does not want that this blocks compute
resources until this problem
> is
>      solved.
>
> > > 2. Why does this error "lock-up" my queues?
> >
> > So that the cluster admin knows that something
wrong
> > is going on.
>
> We had a couple of times this problem report in
the past. I see it would
> be
> better to put the job into error state if user
is already in 16 add.
> groups
>
> Is anyone seeing a reason why it could be a
problem putting the job into
> error state and not the queue in that case? If
no one sees a problem we
> might file this is an enhancement issue.
>
> Andy
>
> > > 3. Is there a simple way of reseting the
error state
> > > of the queues
> > > without losing scheduled/running jobs?
> >
> > As mentioned by other people, use qmod -c
<queue>. You
> > can consider using a cron job to clear the
error state
> > of the queues.
> >
> >  -Ron
> >
> > >
> > > Any info would be helpful.
> > >
> > > -Jon
> > >
> > >
> > > --
> > > Jon  Kleinsmith <jon.kleinsmith@conexant.com>
> > >
> > >

   ------- Additional comments from sgrell Mon Dec 12 02:45:29 -0700 2005 -------
Changed subcomponent.

Stephan

   ------- Additional comments from sgrell Mon Dec 12 02:48:52 -0700 2005 -------
Changed subcomponent.

Stephan
#496 fixed IZ2533: qconf -mrqs adds extra space and linebreak, which cannot be read back wig
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2533]

        Issue #:      2533             Platform:     All      Reporter: wig (wig)
       Component:     gridengine          OS:        Linux
     Subcomponent:    clients          Version:      6.1u3       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    roland (roland)
      QA Contact:     roland
          URL:
       * Summary:     qconf -mrqs adds extra space and linebreak, which cannot be read back
   Status whiteboard:
      Attachments:

     Issue 2533 blocks:
   Votes for issue 2533:


   Opened: Fri Mar 21 13:11:00 -0700 2008 
------------------------


qconf -mrqs: Problems to read it’s own output:
If you try to edit a rule in non SGE_SINGLE_LINE mode, an added space
and line break in the "long" limits leads to
errors when you store and exit the editor (even
without changing a single character).

$ qconf -mrqs
{
name frcq_limit_550_usage
description Limit emulator slot usage to 2
enabled TRUE
limit users * projects frcq hosts muc-ax4x.micronas.com, \
muc-ax5x.micronas.com to axis_slots_550=2
}

---> returns:

unknown attribute name "muc-ax5x.micronas.com"
each value in the attribute value list in line 6 should end with
"<NEWLINE>"
unrecognized characters after the attribute values in line 6: "to"
each value in the attribute value list in line 6 should end with "}"

The \ is not recognized and both space and \ have to be removed
and all of the limit has to be on one line
before one can write back the rules successfully.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.