fw logswitch fails to create file

[Youngy]

Hello all,

Due to a script failing I have just discovered that the fw logswitch
command does not appear to be working as expected.

This is on a win2k Checkpoint management machine.

By example,

If you type the command fw logswitch blah.txt

you would expect the file blah.txt (containing the log information) to
be created and for the logs to roll.

The logs are rolling but no file called blah.txt is being created at
all.

What is going on?

Thanks

PS please let me know if I need to include more details

[srikrishnak]

I dont see an isuse unless the NT permissions doesnt allow you to write anything on the disk. May be you can check the permissions.

[Youngy]

I am logged onto the management server as the local administrator. I have rights to write to the drive.

No error message occurs at the command prompt at the time of the command running. However no file is produced.

Thanks

[srikrishnak]

Hmm...Have you tried from the GUI to switch the log file n see weather it works or not.

[Youngy]

No I have not.

My understanding is that the GUI only refers to the underlying command. Which would be the same as running it from the command line. At this point in time I have raised a case with Checkpoint who appear to be equaly perplexed by this issue.

Today I tried simply the following:

fw logswitch max

expecting that a file called max would be created (should be created with an *.log extension). This file would be the summation of the log file and three pointer files CP uses to log to before the switch occurs.

What I can see is that four new files are created (1 log files and 3 pointer files) and the old four files cease to be written to. But no file is created called max

[Youngy]

Hi all,

Just thought I would update everyone with what is going on with this case. Well it is still open and the symptoms have not changed.

One thing I found interesting is that I was on a NG wit AI II course last week and half the class had the same symptoms when using the logswitch command as I have occurring in our production systems.

What a bug.............

[Youngy]

Another update for all.

Well Uri from checkpoint has helped look into this for a while now and this is what he found.

From the command line interface doc found here:

http://www.checkpoint.com/support/te.../docs_r55.html

on page 62 it states:

The rename operation fails on Windows if the active log that is being
renamed, is open at the same time that the rename operation is taking
place; however; the Logswitch will succeed and the file will be given
the default name $FWDIR/log/current_time_stamp.log.

The new Log File that is created is given the default name
$FWDIR/log/fw.log. Old Log Files are located in the same directory.

He went on to say that this open state of the file occurs if you have smart tracker open at the time of the logswitch.

Unfortunately in my case with nothing else open I still have the same issue when performing a logswitch. I am suspicious though that this may be caused by symantec rimporter running on this box.

Feel free to add your thoughts.

[Youngy]

More updates.

Uri from checkpoint suggested I run a cpstop and cpstart just before running the logswitch:

Check these results out:

C:\>cpstop
The Check Point SmartView Monitor service is stopping..
The Check Point SmartView Monitor service was stopped successfully.

The Check Point FireWall-1 service is stopping.
The Check Point FireWall-1 service was stopped successfully.

The Check Point SVN Foundation service is stopping..........
The Check Point SVN Foundation service was stopped successfully.


C:\>cpstart

cpstart: Starting product - SVN Foundation

The Check Point SVN Foundation service is starting.
The Check Point SVN Foundation service was started successfully.


cpstart: Starting product - VPN-1

The Check Point FireWall-1 service is starting.
The Check Point FireWall-1 service was started successfully.


cpstart: Starting product - SmartView Monitor

The Check Point SmartView Monitor service is starting.
The Check Point SmartView Monitor service was started successfully.


C:\>fw logswitch paul.log
Log file has been switched to: paul.log

C:\>

Now the cool thing is that it created a file called paul.log which is the same size as the log file was roughly before the logswitch. This is how I expect the command to react and expected outputs:

paul.log
paul.loginitial_ptr
paul.logptr
paul.logaccount_ptr

Now to see what happens when I logswitch without doing a start stop.

Again feel free to add your own experience or thoughts

[Youngy]

This is probably mine final update on this issue:

From the look of it - is seems like the issue is resolved - partly as I still think it is a bit buggy.

Doing a log switch on a windows management could create problems while the current log file is beeing held or is opened exclusively so issuing cprestart releases it and then the log switch is enabled.

Cheers all