There is the following process: NetAuthSysAgent which calls/create repeatedly the process mount_nfs of a non-existing NFS share. I have a hunch that these calls are triggered by another process which gives the instruction.
Therefore I would like to profile the NetAuthSysAgent, perhaps using dtrace, and see all inputs (like IPC incl. signals, queues, files, sockets, etc.) for this process and also verify all read files or memory area before it calls the mount_nfs process.
How can I do that? Is dtrace suitable and if yes how?
Any help is welcome. Even if it would only apply/work on FreeBSD or Solaris, I could try to adapt it myself to OS X.
Update:
I have been using the following commands yet, but I have covered only the file part:
dtrace -q -n syscall::open:entry'{ printf("%-16s %-16s\n",execname,copyinstr(arg0)); }'
the above command gave me the processes and opened files.
opensnoop -va -n NetAuthSysAgent
the above command is a script calling DTrace stuffs, it is more or less the same as the previous command but it is filtered by the process NetAuthSysAgent and provides a few more information (e.g. UID, PID, FD, etc.)
Related
Say you have a shell command like
cat file1 | ./my_script
Is there any way from inside the 'my_script' command to detect the command run first as the pipe input (in the above example cat file1)?
I've been digging into it and so far I've not found any possibilities.
I've been unable to find any environment variables set in the process space of the second command recording the full command line, the command data the my_script commands sees (via /proc etc) is just _./my_script_ and doesn't include any information about it being run as part of a pipe. Checking the process list from inside the second command even doesn't seem to provide any data since the first process seems to exit before the second starts.
The best information I've been able to find suggests in bash in some cases you can get the exit codes of processes in the pipe via PIPESTATUS, unfortunately nothing similar seems to be present for the name of commands/files in the pipe. My research seems to be saying it's impossible to do in a generic manner (I can't control how people decide to run my_script so I can't force 3rd party pipe replacement tools to be used over build in shell pipes) but it just at the same time doesn't seem like it should be impossible since the shell has the full command line present as the command is run.
(update adding in later information following on from comments below)
I am on Linux.
I've investigated the /proc/$$/fd data and it almost does the job. If the first command doesn't exit for several seconds while piping data to the second command can you read /proc/$$/fd/0 to see the value pipe:[PIPEID] that it symlinks to. That can then be used to search through the rest of the /proc//fd/ data for other running processes to find another process with a pipe open using the same PIPEID which gives you the first process pid.
However in most real world tests I've done of piping you can't trust that the first command will stay running long enough for the second one to have time to locate it's pipe fd in /proc before it exits (which removes the proc data preventing it being read). So if this method will return any information is something I can't rely on.
I am currently using the leaks command line utility on Mac OS X. It requires an active process which is a pain with a command line utility. Is there a way to launch a process and on exit freeze it (so it stays running) so leaks can work like the following
leaks executable_binary_name
instead of
leaks currently_running_process_name_or_pid
as the latter is a pain to use with a command line application that doesn't normally just remain open. I assume the program has to run through so leaks can observe the used memory and so I'd have to freeze it on exit.
Part of man page dealing with process
leaks requires one parameter -- either the process ID or executable
name
of the process to examine. It also takes several arguments for modifying
its behavior.
Use iprofiler (manpage) instead. It's the command line equivalent of Instruments and allows an executable or process ID to be specified.
Something like:
$ iprofiler -leaks -d $HOME/tmp executable [args]
You can even pass arguments to executable, if it accepts them.
The -d option specifies where the output .dtps file will be written to, which can be loaded into Instruments for examination.
I want to writing a script in shell for solaris paltform regarding some below commands and their output should written in excel file or text file as a output.
How many servers are deployed under global
zone --- zoneadm list -cv
H/w architecture
showrev -a
OS Related Information
uname -a
RAM and its Utilization
echo "::memstat" | mdb -k
Internal Disk
echo | format
Which service is running on which node
hares -state |grep "ONLINE"
Solaris is a not something I am familar with. I think I have logged in once or twice in my life.
However, unix/linux I have some experience with.
You simple need to put your commands in a script file often ends with *sh (myscriptfile.sh). then you simply run the script.
That being said. You need to read up on
output redirect (that is out you write the output to file).
And learn more about your 'shell'. I would further recommend using bash (I believe out-of-the-box solaris uses something different). Bash scripting is far more popular therefore you will find greater support.
So, I need to run a program, not keep track of its PID (in memory, at least), and later kill that program. Any ideas? My immediate thought was to tag the process with something I could find later, but that seems a bust. My next thought was to store on disk the PID, but I've no idea what the convention for that sort of thing is. Any ideas? Thanks!
Your program can create a directory under /var/run/ to store such files. For instance, if your program is myprog it might store its PID on startup in
/var/run/myprog/PID
If your program could have multiple instances running at the same time, you might use the PID itself in the file name, along with its startup time, to ensure a unique file name for each instance.
/var/run/myprog/201410302306.1283.pid
(Note that if you use the PID in the file name, it's up to you if you actually write the PID in the file itself; an empty file would suffice.)
The most straight forward (and common case) is, as you and chepner already mentioned, to store it in a pid file. For this:
If it's a system wide programm:
/var/run/prog.pid
If it's a system installed program that might be run multiple times:
/var/run/prog/prog_instance.pid
If it's a user local program:
$HOME/.prog/prog.pid
Other options might be to use pgrep for finding it as long as you can uniquely define the calling command. For example pass a dummy argument not used and use it for retrieval:
$ prog.sg --instance_1234 &
$ pgrep -f -- '--instance_1234'
3523
you can use start-stop-daemon to start a program and kill it later. It has a lot of options to find the programm, the most usefull is the --pid that stores and retrive the pid from a file in filesystem, usually in /var/run (pay attention to file system privileges to write in it).
See the man pages for more tips.
I have to send a SNMP trap towards my monitor with a script (perl for instance, or other) when some condition is met (e.g. when memory use or disk usage rise above 80%).
I never write script so I have no idea how to do that.
This little script will allow me to test my java program which catch some traps on a given port.
If all you want is to send a trap to test your trap receiver, you don't have to write a script! You can just download and install the net-snmp command line tools from
http://net-snmp.sourceforge.net/download.html
The command "snmptrap" is just what you're looking for.
If you want to do this from a shell script, of course you just ahve the script call the snmptrap binary.
If you are actually writing some monitoring script in perl, I still think the easiest way is to execute the snmptrap program from the perl script. You do also have the option of using some SNMP library. I've used Net::SNMP (unrelated to net-snmp) to good effect:
https://metacpan.org/pod/Net::SNMP