Hi all,

I'm testing an LTSP server using Slackware-10. It looks good except
that if power is cut to the server (like when a colleague steps on the
switch to the surge protector, like just now), the machine re-boots
but seems to stop at the point where ldconfig is run. At least that's
where the screen output stops. At this point I just re-boot it into
the Slack-10 rescue disk and wait twenty minutes while the software
RAID-1 root partition re-builds (/usr is on hardware RAID-5.) Then I
reboot into the machine and things come up fine.

Is there a way I might be able to find out after the fact what is
going on while the screen is frozen? Or, could I disble the running of
ldconfig at boot to see if things really are stopping there? It
doesn't strike me as being dangerous; once it's screwed down the
server is not going to change very often.

thanks all,

r

Reed Loefgren wrote:

> Is there a way I might be able to find out after the fact what is
> going on while the screen is frozen? Or, could I disble the running of
> ldconfig at boot to see if things really are stopping there? It
> doesn't strike me as being dangerous; once it's screwed down the
> server is not going to change very often.

you can skip running ldconfig at boot, just remember to run it when you add
new libraries, etc. i comment it out, since i never need it running on boot
time. the reason why it may be 'stopping' is because your array's
performance is degraded due to the fact that it's rebuilding. of course, rc
scripts are just that - they're scripts. echo "doing this" and echo "doing
that" in proper places is your best debugging friend.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Reed Loefgren dared to utter,
> I'm testing an LTSP server using Slackware-10.

I've always wanted to do that with Slackware and never found the time.

> if power is cut to the server
> the machine re-boots
> but seems to stop at the point where ldconfig is run. At least that's
> where the screen output stops. At this point I just re-boot it into
> the Slack-10 rescue disk and wait twenty minutes while the software
> RAID-1 root partition re-builds (/usr is on hardware RAID-5.) Then I
> reboot into the machine and things come up fine.

Almost certainly there is some problem with your RAID arrays. I would
doubt the RAID-5 hardware array would give you fits, but the software
RAID-1 likely is. For the record, why are you storing / on a software
RAID-1 when you have a hardware RAID-5 controller anyway? That seems
somewhat wasteful to me.

> Is there a way I might be able to find out after the fact what is
> going on while the screen is frozen?

Does the machine lockup hard? Are you able to ping it? Can you log into
the console even though it's blank? Can you ftp or ssh to the machine?

> Or, could I disble the running of
> ldconfig at boot to see if things really are stopping there?

Simple enough.

alan@carrier:~$ grep ldconfig /etc/rc.d/*
/etc/rc.d/rc.M:if [ -x /sbin/ldconfig ]; then
/etc/rc.d/rc.M: echo "Updating shared library links: /sbin/ldconfig"
/etc/rc.d/rc.M: /sbin/ldconfig

I actually recommend picking through the startup scripts and adding
lines like...

echo "A" >> /tmp/boot-log

....in various places. This will give you an idea of where exactly it
stops, if at all.

> It
> doesn't strike me as being dangerous; once it's screwed down the
> server is not going to change very often.

I'd still track it down. I'm willing to bet it has something to do with
your software RAID-1 array, but I'm just guessing.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBWFurlKR45I6cfKARAvn+AJ4uBYXbyiHyTqQLqs7zeo Z70DAhUwCeLjt7
vQ298+8TrwOg+ubYU3x7V1Q=
=RhkT
-----END PGP SIGNATURE-----

NOTE: This message was sent thru a mail2news gateway.
No effort was made to verify the identity of the sender.
--------------------------------------------------------

pgp trash troll delete

Hicks, Alan
188 Shady Dale Dr
Lizella, GA 31052
478-935-8132

+Alan Hicks+ <alan@lizella.network> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In alt.os.linux.slackware, Reed Loefgren dared to utter,
>> I'm testing an LTSP server using Slackware-10.
>
> I've always wanted to do that with Slackware and never found the time.
>
>> if power is cut to the server
>> the machine re-boots
>> but seems to stop at the point where ldconfig is run. At least that's
>> where the screen output stops. At this point I just re-boot it into
>> the Slack-10 rescue disk and wait twenty minutes while the software
>> RAID-1 root partition re-builds (/usr is on hardware RAID-5.) Then I
>> reboot into the machine and things come up fine.
>
> Almost certainly there is some problem with your RAID arrays. I would
> doubt the RAID-5 hardware array would give you fits, but the software
> RAID-1 likely is. For the record, why are you storing / on a software
> RAID-1 when you have a hardware RAID-5 controller anyway? That seems
> somewhat wasteful to me.
>
>> Is there a way I might be able to find out after the fact what is
>> going on while the screen is frozen?
>
> Does the machine lockup hard? Are you able to ping it? Can you log into
> the console even though it's blank? Can you ftp or ssh to the machine?
>
>> Or, could I disble the running of
>> ldconfig at boot to see if things really are stopping there?
>
> Simple enough.
>
> alan@carrier:~$ grep ldconfig /etc/rc.d/*
> /etc/rc.d/rc.M:if [ -x /sbin/ldconfig ]; then
> /etc/rc.d/rc.M: echo "Updating shared library links: /sbin/ldconfig"
> /etc/rc.d/rc.M: /sbin/ldconfig
>
> I actually recommend picking through the startup scripts and adding
> lines like...
>
> echo "A" >> /tmp/boot-log
>
> ...in various places. This will give you an idea of where exactly it
> stops, if at all.
>
>> It
>> doesn't strike me as being dangerous; once it's screwed down the
>> server is not going to change very often.
>
> I'd still track it down. I'm willing to bet it has something to do with
> your software RAID-1 array, but I'm just guessing.
>
> - --
> It is better to hear the rebuke of the wise,
> Than for a man to hear the song of fools.
> Ecclesiastes 7:5
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iD8DBQFBWFurlKR45I6cfKARAvn+AJ4uBYXbyiHyTqQLqs7zeo Z70DAhUwCeLjt7
> vQ298+8TrwOg+ubYU3x7V1Q=
> =RhkT
> -----END PGP SIGNATURE-----

Reed Loefgren wrote:

> Hi all,
>
> I'm testing an LTSP server using Slackware-10. It looks good except
> that if power is cut to the server (like when a colleague steps on the
> switch to the surge protector, like just now), the machine re-boots
> but seems to stop at the point where ldconfig is run. At least that's
> where the screen output stops. At this point I just re-boot it into
> the Slack-10 rescue disk and wait twenty minutes while the software
> RAID-1 root partition re-builds (/usr is on hardware RAID-5.) Then I
> reboot into the machine and things come up fine.
>
> Is there a way I might be able to find out after the fact what is
> going on while the screen is frozen?

IIRC ssh (if enabled) runs before ldconfig. So you can try sshing in and
looking around. If it's truly frozen that won't help, but if something else
is the problem it can be a lifesaver.

> Or, could I disble the running of
> ldconfig at boot to see if things really are stopping there?

Yes, of course. Or, just once, boot "linux 1" or similar. If that screws up
by running rc.M and then shutting it down after (I can't recall off the top
of my head whether slack does this) just boot "linux init=/bin/sh", mount
-o remount /dev/hda1 (root partition), then vi /etc/rc.d/rc.M and comment
out the ldconfig line.

> It
> doesn't strike me as being dangerous; once it's screwed down the
> server is not going to change very often.

It isn't. But it can be a real PITA when you just can't figure out why your
program isn't running. So don't forget you've disabled it.