Hi Sami, > > The last(1) is pretty simple tool. It can and will display information > tracked in utmp(5) data. > > http://man7.org/linux/man-pages/man5/utmp.5.html Thanks for the information. > > The utmp data is stored over many many reboots, that might stay around for > years. Notice that changing utmp(5) is probably not the easiest thing to Yes, staying around for years with an entry for each boot would be desirable. > achieve. That format is part of POSIX. Assuming standards are changed then > update to various libc implementations is needed as well. > > Alternatively some sort of extented-utmp format could be created to avoid > standardization work, but getting that to adopted might be hard. While utmp > has it's flaws it is not exactly broken. In short while I'm not strictly > against better reboot reason tracking I am a somewhat doubtful how feasible > this work is. OK, this makes sense. I might do something simple for our use case. > > That said what is that memtool? I have never noticed it before. By glance > it looks a little like abandonware. Maybe it could be get a home in > util-linux if a tool like that is found to be useful, and old maintainer > does not mind. I'm not sure what the current state is, but it's included in the latest debian: https://packages.debian.org/buster/memtool It's a very simple (if not dangerous) tool to r/w /dev/mem. But it's very handy for spying on memory mapped I/O registers like in this case. I guess adding an interface isn't any worse than /dev/mem directly, but it still might not be desirable to have it on every system? -Paul
