[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] last?
On Mon, Dec 11, 2000 at 07:59:35PM +0100, Tomas Berndtsson wrote:
> Andreas Schwab <email@example.com> writes:
> > Maurits van de Kamp <firstname.lastname@example.org> writes:
> > |> 1. Shouldn't utmp be in /var or /var/tmp/ or something similar? :)
> > On Linux, it is in /var/run.
> Doesn't `last' use wtmp? On Linux, wtmp is in /var/log.
> utmp contains currently logged in sessions, and wtmp contains the
> history or logins, logouts and system reboots..
And there is currently some confusion with utmp/wtmp.
These logging facilities were (IMHO) more or less broken in older MiNT
systems (like KGMD). The file format didn't allow to store the
information that was needed for modern interfaces to these
facilities. Furthermore the location of both files was non-standard (with
respect to the filesystem hierarchy standard FHS).
As a consequence I have changed the MiNTLib (for Noah: MiNT's libc) to
support utmp/wtmp handling in exactly the same manner that Linux
does (I think the Linux interface is pretty standard, hope so, at
least). But in the absence of a shared libc (all programs are statically
linked in MiNT) these changes will only show an effect after recompilation
of the programs that read/write entries in these files.
Hence some programs log in the new files (at the new locations in the new
format), others still follow the old ways (notably TosWin). Besides, the
utmp file must be initialized by the init daemon. The one that is shipped
with KGMD is out of date and a new one still waits to be finished. A
system V compatible init suite is available on Sparemint but in the
current state it is plain crap and non functional (I can say that because
I am the author ...).
This confusion is mostly my fault because I had introduced these
incompatible changes too early in the MiNTLib, hoping that I would be able
to provide the missing parts in reasonable time, thus allowing a complete
migration to the new standards. Unfortunately it turned out that I wasn't
able to do so because my hardware wreaked havoc and the replacement I
have got has technical problems.
A temporary solution: A daemon that scans the old files for changes and
updates the new files accordingly. This daemon needs to be written
though. AFAIR the GNU libc has a similar tool.
BTW, the MiNTLib knows some defines that allow you to use the old
utmp/wtmp interface in your own programs if you feel it is better to stick
with them for a while.