[Box Backup] Problems with cygwin

[Ken Gregoire]

On Windows 2000 Server, running the .80 client, I have a similar 
problem.  The client trys to connect every few minutes, connects 
properly but no backups happen.  The Exception code is 1/9.  It seems 
that that there is a problem with the client - according to the window 
logs - it seems that it might be that a dll is not be properly 
registered or a dll is missing.  Haven't pursued futher.

Cheers!
Ken


Per Thomsen wrote:

> On 11/29/04 2:33 AM, Ben Summers wrote:
>
>>
>> On 28 Nov 2004, at 23:40, Per Thomsen wrote:
>>
>>> On 11/27/04 9:10 AM, Ben Summers wrote:
>>
>>
>>>
>>>> If a directory is modified on the client, it will request a list 
>>>> of  that directory from the server until it has uploaded the files. 
>>>> This  might mean it's requested once an hour with the default 
>>>> settings, for  up to six hours. Might this be it?
>>>>
>>>> Or if the client is a fileserver, and one of it's clients has a 
>>>> clock  which is wildly out of sync, it might be downloading the 
>>>> directories  all the time. Check the client logs for warnings about 
>>>> huge offsets,  but, say, a 12 hour offset won't provoke the warning 
>>>> but continual  filesystem write activity by that fileserver client 
>>>> will result in more  queries to the server.
>>>>
>>>> But as usual, a look at the logs will give more clarity over 
>>>> what's  happening.
>>>
>>>
>>>
>>> I looked at the logs, and here's what I've found: The two wayward 
>>> clients are connecting every 5 minutes and 10 seconds (+/- 3 
>>> seconds), rather than every hour as their config files dictate.
>>
>>
>>
>> I can't think of any reason for that behaviour.
>>
>>>
>>> Your explanation about the higher transmission rates makes sense, if 
>>> the clients are constantly requesting the directory information from 
>>> the server. The connection takes between 2 and 4 minutes, so there 
>>> is always at least one client connected to the server. Hence the 
>>> constant bandwidth drain.
>>>
>>> I won't have access to the client machines until tomorrow (they are 
>>> at 2 different companies that won't be open until Monday), but I 
>>> will look at the Windows event logs for them to see if I can glean 
>>> any more information from them.
>>>
>>> My suspicion is that one of two things is happening:
>>> 1. There is a bug in the 0.08 cygwin client, which causes this 
>>> behavior. My bandwidth use changed after I installed the 0.08 cygwin 
>>> client. I installed the 0.08h win32 client on a Windows machine 
>>> here, and observed no problems like what I'm seeing with the cygwin 
>>> client. The cygwin client on this machine had done the 
>>> 'every-5-minute' thing before that as well.
>>
>>
>>
>> I have never run the cygwin client. I'm afraid I can't really help on 
>> this. Looking at the logs may show something interesting, and perhaps 
>> someone else who does run it can help?
>
>
> I looked at the logs today, but because bbackupd is running as a 
> Windows Service, reading the logs is decidedly difficult (Windows 
> Gurus: is there a plain text file to read the 'Event Log'?), and I 
> didn't see anything weird. I will start it as a regular process 
> tomorrow, and see if I can get some more information from those logs.
>
> Does anyone else run the cygwin 0.08 client? Are you seeing anything 
> similar?
>
>>
>>
>>>
>>> 2. The new versions of the client somehow has permission problems 
>>> with the /var/bbackupd directory. I will be checking into that 
>>> tomorrow. If bbackupd is unable to touch the 'last_sync_start' file, 
>>> I can see how this can happen. last_sync_start never gets a more 
>>> recent timestamp, and bbackupd will continually try to touch the 
>>> file, and re-connect.
>>
>>
>>
>> These timestamps are for information only. The client does not use 
>> them for timing information. This won't be the problem.
>
>
> OK. That didn't seem to be the problem anyway. The files were properly 
> updated.
>
>>
>>>
>>> I'm going to be switching to the Win32 clients anyway, so this may 
>>> be a moot point for me (if it is cygwin-related), but I wanted to 
>>> make sure that something wasn't being missed.
>>
>>
>>
>> I would like to know why it's doing this, in case it's a problem with 
>> some of the non-cygwin code.
>
>
> OK. I'll see what I find tomorrow.
>
> Thanks,
> Per
>