Re: Mirroring procfs.

[Valdis.Kletnieks () vt edu]

On Tue, 25 Jan 2005 08:58:39 GMT, preeth k said:

> I work on Redhat Linux and we want to know if there is any method to mirror
> the '/proc' filesystem on one machine-A to another machine-B so as to monitor
> all the events occuring in A using machine-B

The problem is that even if you *could* mirror /proc in any sensible way,
that would not actually monitor "all the events".  If you look closely at
the source code for the 'procfs' file system (see the code in fs/proc/*.c),
you'd realize that /proc entries are created *on the fly*.  There's not really
anything *in* that file system - it all gets created "on the fly" as you
reference it.  Sure, /proc/$$/cwd *looks* like a symlink to your current working
directory, but look how it's actually implemented (looking at a 2.6.11-rc2-mm1
kernel here, your code may differ):

static int proc_cwd_link(struct inode *inode, struct dentry **dentry, struct vfsmount **mnt)
{
        struct fs_struct *fs;
        int result = -ENOENT;
        task_lock(proc_task(inode));
        fs = proc_task(inode)->fs;
        if(fs)
                atomic_inc(&fs->count);
        task_unlock(proc_task(inode));
        if (fs) {
                read_lock(&fs->lock);
                *mnt = mntget(fs->pwdmnt);
                *dentry = dget(fs->pwd);
                read_unlock(&fs->lock);
                result = 0;
                put_fs_struct(fs);
        }
        return result;
}

The magic here is "*dentry = dget(fs->pwd);" - basically, they just create a clone
of a reference to the process's working directory and return it.

Similarly, the list of directories /proc/NNN for each process ID NNN is generated
on the fly by walking the process table.  So if a process fork()s to create a new
PID, it does *NOT* create a /proc entry *unless somebody actually looks for it*.
If you fork and create process 994, and then it exits before anybody looks in /proc
for it, /proc/994 *never actually happens*.

What you *really* need to mirror to machine-b is enough information of the kernel's
internal state (fork/exec/open/and all the rest), so that your monitor on B is able
to track what's going on...

What "events" were you hoping to monitor, and why?  Understanding that would
help a lot in pointing you in a useful direction....

Attachment: _bin
Description:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html