delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2019/03/24/15:16:55

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:reply-to:subject:to:references:from:message-id
:date:mime-version:in-reply-to:content-type
:content-transfer-encoding; q=dns; s=default; b=xaE1+AdDjm7HjJY8
eVunvj6//LqVRtU3qEZdAWL6m7mdveIp8uaqJX+XNoeWy5zhyZDh2FqU0oWQClnQ
fgpNF4LH0uFAmrrrhIoeiyKMh6eyIvSISZOu95VOcwuxKfofsGt/mIJJ3Ik7lh0z
sBuRqx7boDHoxfXc5XeyrSfO7sw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:reply-to:subject:to:references:from:message-id
:date:mime-version:in-reply-to:content-type
:content-transfer-encoding; s=default; bh=/2cRaj6QmETWuG6NxHxiA9
nuMIA=; b=Hvd+GRaJaGTmLfB+Y7cZAJ5w+bQFolWs4emADJXG1PDKuzfrErFLGZ
FgKwK6PfQan8sPwHzFzLRWkOja28AwlfQ8fHF7GYLwXoR6P1iebj3DAvRvL9x7ib
9nsYRvQiQ9Kol+a28qQF6CiacojczQkvCYoxdqgybJep9w0ABo0YI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=HX-Languages-Length:2018
X-HELO: smtp-out-no.shaw.ca
Reply-To: Brian DOT Inglis AT SystematicSw DOT ab DOT ca
Subject: Re: [PATCH] default ps -W process start time to system boot time when inaccessible, 0, -1
To: cygwin AT cygwin DOT com
References: <20190323034522 DOT 9688-1-Brian DOT Inglis AT SystematicSW DOT ab DOT ca> <87d0mh5x3u DOT fsf AT Rainer DOT invalid> <20190323183653 DOT GB3471 AT calimero DOT vinschen DOT de> <874l7tbfh6 DOT fsf AT Rainer DOT invalid> <4dfdfce1-245d-98fe-0c49-890ba8ec8dd4 AT SystematicSw DOT ab DOT ca> <874l7s65yv DOT fsf AT Rainer DOT invalid> <bacddf44-e71b-08a2-9e93-0da8d98cc540 AT SystematicSw DOT ab DOT ca> <871s2wm956 DOT fsf AT Rainer DOT invalid>
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Openpgp: preference=signencrypt
Message-ID: <a5da8d2d-328e-f60b-3d4a-cfeffc8d7556@SystematicSw.ab.ca>
Date: Sun, 24 Mar 2019 13:16:26 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: <871s2wm956.fsf@Rainer.invalid>
X-IsSubscribed: yes

On 2019-03-24 12:15, Achim Gratz wrote:
> Brian Inglis writes:
>> Boot time is neither magic nor pulled out of thin air.
> No, but other than a lower limit of the process start time it has no
> correlation whatsoever to the start time of a process that I am not
> proviledged to get the start time from.
>> Checking *my* system processes using wmic queries and elevated powershell
>> scripts, the boot time is at most a few seconds off from process start times
>> from other sources.
>> I understand that other systems may run processes where that is not the case.
>> Please explain why you think this is misleadingly not useful, or where or which
>> processes have unvailable start times that are not very close to boot time.
> System processes get started and re-started all the time, as do
> processes from other users (interactive or otherwise).

System processes with more recent process start times seem to make process times
available to unelevated processes.
Do startup system processes not have this info available to unelevated processes
because of some security policy, timing, or possible race conditions with system
process and performance monitor startup?

> So again: in the case under discussion we _know_ that "0" is a bogus
> timestamp value that no process ever got started on, even if it can be
> translated to "Jan 1st 1970" if it were indeed a valid timestamp.  All
> I'm asking is that ps shows something like "N/A" instead of trying to
> print something that looks like it might be a valid time, but still
> isn't.

System startup process start times appear to not be available to unelevated
processes, so the process default value is zero.
ISTM boot time is a better, more accurate, and useful default for those processes.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019