-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Kern. (and list)
I fix my config files for solve the problem, thank you for your help
(and for your great program).
But I still receive messages from bacula whith date 12/31/1969. I use
the version 1.37.37 now. What could be ? The date of
Jeronimo Zucco wrote:
Hi, Kern. (and list)
I fix my config files for solve the problem, thank you for your help
(and for your great program).
But I still receive messages from bacula whith date 12/31/1969. I use
the version 1.37.37 now. What could be ? The date of machine is ok.
It's a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Looking other mails, I think then bacula not put the date field on
e-mail, then the mail server put the date 12/31/1969.
If anyone want I send a copy for e-mail, please ask me.
- --
Jeronimo Zucco
LPIC-1 Linux Professional Institute Certified
Jeronimo Zucco wrote:
Stranger that headers have the correct date, but the client (many,
include webmail) cannot interpret the date. Any caracter not recognized
on the field date ?
Follow an header for example:
Return-Path: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Phil, thank you for your help.
The problem ocours whith all machines backup (I do backup for 30 machines).
Phil Stracchino wrote:
Jeronimo Zucco wrote:
Stranger that headers have the correct date, but the client (many,
include webmail) cannot
Jeronimo Zucco wrote:
Looking other mails, I think then bacula not put the date field on
e-mail, then the mail server put the date 12/31/1969.
Ah! That would make sense. A Unix time field of zero would be
interpreted as the epoch, defined as 00:00:00 01/01/1970 UTC. If your
timezone is
On Tuesday 30 August 2005 16:05, Jeronimo Zucco wrote:
Stranger that headers have the correct date, but the client (many,
include webmail) cannot interpret the date. Any caracter not recognized
on the field date ?
I suspect that your clients (webmail) don't understand Portuguese.
Follow an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
No, this happens only for mails from bacula. I test on webmail imp and
thunderbird client.
Kern Sibbald wrote:
On Tuesday 30 August 2005 16:05, Jeronimo Zucco wrote:
Stranger that headers have the correct date, but the client (many,
include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When I save the e-mail, the date are correct, but the e-mail I receive,
become with date 10/28/47... Then the server translate to 12/31/69 (unix
zero date).
Any configuration to bacula to recognize another formats of date?
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yeaah !!! This is a problem!
Then on my script to start bacula, I unset the environment variable with
the command unset LANG before start bacula.
On version 1.36.30, this is not happens.
Thank you Philip and Kern for your help.
Include my name
On Tuesday 30 August 2005 18:21, Jeronimo Zucco wrote:
When I save the e-mail, the date are correct, but the e-mail I receive,
become with date 10/28/47... Then the server translate to 12/31/69 (unix
zero date).
Any configuration to bacula to recognize another formats of date?
I have bacula running today with version 1.37.30, 2 HP autoloaders, whithout
problems.
I upgrade to version 1.37.36 (for tests), and the following error occurs:
bacula-sd: 3302 Autochanger loaded drive 0, result: nothing loaded.
23-Ago 09:27 pan-fd: PanJob.2005-08-23_09.25.22 Fatal error:
On Tuesday 23 August 2005 16:05, Jeronimo Zucco wrote:
I have bacula running today with version 1.37.30, 2 HP autoloaders,
whithout problems.
I upgrade to version 1.37.36 (for tests), and the following error occurs:
bacula-sd: 3302 Autochanger loaded drive 0, result: nothing loaded.
23-Ago
On Tuesday 23 August 2005 16:18, Jeronimo Zucco wrote:
Another problem: the warnings e erros sending by e-mail having the date 30
of december of 1969, with version 1.37.36. :-)
I'm sorry, but if you don't send some sample output and explain the context,
there is zero anyone can do about your
Sorry, follow a description complete for my problems whith 1.37.36 version:
We have 2 autoloaders (both have just one LTO2 drive) connected to one
Intel server. We have being running bacula 1.37.30 without problems so
far. Today we have upgraded to 1.37.36 and start to get this error:
Hello,
Well, the first thing that I see is that you are using an autochanger but have
not defined an Autochanger resource in the SD. Under 1.37.30, this might
have continued to work as it did in 1.36, because the new autochanger code
was only partially implemented. In 1.37.36, you *must* use
16 matches
Mail list logo