[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: difference in seconds between two formatted dates ...



On Tue, Dec 26, 2023 at 02:57:54PM +0000, Albretch Mueller wrote:
>  1) how do you set up the process to be straced as a parameter? Something like:
> prx="echo hello"
> logfile="file.txt"
> #
> strace "${prx}" 2>"${logfile}"
> ls -l "${logfile}"; wc -l "${logfile}"; cat "${logfile}"

Why?  This does not appear to have any usefulness.  You're just making
your life harder for no reason.

See also <https://mywiki.wooledge.org/BashFAQ/050>.

>  2) how do you know for sure that you are stracing the same process
> that you are running and is logging some data?

You are EXTREMELY confused about something, and we NEED to address this
immediately.

If you run "strace ./foo", a new instance of ./foo is launched right
then and there, and you get the system call trace of THAT instance.

If another instance of ./foo was already running, you do NOT get the
system call trace of that first instance.

If you WANT the system call trace of an ALREADY-RUNNING PROCESS, you
need to get its process ID (PID) and use strace's "-p pid" option to
CONNECT to the existing process and begin tracing it.

That will not give you past system calls from the already-running
process.  What's done is done.  It will only give you system calls
that are made from that point forward.

>  The way I understand the PID options of strace:
> 
>  it seems to be attaching to some already running deamon or server process.

Yes.  If that's what you want.

>  How do you make it swallow a process that would go in one step/moment?

Don't use -p.  -p connects to an existing PID.  Without -p you create a
whole new process.

>  3) I have noticed that strace output is not totally predictable, so
> "parsing" is not that safe, straightforward

It's not meant to be parsed.  It's meant to be read by YOU, as part of
your debugging or diagnostics.  You use this tool when you want information
that nothing else will give you.

The strace output is long, detailed, and difficult to understand.  It
will take some practice to learn how to interpret it.

> $ strace wget --help  2>&1 | tail -n 5
> Email bug reports, questions, discussions to <bug-wget@gnu.org>
> and/or open issues at https://savannah.gnu.org/bugs/?func=additem&group=wget.
> ) = 956
> exit_group(0)                           = ?
> +++ exited with 0 +++
> $

You're talking about timing and buffering issues here.  If these are
a concern, don't use stderr.  Use strace's -o option to log the trace
to a logfile.  That way it will not intermix with the program's standard
output and standard error.

Remember that standard output, when NOT going to a terminal, is usually
buffered.  In your example there, you've got wget's output going to a pipe
(which is not a terminal), so it gets buffered.  This can cause weird
artifacts, if you were expecting each line to be visible immediately for
example.  Even worse, you've got wget's stdout and stderr, and strace's
stderr, all mixed together into a single stream, with who-knows-what
kind of buffering on each component.


Reply to: