I fetch files via SCP from a machine owned by another group. My only access is SCP, I do not have the ability to SSH into their machine. Occasionally, their system is rebooted which causes problems on my end if I don't know about it. I was hoping to SCP some file from their system to find out when it was last booted except I can't seem to find anything appropriate.

I tried copying via scp:

scp -p remoteSys:/proc .

(-p says preserve timestamp) and was told /proc is not a regular file and cannot be copied. When I tried:

scp -p remoteSys:/proc/uptime .

and I got a zero byte file with the current timestamp. I copied:

scp -p remoteSys:/var/log/boot.log .

and I got a zero size file with a date that may or may not be the boot date.

Does anybody have any good suggestions?

Thank you in advance.


3 Answers 3

scp remote:/var/log/wtmp /tmp/remote.wtmp
last -f /tmp/remote.wtmp reboot
  • That helps but it does not quite cut it. I will guess my colleagues on the other system truncated their logs or something. When I run last on the file, I get 'remote.wtmp begins Wed Apr 11 00:50:32 2018' That hints to me that their system was rebooted before last April but I don't know for certain. Jun 6, 2018 at 19:30
  • 1
    @user1683793 but if your local system only has problems when the remote system has been rebooted, surely it only matters to you if that remote system has been rebooted "recently"? (It really doesn't matter that it was rebooted before April 11th, as that's not "recent".)
    – roaima
    Jun 6, 2018 at 22:02
  • On further examination, I will have to agree. All I really care is if that the system has been booted in (say) the last 48 hours. If the wtmp log runs out two months ago, I can be guaranteed that the system has not been rebooted recently and I am done. Thanks. Jun 7, 2018 at 1:11

/proc is created dynamically as it's accessed - which explains the current date timestamp.

The timestamp on boot.log should coincide with the latest boot and all the services coming online.

To me, your current solution seems adequate given your constraints.

  • boot.log is not a good choice. My system was rebooted six days ago, but the mtime on boot.log is in 2015.
    – DopeGhoti
    Jun 6, 2018 at 19:14
  • That's probably due to a skewed clock. ntp (if you're using it) isn't correcting your time until after the boot.log is written.
    – foobar
    Jun 7, 2018 at 18:26
  • I don't believe clock skew would have skewed the time into well before the previous time the system might have been rebooted.
    – DopeGhoti
    Jun 7, 2018 at 18:30
  • It can - especially if power is removed from the system and the hardware clock is unable to maintain itself. This happens routinely when, for instance, a laptop completely loses charge and the CMOS battery is dead. Your hardware clock is reset to whatever the default is in BIOS.
    – foobar
    Jun 7, 2018 at 18:40

If your system uses cronie (most do - and you have access to the directory your crontab is in) you could use a @reboot entry in your crontab and execute a command to create your own log of reboots. If you can do this you could place a crontab file into (normally) /var/spool/cron/ it's not really the correct way to do this but it works (normally you need to invoke crontab -e). If you can do this you need to make sure the file is owned by your user, and that permissions are set to 600 on the file.

For example I placed a file in /var/spool/cron/myusername that had the contents of the following:

@reboot /usr/bin/uptime >> /home/myusername/uptime.log
@reboot /usr/bin/echo "System was rebooted, current reboot date $(/usr/bin/date)" >> /home/myusername/uptime.log

After a reboot the entries are added in /home/myusername/uptime.log:

18:55:06 up 0 min,  0 users,  load average: 0.88, 0.18, 0.06
System was rebooted, current reboot date Wed Jun  6 18:55:06 EDT 2018

I find it odd that you have scp access but no ssh access, would they not grant you ssh access under a non privileged account? It seems to me you should have ssh access as scp runs over ssh so unless you dont have a shell I am a little confused.

  • The system is configured with my username as /bin/nologin This is a case of "Look but don't touch" Jun 7, 2018 at 1:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.