An apt-get update may not create or update files, it does update the cache directory so we can use that to get the timestamp when the last apt-get update was run :
You could check the Access times on the files in /var/lib/apt/lists which is updated
when you run apt-get update. If apt-get update was run with sudo you should have a
line logged in /var/log/auth.log when it was done..
Don't go from the lock files. Lock files aren't reliable, they tend to move around over time with new Linux releases, and many programs cleanup (remove) lock files when they're done with them.
The following command will get you what you're looking for.
This is two commands in one. The results of the first command filter into the second through the pipe (|) symbol.
In the first command, I'm using "ls" to list the file contents of the /var/log/apt directory, which is the directory that stores the access history logs for apt-get. The "-lt" part is actually two switches. The first "l" switch tells "ls" to list one file per line with detail. The second "t" switch tells "ls" to sort by date and time. "--time-style" forces the date time to display in the format "YYYY-MM-DD HH:MM".
In the "grep" portion of the command, the "-o" switch tells grep to only show the portions of each line that match the regular expression exactly. The regular expression I've used here detects date times that are in the format specified in the "ls" command. You'll also notice the true little piece of magic on the very end of the "grep" command that there's a "-m" switch with the number "1" immediately following. This tells "grep" to stop looking for matches after it finds the first one.
So, in summary, we're listing the apt log file details so we can see the last modified date, we then sort by date and tell grep to pull the first date off the top, which it then returns. That's the last date that apt-get ran.
To play devil's advocate for a moment, however, it's common for Debian platforms like Ubuntu to schedule apt-get as a job that runs regularly. If you're looking for the person at the other end of the apt-get execution, you may actually find a machine. You could always match up access logs with the apt logs to see if any time stamps coincide. It's also possible to look at a user's command history to an extent.
I suspect you can check the last modified times on files /var/cache/apt to figure out when the last updates were applied to the package lists.
I just tested this, and ran "sudo apt-get update" twice in a row, and the dates did not change from their current value, but I suspect this is because there were no new updates to apply, and that the caches are up to date.
It looks for the update-success-stamp file, that is modified more than one day ago. If it finds the file of the right age, then it runs the update. Note: the update-success-stamp file has to exist for this to work.
Synaptic logs a history file (>File > History) , aptitude logs both history in /var/log/aptitude and auto-installed packages in /var/lib/aptitude/pkgstates, so you could check these for latest activity.
I use /var/cache/apt to determine if I need to run apt-get update. By default, if the difference between the current time and cache time of /var/cache/apt is less than 24 hr, I don't need to run apt-get update. The default update interval can be overridden by passing a number to function runAptGetUpdate()
function getLastAptGetUpdate()
{
local aptDate="$(stat -c %Y '/var/cache/apt')"
local nowDate="$(date +'%s')"
echo $((nowDate - aptDate))
}
function runAptGetUpdate()
{
local updateInterval="${1}"
local lastAptGetUpdate="$(getLastAptGetUpdate)"
if [[ "$(isEmptyString "${updateInterval}")" = 'true' ]]
then
# Default To 24 hours
updateInterval="$((24 * 60 * 60))"
fi
if [[ "${lastAptGetUpdate}" -gt "${updateInterval}" ]]
then
info "apt-get update"
apt-get update -m
else
local lastUpdate="$(date -u -d @"${lastAptGetUpdate}" +'%-Hh %-Mm %-Ss')"
info "\nSkip apt-get update because its last run was '${lastUpdate}' ago"
fi
}
Sample Output:
<root@ubuntu><~/ubuntu-cookbooks/libraries>
# runAptGetUpdate
Skip apt-get update because its last run was '0h 37m 43s' ago
At least in Ubuntu systems there is a file /etc/apt/apt.conf.d/15update-stamp containing:
So see if you have /var/lib/apt/periodic/update-success-stamp and if you have it, you can use
command to get the the time of the last "apt-get update" invocation.
And if your system does not have that apt configuration file, you can always add it.
An
apt-get update
may not create or update files, it does update the cache directory so we can use that to get the timestamp when the lastapt-get update
was run :You could check the Access times on the files in /var/lib/apt/lists which is updated when you run apt-get update. If apt-get update was run with sudo you should have a line logged in /var/log/auth.log when it was done..
Don't go from the lock files. Lock files aren't reliable, they tend to move around over time with new Linux releases, and many programs cleanup (remove) lock files when they're done with them.
The following command will get you what you're looking for.
This is two commands in one. The results of the first command filter into the second through the pipe (|) symbol.
In the first command, I'm using "ls" to list the file contents of the /var/log/apt directory, which is the directory that stores the access history logs for apt-get. The "-lt" part is actually two switches. The first "l" switch tells "ls" to list one file per line with detail. The second "t" switch tells "ls" to sort by date and time. "--time-style" forces the date time to display in the format "YYYY-MM-DD HH:MM".
In the "grep" portion of the command, the "-o" switch tells grep to only show the portions of each line that match the regular expression exactly. The regular expression I've used here detects date times that are in the format specified in the "ls" command. You'll also notice the true little piece of magic on the very end of the "grep" command that there's a "-m" switch with the number "1" immediately following. This tells "grep" to stop looking for matches after it finds the first one.
So, in summary, we're listing the apt log file details so we can see the last modified date, we then sort by date and tell grep to pull the first date off the top, which it then returns. That's the last date that apt-get ran.
To play devil's advocate for a moment, however, it's common for Debian platforms like Ubuntu to schedule apt-get as a job that runs regularly. If you're looking for the person at the other end of the apt-get execution, you may actually find a machine. You could always match up access logs with the apt logs to see if any time stamps coincide. It's also possible to look at a user's command history to an extent.
Hope this helps!
I suspect you can check the last modified times on files /var/cache/apt to figure out when the last updates were applied to the package lists.
I just tested this, and ran "sudo apt-get update" twice in a row, and the dates did not change from their current value, but I suspect this is because there were no new updates to apply, and that the caches are up to date.
Here's a simple one-liner to run an update if it hasn't been run in the last day.
It looks for the update-success-stamp file, that is modified more than one day ago. If it finds the file of the right age, then it runs the update. Note: the update-success-stamp file has to exist for this to work.
Synaptic logs a history file (>File > History) , aptitude logs both history in /var/log/aptitude and auto-installed packages in /var/lib/aptitude/pkgstates, so you could check these for latest activity.
I use
/var/cache/apt
to determine if I need to runapt-get update
. By default, if the difference between the current time and cache time of/var/cache/apt
is less than 24 hr, I don't need to runapt-get update
. The default update interval can be overridden by passing a number to functionrunAptGetUpdate()
Sample Output:
I extracted these functions from my personal github: https://github.com/gdbtek/ubuntu-cookbooks/blob/master/libraries/util.bash
As fcm stated in a comment, do a stat on /var/lib/apt/lists/partial. It is the only answer that actually worked for me.