On 9/5/19 6:03 PM, Riepl, Gregor (SWISS TXT) wrote:
>
>>> Wido, makes sense that log4j and logrotate would conflict. Log4j
>>> has its
>>> own rotate functionality.
>>
>
> Note that a few CS log files are not generated by log4j.
> You still need external logrotatation if you don't want them to
> > Wido, makes sense that log4j and logrotate would conflict. Log4j
> > has its
> > own rotate functionality.
>
Note that a few CS log files are not generated by log4j.
You still need external logrotatation if you don't want them to fill up
your disk.
I had this issue with access.log, for exam
On 9/5/19 11:13 AM, Daan Hoogland wrote:
> Wido, makes sense that log4j and logrotate would conflict. Log4j has its
> own rotate functionality.
It does indeed :-)
> I didn't understand before but the binary data is always the beginning of
> the file? Is always nulls?
I found this out yesterda
Wido, makes sense that log4j and logrotate would conflict. Log4j has its
own rotate functionality.
I didn't understand before but the binary data is always the beginning of
the file? Is always nulls?
Op do 5 sep. 2019 09:18 schreef Wei ZHOU :
> Hi Wido,
>
> I saw this issue in a 4.11.3 platform t
Hi Wido,
I saw this issue in a 4.11.3 platform today.
It seems to be caused by file
https://github.com/apache/cloudstack/blob/master/agent/conf/cloudstack-agent.logrotate.in
Maybe the file /etc/logrotate.d/cloudstack-agent is not needed ( in Ubuntu
?).
-Wei
On Thu, 5 Sep 2019 at 08:08, Wido
On 9/3/19 2:55 PM, Daan Hoogland wrote:
> On Tue, Sep 3, 2019 at 2:22 PM Wido den Hollander wrote:
>
>>
>>
>> On 9/3/19 9:57 AM, Daan Hoogland wrote:
>>> Can you find/look at the line before in the log. It is probably the one
>>> containing the hindering data. Or otherwise it *might* be a clue
On Tue, Sep 3, 2019 at 2:22 PM Wido den Hollander wrote:
>
>
> On 9/3/19 9:57 AM, Daan Hoogland wrote:
> > Can you find/look at the line before in the log. It is probably the one
> > containing the hindering data. Or otherwise it *might* be a clue where in
> > the flow it happens.
> >
>
> Do you
On 9/3/19 9:57 AM, Daan Hoogland wrote:
> Can you find/look at the line before in the log. It is probably the one
> containing the hindering data. Or otherwise it *might* be a clue where in
> the flow it happens.
>
Do you have any idea what the easiest way might be?
I checked agent.log.1.gz a
Can you find/look at the line before in the log. It is probably the one
containing the hindering data. Or otherwise it *might* be a clue where in
the flow it happens.
On Tue, Sep 3, 2019 at 8:22 AM Wido den Hollander wrote:
>
>
> On 9/2/19 10:18 PM, Wei ZHOU wrote:
> > Hi Wido,
> >
> > I had sim
On 9/2/19 10:18 PM, Wei ZHOU wrote:
> Hi Wido,
>
> I had similar issue (not agent.log). It is probably caused by one or few>
> lines with special characters.
And I'm trying to figure out what causes it :-)
> "grep -a" should work.
I know, but other tools which analyze the logfile might also
bin1kKK_RS4uR.bin
Description: PGP/MIME version identification
Hi Wido,
I had similar issue (not agent.log). It is probably caused by one or few
lines with special characters.
"grep -a" should work.
-Wei
On Mon, 2 Sep 2019 at 19:35, Wido den Hollander wrote:
> Hi,
>
> I've seen this on multiple occasions with Ubuntu 18.04 (and maybe
> 16.04?) hypervisors
Hi,
I've seen this on multiple occasions with Ubuntu 18.04 (and maybe
16.04?) hypervisors where according to 'grep' the agent.log is a binary
file:
root@n06:~# grep security_group /var/log/cloudstack/agent/agent.log
Binary file /var/log/cloudstack/agent/agent.log matches
root@n06:~#
If I open th
13 matches
Mail list logo
