Getting information about short-lived processes





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







4















I want to trace existing process and especially their parameters (like environment variables, cwd directory, stdout and so on). I can do it. However, I cannot get that information about short-lived processes). For example:



If I run:



sleep 120 & 
# get info from /proc/`pgrep sleep`


and it is easy.



But, what if my process is immediately terminated or I don't know PID of process (but I expect that some process will be created).










share|improve this question































    4















    I want to trace existing process and especially their parameters (like environment variables, cwd directory, stdout and so on). I can do it. However, I cannot get that information about short-lived processes). For example:



    If I run:



    sleep 120 & 
    # get info from /proc/`pgrep sleep`


    and it is easy.



    But, what if my process is immediately terminated or I don't know PID of process (but I expect that some process will be created).










    share|improve this question



























      4












      4








      4


      1






      I want to trace existing process and especially their parameters (like environment variables, cwd directory, stdout and so on). I can do it. However, I cannot get that information about short-lived processes). For example:



      If I run:



      sleep 120 & 
      # get info from /proc/`pgrep sleep`


      and it is easy.



      But, what if my process is immediately terminated or I don't know PID of process (but I expect that some process will be created).










      share|improve this question
















      I want to trace existing process and especially their parameters (like environment variables, cwd directory, stdout and so on). I can do it. However, I cannot get that information about short-lived processes). For example:



      If I run:



      sleep 120 & 
      # get info from /proc/`pgrep sleep`


      and it is easy.



      But, what if my process is immediately terminated or I don't know PID of process (but I expect that some process will be created).







      linux process






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Feb 9 at 14:58









      Rui F Ribeiro

      41.9k1483142




      41.9k1483142










      asked Feb 9 at 14:49









      GilgameszGilgamesz

      13015




      13015






















          2 Answers
          2






          active

          oldest

          votes


















          4














          One approach as an ordinary user is an exec wrapper, assuming the programs are run via a PATH search. That is, your wrapper for program



          #!/bin/sh
          env > /some/log/file
          ... (any other desired logging commands here) ...
          exec /path/to/real/program "$@"


          must exist first in PATH, so you might have PATH=/some/wrapper/dir:$PATH and then a wrapper program named exactly for the real program to be logged, and in the wrapper program you replace your wrapper with the original program using exec. If the program is being run by fully qualified paths then it may be necessary to fiddle around with something like LD_PRELOAD or perhaps the application in question may give an option to change the path?



          As root tracing would be quite simple with something like sysdig (various sysdig examples) as that can match the ephemeral process names you are interested in, and can incrementally drill down to what you are interested in, say the program ls run as some user:



          sudo sysdig "proc.name = ls and user.name = jhqdoe" | tee log


          The rather verbose log file after an ls is run shows an execve entry that may give almost everything you need (the environment is truncated):



          9734 16:12:49.683389228 1 ls (20542) < execve res=0 exe=ls args=--color=auto. tid=20542(ls) pid=20542(ls) ptid=20052(bash) cwd= fdlimit=1024 pgft_maj=0 pgft_min=61 vm_size=404 vm_rss=4 vm_swap=0 comm=ls cgroups=cpuset=/.cpu_cgroup=/.cpuacct=/.mem_cgroup=/.devices=/user.slice.freezer=/.ne... env=XDG_SESSION_ID...


          Via the user guide and other documentation, the above can be made precise to only the execve call and the full environment shown via:



          sudo sysdig -p "%proc.env" "proc.name = ls and user.name = jhqdoe and evt.type = execve" | tee xxx


          Adjust -p to show what you want; you could also use a chisel to extract what you want from a live capture or a save file, etc.






          share|improve this answer


























          • I second sysdig +1

            – Rui F Ribeiro
            Feb 9 at 15:52













          • sysdig is great but how to get information about stdout, stderr and stdin?

            – Gilgamesz
            Feb 9 at 20:02













          • what sort of information about those descriptors? dipping into them can be problematical given how they can be shared between processes

            – thrig
            Feb 10 at 15:39



















          3














          You'll have to use forkstat(1) or some other program using the proc connector interface. Unfortunately, you can only do that as root. Also, forkstat(1) isn't extensible or scriptable, so you'll probably have to write your own program combining the data from the proc connector with that from procfs if you also want it to print the environment of a process, its controlling tty, etc.



          Here is a very crude way to "extend" forkstat(1) to also print the actual path to the binary and the current directory of a process upon execve:



          stdbuf -o0 forkstat -e fork,exec | perl -anle '
          print;
          if($F[1] eq "exec"){
          print "texe = ", readlink "/proc/$F[2]/exe";
          print "tcwd = ", readlink "/proc/$F[2]/cwd";
          }
          '


          As an ordinary user, your only solution is run the parent process starting those short-lived processes (or one of its ancestors) via



          strace -s1024 -vfe trace=execve prog args ...


          The -s option controls how much of the argv and env strings strace will print. Running programs via strace may have quite an impact on performance. There may be other more friendly / scriptable alternatives to strace(1), but they all have to use ptrace(2) if they are to be used by an ordinary user, so don't expect them to be essentially different.






          share|improve this answer


























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499653%2fgetting-information-about-short-lived-processes%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4














            One approach as an ordinary user is an exec wrapper, assuming the programs are run via a PATH search. That is, your wrapper for program



            #!/bin/sh
            env > /some/log/file
            ... (any other desired logging commands here) ...
            exec /path/to/real/program "$@"


            must exist first in PATH, so you might have PATH=/some/wrapper/dir:$PATH and then a wrapper program named exactly for the real program to be logged, and in the wrapper program you replace your wrapper with the original program using exec. If the program is being run by fully qualified paths then it may be necessary to fiddle around with something like LD_PRELOAD or perhaps the application in question may give an option to change the path?



            As root tracing would be quite simple with something like sysdig (various sysdig examples) as that can match the ephemeral process names you are interested in, and can incrementally drill down to what you are interested in, say the program ls run as some user:



            sudo sysdig "proc.name = ls and user.name = jhqdoe" | tee log


            The rather verbose log file after an ls is run shows an execve entry that may give almost everything you need (the environment is truncated):



            9734 16:12:49.683389228 1 ls (20542) < execve res=0 exe=ls args=--color=auto. tid=20542(ls) pid=20542(ls) ptid=20052(bash) cwd= fdlimit=1024 pgft_maj=0 pgft_min=61 vm_size=404 vm_rss=4 vm_swap=0 comm=ls cgroups=cpuset=/.cpu_cgroup=/.cpuacct=/.mem_cgroup=/.devices=/user.slice.freezer=/.ne... env=XDG_SESSION_ID...


            Via the user guide and other documentation, the above can be made precise to only the execve call and the full environment shown via:



            sudo sysdig -p "%proc.env" "proc.name = ls and user.name = jhqdoe and evt.type = execve" | tee xxx


            Adjust -p to show what you want; you could also use a chisel to extract what you want from a live capture or a save file, etc.






            share|improve this answer


























            • I second sysdig +1

              – Rui F Ribeiro
              Feb 9 at 15:52













            • sysdig is great but how to get information about stdout, stderr and stdin?

              – Gilgamesz
              Feb 9 at 20:02













            • what sort of information about those descriptors? dipping into them can be problematical given how they can be shared between processes

              – thrig
              Feb 10 at 15:39
















            4














            One approach as an ordinary user is an exec wrapper, assuming the programs are run via a PATH search. That is, your wrapper for program



            #!/bin/sh
            env > /some/log/file
            ... (any other desired logging commands here) ...
            exec /path/to/real/program "$@"


            must exist first in PATH, so you might have PATH=/some/wrapper/dir:$PATH and then a wrapper program named exactly for the real program to be logged, and in the wrapper program you replace your wrapper with the original program using exec. If the program is being run by fully qualified paths then it may be necessary to fiddle around with something like LD_PRELOAD or perhaps the application in question may give an option to change the path?



            As root tracing would be quite simple with something like sysdig (various sysdig examples) as that can match the ephemeral process names you are interested in, and can incrementally drill down to what you are interested in, say the program ls run as some user:



            sudo sysdig "proc.name = ls and user.name = jhqdoe" | tee log


            The rather verbose log file after an ls is run shows an execve entry that may give almost everything you need (the environment is truncated):



            9734 16:12:49.683389228 1 ls (20542) < execve res=0 exe=ls args=--color=auto. tid=20542(ls) pid=20542(ls) ptid=20052(bash) cwd= fdlimit=1024 pgft_maj=0 pgft_min=61 vm_size=404 vm_rss=4 vm_swap=0 comm=ls cgroups=cpuset=/.cpu_cgroup=/.cpuacct=/.mem_cgroup=/.devices=/user.slice.freezer=/.ne... env=XDG_SESSION_ID...


            Via the user guide and other documentation, the above can be made precise to only the execve call and the full environment shown via:



            sudo sysdig -p "%proc.env" "proc.name = ls and user.name = jhqdoe and evt.type = execve" | tee xxx


            Adjust -p to show what you want; you could also use a chisel to extract what you want from a live capture or a save file, etc.






            share|improve this answer


























            • I second sysdig +1

              – Rui F Ribeiro
              Feb 9 at 15:52













            • sysdig is great but how to get information about stdout, stderr and stdin?

              – Gilgamesz
              Feb 9 at 20:02













            • what sort of information about those descriptors? dipping into them can be problematical given how they can be shared between processes

              – thrig
              Feb 10 at 15:39














            4












            4








            4







            One approach as an ordinary user is an exec wrapper, assuming the programs are run via a PATH search. That is, your wrapper for program



            #!/bin/sh
            env > /some/log/file
            ... (any other desired logging commands here) ...
            exec /path/to/real/program "$@"


            must exist first in PATH, so you might have PATH=/some/wrapper/dir:$PATH and then a wrapper program named exactly for the real program to be logged, and in the wrapper program you replace your wrapper with the original program using exec. If the program is being run by fully qualified paths then it may be necessary to fiddle around with something like LD_PRELOAD or perhaps the application in question may give an option to change the path?



            As root tracing would be quite simple with something like sysdig (various sysdig examples) as that can match the ephemeral process names you are interested in, and can incrementally drill down to what you are interested in, say the program ls run as some user:



            sudo sysdig "proc.name = ls and user.name = jhqdoe" | tee log


            The rather verbose log file after an ls is run shows an execve entry that may give almost everything you need (the environment is truncated):



            9734 16:12:49.683389228 1 ls (20542) < execve res=0 exe=ls args=--color=auto. tid=20542(ls) pid=20542(ls) ptid=20052(bash) cwd= fdlimit=1024 pgft_maj=0 pgft_min=61 vm_size=404 vm_rss=4 vm_swap=0 comm=ls cgroups=cpuset=/.cpu_cgroup=/.cpuacct=/.mem_cgroup=/.devices=/user.slice.freezer=/.ne... env=XDG_SESSION_ID...


            Via the user guide and other documentation, the above can be made precise to only the execve call and the full environment shown via:



            sudo sysdig -p "%proc.env" "proc.name = ls and user.name = jhqdoe and evt.type = execve" | tee xxx


            Adjust -p to show what you want; you could also use a chisel to extract what you want from a live capture or a save file, etc.






            share|improve this answer















            One approach as an ordinary user is an exec wrapper, assuming the programs are run via a PATH search. That is, your wrapper for program



            #!/bin/sh
            env > /some/log/file
            ... (any other desired logging commands here) ...
            exec /path/to/real/program "$@"


            must exist first in PATH, so you might have PATH=/some/wrapper/dir:$PATH and then a wrapper program named exactly for the real program to be logged, and in the wrapper program you replace your wrapper with the original program using exec. If the program is being run by fully qualified paths then it may be necessary to fiddle around with something like LD_PRELOAD or perhaps the application in question may give an option to change the path?



            As root tracing would be quite simple with something like sysdig (various sysdig examples) as that can match the ephemeral process names you are interested in, and can incrementally drill down to what you are interested in, say the program ls run as some user:



            sudo sysdig "proc.name = ls and user.name = jhqdoe" | tee log


            The rather verbose log file after an ls is run shows an execve entry that may give almost everything you need (the environment is truncated):



            9734 16:12:49.683389228 1 ls (20542) < execve res=0 exe=ls args=--color=auto. tid=20542(ls) pid=20542(ls) ptid=20052(bash) cwd= fdlimit=1024 pgft_maj=0 pgft_min=61 vm_size=404 vm_rss=4 vm_swap=0 comm=ls cgroups=cpuset=/.cpu_cgroup=/.cpuacct=/.mem_cgroup=/.devices=/user.slice.freezer=/.ne... env=XDG_SESSION_ID...


            Via the user guide and other documentation, the above can be made precise to only the execve call and the full environment shown via:



            sudo sysdig -p "%proc.env" "proc.name = ls and user.name = jhqdoe and evt.type = execve" | tee xxx


            Adjust -p to show what you want; you could also use a chisel to extract what you want from a live capture or a save file, etc.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Feb 9 at 16:22

























            answered Feb 9 at 15:51









            thrigthrig

            25.3k23257




            25.3k23257













            • I second sysdig +1

              – Rui F Ribeiro
              Feb 9 at 15:52













            • sysdig is great but how to get information about stdout, stderr and stdin?

              – Gilgamesz
              Feb 9 at 20:02













            • what sort of information about those descriptors? dipping into them can be problematical given how they can be shared between processes

              – thrig
              Feb 10 at 15:39



















            • I second sysdig +1

              – Rui F Ribeiro
              Feb 9 at 15:52













            • sysdig is great but how to get information about stdout, stderr and stdin?

              – Gilgamesz
              Feb 9 at 20:02













            • what sort of information about those descriptors? dipping into them can be problematical given how they can be shared between processes

              – thrig
              Feb 10 at 15:39

















            I second sysdig +1

            – Rui F Ribeiro
            Feb 9 at 15:52







            I second sysdig +1

            – Rui F Ribeiro
            Feb 9 at 15:52















            sysdig is great but how to get information about stdout, stderr and stdin?

            – Gilgamesz
            Feb 9 at 20:02







            sysdig is great but how to get information about stdout, stderr and stdin?

            – Gilgamesz
            Feb 9 at 20:02















            what sort of information about those descriptors? dipping into them can be problematical given how they can be shared between processes

            – thrig
            Feb 10 at 15:39





            what sort of information about those descriptors? dipping into them can be problematical given how they can be shared between processes

            – thrig
            Feb 10 at 15:39













            3














            You'll have to use forkstat(1) or some other program using the proc connector interface. Unfortunately, you can only do that as root. Also, forkstat(1) isn't extensible or scriptable, so you'll probably have to write your own program combining the data from the proc connector with that from procfs if you also want it to print the environment of a process, its controlling tty, etc.



            Here is a very crude way to "extend" forkstat(1) to also print the actual path to the binary and the current directory of a process upon execve:



            stdbuf -o0 forkstat -e fork,exec | perl -anle '
            print;
            if($F[1] eq "exec"){
            print "texe = ", readlink "/proc/$F[2]/exe";
            print "tcwd = ", readlink "/proc/$F[2]/cwd";
            }
            '


            As an ordinary user, your only solution is run the parent process starting those short-lived processes (or one of its ancestors) via



            strace -s1024 -vfe trace=execve prog args ...


            The -s option controls how much of the argv and env strings strace will print. Running programs via strace may have quite an impact on performance. There may be other more friendly / scriptable alternatives to strace(1), but they all have to use ptrace(2) if they are to be used by an ordinary user, so don't expect them to be essentially different.






            share|improve this answer






























              3














              You'll have to use forkstat(1) or some other program using the proc connector interface. Unfortunately, you can only do that as root. Also, forkstat(1) isn't extensible or scriptable, so you'll probably have to write your own program combining the data from the proc connector with that from procfs if you also want it to print the environment of a process, its controlling tty, etc.



              Here is a very crude way to "extend" forkstat(1) to also print the actual path to the binary and the current directory of a process upon execve:



              stdbuf -o0 forkstat -e fork,exec | perl -anle '
              print;
              if($F[1] eq "exec"){
              print "texe = ", readlink "/proc/$F[2]/exe";
              print "tcwd = ", readlink "/proc/$F[2]/cwd";
              }
              '


              As an ordinary user, your only solution is run the parent process starting those short-lived processes (or one of its ancestors) via



              strace -s1024 -vfe trace=execve prog args ...


              The -s option controls how much of the argv and env strings strace will print. Running programs via strace may have quite an impact on performance. There may be other more friendly / scriptable alternatives to strace(1), but they all have to use ptrace(2) if they are to be used by an ordinary user, so don't expect them to be essentially different.






              share|improve this answer




























                3












                3








                3







                You'll have to use forkstat(1) or some other program using the proc connector interface. Unfortunately, you can only do that as root. Also, forkstat(1) isn't extensible or scriptable, so you'll probably have to write your own program combining the data from the proc connector with that from procfs if you also want it to print the environment of a process, its controlling tty, etc.



                Here is a very crude way to "extend" forkstat(1) to also print the actual path to the binary and the current directory of a process upon execve:



                stdbuf -o0 forkstat -e fork,exec | perl -anle '
                print;
                if($F[1] eq "exec"){
                print "texe = ", readlink "/proc/$F[2]/exe";
                print "tcwd = ", readlink "/proc/$F[2]/cwd";
                }
                '


                As an ordinary user, your only solution is run the parent process starting those short-lived processes (or one of its ancestors) via



                strace -s1024 -vfe trace=execve prog args ...


                The -s option controls how much of the argv and env strings strace will print. Running programs via strace may have quite an impact on performance. There may be other more friendly / scriptable alternatives to strace(1), but they all have to use ptrace(2) if they are to be used by an ordinary user, so don't expect them to be essentially different.






                share|improve this answer















                You'll have to use forkstat(1) or some other program using the proc connector interface. Unfortunately, you can only do that as root. Also, forkstat(1) isn't extensible or scriptable, so you'll probably have to write your own program combining the data from the proc connector with that from procfs if you also want it to print the environment of a process, its controlling tty, etc.



                Here is a very crude way to "extend" forkstat(1) to also print the actual path to the binary and the current directory of a process upon execve:



                stdbuf -o0 forkstat -e fork,exec | perl -anle '
                print;
                if($F[1] eq "exec"){
                print "texe = ", readlink "/proc/$F[2]/exe";
                print "tcwd = ", readlink "/proc/$F[2]/cwd";
                }
                '


                As an ordinary user, your only solution is run the parent process starting those short-lived processes (or one of its ancestors) via



                strace -s1024 -vfe trace=execve prog args ...


                The -s option controls how much of the argv and env strings strace will print. Running programs via strace may have quite an impact on performance. There may be other more friendly / scriptable alternatives to strace(1), but they all have to use ptrace(2) if they are to be used by an ordinary user, so don't expect them to be essentially different.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Feb 9 at 17:21

























                answered Feb 9 at 15:14









                mosvymosvy

                9,0571833




                9,0571833






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499653%2fgetting-information-about-short-lived-processes%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Human spaceflight

                    Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

                    張江高科駅