Hello,
pt., 13 sty 2023 o 11:34 Zsolt Kozak <koza...@gmail.com> napisał(a):
> Hello Radosław,
>
> The Bacula Filedaemon was logging these messages. Then after logging
>
> DEBUG:[baculak8s/util/sslserver.py:193 in handle_connection]
> ConnectionServer:Connection from: ('192.168.XX.YY', 10541)
> DEBUG:[baculak8s/util/sslserver.py:145 in gethello] ['Hello',
> 'KubernetesBackup.2023-01-04_21.05.03_10', '410706']
> DEBUG:[baculak8s/util/token.py:57 in check_auth_data] AUTH_DATA:Token:
> xx88M5oggQJuGsPbtD........ohQjeU7PkA4YDbSwBRxTOhT
> DEBUG:[baculak8s/util/token.py:59 in check_auth_data]
> RECV_TOKEN_DATA:Token: xx88M5oggQJuGsPbtD....ohQjeU7PkA4YDbSwBRxTOhT
> DEBUG:[baculak8s/util/sslserver.py:105 in authenticate]
> ConnectionServer:Authenticated
>
> there was some waiting. I guess it was 60 or 120 sec or something. Then
> the daemon was logging the following:
>
> DEBUG:[baculak8s/jobs/job_pod_bacula.py:121 in handle_pod_data_recv]
>> handle_pod_data_recv:EOT
>>
>
This log message means - connection from Bacula Backup POD was closed,
which is unusual when no data was transferred. It could be a timeout which
by default is set to 600 secs (I could extend the `streamrecv` method to
distinguish between closed connection and timeout). You can check if it is
a timeout when it is 600 secs or a time set by a `timeout=xxx` plugin
command parameter.
> DEBUG:[baculak8s/util/sslserver.py:201 in handle_connection]
>> ConnectionServer:Finish - disconnect.
>> DEBUG:[baculak8s/jobs/backup_job.py:85 in __backup_pvcdata]
>> backup_pvcdata:logs recv
>>
>
> I guess there was some "waiting" between the 2 parts and after the timeout
> the logging went on.
>
>
No, in the debug log you should get the following entry showing a proper
transfer:
...
logging.debug('handle_pod_data_recv:D' + str(len(data)))
...
so, you should get at least one entry for successful communication.
Additionally you can check the Backup POD logs to see if there are any
> issues for PVC backup.
>
> The POD logged the following (it was a brand new test today):
>
> 2023-01-13 07:45:48,817:INFO:Bacula Kubernetes backup helper version
> 1.0-rpk. Copyright Copyright (C) 2000-2022 Kern Sibbald
> 2023-01-13 07:45:48,819:INFO:BaculaConnection: mode=backup
> host=kubernetes.server port=9104 token=aR8xp8......KPROZN
> 2023-01-13 07:45:48,819:INFO:BaculaJob:
> KubernetesBackup.2023-01-13_08.45.44_07:411957
> 2023-01-13 07:45:48,820:INFO:Try to connect to: kubernetes.server:9104
> 0/600
> 2023-01-13 07:45:50,041:INFO:Connected.
> 2023-01-13 07:45:50,041:INFO:Authenticated.
>
> And that's all. No more log messages but the back job went failure. :(
>
Could you check the contents of the files: /tmp/baculatar.stdout and
/tmp/baculatar.stderr on Bacula Backup POD and what processes are running
in this Pod (a `df -h` on Pod will be helpful too)?
It is plausible that baculatar cannot read data from PVC and simply hangs
on read call, so a timeout breaks your job.
btw. a token is a random sequence of chars which is valid for a single job
execution only. No need to hide it from the public. :)
best regards
--
Radosław Korzeniewski
rados...@korzeniewski.net
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
