All of lore.kernel.org
 help / color / mirror / Atom feed
* determining which process triggered an automount
@ 2007-04-11 23:48 Chris Walker
  2007-04-12 10:05 ` Ian Kent
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Walker @ 2007-04-11 23:48 UTC (permalink / raw)
  To: autofs

I'd like to determine which process triggered an automount. Might I have
to use Systemtap or some other tool to determine this?

I'm on Fedora Core 5.

Thanks,

-- 
Chris Walker
Render Pipeline Group
Pixar Animation Studios
510/922.3736
cwalker@pixar.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: determining which process triggered an automount
  2007-04-11 23:48 determining which process triggered an automount Chris Walker
@ 2007-04-12 10:05 ` Ian Kent
  2007-04-12 14:13   ` Peter C. Norton
  0 siblings, 1 reply; 5+ messages in thread
From: Ian Kent @ 2007-04-12 10:05 UTC (permalink / raw)
  To: Chris Walker; +Cc: autofs

On Wed, 2007-04-11 at 16:48 -0700, Chris Walker wrote:
> I'd like to determine which process triggered an automount. Might I have
> to use Systemtap or some other tool to determine this?

Can't really do that with autofs version 4.
It's a bit of information that the daemon doesn't get in the request
packet from the kernel. This information is passed to the daemon in
autofs version 5 and is logged when debug logging is enabled so you
could try that.

Sorry I can't be more help.
Ian

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: determining which process triggered an automount
  2007-04-12 10:05 ` Ian Kent
@ 2007-04-12 14:13   ` Peter C. Norton
  2007-04-13  4:20     ` Fabio Olive Leite
  0 siblings, 1 reply; 5+ messages in thread
From: Peter C. Norton @ 2007-04-12 14:13 UTC (permalink / raw)
  To: Ian Kent; +Cc: autofs

On Thu, Apr 12, 2007 at 06:05:04PM +0800, Ian Kent wrote:
> On Wed, 2007-04-11 at 16:48 -0700, Chris Walker wrote:
> > I'd like to determine which process triggered an automount. Might I have
> > to use Systemtap or some other tool to determine this?
> 
> Can't really do that with autofs version 4.
> It's a bit of information that the daemon doesn't get in the request
> packet from the kernel. This information is passed to the daemon in
> autofs version 5 and is logged when debug logging is enabled so you
> could try that.
> 
> Sorry I can't be more help.
> Ian

I think a system tap module could get you this, but it will take some
time investment for you to find out how to use it.

http://sourceware.org/systemtap/

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: determining which process triggered an automount
  2007-04-12 14:13   ` Peter C. Norton
@ 2007-04-13  4:20     ` Fabio Olive Leite
  2007-04-13  5:22       ` Chris Walker
  0 siblings, 1 reply; 5+ messages in thread
From: Fabio Olive Leite @ 2007-04-13  4:20 UTC (permalink / raw)
  To: autofs

On Thu, Apr 12, 2007 at 07:13:07AM -0700, Peter C. Norton wrote:
> 
> I think a system tap module could get you this, but it will take some
> time investment for you to find out how to use it.
> 
> http://sourceware.org/systemtap/

And it also takes a bit of time to find probe points that have not
been optimized away, auto-inlined, etc. In any case, here's a working
(in FC5) probe that will tell you who requested a directory. It could
be improved to provide a full path, but I'm satisfied by it as is.

probe module("autofs4").function("autofs4_find_wait") {
	printf("%s(%d) requested %s\n", execname(), pid(),
		kernel_string($name))
}

The output is:

$ sudo stap autofs4_notify_daemon.stap
bash(5913) requested foobar
bash(5913) requested foobar
bash(5913) requested foobar
...

Maybe autofs4_find_wait is not the best place, but it works, and I
found the more obvious autofs4_notify_daemon to be auto-inlined.

Hope this helps!
Fábio
-- 
ex sed lex awk yacc, e pluribus unix, amem

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: determining which process triggered an automount
  2007-04-13  4:20     ` Fabio Olive Leite
@ 2007-04-13  5:22       ` Chris Walker
  0 siblings, 0 replies; 5+ messages in thread
From: Chris Walker @ 2007-04-13  5:22 UTC (permalink / raw)
  To: autofs

This is *exactly* what I wanted. I tried it out and it works great.
Thanks.

From fleite:
> On Thu, Apr 12, 2007 at 07:13:07AM -0700, Peter C. Norton wrote:
> > 
> > I think a system tap module could get you this, but it will take some
> > time investment for you to find out how to use it.
> > 
> > http://sourceware.org/systemtap/
> 
> And it also takes a bit of time to find probe points that have not
> been optimized away, auto-inlined, etc. In any case, here's a working
> (in FC5) probe that will tell you who requested a directory. It could
> be improved to provide a full path, but I'm satisfied by it as is.
> 
> probe module("autofs4").function("autofs4_find_wait") {
> 	printf("%s(%d) requested %s\n", execname(), pid(),
> 		kernel_string($name))
> }
> 
> The output is:
> 
> $ sudo stap autofs4_notify_daemon.stap
> bash(5913) requested foobar
> bash(5913) requested foobar
> bash(5913) requested foobar
> ...
> 
> Maybe autofs4_find_wait is not the best place, but it works, and I
> found the more obvious autofs4_notify_daemon to be auto-inlined.
> 
> Hope this helps!
> Fábio
> -- 
> ex sed lex awk yacc, e pluribus unix, amem
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

-- 
Chris Walker
Render Pipeline Group
Pixar Animation Studios
510/922.3736
cwalker@pixar.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-04-13  5:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-11 23:48 determining which process triggered an automount Chris Walker
2007-04-12 10:05 ` Ian Kent
2007-04-12 14:13   ` Peter C. Norton
2007-04-13  4:20     ` Fabio Olive Leite
2007-04-13  5:22       ` Chris Walker

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.