Can I get some gdbadmin logs?

Can I get some gdbadmin logs?

[Michael Elizabeth Chastain]

One of the gdbadmin scripts to update version.in has not run properly
for 4 weeks.  Here is the story so far:

  http://sources.redhat.com/gdb/bugs/1653
  gdb cvs HEAD version.in stuck at 2004-04-17

I don't have login access or scp access to sourceware.
Could somebody in overseers mail me a couple of log files?

The files I need are:

  $HOME/log/update-cvs-version
  $HOME/log/update-cvs-version.gdb_6_1-branch

I don't know this $HOME resolves to, but the crontab is running
the update scripts out of $HOME/ss/update-cvs-version.

Thanks,

Michael C

Re: Can I get some gdbadmin logs?

[Christopher Faylor]

On Sun, May 16, 2004 at 03:31:55PM -0400, Michael Elizabeth Chastain wrote:
>One of the gdbadmin scripts to update version.in has not run properly
>for 4 weeks.  Here is the story so far:
>
>  http://sources.redhat.com/gdb/bugs/1653
>  gdb cvs HEAD version.in stuck at 2004-04-17
>
>I don't have login access or scp access to sourceware.
>Could somebody in overseers mail me a couple of log files?
>
>The files I need are:
>
>  $HOME/log/update-cvs-version
>  $HOME/log/update-cvs-version.gdb_6_1-branch
>
>I don't know this $HOME resolves to, but the crontab is running
>the update scripts out of $HOME/ss/update-cvs-version.

A script is trying to write to the "root" of /sourceware/snapshot-tmp.
The way this is supposed to work is that each project has their own directory
which is used for their temporary needs.  Apparently a gdbadmin script is
attempting to write files into /sourceware/snapshot-tmp which is a no-no
and something that I thought we'd previously dealt with for gdb.

cgf

Re: Can I get some gdbadmin logs?

[Michael Elizabeth Chastain]

ac> Ok, I think the nightly snapshot and version.in worked (which is no 
ac> worse than before).  Delete away ...

Looks good from where I'm sitting.  Good job!

Michael C

Re: Can I get some gdbadmin logs?

[Christopher Faylor]

On Tue, May 18, 2004 at 11:48:31AM -0400, Andrew Cagney wrote:
>>>Eventually delete them.  Once I've made the tweaks, I'd like to let the 
>>>>stuff go through a full 24hr cycle.
>>
>>
>>Ok.  The directory is created.
>
>Ok, I think the nightly snapshot and version.in worked (which is no 
>worse than before).  Delete away ...
>
>thanks,

Thanks.  Apologies for any problems.  I don't recall changing the protection on
this directory but since I assumed that this was the way it was supposed to
be I can easily see myself doing it in an idle moment.

cgf

Re: Can I get some gdbadmin logs?

[Andrew Cagney]

>>Eventually delete them.  Once I've made the tweaks, I'd like to let the 
>>>stuff go through a full 24hr cycle.
> 
> 
> Ok.  The directory is created.

Ok, I think the nightly snapshot and version.in worked (which is no 
worse than before).  Delete away ...

thanks,
Andrew

Re: Can I get some gdbadmin logs?

[Christopher Faylor]

On Mon, May 17, 2004 at 02:40:54PM -0400, Andrew Cagney wrote:
>>On Mon, May 17, 2004 at 02:00:10PM -0400, Andrew Cagney wrote:
>>
>>>>>>cgf> Apparently a gdbadmin script is attempting to write files into
>>>>>>cgf> /sourceware/snapshot-tmp which is a no-no and something that I 
>>>>>>thought
>>>>>>cgf> we'd previously dealt with for gdb.
>>>
>>>>
>>>>Nope :-(
>>>>
>>>
>>>>>>! workdir=/sourceware/snapshot-tmp/gdb-ucv/ucv-$$
>>>>>> mkdir -p ${workdir}
>>>>>> cd ${workdir}
>>>
>>>>
>>>>Chris, can you please create /sourceware/snapshot-tmp/gdb/ (uid:gid = 
>>>>gdbadmin:gdbadmin) I'll then change all the scripts to use sub 
>>>>directories of that.
>>
>>
>>There are already two directories in /sourceware/snapshot-tmp which are
>>owned by gdbadmin.  Should I move all of those under the new gdb
>>directory or just delete them?
>
>Eventually delete them.  Once I've made the tweaks, I'd like to let the 
>stuff go through a full 24hr cycle.

Ok.  The directory is created.

cgf

Re: Can I get some gdbadmin logs?

[Andrew Cagney]

> On Mon, May 17, 2004 at 02:00:10PM -0400, Andrew Cagney wrote:
> 
>>>>>cgf> Apparently a gdbadmin script is attempting to write files into
>>>>>cgf> /sourceware/snapshot-tmp which is a no-no and something that I thought
>>>>>cgf> we'd previously dealt with for gdb.
>>
>>>
>>>Nope :-(
>>>
>>
>>>>>! workdir=/sourceware/snapshot-tmp/gdb-ucv/ucv-$$
>>>>>  mkdir -p ${workdir}
>>>>>  cd ${workdir}
>>
>>>
>>>Chris, can you please create /sourceware/snapshot-tmp/gdb/ (uid:gid = 
>>>gdbadmin:gdbadmin) I'll then change all the scripts to use sub 
>>>directories of that.
> 
> 
> There are already two directories in /sourceware/snapshot-tmp which are
> owned by gdbadmin.  Should I move all of those under the new gdb
> directory or just delete them?

Eventually delete them.  Once I've made the tweaks, I'd like to let the 
stuff go through a full 24hr cycle.

Andrew

Re: Can I get some gdbadmin logs?

[Christopher Faylor]

On Mon, May 17, 2004 at 02:00:10PM -0400, Andrew Cagney wrote:
>>cgf> Apparently a gdbadmin script is attempting to write files into
>>cgf> /sourceware/snapshot-tmp which is a no-no and something that I thought
>>cgf> we'd previously dealt with for gdb.
>
>Nope :-(
>
>>! workdir=/sourceware/snapshot-tmp/gdb-ucv/ucv-$$
>>  mkdir -p ${workdir}
>>  cd ${workdir}
>
>Chris, can you please create /sourceware/snapshot-tmp/gdb/ (uid:gid = 
>gdbadmin:gdbadmin) I'll then change all the scripts to use sub 
>directories of that.

There are already two directories in /sourceware/snapshot-tmp which are
owned by gdbadmin.  Should I move all of those under the new gdb
directory or just delete them?

cgf

Re: Can I get some gdbadmin logs?

[Andrew Cagney]

> cgf> Apparently a gdbadmin script is attempting to write files into
> cgf> /sourceware/snapshot-tmp which is a no-no and something that I thought
> cgf> we'd previously dealt with for gdb.

Nope :-(

> ! workdir=/sourceware/snapshot-tmp/gdb-ucv/ucv-$$
>   mkdir -p ${workdir}
>   cd ${workdir}

Chris, can you please create /sourceware/snapshot-tmp/gdb/ (uid:gid = 
gdbadmin:gdbadmin) I'll then change all the scripts to use sub 
directories of that.

Andrew

Re: Can I get some gdbadmin logs?

[Michael Elizabeth Chastain]

Chris Faylor writes:
cgf> A script is trying to write to the "root" of /sourceware/snapshot-tmp.

You're right.  ss/update-cvs-version is doing this.

It looks like I'm rediscovering stuff that you already know quite well.
But I'll recap for completeness.

There are three scripts in ss/ which use snapshot-tmp:

  do-snapshot
    converted on 2002-09-02 from /sourceware/snapshot-tmp to
    /sourceware/snapshot-tmp/gdb-snapshot

  do-ss
    has always used fixed subdirectories in snapshot-tmp

  update-cvs-version
    has always used unique files in snapshot-tmp
    this worked until 2004-04-17 18:00:00 UTC, when it stopped working

cgf> Apparently a gdbadmin script is attempting to write files into
cgf> /sourceware/snapshot-tmp which is a no-no and something that I thought
cgf> we'd previously dealt with for gdb.

do-snapshot got fixed but update-cvs-version did not get fixed.

Here's a patch for update-cvs-version.  It's trivial.

In conjunction with the patch, the directory
/sourceware/snapshot-tmp/gdb-ucv needs to be created with the right
ownership and permissions.  The same ownership and permissions of
gdb-snapshot ought to be fine.

I haven't tested this patch at all.

I don't know what the maintainer policy for gdbadmin is.
Andrew?

Michael C

===

2004-05-17  Michael Chastain  <mec.gnu@mindspring.com>

	* update-cvs-version: Use a fixed subdirectory in
	/sourceware/snapshot-tmp.

Index: update-cvs-version
===================================================================
RCS file: /cvs/gdbadmin/ss/update-cvs-version,v
retrieving revision 1.5
diff -c -3 -p -r1.5 update-cvs-version
*** update-cvs-version	12 Oct 2001 23:31:22 -0000	1.5
--- update-cvs-version	17 May 2004 05:53:46 -0000
*************** dir=`dirname $file`
*** 21,27 ****
  ver=`basename $file`
  
  
! workdir=/sourceware/snapshot-tmp/update-cvs-version.$$
  mkdir -p ${workdir}
  cd ${workdir}
  
--- 21,27 ----
  ver=`basename $file`
  
  
! workdir=/sourceware/snapshot-tmp/gdb-ucv/ucv-$$
  mkdir -p ${workdir}
  cd ${workdir}