Shannon Dealy <de...@deatech.com> writes:
>> At least at the time that you issued the "kill" command, mount.s3ql was
>> busy doing the SSL handshake with the remote server, so while it looked
>> like it was hanging, it was probably waiting for the remote server.
>
> It had been waiting a very long time, though I don't remember exactly,
> for this case. I have limited the cache to 1GB so I don't have to
> wait too long if I need to kill a backup, pack up the computer and
> leave. Because of this, I know from past experience the maximum amount
> of time it takes to flush the cache and unmount using this network. I
> figure it is dead if the network has remained up, but network and cpu
> load for this process are minimal to zero and it has taken more than
> twice as long as it should for the unmount. In this case it should be
> done in 15 to 20 minutes max, so figure it had been at least twice
> that. Sorry I don't have a better answer. If you have a suggestion
> for a better way to tell if the filesystem is hung, it would be
> helpful. On one occasion I let a hung system sit for hours to see if
> it would recover (it didn't)
The only truly reliable way is to generate a stacktrace (as you've done)
and check if any threads are blocked in a read/recv/write/send
syscall. If not, the file system hangs. If they are, then it's waiting
for the remote server.
Unfortunately S3QL's TCP timeout setting only applies after the SSL
handshake, so the handshake can last as long as the Linux TCP stack
allows...
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
