Re: init scripts problems ?

"Also sprach denis bonnenfant:"
> just some other (useful?) infos :

I'm afraid it's too confused - one needs very tightly conrolled data to
be able to learn anything.

> i just started 2 enbd links just by rebooting the client, so it starts
> automatically via cstatd,

I don't think it should .. cstatd is used to tell the client that the
server has rebooted (not the client). The server contacts it on a server
reboot.

> and the result was quite strange (there is no
> md involved here) :

> first everything semmed ok. But, after 30 seconds, there was errors, and client is blocked again :
> 
> ps axf opid,wchan:20,state,cmd  :
> 
>   3004 -                    D [enbd-client]
>   3005 -                    D [enbd-client]

Well, I don't know what those are. They're probbaly the problem! If
they are having trouble, they may be holding the block device lock,
and stopping everything else.


>   3009 -                    S enbd-client se3-croise 12360 -i B-2 -e -n 2 -m -b 512 /dev/ndb
>   3013 sync_page            D  \_ enbd-client se3-croise 12360 -i B-2 -e -n 2 -m -b 512 /dev/ndb
>   3014 -                    D  \_ enbd-client se3-croise 12360 -i B-2 -e -n 2 -m -b 512 /dev/ndb
>   3010 -                    S enbd-client se3-croise 12355 -i A-2 -e -n 2 -m -b 512 /dev/nda
>   3011 sync_page            D  \_ enbd-client se3-croise 12355 -i A-2 -e -n 2 -m -b 512 /dev/nda
>   3012 -                    D  \_ enbd-client se3-croise 12355 -i A-2 -e -n 2 -m -b 512 /dev/nda

These look like what you started. They're blocked - at least the slaves
are. I would guess that the kernel block device semaphore is simply
taken.

> ENBD #3814[2]: print_slot_pids device ndb1 has pid 0
> ENBD #3814[3]: print_slot_pids device ndb2 has pid 3004
> ENBD #876[2]: enbd_open DISK CHECK wanted in open on device nda
> ENBD #4631[2]: enbd_media_changed MEDIA CHANGED called
> ENBD #876[3]: enbd_open DISK CHECK wanted in open on device ndb
> ENBD #4631[3]: enbd_media_changed MEDIA CHANGED called
> ENBD #3626[1]: enbd_wait_on_ioctl_timeout remote ioctl timed out (-1 remaining)

Well, the server did not answer.

> ENBD #3710[1]: do_enbd_remote_ioctl timed out remote ioctl cfb8d618 lost
> ENBD #3626[2]: enbd_wait_on_ioctl_timeout remote ioctl timed out (-1 remaining)
> ENBD #3710[2]: do_enbd_remote_ioctl timed out remote ioctl cfb8d45c lost
> ENBD #1092[0]: enbd_error error out req cfb8d618 from slot 0!
> ENBD #1098[0]: enbd_error erroring and putting ioctl req cfb8d618
> ENBD #1092[1]: enbd_error error out req cfb8d45c from slot 1!
> ENBD #1098[1]: enbd_error erroring and putting ioctl req cfb8d45c
> ENBD #3626[3]: enbd_wait_on_ioctl_timeout remote ioctl timed out (-1 remaining)
> ENBD #3715[0]: do_enbd_remote_ioctl remote ioctl cf667868 found on dev queue
> ENBD #3735[0]: do_enbd_remote_ioctl timed out remote ioctl cf667868 cleaned up
> ENBD #4656[0]: enbd_media_changed REMOTE CHECK remote is down!
> ENBD #4735[0]: enbd_revalidate REVALIDATE called on nda
> ENBD #4767[0]: enbd_revalidate set VALID on nda
> ENBD #4735[1]: enbd_revalidate REVALIDATE called on nda
>   nda:remote ioctl timed out (-1 remaining)
> ENBD #3715[1]: do_enbd_remote_ioctl remote ioctl cf6670e4 found on dev queue
> ENBD #3735[1]: do_enbd_remote_ioctl timed out remote ioctl cf6670e4 cleaned up
> ENBD #4656[1]: enbd_media_changed REMOTE CHECK remote is down!
> ENBD #4735[2]: enbd_revalidate REVALIDATE called on ndb
> ENBD #4767[1]: enbd_revalidate set VALID on ndb
> ENBD #4735[3]: enbd_revalidate REVALIDATE called on ndb

They're clear that they can't contact the remote server. At least
something can't.

> echo 0 solves the problem :
> 
>   3009 -                    S enbd-client se3-croise 12360 -i B-2 -e -n 2 -m -b 512 /dev/ndb
>   3013 enbd_get_req         S  \_ enbd-client se3-croise 12360 -i B-2 -e -n 2 -m -b 512 /dev/ndb
>   3014 enbd_get_req         S  \_ enbd-client se3-croise 12360 -i B-2 -e -n 2 -m -b 512 /dev/ndb
>   3010 -                    S enbd-client se3-croise 12355 -i A-2 -e -n 2 -m -b 512 /dev/nda
>   3011 enbd_get_req         S  \_ enbd-client se3-croise 12355 -i A-2 -e -n 2 -m -b 512 /dev/nda
>   3012 enbd_get_req         S  \_ enbd-client se3-croise 12355 -i A-2 -e -n 2 -m -b 512 /dev/nda

So those two rogue clients have disappeared. I would suspect that they
were two dying clients unable to die fully. Do you know where they came
from? It looks like you had two clients running, and then you started
two more, and the first two wouldn't die properly.

Take the tasklets patch out and see if that is really the problem.

Peter