strange zipped .gz logs in console

Those .gz logs are the product of the "unix maintenance scripts". It is normal to see them if the scripts run. The system.log is not readable in a non-admin account, only the root user or an admin user can read the system.log.

The maintenance scripts have probably not run on your powerbook. As I said in my previous post only the root user or an admin user can read the system.log. Changing the file mode on the system.log could compromise your computer. Log in as an admin user to view the log.

If this is not meant to be possible, has something been corrupted?

Well, somehow thru your interaction, the file permissions have been altered on the system.log. Permissions on files can vary. Log files should have limited access to non-admin users. You can use the Repair Permissions function of Disk Utility to set the permissions on your system files to Apple's default settings.

Naj

i've always been able to read the system log from my non-admin account on my powerbook

You will help Mark (and the rest of us) to help you better if you do the following on both your computers so we can see what is happening:

Open the Terminal (from /Applications/Utilities) and copy and paste the following into the Terminal window, one line at a time, with a return after each line:

id
ls -l /var/log/sys*

Then copy and paste all the output from Terminal, including the commands, identifying which computer it comes from.

Naj

OK, it's simple really. On your PowerBook, "Read" permission is set for "Other" for the system.log, but this is not set on the mini.

If you had run "Repair Permissions" on both machines, this should not be the case. This is the "correct" output from that command when permissions are correct as set by Repair Permissions:
<pre>

ibook:/var/log michaelc$ ls -l /var/log/sys*
-rw-r----- 1 root admin 246 Jul 6 18:35 /var/log/system.log
-rw-r----- 1 root admin 758 Jul 6 18:17 /var/log/system.log.0.gz
-rw-r----- 1 root admin 1466 Jul 5 23:15 /var/log/system.log.1.gz
-rw-r----- 1 root admin 1994 Jul 4 23:59 /var/log/system.log.2.gz
-rw-r----- 1 root admin 6544 Jul 3 23:13 /var/log/system.log.3.gz
-rw-r----- 1 root admin 7301 Jun 27 19:27 /var/log/system.log.4.gz
-rw-r----- 1 root admin 2468 Jun 14 14:30 /var/log/system.log.5.gz
-rw-r----- 1 root admin 920 Jun 10 19:06 /var/log/system.log.6.gz
-rw-r----- 1 root admin 2105 Jun 10 00:06 /var/log/system.log.7.gz

</pre>So that explains the discrepancy.

As to why you are unable to run the maintenance tasks on your PowerBook, I'm not so sure. First try this command on both machines:

ls -ld /var/log

and see if you get the following output: <pre>

ibook:~ michaelc$ ls -ld /var/log
drwxr-xr-x 72 root wheel 2448 Jul 6 18:17 /var/log

</pre>(Obviously the numbers and dates may be different). Let us know what you get.

Then Repair Permissions on both machines and rerun all the "ls" commands to see how the permissions look now. I'm particularly interested in (a) whether the "Read" permission for "Other" disappears, and (b) whether that "wheel" group you have listed turns to "admin".

Then, let's force a rotation of your system.log on the PowerBook only:

sudo periodic daily

Press return and you will be prompted for your password. This is not echoed for security reasons: just type it and press return.

If you haven't used 'sudo' before, you will receive a little lecture before being prompted for the password. Read it and continue 🙂

When it's done, which won't take long at all, try the

ls -l /var/log/sys*

command again (only on the PowerBook) and let us know what it now says.

Naj

Ooops! Too late for the edit button!

You will need to log on as an 'admin' user to Repair Permissions and to use 'sudo'
to run the maintenance tasks. The password you supply for 'sudo' is the admin password.

Naj

Am i at all on the right track??

Yes 🙂

1. The discrepancy is the powerbook has a read permission for 'other' — correct
2. I only have one system log on the powerbook because my unix maintenance task hasn't run — it looks that way

Well I have repaired permissions on both machines and the results are the same as before

It is possible that Repair Permissions wouldn't affect these logs: About Disk Utility's Repair Disk Permissions feature says:

Also, certain files whose permissions can be changed during normal usage without affecting their function are intentionally not checked.

In fact, there is nothing in the Receipts folder to set the 'system.log' permissions. These are set on rotation by the daily maintenance to be owner root, group admin and permissions rw-r-----.

However, the Receipts does contain the information to set the ownership and permissions of the /var/log directory, so the two ls -ld /var/log commands should give the same results as mine.

As for the powerbook not running the maintenance, is it possible that it is because I always switch it off after I use it?

This would certainly make it not run as often as intended, but it should eventually get run. Look at my post above to see when mine were run recently. The two today are because I did one manually. But you'll also see some gaps — my machine sleeps when not in use, so the maintenance will run at some time after it wakes. But I was away a couple of times, so the machine never woke, hence the gaps.

I assume you didn't try logging into an admin account and rotating the log?

Hi Michael,

In fact, there is nothing in the Receipts folder to set the 'system.log' permissions.

On my Panther machine, I get:

lsbom /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom | grep system.log
./private/var/log/system.log 100640 0/80 0 4294967295

Another Tiger difference?

Hi Mark

Another Tiger difference?

It seems so! Just to be certain I copied and pasted your command, and as expected got nothing.

I had done it differently, not relying on it being in the BaseSystem package, and looked for everything that mentioned "/private/var/log". Some log files showed up in BaseSystem.pkg, and some others in Essentials.pkg. But no system.log anywhere!