bproc-users — General discussion about BProc.

Re: [BProc] mpi problems

[Nicholas H. <he...@se...>]

On Tue, 2003-06-24 at 05:39, Nasikas Pantelis wrote:
> Hi ,
> 
> I've setup(or at least think so...) Clustermatic that uses
> Bproc for process migration.The slave nodes boot without
> problems and I can confirm that through bpstat.
> When I try to run programs with mpirun I get some
> problems....
> I get the following message
> " p0_4561:  p4_error: Could not gethostbyname for host n1; may be invalid
> name: 61"
> 
> n1 is the name of the slave node(I use only one initially for the
> configuration).I've changed the entries in the file
> /usr/mpich-p4/share/machines.LINUX to include the name n1(and my
> server's hostname) but nothing changed I get the same error message
> again and again.
> 
> Has anyone expierienced the same problems?What might be a solution?

You may wish to try LAM/MPI ( www.lam-mpi.org ) The beta releases of
7.0, and 7.0 when it is release finally all have very nice support for
Bproc. 

Nic
-- 
Nicholas Henke
Penguin Herder & Linux Cluster System Programmer
Liniac Project - Univ. of Pennsylvania

[BProc] mpi problems

[Nasikas P. <pn...@it...>]

Hi ,

I've setup(or at least think so...) Clustermatic that uses
Bproc for process migration.The slave nodes boot without
problems and I can confirm that through bpstat.
When I try to run programs with mpirun I get some
problems....
I get the following message
" p0_4561:  p4_error: Could not gethostbyname for host n1; may be invalid
name: 61"

n1 is the name of the slave node(I use only one initially for the
configuration).I've changed the entries in the file
/usr/mpich-p4/share/machines.LINUX to include the name n1(and my
server's hostname) but nothing changed I get the same error message
again and again.

Has anyone expierienced the same problems?What might be a solution?

Thanks for your time

Re: [BProc] Bproc and SystemV IPC?

[<er...@he...>]

On Thu, Jun 19, 2003 at 07:54:22AM -0700, rwillis wrote:
> 
> I noticed that the following does not work;
>  'bproc 0 ipcs' 
> Is this because bproc uses IPC calls? Let me know if others have the 
> same problem, or if it is just something that I am doing wrong, 
> (everything else works fine). 
> 
> Also, I thought that bproc would move shared object files over with 
> the executable, but this does deem to be working, at least with the .so
> files that I am creating. I have to move them to the remote machines and
> install them. Let me know if there is a way to fix this.

Automatically getting all the shared objects that program needs is
currently an open problem in BProc.  This is because BProc doesn't
have any way of knowing what SOs an app will use before it tries to
open them.

The solution for know is to place the SOs we know people will use on
the nodes (either manually or with beoboot's node_up).

- Erik

Re: [BProc] How do I make a beoboot kernel that will work with beoboot-cm.1.5?

[Larry B. <ba...@us...>]

Thanks to Josh Aune and Mike Madore for their help.

I have updated my Clustermatic 3 installation with the latest versions of
cmtools and beoboot.  I made notes for myself which I have included below.

My intent is to modify the new beoboot so it behaves more like it did on
Clustermatic 2.  In particular, I used to be able to NFS mount several file
systems -- shared read-only, shared read-write, and node-specific read-writ=
e
-- using a single /etc/beowulf/fstab:

    #
    # Read-only mount points
    #
    $MASTER:/bin    /bin            nfs     ro,nolock,rsize=3D8192    0 0
    $MASTER:/opt    /opt            nfs     ro,nolock,rsize=3D8192    0 0
    $MASTER:/sbin   /sbin           nfs     ro,nolock,rsize=3D8192    0 0
    $MASTER:/usr    /usr            nfs     ro,nolock,rsize=3D8192    0 0
    #
    # Private read-write mount points
    #
    $MASTER:/var/node.$NODE /var    nfs     rw,nolock,rsize=3D8192,wsize=3D8192
0 0
    #
    # Shared read-write mount points (MPICH 1.2.4, section 4.11.1: use
"noac")
    #
    $MASTER:/home  /home           nfs
rw,nolock,rsize=3D8192,wsize=3D8192,noac   0 0

This worked in Clustermatic 2 because setupfs was a shell script, and it
expanded each line in fstab before using it.  Clustermatic 3 changed that.
($MASTER has to be changed to MASTER; setupfs substitutes the master node's
IP address for MASTER for NFS mounts; no other substitutions are supported.=
)

I have tested code that defines the MASTER and NODE variables in the
Clustermatic 3 beoboot-cm.1.4 node_up program, and I wrote a beoboot plugin
that supports variable substitution while copying /etc/beowulf/fstab to the
node's /etc/fstab.  Next I will modify setupfs to merge that code into it
and then have setupfs work from the node's /etc/fstab.  I'm going to do tha=
t
work on the beoboot-cm.1.5 code, which I will publish when it is done.

I have never used the Clustermatic 2 setupfs feature that looks for
fstab.$NODE, but I have some ideas about restoring that feature in
Clustermatic 3.  I have to look at the node_up code in beoboot-cm.1.5 to se=
e
what has changed from beoboot-cm.1.4.  Also, it would be nice to expand
$MASTER and $NODE in node_up.conf, e.g., for node-specific miscfiles.

How important is support for $MASTER and $NODE expansion for fstab.$NODE or
in node_up.conf to you?


Larry Baker
US Geological Survey



LANL Clustermatic 3 Update


Install Clustermatic 3.  (See LANL Clustermatic 3 Install.)

Download the cmtools-1.2 and beoboot-cm.1.5 updates from
http://bproc.sourceforge.net to /usr/local/src.

Make an RPM for cmtools-1.2 and install it:

    # rpmbuild =ADtb /usr/local/src/cmtools-1.2.tar.gz
    # rpm =ADUvh /usr/src/redhat/RPMS/i386/cmtools*.rpm

Insert the LANL Clustermatic 3 CD in the CD reader and mount it, or mount
the downloaded ISO image directly:

    # mount =ADt iso9660 =ADr /dev/cdrom /mnt/cdrom

    or:

    # mount =ADt iso9660 =ADr =ADo loop /usr/local/src/CM3.iso /mnt/cdrom

Install the Clustermatic 3 kernel source RPM:

    # rpm =ADUvh /mnt/cdrom/SRPMS/kernel-2.4.19-lanl.22.src.rpm

Unmount the CD/ISO image file:

    # umount /mnt/cdrom

Enable tmpfs support in the beoboot phase 1 kernel:

    # cd /usr/src/redhat/SOURCES
    # vi kernel-2.4.19-i386-beoboot.config

    Change

        # CONFIG_TMPFS is not set
    to

        CONFIG_TMPFS=3Dy

Make the LANL 2.4.19 kernel RPMs and install the new beoboot phase1 kernel:

    # rpmbuild =ADba /usr/src/redhat/SPECS/kernel-2.4.spec
    # rpm =ADUvh =AD-force /usr/src/redhat/RPMS/i386/kernel-beoboot*.rpm

Make the beoboot-cm.1.5 RPMs and install them:

    # cd /usr/src
    # ln =ADs linux-2.4.19-lanl.22 linux
    # rpmbuild =ADtb /usr/local/src/beoboot-cm.1.5.tar.gz
    # rm linux
    # rpm =ADUvh /usr/src/redhat/RPMS/i386/beoboot*.rpm

Create a beoboot floppy disk for the phase 1 boot step for each slave node:

    # beoboot =AD1 =ADk /boot/vmlinuz-2.4.19-lanl.22beoboot =ADf =ADo /dev/fd0

Create the phase 2 boot images:

    # beoboot =AD2 -n

Reboot the master node and boot the slave nodes using the beoboot floppy
disks.

Verify the cluster configuration:

    # bpstat =ADal

Re: [BProc] Bproc and SystemV IPC?

[Joshua A. <lu...@ln...>]

On Thu, Jun 19, 2003 at 07:54:22AM -0700, rwillis wrote:
> 
> I noticed that the following does not work;
>  'bproc 0 ipcs' 
> Is this because bproc uses IPC calls? Let me know if others have the 
> same problem, or if it is just something that I am doing wrong, 
> (everything else works fine). 
> 
> Also, I thought that bproc would move shared object files over with 
> the executable, but this does deem to be working, at least with the .so
> files that I am creating. I have to move them to the remote machines and
> install them. Let me know if there is a way to fix this.

There are two ways to get .so files on the nodes that I know of.  The
first is to use bplib to add the files to the nodes.  This is useful
when you have a program that needs a new .so, but needs to be done
everytime the nodes are rebooted.

A more perminant solution is to use the libraires plugin in
/etc/beowulf/config.  ex:

# GM
libraries /usr/lib/libgm.so*
 
# PGI
libraries /opt/pgi/linux86/lib/


New libraries listed in beowulf/config are not picked up by the
nodes until bpmaster (I think) is restarted on the host, which is why
a combination of bplib to get the lib out the first time and adding it
to beowulf/config is how I usually push out a new library.

Josh

[BProc] Bproc and SystemV IPC?

[rwillis <rw...@ct...>]

I noticed that the following does not work;
 'bproc 0 ipcs' 
Is this because bproc uses IPC calls? Let me know if others have the 
same problem, or if it is just something that I am doing wrong, 
(everything else works fine). 

Also, I thought that bproc would move shared object files over with 
the executable, but this does deem to be working, at least with the .so
files that I am creating. I have to move them to the remote machines and
install them. Let me know if there is a way to fix this.

 - Richard

Re: [BProc] How do I make a beoboot kernel that will work with beoboot-cm.1.5?

[Michael M. <mm...@as...>]

Larry Baker wrote:

> I have the Clustermatic 3 CD distribution installed, and I want to use 
> the beoboot-cm.1.5 package.  I downloaded the beoboot-cm.1.5 tarball, 
> made an RPM, installed it, created a phase 1 boot floppy and a new 
> phase 2 image file.  Unfortunately, it did not work.  >From 
> Eric's release notes, I assume this is because the phase 1 kernel does 
> not support tmpfs.  I also assume the phase 1 kernel it is using is 
> the one that came with the Clustermatic CD distribution, because I can 
> see from its .config file that it does not support tmpfs.
>  
> I tried using the non-smp bproc kernel from the Clustermatic 3 CD 
> distribution as my phase 1 beoboot kernel.  It made it further into 
> the boot process, but it failed with: "Couldn't find symbol 
> real_mode_conf".
> Next, I tried to make a new beoboot kernel with tmpfs support using 
> the kernel source tree from the Clustermatic 3 CD distribution:
>  
>    # cd /usr/src
>    # tar -cf - linux-2.4.19-lanl.22 | ( cd /home/baker/tmp ; tar -xf - )
>    # cd /home/baker/tmp/linux-2.4.19-lanl.22
>    # cp configs/kernel-2.4.19-i386-beoboot.config ./.config
>    # vi .config
>  
>       Change # CONFIG_TMPFS is not set
>       to     CONFIG_TMPFS=y
>  
>    # make symlinks
>    # make dep
>    # make clean
>    # make bzImage
>  
> "make bzImage" fails when compiling lib/rwsem-spinlock.c.  The 
> errors are: "redefinition of `init_rwsem'" and other function 
> names, ".../include/asm/rwsem.h:85: `init_rwsem' previously defined 
> here" and other function names, and "structure has no member named 
> `activity'".
>  
> Given a clean Clustermatic 3 CD installation, how do I make a beoboot 
> kernel that will work with beoboot-cm.1.5?
>  
>  
> Larry Baker
> US Geological Survey
>  

The easiest thing to do would be to rebuild the kernel from the source RPM:

rpm -ivh kernel-2.4.20-lanl.22.src.rpm
cd /usr/src/redhat/SOURCES
enable TMPFS in kernel-2.4.19-i386-beoboot.config
cd /usr/src/redhat/SPECS
rpmbuild -ba kernel-2.4.spec

Mike

[BProc] How do I make a beoboot kernel that will work with beoboot-cm.1.5?

[Larry B. <ba...@us...>]

I have the Clustermatic 3 CD distribution installed, and I want to use =
the beoboot-cm.1.5 package.  I downloaded the beoboot-cm.1.5 tarball, =
made an RPM, installed it, created a phase 1 boot floppy and a new phase =
2 image file.  Unfortunately, it did not work.  From Eric's release =
notes, I assume this is because the phase 1 kernel does not support =
tmpfs.  I also assume the phase 1 kernel it is using is the one that =
came with the Clustermatic CD distribution, because I can see from its =
.config file that it does not support tmpfs.

I tried using the non-smp bproc kernel from the Clustermatic 3 CD =
distribution as my phase 1 beoboot kernel.  It made it further into the =
boot process, but it failed with: "Couldn't find symbol real_mode_conf".

Next, I tried to make a new beoboot kernel with tmpfs support using the =
kernel source tree from the Clustermatic 3 CD distribution:

   # cd /usr/src
   # tar -cf - linux-2.4.19-lanl.22 | ( cd /home/baker/tmp ; tar -xf - )
   # cd /home/baker/tmp/linux-2.4.19-lanl.22
   # cp configs/kernel-2.4.19-i386-beoboot.config ./.config
   # vi .config

      Change # CONFIG_TMPFS is not set
      to     CONFIG_TMPFS=3Dy

   # make symlinks
   # make dep
   # make clean
   # make bzImage

"make bzImage" fails when compiling lib/rwsem-spinlock.c.  The errors =
are: "redefinition of `init_rwsem'" and other function names, =
".../include/asm/rwsem.h:85: `init_rwsem' previously defined here" and =
other function names, and "structure has no member named `activity'".

Given a clean Clustermatic 3 CD installation, how do I make a beoboot =
kernel that will work with beoboot-cm.1.5?


Larry Baker
US Geological Survey

FW: [BProc] Re: BProc-users -- confirmation of subscription -- request 997508

[Larry B. <ba...@us...>]

I don't understand why this message came to me.  It looks to me like the
person at br...@se... is trying to sign up, but the confirmation came
to me.

Larry Baker
US Geological Survey

-- 


----------
From: <br...@se...>
Date: Wed, 18 Jun 2003 16:07:04 +0100 (CET)
To: <bpr...@li...>
Subject: [BProc] Re: BProc-users -- confirmation of subscription -- request
997508

> BProc-users -- confirmation of subscription -- request 997508
>
> We have received a request from 80.231.200.125 for subscription of your
> email address, <br...@se...>, to the
> bpr...@li... mailing list.  To confirm the
> request, please send a message to
> bpr...@li..., and either:
>
> - maintain the subject line as is (the reply's additional "Re:" is ok),
>
> - or include the following line - and only the following line - in the
> message body:
>
> confirm 997508
>
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
>
> If you do not wish to subscribe to this list, please simply disregard
> this message.  Send questions to
> bpr...@li....





-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
BProc-users mailing list
BPr...@li...
https://lists.sourceforge.net/lists/listinfo/bproc-users

[BProc] Re: BProc-users -- confirmation of subscription -- request 997508

[<br...@se...>]

> BProc-users -- confirmation of subscription -- request 997508
>
> We have received a request from 80.231.200.125 for subscription of your
> email address, <br...@se...>, to the
> bpr...@li... mailing list.  To confirm the
> request, please send a message to
> bpr...@li..., and either:
>
> - maintain the subject line as is (the reply's additional "Re:" is ok),
>
> - or include the following line - and only the following line - in the
> message body:
>
> confirm 997508
>
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
>
> If you do not wish to subscribe to this list, please simply disregard
> this message.  Send questions to
> bpr...@li....

[BProc] Sticky options in miscfiles plugin

[Larry B. <ba...@us...>]

"plugin miscfiles ..." can appear any number of times in =
/etc/beowulf/node_up.conf.  However, the miscfiles beoboot plugin does =
not reinitialize the default values for -i (ignore_missing) and -f =
(follow_symlink) each time it is used.  Consequently, once the -i or -f =
options are used, they remain in effect and cannot be undone.

The following 2 lines should be added to miscfiles_premove() in =
beoboot.../node_up/miscfiles.c before "while ((c=3Dgetopt() ... ) {":

    ignore_missing =3D 0;
    follow_symlink =3D 1;


Larry Baker
US Geological Survey

Re: [BProc] Installing BProc on Suse

[J.A. M. <jam...@ab...>]

On 06.11, "RANGI, JAI" wrote:
> Hi,
> I am trying to compile BProc utilities on our SuSe 8.0 with kernel 2.4.18.
> But at the kernel patch level itself it is giving some errors. 
> Is there any RPMS available for Suse linux. Or any detailed documentations
> will also help.
> Thanks
>  

AFAIK SuSE ships an -aa kernel, not just a plain 2.4.18. I probably
have a version of bproc that patchs on top of that, but it could not
work. I think bproc has some problem with the O(1) scheduler (processes
rforked do not start or do not exit...)
If the -aa shipped in SuSE still does not have the O(1) scheduler, perhaps...
I was using bproc on top of -aa kernels for sometime, and it stopped
working. When I have the time will try to track when did it broke exactly.

-- 
J.A. Magallon <jam...@ab...>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.21-rc7-jam1 (gcc 3.3 (Mandrake Linux 9.2 3.3-1mdk))

Re: [BProc] beoboot setupfs leaves fstab open?

[<er...@he...>]

On Wed, Jun 11, 2003 at 10:43:38AM -0700, Larry Baker wrote:
> When I look at the source code for setupfs.c in beoboot.../node_up, I cannot find any fclose() of /etc/beowulf/fstab.  I don't completely understand the way the beoboot plugins work, but it looks to me like the container process for the beoboot setupfs plugin will continue to use up system and process resources as a result.  Is this a bug?

Yeah, it's a bug but it should be harmless.  The node_up stuff runs in
a child process of beoserv so it should all get cleaned up once it
exits.

Basically node_up goes like this:

beoserv gets request(s) to setup nodes.  It forks off a node_up
process.  The node_up process reads node_up.conf and loads plugins.
The plugins are what do all the real work.  They are basically shared
libraries that contain callbacks so they can do stuff before and after
moving to the node.  The advantage of using plugins is that the whole
mess ends up being one process migration instead of many smaller ones.
Plus you get to use the mass process creation stuff that BProc
provides too.

- Erik

[BProc] beoboot setupfs leaves fstab open?

[Larry B. <ba...@us...>]

When I look at the source code for setupfs.c in beoboot.../node_up, I =
cannot find any fclose() of /etc/beowulf/fstab.  I don't completely =
understand the way the beoboot plugins work, but it looks to me like the =
container process for the beoboot setupfs plugin will continue to use up =
system and process resources as a result.  Is this a bug?

Larry Baker
US Geological Survey

[BProc] Re: [GE users] Re: SGE and Bproc

[Andrew S. <sh...@in...>]

ha...@no... wrote:
> I created first draft of SGE+BProc MicroHOWTO:
> 
>   http://noel.feld.cvut.cz/magi/sge+bproc.html
> 
> Any comments welcome.

Thanks for writing that up.  I plan on setting
this up with MPI and PVM in the next week or so.
I'll let you know how that goes.

Andrew

-- 
Andrew Shewmaker, Associate Engineer
Phone: 1-208-526-1276
Idaho National Eng. and Environmental Lab.
P.0. Box 1625, M.S. 3605
Idaho Falls, Idaho 83415-3605

[BProc] Re: SGE and Bproc

[<ha...@no...>]

I created first draft of SGE+BProc MicroHOWTO:

  http://noel.feld.cvut.cz/magi/sge+bproc.html

Any comments welcome.

Regards

Vaclav Hanzl

>Subject: Re: [GE users] SGE and Bproc
>From: Andrew Shewmaker <sh...@in...>
>To: us...@gr..., Dale Harris <ro...@ma...>
>Date: Tue, 27 May 2003 16:22:07 -0600
>
>On Tuesday 27 May 2003 03:32 pm, Dale Harris wrote:
>> Has anyone tried to use SGE on a bproc based system?  I'm kind of
>> wondering what possible pitfalls there might be.
>>
>> Info on bproc at:
>>
>> http://bproc.sourceforge.net/
>
>I haven't..yet, but Vaclav Hanzl has.  Look at these messages/threads.
>
>http://gridengine.sunsource.net/servlets/ReadMsg?msgId=7985&listName=users
>
>http://www.geocrawler.com/mail/thread.php3?subject=Running+perl+scripts+and+non-mpi+programs+on+scyld&list=423
>
>-Andrew

[BProc] Installing BProc on Suse

[RANGI, J. <JAI...@SD...>]

Hi,
I am trying to compile BProc utilities on our SuSe 8.0 with kernel 2.4.18.
But at the kernel patch level itself it is giving some errors. 
Is there any RPMS available for Suse linux. Or any detailed documentations
will also help.
Thanks
 
 


Jai Rangi

Re: [BProc] Question about Bproc and Redhat7.3

[<er...@he...>]

On Wed, Jun 11, 2003 at 10:50:27AM -0400, Nicholas Henke wrote:
> On Wed, 2003-06-11 at 10:37, Chong Chen wrote:
> > Hi all:
> > 
> >        I have a Redhat7.3 box. Can I install Clustermatic 3 CD on it?
> > If not, what should I do to run a bproc kernel on Redhat7.3? 
> > 
> >        Thanks
> >        Chong
> 
> You will need to get the SRPMS and recompile them on a RH 7.3 machine. I
> think you will need to recompile the kernel & bproc SRPMs.

Probably everything will need to be recompiled.  The issue is gcc 2.96
vs gcc 3.2.  The rules for structure packing changed.  A mismatch
there will definitely break kernel modules.

- Erik

Re: [BProc] Question about Bproc and Redhat7.3

[Nicholas H. <he...@se...>]

On Wed, 2003-06-11 at 10:37, Chong Chen wrote:
> Hi all:
> 
>        I have a Redhat7.3 box. Can I install Clustermatic 3 CD on it?
> If not, what should I do to run a bproc kernel on Redhat7.3? 
> 
>        Thanks
>        Chong

You will need to get the SRPMS and recompile them on a RH 7.3 machine. I
think you will need to recompile the kernel & bproc SRPMs.

Nic
-- 
Nicholas Henke
Penguin Herder & Linux Cluster System Programmer
Liniac Project - Univ. of Pennsylvania

[BProc] Question about Bproc and Redhat7.3

[Chong C. <cc...@pl...>]

Hi all:

       I have a Redhat7.3 box. Can I install Clustermatic 3 CD on it? If =
not, what should I do to run a bproc kernel on Redhat7.3?=20

       Thanks
       Chong

[BProc] ntpd: too many recvbufs allocated

[<gor...@ph...>]

On a couple of occaisions, bproc has abruptly lost a mojority (but not all)
connections to its slaves.  The first time this happened was with bproc
3.2.0 on kernel 2.4.19.  None of the connections dropped at the time had
jobs running on them.  Only 4 jobs were running at the time.

The second time was with bproc version 3.2.5 on kernel 2.4.20.  This time
most, but not all, of the dropped connections had jobs running across them.
There were about 75 jobs running.  Connections to all but two nodes were
dropped. Unlike the first occurance, this was was preceeded by error
messages from NTP.

system log:

Jun 11 00:23:42 lxsrvr ntpd[559]: too many recvbufs allocated (40)
Jun 11 00:23:42 lxsrvr last message repeated 3 times
Jun 11 00:23:43 lxsrvr bpmaster: lost connection to slave 4
Jun 11 00:23:43 lxsrvr bpmaster: lost connection to slave 13
Jun 11 00:23:43 lxsrvr bpmaster: lost connection to slave 6

I have the usual suspects disbled under cron (makewhatis, locate.db)

Does anyone have any idea what's taking place here?  Could this be some
sort of network storm?

Goran

Re: [BProc] VMADump with non-exported sys_call_table

[<er...@he...>]

On Mon, Jun 09, 2003 at 06:27:30PM -0700, Paul Hartke wrote:
> Hi all,
> 
> I would like to use VMADump standalone (ie, without the rest of Bproc) 
> to checkpoint longrunning applications.  It currently works fine for 
> that.  However, with the new Linux kernels, the sys_call_table is no 
> longer exported so a new mechanism is needed over what is currently 
> provided in VMADump.  Are folks looking into this already?   If so, I 
> don't want to reinvent the wheel.   Ideally, the solution would not 
> involve end users needing to recompile their kernel but they could 
> simply load a module and be up and running--just as things work now.  

Yeah, something is going to have to be done about that.  I agree that
having to patch the kernel for things like this is disgusting but it
may be the only "clean" option.

If you REALLY don't want to recompile and you're willing to try
something which as best "unclean" and may even be "gross and
disgusting" there's this little gizmo I call "symdm" that I use to
resolve symbol problems when I'm just fooling around with stuff.  It's
a little tool to export arbitrary name/address pairs.

You can download it from:

http://www.acl.lanl.gov/supermon/symdm.html

Matt Sottile also did a nice little write-up for it there.

> From the Linux-Kernel Mail Archive, I see that Erik requested a 
> dedicated syscall number for that.  What is the status of that?

I think the answer was "no".  BProc's syscall API was deemed "badly
designed".  There were some philosophical differences there.  I think
the messages in the archives sum it up pretty well.

Considering BProc's status as a kernel patch, it always requires a
rebuild so it doesn't matter if it's blessed by the keepers of the tar
ball.

- Erik

Re: [BProc] Updates to Clustermatic 3 CD

[Larry B. <ba...@us...>]

Josh's recipe worked for me (Red Hat 8.0).  However, I am not able to update the Clustermatic 3 CD installation with the
tarballs from bproc.sourceforge.net.  The bjs package does not need updating.  Of the 3 for which there are updates
(beoboot, bproc, and cmtools), I was only able to update the cmtools library.  To get beoboot to build an RPM, I had to
create a soft link from /usr/src/linux to the 2.4.19 LANL kernel directory.  But, the phase 1 boot images failed -- I'm
guessing because the 2.4.19 LANL kernel doesn't support tmpfs.  I then tried to make an RPM for the new bproc, hoping it
would have the new kernel.  But, it does not, and the rpmbuild failed.  So, I guess I'll just wait for the next
Clustermatic CD.

Larry Baker
US Geological Survey


----- Original Message ----- 
From: "Joshua Aune" <lu...@li...>
To: <bpr...@li...>
Sent: Monday, June 09, 2003 1:49 PM
Subject: Re: [BProc] Updates to Clustermatic 3 CD


> An even easier method is to rpm -tb the .tar.gz file directly.  Note
> that on newer versions of RH you may need to use the rpmbuild command
> instead of rpm.
>
> # rpmbuild -tb cmtools-1.2.tar.gz
> # rpm -Uvh /usr/src/redhat/RPMS/i386/cmtools*rpm
>
> Josh
>
> On Mon, Jun 09, 2003 at 12:08:58PM -0700, Michael Madore wrote:
> > Hi Larry,
> >
> > I have done this recently:
> >
> > 1) Copy the .spec file to /usr/src/redhat/SPECS
> > 2) Copy the tar file to /usr/src/redhat/SOURCES
> > 3) cd /usr/src/redhat/SPECS
> > 4) rpm -ba cmtools.spec
> > 5) rpm -Uvh ../RPMS/i386/cmtools-*1.2.1.i386.rpm
> >
> > You may have to modify the spec file slightly to reflect the new version
> > number.  The same process can be applied to the other Clustermatic packages.
> >
> > Mike
> >
> > Larry Baker wrote:
> >
> > >I want to apply the updates from broc.sourceforge.net to my
> > >Clustermatic 3 CD installation.  Newer versions of beoboot, bproc, and
> > >cmtools are available.  However, they are not packaged as RPMs.
> > >
> > >I un"tar"ed cmtools and did a "make", which worked.  Now I want to get
> > >the files moved where they belong (with soft links setup) and have the
> > >RPM database updated to reflect the new version.  I see a .spec file
> > >that looks like it has the information -- how can I make use of it?
> > >
> > >1. What commands should be used to apply the updates to an existing
> > >Clustermatic 3 installation?
> > >
> > >2. What order should the updates be applied and tested?
> > >
> > >Larry Baker
> > >US Geological Survey
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> BProc-users mailing list
> BPr...@li...
> https://lists.sourceforge.net/lists/listinfo/bproc-users

Re: [BProc] bproc and Maui

[steven j. <py...@li...>]

Greetings,

Bproc itself isn't really a queueing system, it is a remote execution
system (equivilant to the execution daemons seen in some queueing systems.

G'day,
sjames



On Mon, 9 Jun 2003, Dale Harris wrote:

> On Thu, May 29, 2003 at 03:25:39PM -0700, Michael Madore elucidated:
> > Hi,
> > 
> > On the Maui homepage there is mention of support for bproc.  Specifically:
> > 
> >   BProc Scheduling API - BProc (Scyld)
> > 
> > Is this a feature present in the standard bproc, or is it an extension 
> > provided by Scyld?
> 
> 
> Has anyone tried Sun Grid Engine and bproc?  GridEngine can already use
> Maui.  Or is that too many layers of indirection.  I was under the
> impression that bproc was a queuing system, per se.
> 
> 
> --
> Dale Harris   
> ro...@ma...
> /.-)
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> BProc-users mailing list
> BPr...@li...
> https://lists.sourceforge.net/lists/listinfo/bproc-users
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------

[BProc] VMADump with non-exported sys_call_table

[Paul H. <ph...@st...>]

Hi all,

I would like to use VMADump standalone (ie, without the rest of Bproc) 
to checkpoint longrunning applications.  It currently works fine for 
that.  However, with the new Linux kernels, the sys_call_table is no 
longer exported so a new mechanism is needed over what is currently 
provided in VMADump.  Are folks looking into this already?   If so, I 
don't want to reinvent the wheel.   Ideally, the solution would not 
involve end users needing to recompile their kernel but they could 
simply load a module and be up and running--just as things work now.  

From the Linux-Kernel Mail Archive, I see that Erik requested a 
dedicated syscall number for that.  What is the status of that?

Thanks.
Paul