Public SourceMage Discussion List

[Paul Mahon <dufflebunk AT dufflebunk.homeip.net>]

I do know a fair ammount of bash, I'll comment:

On Wed, 2003-10-08 at 20:51, Damien Mascord wrote:
> 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).
Arrays in Bash are limited to 1D. However, we do have a nice libhash
which is a hashtable library.

> 
> 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   ]
IPC solutions all require a file system. Init cannot assume that there
is one. Worse, the multi-process ability (aka job control) of bash is
quite limited (compared to say, C) and I've found it buggy, to the point
where I can crash bash in a few lines using job control stuff that
SHOULD work.

> 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
> }
Again, we hit the limitations of Bash and no FS. There's no way to make
a variable change in all sub processes. What would normaly be done is
touch a file in /tmp to notifiy that somethign is being used (or in smgl
use liblock). However, that depends on a FS existing, which is not
always there.

> (As you can see I don't know my bash well enough).
Pfft, anyone can learn bash well enough, it's ideas that matter, not
syntax, and your ideas are fine.

> 
> 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.
That would be a bad idea, not all terminal support ANSI, particularly
the cursor moving around stuff. Of course, they are ususaly the same
ones that don't support colour either. However, the biggest problem with
that is if you have > 25 init tasks that start quickly, you run out of
screen. It wouldn't be necessary to use dialog either (although it would
save time, it needs a FS).

> 
> Let me know how crazy you think these ideas are, or whatever :)
I don't know how the init stuff actualy works, so the no FS limitation
may not be as bad. Good ideas though.

> 
> 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
<snip lots of sigs>
-- 
De mortuis nihil nisi bonum.

What is that funny looking stuff in the attachment?
http://www.technomom.com/cynthia/pgp/

Attachment: signature.asc
Description: This is a digitally signed message part