41

I need to find the last time that the

apt-get update

command was run on my server. How can I determine this information?

Mark Roddy
  • 747
  • 2
  • 10
  • 13

12 Answers12

30

At least in Ubuntu systems there is a file /etc/apt/apt.conf.d/15update-stamp containing:

APT::Update::Post-Invoke-Success {"touch /var/lib/apt/periodic/update-success-stamp 2>/dev/null || true";};

So see if you have /var/lib/apt/periodic/update-success-stamp and if you have it, you can use

stat -c %y /var/lib/apt/periodic/update-success-stamp

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.

Tuomas
  • 705
  • 7
  • 9
  • +1 for including the apt.conf line. On ubuntu 14.04 it seems the file is at `/var/lib/apt/periodic/update-stamp` – GnP Dec 02 '16 at 20:47
  • 2
    On my debian `stat -c %y /var/lib/apt/lists/partial` do the trick. File update-success-stamp doesn't exist. – fcm Sep 05 '20 at 16:06
  • 1
    unfortunately -- this seems to get updated when doing a `apt-get upgrade --dry-run` – m1m1k Nov 03 '21 at 15:14
12

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 :

stat -c %Y /var/cache/apt/
Zulu
  • 109
  • 7
Hans Lambermont
  • 121
  • 1
  • 2
  • Note that package installation may also update the cache directory. This is not a reliable check for `apt-get update` – GnP Dec 02 '16 at 20:37
11

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..

rkthkr
  • 8,503
  • 26
  • 38
  • 2
    As pointed out somewhere else, you may find some files aren't updated and therefore haven't been downloaded again. This is fine if you want to know how up to date your package lists are, but not if you want to know when apt-get update was last run. The former is more likely. – David Pashley Jun 06 '09 at 05:27
4

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.

ls -lt --time-style="long-iso" /var/log/apt | grep -o '\([0-9]\{2,4\}[- ]\)\{3\}[0-9]\{2\}:[0-9]\{2\}' -m 1

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!

  • 1
    Unfortunately not working. In `/var/log/apt` it is also logged when I for example do an `apt-get install some-package`. Actually on Ubuntu it does *not* log something when I do `apt-get update` – Alex Oct 20 '12 at 22:19
  • worked for me, thank you! – m1m1k Nov 03 '21 at 15:13
2

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.

slacy
  • 910
  • 1
  • 9
  • 11
2

Here's a simple one-liner to run an update if it hasn't been run in the last day.

(find /var/lib/apt/periodic/update-success-stamp -mtime +1 | grep update-success-stamp) && (/usr/bin/apt-get update)

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.

1

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.

user658875
  • 11
  • 2
1

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.

Wesley
  • 32,320
  • 9
  • 80
  • 116
Josh Brower
  • 1,659
  • 3
  • 18
  • 29
1
$ ls -l /var/lib/dpkg/lock 
-rw-r----- 1 root root 0 2011-11-16 09:40 /var/lib/dpkg/lock
user104833
  • 11
  • 1
1

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

I extracted these functions from my personal github: https://github.com/gdbtek/ubuntu-cookbooks/blob/master/libraries/util.bash

Nam Nguyen
  • 169
  • 1
  • 5
  • Answer is incomplete. What is `info` and `isEmptyString`? Also, `info` is a poor choice of function name since that is also a command. Other than that, nice solution! – Ronny Andersson Dec 10 '15 at 22:21
  • @RonnyAndersson , all in this lib: https://github.com/gdbtek/ubuntu-cookbooks/blob/master/libraries/util.bash – Nam Nguyen Dec 11 '15 at 00:16
0

/var/log/dpkg.log will keep a history of what was done, but not necessarily which app called dpkg (synaptic, apt-get, etc).

Jonathan
  • 9
  • 1
0

wrap apt-get in a script that first writes a timestamp to a file, and then does the usual work. that way, you can define the timestamp format and location ;)

Sujoy
  • 101
  • 3
  • Sujoy, Wrapping it in a script is not practical if you have hundreds of servers, and you do not wish to maintain yet another script that might cause problems the next time you update your apt-get package. I think the requestor is looking for an answer that makes use of information already existing in his computer. – pdwalker Jan 11 '11 at 14:44