Re: launched by rungetty bash breaks terminal input interpretation upon runlevel change

[Dumas Patrice]

On Wed, Dec 05, 2001 at 02:00:50PM -0500, Paul Jarc wrote:
> >> find the record it's supposed to clean up.
> >
> > Yes, but if I am not wrong, init doesn't use the utmp record to find that a
> > process has to be killed, but some information in memory.
> 
> Right; that's for changing runlevels.  But when the process exits on
> its own (e.g., when you log out), init marks the utmp record.  It
> needs the id field to update it correctly.

You are totally right. Thus when there is utmp accounting some programms may
think that some process are alive although they are dead, but init was unable
to mark them as such.
 
> > I checked, it seems that I don't have any utmp accounting, as I have nothing
> > in /var/run and most of the filesystem is read-only (except /tmp and
> > some files/dir linked to /tmp, like /var).
> 
> What do "w" and "who" say?

Absolutely nothing. And a strace shows that it stops after trying some open on
/var/run/utmp (and /var/run/utmpx). 

I've tried to understand why utmp isn't initialized, I think I know why.

I've read the init code related to utmp initialization, it is:
        /*
         *      Initialize /var/run/utmp (only works if /var is on
         *      root and mounted rw)
         */
        (void) close(open(UTMP_FILE, O_WRONLY|O_CREAT|O_TRUNC, 0644));   

But in my case there is no /var/run/ at the time init tries to do it, because
the root filesystem is mounted ro and /var is a symlink to /tmp/var which
doesn't exist at that time... Later in a rc script a ramdisk is mounted on /tmp
and /tmp/var and /tmp/var/run is created. Hum, with / mounted ro, is it really
possible to have easily utmp accounting ? It should be possible if init could
notice that there is a possibility of starting utmp accounting upon re-exec.

Pat

(I still think my problem isn't related to init, but thanks for your responses
and ideas, I am learning a lot)