0

Note that the FS is mounted with the relatime option (thus the recent last access time is not shown).

Is there a way to see when an executable (ELF 64-bit LSB executable) was run for the last time?

Using root access. The idea is that a complex production application can run the same exec that currently exists at two different places (pending installation). I just want to ensure that only one of them is run from now on, without interrupting anything (cannot temporarily remove one for instance ; it's 99% sure only one of them is used, but need to be 100% sure).

Déjà vu
  • 626
  • 2
    Do you have audit logging enabled? – muru Jan 07 '22 at 05:09
  • It's not enabled (for performance reason). – Déjà vu Jan 07 '22 at 05:11
  • 1
    How about process accounting (acct)? – Stephen Kitt Jan 07 '22 at 05:38
  • @StephenKitt Great idea, it's not installed yet, but can do it. Does it have a performance impact? (monitoring only 2 execs) – Déjà vu Jan 07 '22 at 06:28
  • If audit logging or process accounting has a performance impact that actually matters to you is not something that anyone could tell you. We don't even know whether a millisecond, minute or day of extra time to your unknown workflow matters to you or whether your system is heavily I/O limited or all running in a VM in RAM. Also, don't you have a development or testing setup that you could test things on, or do you require us to give you zero-error professional suggestions for your unknown production system? – Kusalananda Jan 07 '22 at 06:34
  • 1
    Doesn't relatime update the access time every 24 h or if the old atime was earlier than mtime? That would let you know if the program has been unused for a full day, or you could just touch programfile and then check if the atime gets updated after that. That is of course assuming there's nothing else to read the file. – ilkkachu Jan 07 '22 at 06:45
  • @ilkkachu That is correct and relevant. But the changes were done a couple hours ago, and we don't want to wait for a whole day. – Déjà vu Jan 07 '22 at 06:47
  • 1
    @Déjàvu, hence the thing about touching the file to update mtime. running the program should update atime if it was <= mtime. – ilkkachu Jan 07 '22 at 06:48
  • 1
    Or you could always just chmod a-x and check for errors :P – ilkkachu Jan 07 '22 at 06:49
  • @ilkkachu That is the solution, smart, with no performance impact risk on the system (touch and check access time). Please detail this in the answer section, I'll accept it. – Déjà vu Jan 07 '22 at 06:54
  • @they The specifications given are not really detailed, and a general comment like "we usually notice an impact on the load" could have been mentioned (or nothing), based on this simple problem description. We did actually install it on a test server (acct is great) and did not notice any impact, but someone who used it - as it seems it is the case of Stephen Kitt - could still have an interesting input about that, and this is why the comment was addressed to him. – Déjà vu Jan 07 '22 at 07:06

2 Answers2

2

As far as I recall, relatime updates the access time every 24 h or if the old atime was earlier than or equal to mtime. That would let you know if the program has been unused for a full day; or, if you don't care to wait, run touch programfile and then see if the atime has changed later.

Plain touch would set atime == mtime, but atime gets updated if it's <= mtime, so that's ok. You could also do something like touch -a -d 1999-12-31 instead to change atime without modifying mtime.

Like so:

$ cp /bin/ls .
$ touch ./ls
$ stat ./ls
...
Access: 2022-01-07 13:07:16.640132600 +0200
Modify: 2022-01-07 13:07:16.640132600 +0200
Change: 2022-01-07 13:07:16.640132600 +0200
 Birth: -
$ ./ls > /dev/null
$ stat ./ls
...
Access: 2022-01-07 13:07:57.175525517 +0200
Modify: 2022-01-07 13:07:16.640132600 +0200
Change: 2022-01-07 13:07:16.640132600 +0200
 Birth: -

The access timestamp was updated when the program was run.

Of course, atime would also change if the file is just read. It's probably not that common for binary files to be read just like that, but e.g. a backup tool could do just that. That would make atime useless for this.

But if atime doesn't change, then the file has been neither read nor executed, so it can be used to prove the negative case.

ilkkachu
  • 138,973
  • With the caveat that the most recent access time could have been a plain read, rather than execution. I think you need a system with process accounting enabled to know when particular programs were run... – Toby Speight Jan 17 '22 at 14:23
  • 1
    @TobySpeight, yes, that's true. It still works to prove the negative though, and that just might be enough. At least as long as there isn't e.g. a backup tool running that unconditionally reads everything regurlarly... – ilkkachu Jan 17 '22 at 21:44
  • I'm not that familiar with accounting so I won't be the one to write that answer... – ilkkachu Jan 17 '22 at 21:46
2

You might be in a position to modify the program to make it log when it is used.

Move the program to a new location (e.g. /usr/bin/program.real) and replace it with a short wrapper script that writes the time to a file:

#!/bin/sh
/usr/bin/date -u >/var/log/program.access
exec /usr/bin/program.real "$@"

Obviously, you can add a + argument to format the date string as you would like.

Toby Speight
  • 8,678