Logging When a Computer is Powered On
I want to know when each computer in the house network was last powered on. One reason is to keep systems updated that usually are powered off. Another is simple curiosity — when was a system last powered on and used?
There are more than two dozen systems in the network, but I did not want or need to monitor all of them. House network computers include vintage systems, test systems, and virtual machine (VMs). Several systems are multi-boot, hence the number of systems.
Something simple to record a “This system was powered on” event. Nothing fancy.
Many people might suggest a cron job, a shell script, and ping tests.
Similarly, there are dedicated network monitoring systems, but such software is overkill for a simple note that a system was powered on. At the core, many network monitoring systems are glorified wrappers to the ping command.
Most of the systems are powered off much of the time. Not quite grasping in the dark, but flooding the network with continual pings for systems that usually are unavailable seems — clumsy.
A more common sense approach is recording information from each respective computer after powering on rather than have an external system continually probing.
Throwing proverbial sand in the gears is a ping test will not find systems with no traditional network connection. For example, VMs using NAT rather than bridged networking. With NAT a VM can access external files through shared folders on the host system. Shared folders are a form of networking within the virtual system framework, but a ping test will not find these systems because they are not on a traditional network subnet.
One thought is all physical systems in the house network sync the system clock to a local house network NTP server. VMs could do this too but commonly a clock sync is unnecessary because the system clock is derived from the host system. While a clock sync would not meaningfully sync or harm a VM clock, such a single shot network connection could announce the system is powered on.
That clock sync is a real-time but short one-time network connection. I found no information anywhere that the NTP logs track any such connections. Monitoring time syncs falls short of the goal because UDP is used. There is no persistent connection to monitor.
An iptables rule to monitor port 123 (NTP) might succeed but again, those VMs using NAT rather than bridged networking cannot be monitored. The VMs using NAT rather than bridged networking are not on a traditional network subnet and cannot sync clocks likes the physical systems.
Other ideas seemed to fall short as well. The nmap command can scan an entire subnet (nmap -sn), but the underlying foundation is the ping command. Same problem as running a ping test cron job or network monitor.
A system could boot and power off in less than a minute. Traditional ping tests through a cron job could miss the event. Usually network monitoring systems have finer time resolutions, as do alternatives to cron, but again that approach seems clumsy.
VM logs could be queried or the respective virtual disk file date stamps could disclose when VMs were powered on, but does not help with physical vintage systems.
Many of the systems use NFS or CIFS to connect to network shares. NFS and Samba logs could be queried. Yet again, this approach does not resolve the challenge of VMs using NAT rather than bridged networking.
Scratch those ideas.
Yet network file sharing gets close to a solution. There is one notable common feature in the house network. A common element with most of the systems is some kind of access to a shared directory, whether through NFS, CIFS, or shared folders.
All I needed was a way to touch a file that a system had powered on.
With Linux systems a one-time logging event is straightforward in rc.local with a shell script snippet. This scheme worked well for the local Linux systems.
That left the Windows systems to resolve.
One speed bump to this logging strategy are “vintage” Windows systems, including Windows for Workgroups (WFWG) 3.11, Windows NT4 Workstation (NT4), and Windows 2000 (W2K). These systems are maintained for vintage computing reasons (hobby!) and not for common production usage. These vintage systems are from an era when scripting was not yet popular and PowerShell did not exist. All that was available in those days were “batch files.”
Another speed bump is some Windows systems are VMs. Some use bridged networking and some use NAT and shared folders.
On Windows systems, both physical and virtual with shared folders, the following command would “touch” a file on a common network share:
hostname > Y:\some\network\share\%COMPUTERNAME%
Except there is no hostname command in WFWG. The hostname is stored in C:\WINDOWS\SYSTEM.INI using the ComputerName key.
Rather than fiddle with the differences in the vintage Windows systems, archaic “batch file” scripting, and trying to parse system information in different locations, for consistency with all Windows systems I manually created a C:\$(hostname -s)text file, where $(hostname -s) is the hard-coded computer name.
The contents of the file on each Windows system uses the hard-coded format of:
$(hostname -s)-$static_ip_address
MS-DOS in those days did not recognize long file names, only being capable of using 8.3 file names. Fortunately the two WFWG systems in the network both have hostnames of 8 characters or less.
I needed a simple “batch file” script in a respective “Startup” folder to copy (using the DOS TYPE command) the contents of the file redirected to a shared directory. The redirected file would receive a new time stamp indicating when the system was powered on.
type c:\$(hostname -s) > Y:\some\network\share\$(hostname -s)
Where $(hostname -s) is hard-coded with the computer name.
On NT4 and W2K systems I could have used the hostname command. I wanted to use a similar method on all Windows systems. I wanted the “touched” files from all systems to have the same content structure.
The sole Windows 10 VM is not bridged to the house network and uses a single shared folder. Unlike the vintage Windows systems using CIFS and drive mapping, that shared folder is not mapped explicitly to a “drive letter.” The final script looked like this:
type c:\$(hostname -s) > \\VBOXSVR\some\network\share\%COMPUTERNAME%
Unlike the Linux systems, all of the Windows systems require a user account login to launch the simple “batch file” script. Starting with W2K there is a task scheduler that could launch a process without logging in, but NT4 and WFWG do not have that tool. The NT4 system has the Norton Utilities installed that came with a program scheduler, but as far as I can tell and remember, there is no direct access to the scheduler, which runs only as a utilities related service. Tasks are scheduled through parent tools such as the disk doctor and anti-virus.
Similarly, there is no networking in WFWG until the desktop is launched, through which the TCP/IP networking protocols are initialized.
While being required to log in is not ideal, this is okay because as vintage systems none of them get powered on unless they are going to be used in some kind of hobby manner.
All of the desired network systems now have a way to record when they powered on. Important is the method used is consistent among Linux systems as well as Windows systems.
A new shell script and weekly email inform me when systems were last powered on without needing to manually browse the respective “log” directory.
No complex network monitoring systems. No ping probing or flooding. No cron jobs. No guessing when a system might have been powered on.
Not a traditional “log” but “touched” files. Something simple to record a “This system was powered on” event. Nothing fancy.
Posted: Category: Usability Tagged: General
Next: No Router Redux
Previous: Ping by Name — Unknown Host