Logging

[Mousikos]

Does something like this actually work?

[SELECT ALL] Code:

./server.sh 2>&1 |tee -a servername/severname_`date +"%Y-%m-%d`.log

Actually work or will it not update the date command every day?

[blueberry]

It won't create more than one file so you'll only get the date when the tee command is executed.

Also, see here.

[RandumKiwi]

Blueberry is correct. It won't create more than one file, so you'll only get the date when the tee command is executed. I know from experience there's a way around this (and it's not the way you probably think it is - because that way, breaks the logging), but I'm not going to explain this method to you.

Why?

Using the actual Linux logging system, would work better, as it has better redundancy built in (i.e. less chance of missing something, etc). Additionally, 'tee' will only append to a file every now-and-then, not straight away

So, I'll be helpful and give you some instructions to do what you want, for an rsyslog based system!


Step 1: You'll notice that everything from AssaultCube is already being logged to /var/log/syslog - so, no need to set up logging, just re-configure it to direct correctly.

Step 2: Open /etc/rsyslog.conf and find this line to change:

[SELECT ALL] Code:

*.*;auth,authpriv.none          -/var/log/syslog

Replace it with the following, which will stop AssaultCube from being logged to /var/log/syslog:

[SELECT ALL] Code:

*.*;auth,authpriv.none;local6.none;      -/var/log/syslog

Step 3: I recommend that above where the "RULES" list is, that you use the following extra commands:

[SELECT ALL] Code:

$ActionResumeRetryCount -1      # Infinite retries on insert-failure.
$ActionQueueType LinkedList     # Memory-based logging, this one uses less memory/more CPU.
$ActionQueueFileName /var/log/emergency_rsyslog # Enables disk-assist, just in case of failure.
$ActionQueueMaxFileSize 250M    # Limit emergency file-size, just in case.
$ActionQueueSaveOnShutdown on   # Save in-memory data if rsyslog shuts down.

Step 4: Below the commands you just copy/pasted, type this to redirect the log to a file, on a per-server basis. Ensure you replace "SERVERTAG" with whatever your server tag is. Remember, you can change this tag using the -N command-line argument:

[SELECT ALL] Code:

if $syslogtag contains 'SERVERTAG' then /path/to/your/logfile.log

Step 4 OPTIONAL: Use the following to just redirect ALL AssaultCube log data to a file:

[SELECT ALL] Code:

if $programname == 'AssaultCube' then /path/to/your/logfile.log

Step 5: Below these, add the following line to stop any further data being logged to syslog:

[SELECT ALL] Code:

&~

Step 6: After all these changes, save the file. Reboot rsyslog:

[SELECT ALL] Code:

service rsyslog restart

Congratulations. You're now logging AssaultCube to a separate file (or files if you did it on a per-server basis) and not clogging your syslog file! Now we talk about logrotate. You should use logrotate (instead of your own script) - but, if you've come this far and don't trust me, I'm not going to explain why you should - go google it.

The following syslog commands will make your files be archived by date in the folder they were found.


Step 7: In this example, I'm going to pretend the config file is named /etc/logassaultcube.conf (replace the filepath in all the examples below if you choose a different name).

[SELECT ALL] Code:

nano -w /etc/logassaultcube.conf

Step 8: Copy/paste the below code into the file, then adjust it according to your needs. If you're not sure what any of these options do, then type 'man logrotate':

[SELECT ALL] Code:

nocompress    # Don't tarball any of the logs.
/path/to/your/logfile.log {
    rotate 36500    # Keep archived logs for 100 years.
    daily            # Rotate daily (not weekly, etc).
    missingok        # Rotate even if file is missing.
    ifempty        # Rotate even if file is empty.
    noolddir        # Don't archive logs into a separate folder.
    dateext        # Archived logs get dated, as per below:
    dateformat -%Y-%m-%d    # NAME-2014-03-09.log
    extension .log            # NAME-2014-03-09.log
    create 0644 root root        # Permissions for archived files.
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

Step 9: Set up a script run your logrotate file. In this example, I'm going to pretend the script file is named /etc/logassaultcube.sh (replace the filepath in all the examples below if you choose a different name).

[SELECT ALL] Code:

nano -w /etc/logassaultcube.sh

Step 10: Copy/paste the below into that script file:

[SELECT ALL] Code:

#!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate -f /etc/logassaultcube.conf

Step 11: Make the script file executable:

[SELECT ALL] Code:

chmod +x /etc/logassaultcube.sh

Step 12: Set up the super-user's cron to run logrotate at 11:59pm daily:

[SELECT ALL] Code:

sudo crontab -e

Step 13: Copy/paste this line into the crontab:

[SELECT ALL] Code:

59 23    * * *    /etc/logassaultcube.sh

... AND, you're done.

[RandumKiwi]

Not even a thank you?

By the way, your logging to a file by date using tee... I REALLY REALLY don't recommend it, but the solution is to set up a once-daily crontab, which copies (not moves) the file somewhere else. Then, to clear the file without interrupting the logging, use 'echo "" > /path/to/file.log'.

[Mousikos]

Sorry, I haven't had a chance to try your solution yet. I usually give a thank you after I try and it works =P

But thank you for supplying one. =P

[+f0r3v3r+]

I have been shown a number of ways to set up logging, but not yet seen anyone put forth a clear set of instructions like this with regards to AssaultCube...
You may be random, but you are an awesome kiwi...
Thank you for putting forth the effort to manifest this here!

[DeafieGamer]

I think this thread should be pinned for all others

[Mousikos]

...

My /etc/rsyslog.conf looks different (I didn't do default configs). The thing seems to be running some Debian-derivative (Ubuntu?). Are you running systemd? My VPS seems to be....

At any rate I'll try this out, and I'll work this out to work with systemd and get it all working and I'll post a systemd guide.

[RandumKiwi]

...

My /etc/rsyslog.conf looks different (I didn't do default configs). The thing seems to be running some Debian-derivative (Ubuntu?). Are you running systemd? My VPS seems to be....

At any rate I'll try this out, and I'll work this out to work with systemd and get it all working and I'll post a systemd guide.

Yes, these instructions are for a debian system with rsyslog installed. But, rsyslog is quite generic, it should not be hard to figure it out for a non-debian system.

[Mousikos]

Okay. So I figured out that I had a stupid way back when. I am not using systemd. However, I think I'm doing something stupidly wrong that I just can't figure out. Help?

Here are a few files I am having trouble with:

rsyslog.conf
http://paste.ubuntu.com/7370792/

/etc/rsyslog.d/20-ufw.conf
http://paste.ubuntu.com/7370797/

/etc/rsyslog.d/50-default.conf
http://paste.ubuntu.com/7370798/

cmdline file:
https://dpaste.de/EO10

[jamz]

...
#AssaultCube
*.*;auth,authpriv.none;local6.none; -var/log/syslog
...

If you have AC running on local6 (the default facility), specifying local6.none to syslog is simply going to cause AC not to be logged by the system at all. You need to then point local6.* to a file, eg.

[SELECT ALL] Code:

# Save AC messages to AC log
local6.*                          -/usr/games/ac/logs/callisto.txt

[RandumKiwi]

...
#AssaultCube
*.*;auth,authpriv.none;local6.none; -var/log/syslog
...

If you have AC running on local6 (the default facility), specifying local6.none to syslog is simply going to cause AC not to be logged by the system at all. You need to then point local6.* to a file, eg.

[SELECT ALL] Code:

# Save AC messages to AC log
local6.*                          -/usr/games/ac/logs/callisto.txt

Incorrect, as he's attempted to make AC direct somewhere later (see "if $syslogtag"... rsyslog's different to normal syslogd).

Stab in the dark, from my own testing. I think that it's your AC config... one small whitespace makes a tonne of difference:
-N MCastle = local#28763
-NMCastle = NCastle

Of course, this all depends on how you're issuing these command line options... so, please, run the server, and give me the output of your log that goes like this (or similar):
logging started: console(INFO), file(DISABLED), syslog(INFO, "AssaultCube[MCastle]", local6), timestamp(DISABLED)

[RandumKiwi]

Also, another stab in the dark. Put your new AC directives *AFTER* the line that states $IncludeConfig /etc/rsyslog.d/*.conf

(some of them may conflict?)

[Mousikos]

...
#AssaultCube
*.*;auth,authpriv.none;local6.none; -var/log/syslog
...

If you have AC running on local6 (the default facility), specifying local6.none to syslog is simply going to cause AC not to be logged by the system at all. You need to then point local6.* to a file, eg.

[SELECT ALL] Code:

# Save AC messages to AC log
local6.*                          -/usr/games/ac/logs/callisto.txt

Incorrect, as he's attempted to make AC direct somewhere later (see "if $syslogtag"... rsyslog's different to normal syslogd).

Stab in the dark, from my own testing. I think that it's your AC config... one small whitespace makes a tonne of difference:
-N MCastle = local#28763
-NMCastle = NCastle

Of course, this all depends on how you're issuing these command line options... so, please, run the server, and give me the output of your log that goes like this (or similar):
logging started: console(INFO), file(DISABLED), syslog(INFO, "AssaultCube[MCastle]", local6), timestamp(DISABLED)

I thought Stef said (on irc) that whitespace doesn't matter anymore?

[SELECT ALL] Code:

reading commandline parameters from file 'config/servercmdline.txt'
reading commandline parameters from file 'config/custom/cmdline/CastleCmdLine.txt'
logging started: console(INFO), file(DISABLED), syslog(VERBOSE, "AssaultCube[MCastle]", local6), timestamp(ENABLED)

---

Also, another stab in the dark. Put your new AC directives *AFTER* the line that states $IncludeConfig /etc/rsyslog.d/*.conf

(some of them may conflict?)

No effect. Here's the weird thing, I'm pretty sure castle.log is being created. But 1) I have to sudo vim to view it, 2) The contents contain 0 lines, 0 bytes (unlike where syslog is actually being logged to)

[jamz]

...see "if $syslogtag"...

Oh, yes.

I thought Stef said (on irc) that whitespace doesn't matter anymore?

It doesn't in servercmdline.txt, but it does if you put the switch in the command line.

[RandumKiwi]

I thought Stef said (on irc) that whitespace doesn't matter anymore?

It doesn't in servercmdline.txt, but it does if you put the switch in the command line.

Of course, this all depends on how you're issuing these command line options...

... and, as such, it's good to see that AC is definitely logging correctly, based on your output above.

No effect. Here's the weird thing, I'm pretty sure castle.log is being created. But 1) I have to sudo vim to view it, 2) The contents contain 0 lines, 0 bytes (unlike where syslog is actually being logged to)

Note how your cfg has these:
$FileOwner syslog
$FileGroup adm

Are syslog/adm able to write to the directory the logfile is stored in?

P.S: On debian, those settings are root/adm by default.
P.P.S: You've restarted rsyslog service each time, before you tested, right?
P.P.P.S: For testing, please remove &~
P.P.P.P.S: If all else fails, do it like normal syslog, as mentioned by jamz. I've found rsyslog's syntax to be a PITA sometimes (make sure rsyslog is up to date!!!)

[Mousikos]

I thought Stef said (on irc) that whitespace doesn't matter anymore?

It doesn't in servercmdline.txt, but it does if you put the switch in the command line.

Of course, this all depends on how you're issuing these command line options...

... and, as such, it's good to see that AC is definitely logging correctly, based on your output above.

No effect. Here's the weird thing, I'm pretty sure castle.log is being created. But 1) I have to sudo vim to view it, 2) The contents contain 0 lines, 0 bytes (unlike where syslog is actually being logged to)

Note how your cfg has these:
$FileOwner syslog
$FileGroup adm

Are syslog/adm able to write to the directory the logfile is stored in?

P.S: On debian, those settings are root/adm by default.
P.P.S: You've restarted rsyslog service each time, before you tested, right?
P.P.P.S: For testing, please remove &~
P.P.P.P.S: If all else fails, do it like normal syslog, as mentioned by jamz. I've found rsyslog's syntax to be a PITA sometimes (make sure rsyslog is up to date!!!)

Sorry I injured my palms today so using my laptop will hurt so I'm taking a break but I have to double check.
PS: Seems to be the same on Ubuntu
PPS: Yes.
PPPS: Tried it.
PPPPS: Updated today just in case. Didn't fix anything.

[RandumKiwi]

PS: Seems to be the same on Ubuntu

Line #42 of http://paste.ubuntu.com/7370792/ says otherwise.