Public SourceMage Discussion List

[Damien Mascord <tusker AT tusker.org>]

Hi Seth (et al),

One way of doing it would be to have a queue type system, so you have a 
"hashtable" of sorts (or just a multi dimensional array), which you 
populate with the status events as they come in.  (I'm not a bash 
programmer, so I'm not sure how easy this would be).

Once you have this status table, you could either print this at 
intervals, or have some kind of IPC event model which when a status 
event is populated into the table, it would print that status out.

Something like:

Samba                  [STARTING]
.
SSH                     [STARTING]
.
Samba                   [    OK     ]
.
.
.
SSH                      [   FAIL   ]

To make sure things don't get printed over each other, perhaps you can 
have a "locking" mechinism, ie...

echo() {
   if [lock -eq "true" ] {
             # somehow wait
   }
    echo $1
}

(As you can see I don't know my bash well enough).

Another possible way would be to use some kind of ncurses programming, 
so that you can play around with the screen co-ordinates a bit more 
cleanly...   so maybe have a list of services currently in action... and 
then pop them off the screen as they start successfully.... ie:

To start with:

SSH             [STARTING]
SAMBA      [STARTING]
OTHER        [ FAIL]

And after a while show something like

SSH   [ OK   ]
SAMBA [STARTING]
OTHER [ FAIL ]


After a delay period, remove the services that start succesfully to 
remove the clutter.

Let me know how crazy you think these ideas are, or whatever :)

Damien





Seth Woolley wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I hope it wasn't moved into test yet.  Oh well, do this to fix:
>
> smgl_functions
> 89a90
>  
>
> > export -f logger_func
> >    
> 132a134
>  
>
> > export -f print_status
> >    
>
> or wait for the next tarballing.
>
> the reason why it prints success four times is because the init script was
> buggy to begin with.  The new format only shows you how buggy the old
> script is because it doesn't line-up-print-status four times in a row
> which is unneeded status printing.  I'm open to suggestions for a better
> way to print paralleled status.  In parallel init, you can't just print
> [  OK  ] on the same line due to the fact that you don't know what the OK
> was for if things can run in parallel.
>
> I suppose I could check for sequential init, but since the move up print
> status is also printing anyways, I don't see how it can be faster.
> Yes, prepending with 'init.d: ' may be overkill, so I removed that now,
> and scripts have color anyways, so you should know if it came from init.d.
>
> Now, it might be slower because of the system logger code (that was in
> there before though), but for good measure, I made it optional, so there's
> no fork needed for that.
>
> Perhaps success should be silent and only failures should be printed (but
> you wouldn't know if one script hung since you didn't not see success), or
> I could have it remember the last line printed for each script and have
> status go up the number of lines needed, print [   OK   ] on the right
> side of it, then go back down a number of lines, but I would think that
> might be slower, even if it looks pretty.
>
> Another alternative is to have it print [ alsa:   OK   ] on the right
> side.  The way I did it was quite simple, I thought, even though one may
> think it's not as pretty.
>
> The major gotcha so far is that echo used for anything other than printing
> to the screen needs to be "builtin echo" in init scripts since it occurs
> much more often as sent to the screen than as piped through another
> binary.  When running sub-scripts, also, if one doesn't want the echo
> override to inherit, one needs to "(unset -f echo; subscript)" instead of
> running the subscript directly.
>
> Almost all standard init scripts work fine with it though.
>
> Hope that helps.
>
> Seth
>
> On Wed, 8 Oct 2003, Jeremy Kolb wrote:
>
>  
>
> > So my xscreensaver decided to lock up my system (think it's the nvidia
> > drivers), and so I had to reboot.  When I did, I noticed that the output
> > to the init stuff had changed.  While I understand why the change was
> > made it looks kind of ugly to me.  Also, it seems like everything takes
> > longer to load because more text is placed on the screen, and somethings
> > are displayed twice (samba has a "success" a total of four times) and
> > gdm comes up with about twenty of these: "line 10: printstatus not
> > found" or something like that.
> >
> > I understand that this was changed so that we could have services start
> > in parallel, but is there anyway we could have the old behavior stay for
> > the sequential init? Or modify what we have now as it's a little slower
> > and not as pretty?
> >
> > I'm just trying to think this through and I respect the work that's gone
> > into this (don't take this the wrong way!).
> >
> > Jeremy
> >
> > _______________________________________________
> > SM-Discuss mailing list
> > SM-Discuss AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> >
> >    
>
> - --
> Seth Alan Woolley <seth at tautology.org>, SPAM/UCE is unauthorized
> Key id 7BEACC7D = 2978 0BD1 BA48 B671 C1EB 93F7 EDF4 3CDF 7BEA CC7D
> Full Key at seth.tautology.org and pgp.mit.edu. info: www.gnupg.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (FreeBSD)
>
> iD8DBQE/hIiP7fQ833vqzH0RAmBZAJ99vnkiqu/gb8xOb2ZuZdXyjFpkvQCfSLvj
> R8GmNhxLxaRM+/umEBOGTZc=
> =DMW8
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>